jcxz

Интересно как Вы это протестировали? Конечно протестировали и ускоренную деградацию материала чипа из-за повышенной температуры в течение N лет? И деградацию зарядов в ячейках флеша? Интересно - какой срок службы вы указали в документации на эти ваши приборы? ;)

Хм.... А если ваш девайс висит на гранитной стене, рядом с которой проехал Абрамс, то получаем тройной удар: гранит + стальной массив + включения обеднённого урана. И тогда совсем кранты :smile3009: Отседова вывод: на подступах к девайсу необходима установка противотанковых ежей. Во-во! Как раз сейчас наш железячник борется с подобным на I2C при воздействии наносекундных помех. И пока безуспешно... :( Мы в своих устройствах всегда в обязательном порядке ставим внешний WDT. Тут косяк тока в том, что если к примеру какая-то задача X зациклилась в некоем цикле без вызова функций ожидания ОС (100% загрузка CPU), а в этот момент контролировалась другая задача Y (имеющая приоритет ниже чем у X), то reset произойдёт, но как проблемная будет обозначена задача Y, а не X.

Если Вы потрудитесь открыть например "Cortex-M3 Technical Reference Manual", то тоже сможете усмотреть. Например в разделе Bus Interface\Write buffer: The processor exports memory attributes on the System bus by the addition of a sideband bus, MEMATTR. Table 14-3 shows the relationship between MEMATTR[0] and HPROT[3:2]. Table 14-3 Memory attributes MEMATTR[0] HPROT[3] HPROT[2] Description 0 0 0 Strongly ordered 0 0 1 Device 0 1 0 L1 cacheable, L2 not cacheable 1 0 0 Invalid 1 0 1 Invalid 1 1 0 Cache WT, allocate on read 0 1 1 Cache WB, allocate on read and write 1 1 1 Cache WB, allocate on read Да и вообще в куче мест, если воспользуетесь поиском по "cache". Например ещё в MPU. PS: К тому-же кеш может быть не в ядре M3, а периферии конкретного МК, например в его External Memory Interface. PPS: А интересно, уважаемый DASM, у вас не возникала мысль "зачем вообще нужны команды типа DMB/DSB если кеша нет"?

Тогда сильно сомневаюсь, что заполнение массива uint_fast8_t в цикле будет быстрее, чем массива u8. Скорее - наоборот. Так как по размеру/кол-ву команд - одинаково, но кэш обратной записи предпочтёт u8. Да и на чтение - аналогично.

Не очень понял что это даст и как оценить - работает или нет программа? Эти счётчики в любой момент времени могут совпадать (in и out) или различаться на >=1. Что по ним можно понять? Если вы про отслеживание их изменений, ну и что? Зависла одна задача, зато другая - нет, она продолжает вызывать эти функции и счётчики меняются. И какой выигрыш? А ещё иногда (хоть и редко) бывают переключения стека, когда с самой глубины вложенности управление передаётся на верх стека, минуя все выходы из функций (типа longjmp()). Ну или try/catch на худой конец. А накладные расходы - огромные, если на каждую функцию... Как памяти, так и быстродействия.... Я делаю так: Есть некая периодическая задача ОС (выполняется циклически раз в неск. сотен мс), она полностью управляет сторожевиком (линией WDI). У неё есть список задач, которые нужно контролировать. Каждая задача представляет из себя собственно цикл обработки сообщений: пока задаче нечем заняться, она ждёт на каком-то объекте синхронизации ОС. Когда задаче откуда-то приваливает работа (из ISR или от другой задачи), то оттуда активируют её объект синхронизации. Выполнив работу, задача опять ждёт на этом объекте. Соответственно - она периодически проходит через функцию ожидания этого объекта. Подобным образом построена работа программ в винде (ожидание сообщения WMSG_..., обработка его и опять ожидание). Так вот, та, периодическая контролирующая задача, перебирает по порядку контролируемые задачи, ставит флажок "а жива-ли сейчас такая-то задача?" (ID задачи), затем активирует объект синхронизации данной задачи и перестаёт дёргать WDI пока стоит этот флажок. Каждая контролируемая задача, выйдя из объекта синхронизации, проверяет не по ней-ли стоит флажок? Если да - сбрасывает его, говоря тем самым: "я жива!". Контролирующая задача, увидев это, дёргает WDI, и переходит к след. подопечной задаче. Если возможны случаи, когда какие-то контролируемые задачи могут быть заняты длительное время обработкой каких-то данных (штатно) и долгое время (близкое или более чем время == период_WDI - период_контролирующей_задачи) не возвращаются к функции проверки флажка "ты жива?", то контролирующая задача, зная это, после установки флажка "ты жива?", продолжает какое-то время дёргать WDI (это время равно разнице между максимальной длительностью занятости задачи и разностью (период_WDI - период_контролирующей_задачи)). Так что - при такой схеме, при зависании одной из задач (не выходе её к своему основному объекту синхронизации) или зависании контролирующей задачи, перестанет дёргаться WDI со всеми вытекающими. Ну и конечно всегда использую механизм ловушек: все необрабатываемые fault-ы и прочие прерывания идут на ловушку, assert-ы, и везде где нужно в программе вызываю программные ловушки по критическим ошибкам. Обработчик ловушек пишет дамп ловушки с регистрами/дампом стека опционально во FRAM, и, в зависимости от режима компиляции (DEBUG/RELEASE), уходит либо (для DEBUG) в trap-режим с периодическим выводом на отладочный лог дампа критической ошибки, либо (для RELEASE) - в reset.

Для локальных переменных, аргументов/результатов функций, используйте всегда нативные типы данных - int/uint. Даже в случае экономии ОЗУ. По занимаемому ОЗУ не будет никакой разницы, но кол-во команд однозначно будет меньше. Для хранения в static памяти, нет большой разницы, но всё-же нативные типы тоже в некоторых случаях требуют меньше команд (или команды короче), так что для одиночных переменных - лучше они. Для массивов лучше элементы меньшей разрядности (и в целях быстродействия операций с ними - тоже лучше). Но это моё имхо, не уверен, но надеюсь на повсеместное наличие write-back caching в M3/M4. Так что здесь предпочтение: u8/s8/u16/s16.

Много-ли можно взять с бедного студента?...

Земля-матушка не принимает ARM7?

Чего именно Вы хотите? Обнаруживать повисание определённых задач (а-ля позадачный вотчдог)?

EDMA3 - вообще очень хороший DMA-контроллер, лучший из всех с которыми я работал в embedded-области. Наиболее богатый по режимам. А раз так, то можно сказать, что он для любой области применения "лучше заточен".

У нас на L137 кардиограф :) В L137 то же самое C674x-ядро.

