Перейти к содержанию

Философия аппаратного SPI - чем занять МК?


Рекомендуемые сообщения

1 час назад, parovoZZ сказал:

В любом другом случае эффективнее самим опрашивать аппаратный флаг счетчика и самим же его сбрасывать.

Если в программе нет ничего, кроме опроса флага, то эффективнее. В противном случае нет.

 

1 час назад, parovoZZ сказал:

Если UART настолько быстр, что мы не успеваем обработать данные, то надо использовать кольцевой буфер и надеяться на паузы в общении, либо же менять МК. Опять-таки не вижу смысла в использовании флагов, дублирующих аппаратные.

Что-то я не пойму, про какие дублирующие флаги идет речь. Есть у нас тот же UART. Временами по нему прилетают данные которые МК обрабатывает и как-то на них отвечает. Все остальное время он занят другой работой. По приходу данных МК вываливается в прерывание, забирает байт из регистра, кладет его в буфер, сбрасывает счетчик времени ожидания, запускает таймер который будет ждать окончание конца пакета и продолжает делать свою работу. Дальше, если таймер дотикал до определенного времени, значит пакет закончился и можно его обработать. Т.е. нам надо, как минимум, мониторить два флага наличие данных в буфере UART и событие от таймера, время срабатывания которого пара микросекунд. И как это делать без прерываний? Ну и надеяться в написании программ ни на что нельзя, все должно быть четко и структурировано.

Ссылка на комментарий
Поделиться на другие сайты

6 минут назад, BARS_ сказал:

И как это делать без прерываний?

Я где-то писал, что это надо делать без прерываний? Вопрос был про флаги.

Ссылка на комментарий
Поделиться на другие сайты

1 час назад, parovoZZ сказал:

Что мешает точно также опросить аппаратный флаг?

Например то, что в одном прерывании можно выставлять разные флаги. Есть, к примеру, таймер. Тикает пусть раз в 100мс. Прописываем ему счетчики, которые будут досчитывать в разное время. Пусть будет 500мс, 1с, 5с. По счетчикам выставляем флаги, которые будут мониториться в главном цикле и по которым будут выполняться операции некритичные к времени. Или если вернуться к UART, пусть МК принимает большой пакет данных, например от GPS приемника в NMEA формате. Затем он их парсит для получения требуемых параметров. Алгоритм приема будет примерно такой:

  1. Упали в прерывание
  2. Приняли байт
  3. Положили в буфер
  4. Обнулили счетчик времени
  5. Пнули таймер
  6. вышли из прерывания

В конце концов пакет закончится и будет иметь размер байт 100. Таймер дотикает, выставит программный флаг о готовности пакета и вырубится. Как только МК освободится, он увидит флаг и займется парсингом пакета. при этом все другие прерывания останутся активными. А вот если кинуться парсить пакет сразу в прерывании таймера, то прерывания будут заблокированы до конца парсинга (не все, только более с более низким приоритетом). 

Ссылка на комментарий
Поделиться на другие сайты

Сравнительное тестирование аккумуляторов EVE Energy и Samsung типоразмера 18650

Инженеры КОМПЭЛ провели сравнительное тестирование аккумуляторов EVE и Samsung популярного для бытовых и индустриальных применений типоразмера 18650. 

Для теста были выбраны аккумуляторы литий-никельмарганцевой системы: по два образца одного наименования каждого производителя – и протестированы на двух значениях тока разряда: 0,5 А и 2,5 А. Испытания проводились в нормальных условиях на электронной нагрузке EBD-USB от ZKEtech, а зарядка осуществлялась от лабораторного источника питания в режиме CC+CV в соответствии с рекомендациями в даташите на определенную модель. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

да о чем речь) может быть ситуация когда флаг не нужен, может быть когда нужен) может быть когда флага вообще нет)

моет быть когда в схеме нет мк :)

Ссылка на комментарий
Поделиться на другие сайты

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. 

Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств. Подробнее параметры и результаты тестов новой серии PLM по ссылке.

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

3 минуты назад, BARS_ сказал:

Есть, к примеру, таймер. Тикает пусть раз в 100мс. Прописываем ему счетчики, которые будут досчитывать в разное время. Пусть будет 500мс, 1с, 5с.

У счетчика же есть цифровые компараторы? Или есть МК, в которых их нет? К черту такой МК. Выставляем значение, которое нам нужно и всё. А дальше хоть флаг компаратора опрашивай, хоть в прерывание уходи. Зачем усложнять себе жизнь?

