STM32F407: Ethernet, HAL + Lwip Опции

[k000858]

Всем привет.

Кто изучал драйвер Ethernet'а, идущий с HAL библиотеками (вариант для FreeRTOS: ETHERNET прерывание релизит семафору, которая парсится в отдельной realtime задаче ОС)? Что будет при переполнении указанного количества приёмных буферов? Ошибка DMA обработается, но не будет ли DMA записывать данные дальше (портить память) или это исключено т.к. указывается в размер буферов в настройках DMA?

Имею следующую ситуацию: устройство с Ethernet в параллельной задаче (с меньшим приоритетом чем Ethernet) копирует данные (memcpy функцией) с внутренней FLASH контроллера. При шторме устройства Ethernet трафиком, в какой то раз данные копируются неправильно (временно нарушается адресация флэш - откуда копировать, но до конца процесса восстанавливается), в результате часть данных получается битыми.

Пока подозрения на ошибку в Ethernet драйверах либо LwIP стеке (v1.4.1).

То есть многократное срабатывание прерывания Ethernet + работа задачи по сохранению принятого по Ethernet пакету приводит к сбою работы memcpy

Нехватка памяти для RTOS и его задач контролируется соответствующими отладочными функция FreeRTOS

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

[SasaVitebsk]

Стиль написания, конструирование программы и язык всё же параллельны. А стабильность работы вообще к языку никакого отношения не имеет.
Не в плане спора, но как известно С++ ни в одном источнике, как ясный прозрачный и без проблемный не рассматривается. Ну это же объективно. Просто почитайте мнение специалистов.
В предпоследнем проекте у меня было 411 объектных файлов и более 50 тыс строк текста. Это прибор коммерческого учёта. Я не видел случаев его падения.
Там Си + FreeRTOS + LwIP. Драйвера в несколько уровней.
Например, обращение к флэшке SPI из различных задач - на ура. Мало того, использовались 2 аппаратных буфера поочерёдно для ускорения. В некоторых случаях заливка производилась потоковым способом. Всё работало как часики. При падении напряжения возникало прерывание, сохранялся контекст, сохранялись указатели архивов... Сделал - положить нельзя прибор. Только контрольный выстрел. ))
Меню там экранов штук сто - объектно построено.
Вот подумываю один проект замутить на плюсах. Там просто графика будет приличная. Должно окупиться.
А что вы так взъелись на динамическое выделение памяти? Тоже пробовал в проектах. В одном проете вообще на нём всё построено было. Причём там у меня дырки появлялись. Так я свой сборщик мусора сделал. Тоже претензий не было. Если всё продумать, то всё работает.

[Forger]

В предпоследнем проекте у меня было 411 объектных файлов и более 50 тыс строк текста.

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

Вот подумываю один проект замутить на плюсах.

В чем смысл переходить на плюсы, коли уже выработалась стойкая привычка применять объектные фишки на голом С?
Неужели и вас тоже утомило работать "молотком по стамеске"?

А что вы так взъелись на динамическое выделение памяти?

Все просто - категорически не люблю мотаться по командировкам

Есть у меня испытанный в тестах неплохой диспетчер динамической памяти (TLFS), но пока нет ни одного проекта, где понадобилось применять динамическую память.
Поэтому пока что предпочитаю заложить в проект камень с достаточным объемом памяти (или прикрутить внешнюю), вместо того, чтобы мотаться по командировкам, вылавливая баги.
В моем случае такой подход выгоднее ))

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

[SasaVitebsk]

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

Из сторонних библиотек только LwIP и FreeRTOS. Больше ничего нет. Я HAL не пользуюсь. Из HAL использовал только инициализацию CPU и шин переписанную и Ethernet подправленный.
Строки, естественно считал по своим файлам. Нафига чужое считать.
Проект реально большой. Я 2 года писал. Понятно, что попутно куча другой работы была. Поддержка старых приборов, всякие там сертификации, поездки .. ))

Насчёт плюсов я так скажу. Это надо бы взять какой-нибудь камень ясный... Ну типа того же AVR. Ну чтобы ассемблер был такой, чтобы читался как роман... ))
После чего наваять несколько простых проектов. Компильнуть и посмотреть чё получилось. Поиграться. Ну чтобы ясная картина появилась, во что превращается та хрень, что ты написал.
Вот где на это время взять?

[scifi]

Насчёт плюсов я так скажу. Это надо бы взять какой-нибудь камень ясный... Ну типа того же AVR. Ну чтобы ассемблер был такой, чтобы читался как роман... ))
После чего наваять несколько простых проектов. Компильнуть и посмотреть чё получилось. Поиграться. Ну чтобы ясная картина появилась, во что превращается та хрень, что ты написал.

Это ассемблер головного мозга. Его надо лечить электрошоком.
В машинный код нужно смотреть тогда, когда реально не хватает памяти и/или скорости, то есть раз в год
А иначе не останется времени на отдых. Ну и программы будут писАться по два года