В точку!

Пока к сожалению занят, но если терпит до осени, то там разгребусь с текущими проектами и смогу предложить свои услуги.

А откуда вы знаете долго или нет? вы же не знаете какими блоками будет писать ТС, и вообще - блоками-ли он будет писать? Он писал как раз про байтовый ввод/вывод. Размер FIFO можно выбрать соответствующим (побольше) и стартовать DMA-транзакцию, как я уже писал, можно раньше, до полного заполнения буфера. У меня был простой символьный вывод, DMA-транзакция стартовала по некоему таймауту (с величиной задержки некритичной для потока) или по заполнению трети буфера. Как оптимально - будет зависеть от протокола обмена, который идёт через этот канал.

У меня был опыт перехода на OMAP-L137 и то особых проблем не было, кроме кучи времени на чтение pdf-ов. А STM32F40x оч. далеко до OMAP-L137....

Не согласен с Вами. Для человека незнакомого с целевой платформой, срок не умножается, а к нему прибавляется какой-то период времени на освоение. Думаю - от пары недель до месяца. И кстати, возможно, опыт работы с SIM900, как раз позволит больше сократить время разработки, чем опыт с данным CPU. Недавно переносил свой базовый проект с LPC на STM32, по ходу дела изучая его. Заняло это около недели. Это с учётом того, что: 1) раньше я вообще не работал с STM32; 2) не использую никаких библиотек, только референс мануал + даташит; 3) в проекте есть базовый минимум: настройка тактирования (используются все источники, PLL), GPIO, отладочный вывод (UART+DMA), uCOS. Т.е. - через неделю уже можно начинать добавлять собсно прикладной функционал для нужной задачи. PS: Да, конечно, GUI в вышеозвученной задаче, мне видится самой времязатратной частью. Возможно :)

Если планируется какой-то стандартный протокол, то можно так. Но если планируется некий самопальный протокол, то лучше так не делать: программисты верха обычно не понимают потребностей встроенного ПО и такого наваяют, что потом весь протокол придётся переделывать. Лучше сперва обговорить протокол обмена с тем, кто будет встроенное ПО писать.

Проблема не с DMA, проблема с их количеством. ТС написал про "кучу UART-ов", а кол-во DMA-каналов у нас сильно ограниченно. И если для передачи ещё можно как-то попытаться расшарить один DMA-канал на неск. UART-ов, то вот для приёма ой.... А ведь в девайсе возможно DMA и для других нужд могут быть нужны. С передачей как раз всё просто. При перехлёсте очевидно же - передавать в два приёма: до конца и с начала. В обработчике завершения DMA проверять "имеются-ли ещё символы в TX-буфере?" и стартовать новый блок если да. Если нет - стоп, сброс флага активности TX.DMA (с опциональным освобождением DMA-канала в пул). Стартовать сам процесс передачи можно либо в каком-то периодическом процессе (периодически проверяя есть-ли байты в TX-FIFO), либо в функции, пишущей в TX-FIFO при достижении некоей water mark. Либо и так и так. Но это при условии, что флаг активности TX.DMA сброшен. Недавно когда я переносил некоторый шаблонный проект с LPC на STM32 (там имелся символьный вывод потока в UART), в LPC DMA для этого не использовался (так как там хватало FIFO). На STM32 пришлось сделать через DMA именно так как и описал. Заняло это около дня.