Вот у меня работает АЦП, а также есть PCINT прерывание. Когда я ничего не делаю, я либо в IDLE, либо ADC_NOISE. Вот тут мне без доп флагов никак, т.к. обработчики прерываний совершенно пустые. А без них никак - тупо по флангам МК не просыпается. Для флага я использую регистр GPIOR.

 

Ссылка на комментарий
Поделиться на другие сайты

Литиевые батарейки и аккумуляторы от мирового лидера  EVE в Компэл

Компания Компэл, официальный дистрибьютор EVE Energy, бренда №1 по производству химических источников тока (ХИТ) в мире, предлагает продукцию EVE как со склада, так и под заказ. Компания EVE широко известна в странах Европы, Америки и Юго-Восточной Азии уже более 20 лет. Недавно EVE была объявлена поставщиком новых аккумуляторных элементов круглого формата для электрических моделей «нового класса» компании BMW.

Продукция EVE предназначена для самого широкого спектра применений – от бытового до промышленного. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

43 минуты назад, parovoZZ сказал:

У счетчика же есть цифровые компараторы?

При чем тут компараторы (и не компаратор, а регистр сравнения)? Один таймер будет формировать только один клок, а с помощью флагов я могу получить с него хоть десяток. Смысл мне тупо для формирования временных интервалов крутить десяток таймеров?

Изменено пользователем BARS_
Ссылка на комментарий
Поделиться на другие сайты

26 минут назад, BARS_ сказал:

и не компаратор, а регистр сравнения

Output Compare Units, как гласит даташит для младших AVR.

26 минут назад, BARS_ сказал:

крутить десяток таймеров?

Зачем десять? Достаточно одного. Я так с вачдогом забавляюсь, когда надо выдерживать разные периоды времени.

Ссылка на комментарий
Поделиться на другие сайты

2 минуты назад, parovoZZ сказал:

Зачем десять? Достаточно одного. Я так с вачдогом забавляюсь, когда надо выдерживать разные периоды времени.

Менять регистр сравнения таймера не вариант. Все клоки должны идти все время.  И 100мс, и 500мс и любые другие.

Ссылка на комментарий
Поделиться на другие сайты

57 минут назад, BARS_ сказал:

пусть МК принимает большой пакет данных, например от GPS приемника в NMEA формате. Затем он их парсит для получения требуемых параметров. Алгоритм приема будет примерно такой:

Для маломерок типа AVR ваш алгоритм в чистом виде не подойдет. GPS выпихивает слишком много данных, чтобы их все принять в буфер, а потом парсить. Великоват буфер будет, а ОЗУ мало. В конкретном случае с NMEA надо алгоритм модфицировать: в прерывании ждать начала того пакета, который нужен, и затем принимать в буфер уже только его - так буфер будет короче во много раз. Но  это нюансы, конечно.

Если забанить всех, кто набрался смелости думать независимо, здорово будет на форуме - как на кладбище: тишина, птички поют...

Ссылка на комментарий
Поделиться на другие сайты

При чем тут тини вообще? Речь идет про любой МК. Таймеры работают +/- одинаково везде, по крайней мере базовые функции. Речь про то, что один таймер может выставлять флаги для десятка событий. Например:

  • Каждые 100 мс опрос кнопок
  • Каждые 200 мс обновление дисплея, если есть соответствующие данные
  • Каждые 500 мс мигать светодиодом (или толпой светодиодов)
  • Каждую 1с отсылать данные по тому же ЛАН
  • и т.д. и т.п.

Задействовать под каждое событие отдельный таймер как минимум нерационально, поэтому ставятся программные флаги и все. А таймер просто вываливается в прерывание каждые 100 мс и все.

4 минуты назад, ARV сказал:

Для маломерок типа AVR ваш алгоритм в чистом виде не подойдет

Верно, но с ними я уже давно завял в силу их убогости:crazy: Так да, можно ждать нужный пакет, но это не сильно удобно, т.к. начала пакетов очень похожи и проверку заголовка надо делать по 3-4 символам, следующим друг за другом. А на STM я спокойно могу принять пакет размером хоть 1024 байт без ущерба для ОЗУ. 

Ссылка на комментарий
Поделиться на другие сайты

10 часов назад, DrobyshevAlex сказал:

Разве в прерывании аппаратный не сбросится? ну точнее после прерывания?

