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]

Посмотрите с чего начиналась тема. Начали гнать на HAL от ST. Что по своей сути это такое? По сути это попытка создания универсальной библиотеки. Более того, в купе с генератором, это попытка создания универсального подхода. С моей точки зрения - он провалился. Хотя куча его использует и счастливы.
Что предлагаете вы? Вы пытаетесь создать туже универсальную библиотеку, с универсальным подходом. Только 2 отличия. 1 - на С++. 2 - вы не ST.
Простите - я лучше стамеской поработаю.
Любая универсальная библиотека будет избыточна. И должна быть избыточна. Потому что универсальность и избыточность это одно и тоже. Меня не напрягает избыточность сама по себе. Камни сейчас обеспечивают - я не парюсь. Но весь мой опыт написания универсальных вещей, говорит что они не нужны. В принципе не нужны. Посмотрите HAL от ST на USART. Пипец. Я даже не представляю приложение куда это можно воткнуть!!! Получается, что для применения этой универсальной вещи потребуется обёртка большая по объёму, чем если бы я с нуля написал неуниверсальный драйвер. Я уже писал по этому поводу. Я делаю 2 уровня дров. Железозависимая часть и железонезависимая. Ну например SPI и ADC. Этот же SPI и DATAFLASH.
USART -> MODBUS. Нижняя часть - это десяток строк. Дрова у меня в проекте занимают 2% по объёму и ещё меньше по времени. Отлаживаются на раз и к ним никогда не возвращаешься.
А остальная часть проекта это как раз то, что я постоянно меняю. Даже если прибор аналогичный.
Я видел несколько попыток создания универсальных платформ. В том числе на плюсах. Ни одна меня не впечатлила.
Возможно вы от своей без ума. Но это не значит, что я был бы счастлив ей пользоваться. Или кто-то другой.

Теперь по поводу динамической памяти. В том проекте, о котором я писал примерно такое построение было... Поступают данные с внешнего интерфейса. Данные поступают в виде команд. Команды разной длины и разного времени жизни. Устройство выполняет команду и удаляет её. Получается, что одна команда могла выполниться и сразу удалялась, а другая выполнялась в течении длительного времени. В результате память дифрагментировалась. Поток команд был очень интенсивный. Объём памяти тогда на контроллере был 64к всего. Под кучу килобайт 30 было отведено. Уже не помню. Были бы проблемы это бы вылезло достаточно быстро. Устройство не выключалось. Работало круглосуточно. Не скажу что мы их много сделали. Ну несколько десятков было.
А вот на плюсах как раз трудноустранимые утечки случаются. Парень писал для нас OPC сервер. На QT4 + VS. Была утечка памяти. Устранил только когда свой QSerialPort написал. Хотя я с той же версией QT+GCC писал прогу удалённого управления прибором и проблем не было. При этом для связи использовали те же классы. Вот такой вот пример.

[Forger]

Что предлагаете вы? Вы пытаетесь создать туже универсальную библиотеку, с универсальным подходом. Только 2 отличия. 1 - на С++. 2 - вы не ST.

Вы нифига ничего не поняли ))

Я пытаюсь донести простую мысль, что грамотное построение (своевременное проектирование) проекта значительно упрощает жизнь при дальнейшей работе, в т.ч. и в других проектах.
Искать баги в лаконично и грамотно спроектированном коде значительно проще.
На С++ это сделать проще и нагляднее, чем городить огород из С-костылей (сужу исключительно по своему опыту).

Нету у меня единой обертки под все железные дела, есть лишь заранее скомпилированные либы на базе индусской PeriphLib под разные ST-процы (сижу плотно на них).
Правда, все же есть у меня один класс - Pin, он реализован под каждое семество, т. к. библиотечный код для управления пинами от ST в данном случае слишком тяжелый.
Все остальное - по максимому чужое. Изобретать велосипед - уже не тот возраст ))
Так как поддержка PeriphLib прекращена, похоже, придется переключаться на HAL, но по возможности по максимому буду использовать только объявления регистров и ессно cmsis.
Но вся эта тряхомуть с железов закопана глубоко и при переноски модулей из одного проекта в другой почти ничего переписывать уже не нужно, кроме функционала самого модуля под конкретный проект.

Любая универсальная библиотека будет избыточна.

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

Есть у меня также самописный Iterator (изумительная вешь, я в восторге от ее простоты и функциональности!),
Queue для управления списками (самописный простой),
набор разных цифровых фильтров (шаблоны, т.е. не привязаны к типам данных)
есть само собой Singleton, от которого наследуются все синглтоны (модули проекта)....
Все это - шаблоны классов, т.к. просто hpp файлы. Вообще не зависят ни от какого железа.

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