Можно предложить "ощущение клика" (это называется "тактильный эффект") заменить на писк динамиком. Да ладно! Правда что-ль? :rolleyes: "Жёсткость реалтайма" одинакова хоть с RTOS хоть без при грамотном построении алгоритма. Какая разница - данная процедура обслуживания чего-либо активируется шедулером или как аппаратное/программное прерывание? Без RTOS - разбиваете данные процедуры по уровню приоритета и программируете NVIC. Сложности без RTOS будут только с разделением ресурсов - разделять блокировкой задач нельзя. Нужно по другому строить арбитраж разделяемых ресурсов, без блокировок. Тогда логичнее Вам стать манагером проекта: координировать работу отдельных исполнителей, контролировать, разбивать на этапы и т.д. А то Вы хотите найти ещё одного человека который это ещё будет делать. Будет испорченный телефон - желание главного заказчика пока дойдёт до конечного скажем программера через Вас и нанятого манагера, сильно исказится. Да и сроки принятия решений растянутся... пока всё со всеми согласуешь... Кроме схемотехника и программиста, надо ещё будет подумать о тестировщике. Да, ещё: нужно писать только прошивку устройства или ещё нужно какое-то ПО на PC для работы с этим устройством?

...либо снизить потребление электричества. ЖЕСТЬ :twak:

ну-ну... Это возможно только если хорошо знаком с данным CPU и недавно делал что-то на нём (можно использовать существующие наработки). С нуля, этот этап (со знакомством со всей необходимой периферией) может растянуться до месяца (а может и больше, если потребуется работа с какой-то сложной периферией типа USB или Ethernet). Гарантирую, что я возьмусь если сиё будет подкреплено соответствующе финансово со стороны ТС. :laughing: Любой каприз за деньги Заказчика...

Скажем так - не абсурдно, а вполне возможно. Но однозначно - будет сложнее чем с ОС. А посему вопрос - зачем без? Какой в этом смысл? Если ТС отдаёт и создание ПО на сторону, а не сам будет писать, то какая ему разница - будет там ОС или нет? Макетирование как раз не оттягивает, а ускоряет получение результата (в случае если разработка схемотехники/конструктива и ПО ведётся разными исполнителями), так как можно распараллелить работу. В моей работе (хоть удалённой, хоть по основному месту работы) это обычная практика. Тем более у вас вся периферия стандартная, которую легко смакетировать на существующей отладке. Точку готовности ПО (в объявленном ТС минимуме функционала) можно указать примерно - через 4 мес. после старта. Но к этому времени скорей всего железо ещё не будет готово, но на макете всё уже более-менее будет работать. Я бы взялся, но только за ПО. На схему/конструктив нужен другой человек.

На Вашу задачу STM32 - никак не ложится, ибо очень неудобно в нём использовать UART, а тем более если нужна куча их. Нужно было выбирать что-то другое, где есть нормальное FIFO в UART. А так - на каждый UART Вам придётся выделить в худшем случае по два DMA-канала. Может и не хватить их. А использовать DMA совместно с кольцевым буфером никакой проблемы нет. Зачем там что-то останавливать и перезапускать? Почитайте описание работы DMA. Накопилось у Вас в Вашем кольцевом буфере сколько-то данных - программируете DMA-канал на передачу этого блока. Закончилась DMA-передача блока - программируете на след. блок (если уже накопился). Что тут сложного? С приёмом сложнее. Так как размер входящих данных заранее не известен, то нужно будет программировать на какой-то размер блока, а потом возможно - контролировать кол-во поступивших на данный момент данных и останавливать DMA-приём. Я на STM32 связку UART.RX+DMA не использовал, так что сказать точно про приём не могу.

И что? Вам же сразу предложили этот вариант - гальванически развязывать на стороне UART. Но Вы же сами отказались и сказали что Вам надо развязывать по RS-485, а не по UART. Конечно с помощью этой микросхемы можно развязать: сигналы A/B поступают на MAX13487, далее линии RO/DI на ADUM, далее эти линии на входы UART контроллера. Это, что Вам сразу и предложили. Классическая развязка по UART. А если Вы хотите на ней сделать законченный блок, где с одной стороны выводы A/B и с другой - другие выводы A/B и между ними гальванический барьер, то не получится.

Некорректное замечание. Что с SARAM, что с DARAM задержки у вас могут быть и там и там. Всё зависит от алгоритма. И с SARAM можно буферы - источники/приёмники данных расположить в разных блоках SARAM и не получить никакой задержки. И с DARAM можно в пределах одного такта расположить три доступа к одному блоку DARAM и получить stall. И что? Прочитайте внимательнее что я писал. Если сделать в каждом такте некоего цикла обращение к одному блоку SARAM (а такое возможно с аппаратными циклами DSP), то через N тактов (~500 для C55x) получите сбой DMA. Так как приоритет арбитража для DMA ниже, чем для CPU. Из-за этого мне например приходилось прореживать обращения к памяти за данными, пришедшими с DMA-канала (на C55x).