Смотря о чем вы говорите. Флаг переполнения - НЕ СБРОСИТСЯ, но выставленный этим флагом флаг прерывания - он СБРОСИТСЯ при входе в обработчик прерывания, при этом флаг переполнения не будет тронут.

Поэтому единственное оправдание своих флагов - это удобство написания программы - все флаги в паре регистров, не надо метаться по регистрам периферии в извлечении флагов для проверки.

Учение - изучение правил. Опыт - изучение исключений.

Ссылка на комментарий
Поделиться на другие сайты

1 час назад, Alexeyslav сказал:

флаг прерывания

естественно о нем, речь же была о том зачем ставить свой флаг по прерыванию если есть аппаратный флаг прерывания)

 

Ссылка на комментарий
Поделиться на другие сайты

Так мы же ставим не флаг прерывания, а флаг готовности устройства, вызвавшего прерывание. Этот флаг находится в более удобном месте, чем аппаратный флаг состояния чтобы потом по нему сделать ветвление в основном цикле.

Учение - изучение правил. Опыт - изучение исключений.

Ссылка на комментарий
Поделиться на другие сайты

  • 3 недели спустя...
В 21.01.2019 в 19:51, ARV сказал:

// правильный подход - минимальное ожидание uint8_t spi(uint8_t d){ while(!(SPSR & (1<<UDRE)); uint8_t res = UDR; UDR = d; return res; }

Вот здесь косячокс - если в регистре ничего нет, то и работать не будет.

Ссылка на комментарий
Поделиться на другие сайты

Нет никакого косячка: кода UDR пуст, бит UDRE всегда установлен.

Если забанить всех, кто набрался смелости думать независимо, здорово будет на форуме - как на кладбище: тишина, птички поют...

Ссылка на комментарий
Поделиться на другие сайты

В 10.02.2019 в 09:41, ARV сказал:

Нет никакого косячка: кода UDR пуст, бит UDRE всегда установлен.

Что-то я тупанул. Это же речь про UART/ А тема вроде про SPI.

Ну раз такие дела, то придется UART в качестве SPI погонять)

Изменено пользователем parovoZZ
Ссылка на комментарий
Поделиться на другие сайты

С SPI то же самое. Вероятно, тупанул и я, назвав не тот регистр и флаг, но все идентично. Правда, с точностью до наоборот: если есть флаг - пусто, и можно писать.

	for(uint8_t i=0; i < CNT; i++){
		while(bit_is_clear(SPSR, SPIF));
		SPDR = *data++; 
	}

Вот таким кодом 100 лет пользуюсь - как видите, ждем флаг SPIF, и как встал - пихаем :) Прям по жизни все.

Если забанить всех, кто набрался смелости думать независимо, здорово будет на форуме - как на кладбище: тишина, птички поют...

Ссылка на комментарий
Поделиться на другие сайты

  • 2 месяца спустя...

Хочу вернуться к нашим баранам.

В 13.02.2019 в 13:54, ARV сказал:

ждем флаг SPIF, и как встал - пихаем

В новых тинях

в блоке SPI есть буферы на передачу и прием. То бишь данные вида "команда & байт данных" можно пропихнуть за один присест - команда попадает в буфер и сразу уходит в сдвиговый регистр (если он свободен). Её место на следующем такте занимает байт данных. Далее всё произойдет на автомате. Выходим из функции. И всё в этом алкоритме хорошо, если бы не одно НО! Пин выбора устройства. Есть два варианта - остановить проц и подождать прерывания, после чего "отпустить" устройство. Либо же пойти по своим делам и уже в прерывании поднять ногу. В последнем варианте иметь буферы в SPI не обязательно - можно организовать и в нормальном режиме. Но стоит ли? Уход на прерывание занимает 3 такта. Возврат из него тоже 3 такта. Итого - 6 тактов накладных расходов. Отправить данные, если блок SPI тактируется на максимуме - занимает 16 тактов или 32 в буферном режиме. Вариант с ожиданием в IDLE интересен энергопотреблением. Вариант с прерыванием - быстродействием. Стоит ли игра свеч, ведь вырастают грабли на ровном месте:

1. Необходим какой-то флаг занятости устройства (устройств может быть не одно). Если одно, то можно контролировать флаги SPI. Как правило, выбор устройства означает, что сейчас на линии будет выставлена команда. Если мы "просахатим" "передёр" устройства, то наступит катаклизм.

2. Код получается платформозависимым. Если сейчас у меня платформозависимый только SPI.h (сменил его и с драйверами высшего уровня можно работать на любой другой 8-ми битке), то с прерываниями под каждую платформу придется переписывать не только SPI.h.

3. И совсем не красивый код получается, если мы запрашиваем у устройства какие-то данные. 16 тактов на отправку, 6 тактов накладных расходов = 10 тактов свободных. Стоит ли оно того?

3а. Ну и получается, что аппаратный SPI перед USI каких-то преимуществ не дает. В здравом уме никто искусственно занижать скорости на интерфейсе не будет, а на предельных скоростях USI даёт то же быстродействие.

Ссылка на комментарий
Поделиться на другие сайты

Только что, parovoZZ сказал:

Но стоит ли?

Новые тиньки не изучал, по вашим статьям сложилось впечатление, что прерывание как было по окончанию передачи байта, так и осталось. Оттого и проблемы. А ведь по идее должно быть еще прерывание по опустошению буфера - оно более полезно в данном случае (кстати, для USART как и есть, хоть и буфер всего 1 байт, вроде). То есть напихали в буфер данных на передачу и пошли по делам. Если буфер хотя бы на 4 байта - это уже много тактов, и затраты на обработчик прерывания менее заметны.

Если забанить всех, кто набрался смелости думать независимо, здорово будет на форуме - как на кладбище: тишина, птички поют...

Ссылка на комментарий
Поделиться на другие сайты

4 минуты назад, ARV сказал:

прерывание как было по окончанию передачи байта, так и осталось.

В нормальном режиме так и есть. В буферном режиме также, да не также)) Вектор прерывания один. А вот прерываний уже несколько - по отправке байта (опустошению сдвигового регистра), по опустошению буфера и по приему байта. То бишь в обработчике прерывания необходимо проверять флаги разрешенных прерываний. Всё это не даёт особых преимуществ перед "тупо ждем улет байта".

7 минут назад, ARV сказал:

Если буфер хотя бы на 4 байта - это уже много тактов, и затраты на обработчик прерывания менее заметны.

увы, только 1 байт.

 

Сейчас переписал код под буферный режим и с ожиданием в IDLE до момента, когда можно отпустить устройство. Хоть и работает, но нет лаконичности в коде...

Ссылка на комментарий
Поделиться на другие сайты

Только что, parovoZZ сказал:

Вектор прерывания один. А вот прерываний уже несколько - по отправке байта (опустошению сдвигового регистра), по опустошению буфера и по приему байта.

Чувствуется тлетворное влияние архитекторов Микрочипа :) У них с древних времен повелось источник прерывания поллингом выяснять (если не ошибаюсь). Или разработчикам платят за количество фич. Смысл такого "изобилия" для столь небыстрых микроконтроллеров вообще не понятен. Нет, когда мы SPI гоняем на скорости 100 бод (при тактовой 20 МГц) - вопросов нет :) Но разве кому-то надо работать медленно?!

Если забанить всех, кто набрался смелости думать независимо, здорово будет на форуме - как на кладбище: тишина, птички поют...

Ссылка на комментарий
Поделиться на другие сайты

47 минут назад, ARV сказал:

Смысл такого "изобилия" для столь небыстрых микроконтроллеров вообще не понятен. Нет, когда мы SPI гоняем на скорости 100 бод (при тактовой 20 МГц) - вопросов нет :) Но разве кому-то надо работать медленно?!

Так вот умел бы SPI аппаратно заруливать пином выбора устройства - было бы вопросов меньше. А так или на таймер его вешать или же в прерывании с ним работать.

Ссылка на комментарий
Поделиться на другие сайты

Только что, parovoZZ сказал:

Так вот умел бы SPI аппаратно заруливать пином выбора устройства

Это надо, чтобы искусственный интеллект в нем был :) Как узнать, когда "заруливать" этим пином? Для SD-карты это может быть спустя сотни две байтов, а для какого-нибудь датчика спустя один байт, а дисплею надо шестнадцать... Это известно только программисту, и не является какой-то константой.

Изменено пользователем ARV

Если забанить всех, кто набрался смелости думать независимо, здорово будет на форуме - как на кладбище: тишина, птички поют...

Ссылка на комментарий
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы публикуете как гость. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Ответить в этой теме...

×   Вставлено с форматированием.   Восстановить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

Загрузка...
  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу

×
×
  • Создать...