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]

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

[k000858]

где-то используется глобальная переменная, доступная на запись из нескольких задач. Туда ройте.

такое есть. чем это чревато?

[Forger]

такое есть. чем это чревато?

Курим интернеты, думаем, делаем соотв. выводы
Лично рекомендую нафик уходить с голого C на C++ и использовать вместо глобальных объектов синглтоны.
Особенно для толстых проектов.

[Aner]

Курим интернеты, думаем, делаем соотв. выводы
Лично рекомендую нафик уходить с голого C на C++ и использовать вместо глобальных объектов синглтоны.
Особенно для толстых проектов.

С++ и его достоинства перед С, ... думаю не для STM c его осами и ограниченностью памяти. C++ даст только увеличение объема кода, подъест ресурсы которые и так ограничены. Хотя если задачка простенькая то пофигу на чем писать под STM хоть на С#.

Правильно pitt пишет в STM HAL в принципе не годится, у меня тоже свой. Все отлажено и работает в серийном изделии. А тот что выложен, у всех глючит и будет глючить по понятным причинам. Он для начинающих и лентяев.

И что ещё за шторм устройства Ethernet трафиком? Дураку, понятно что простых DoS атак STMы никак не потянут, даже старшие.

[Сергей Борщ]

С++ и его достоинства перед С, ... думаю не для STM c его осами и ограниченностью памяти. C++ даст только увеличение объема кода, подъест ресурсы которые и так ограничены.

Опять двадцать пять. Снова повторение одних и тех же мантр. Вы можете свои слова подтвердить хоть одним примером, когда хоть какое-то действие, алгоритм и т.д. даст "увеличение объема кода, подъест ресурсы" только потому, что написана на плюсах вместо голых сей? Криворукость программиста не рассматриваем, мы знаем, что "настоящие программисты пишут на Паскале на любом языке". Уже много лет как перешел на плюсы не только на STM32 "c его осами и ограниченностью памяти" но и, страшно сказать, на AVR(!) и не вижу описываемых вами ужасов. Вот совсем не вижу. А преимущества плюсов вижу и постоянно использую.

[SasaVitebsk]

А преимущества плюсов вижу и постоянно использую.

Сергей, но по сабжу применение синглтонов, явно не то преимущество, согласитесь.

[Сергей Борщ]

Сергей, но по сабжу применение синглтонов, явно не то преимущество, согласитесь.

Про синглтон как таковой ничего пока сказать не могу, не проникся им пока. Но спорю на ящик пива, что та же функциональность, написанная на голых сях, будет занимать не меньше памяти и "ограниченных ресурсов", а исходный текст при этом выглядеть будет куда более чудовищно. К тому же оставит программисту кучу возможностей натворить ошибок в процессе использования этого готового и безусловно рабочего кода.

[Forger]

Про синглтон как таковой ничего пока сказать не могу, не проникся им пока.

А мне пришлось их использовать, т. к. в противном случае просто нереально контроллировать порядок вызова конструкторов статически создаваемых классов.

Например:
есть класс Hardware, где инициализируется и используется железо МК,
есть класс RTOS, инициализация которой должна пройти сразу после инициализации тактового генератора,
но до всех остальных инциализаций, в т. ч. и до создания задач и других объектов.

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

Конечно, отложенная инициализация - неплохое решение (перенос содержимого конструктора в отдельный метод initialize(), который уже вызывается в определенном месте).
Но все равно возникает проблема видимости статически созданных классов в других файлах.
Можно пойти дальше - объявлять некоторые поля таких классов со словом static.
Но это по-сути выраждается в коряво имитируемый синглтон ))

В итоге все равно приходишь к полноценному готовому шаблону - синглтону ))

К слову, под синглтон идеально ложится класс RTOS, класс железа или чего-то, что в проекте ВСЕГДА будет существовать в единственном экземпляре.
Синглтон позволяет сам контроллировать вызов своей инциализации, причем делать это лишь один раз.
Например, инициализаця класса RTOS должно проводится всего один раз и всегда ДО создания объектов классов задач/потоков, семафоров, мьютексов и др. сервисов RTOS.
Достаточно лишь в конструкторе каждого такого объекта вызывать соотв. метод отложенной инициализации класса RTOS, где уже внутри него проверятся - была проведена инициализация или нет.
Вся эта "тряхомуть" сложена в одном файле, один раз отлажена, собрана в библиотеки под разные виды платформ и забыта до тех пор, пока не потребуется расширить ее функционал или поменять ядро RTOS.

Снаружи любого проекта это выглядить очень просто и лаконично - задачи, сервисы RTOS можно объявлять где угодно:
статически (в начале файле cpp), динамически, размещать их в закрытой секции (private) соотв. класса, да хоть локально в соотв. функции ))
Голова никогда не болит где и в каком поредке они будут созданы, но будут проинициализированы и запущены в строго отведенных местах в заданном порядке (см. код из предыдущего моего поста).

Впрочем, прелесть сигнлтона есть и в другом - он легко позволяет перестать быть синглтоном, а сам код класса при этом почти не меняется.
Т.е. можно при желании создать несколько экзэмпляров RTOS, и переписать порт под многоядерную систему, где будут крутиться более одной оси ....
На данный момент это пока что абсурд, но тем не менее!

Что там мешает плохому танцору?

Рукастый слесарь со стажем, который работал только стамеской и молотком, может сотворить настоящее чудо.
Когда потребуется сделать что-то подобное, то все по новой - долго, муторно, трудоемко
В этот раз чуда может не получится - скажем, отколется часть детали и все по-новой....

Другой же слесарь, который смотрит дальше того, что умеет, поступит иначе:
нарисует 3D модель (придется освоить соотв. инструменты), отдаст ее в деревообрабатывающий цех (придется научится правильно рисовать модели под особенности технологии),
ему на ЧПУ станке по дереву вырежут ему десяток таких чудесных деталей.
Когда ему потребуется еще десяток таких же деталек или подобных, но отличающихся, скажем, лишь положением крепежных отверстий,
его задача - потратить 10 минут на исправление уже созданной им ранее модели, далее процедура знакомая и быстрая.
ЧПУ станок нарежет столько деталей, сколько нужно. В этом время этот слесарь занят следующей моделью.

Конечно, никто не мешает до конца жизни стучать молотком по стамеске

[SasaVitebsk]

Конечно, никто не мешает до конца жизни стучать молотком по стамеске

Завидую я вам. А у меня практически каждый проект - новый проект. А идей ещё больше. Заимствуются крохи. Причём то что заимствуется, как то без особых проблем.
Я ничего не говорил, по С++. Я им пользуюсь. Какие-то проекты, обслуживания прибора пишу на QT. Но как то всё равно язык не стал своим...
Я - убей - не пойму, что мне даёт класс Hardware... Выглядит несколько надуманно. Я не утверждаю, что так и есть. Просто представить себе не очень могу...
Типа базовый класс? Далее от него класс SPI?
А что вы за ось пользуете?

[Forger]

Я - убей - не пойму, что мне даёт класс Hardware... Выглядит несколько надуманно.

В текущих проектах у меня давно нет такого отдельного класса (выше указал для примера), а все периферийные вещи, привязывающие код к железу, рассованы по разных низкоуровым методам в соотв. модулях.
Некоторые вынесены в отдельные классы, например, драйвер для общения по сети CAN, экземпляр класса просто "подключается" библиотеке, которая требует CAN driver для своей работы.
Общая система взаимодействия формируется постепенно - от проекта к проекту.
Например, общие для всех проектов библиотеки я размещаю отдельно (разумеется, все под контролем SVN) в отдельном каталоге, где все разложено по своим местам.
Там же библиотеки RTOS, драйверы на некоторую периферию.
Это позволяет избежать ненужного копирования уже готовых отлаженных библиотек (кода) из предыдущего проекта в новый - общие библиотеки потому и называются общими, что они общие )))
Более того, они заранее скомпилированы и собраны в либы, чтобы в самих проектах компиляция проходила быстрее и меньше файлов болталось в дереве файлов. Только самое необходимое.

Типа базовый класс? Далее от него класс SPI?

Есть готовые открытые С++ либы под периферию разных процов. Погуглите ))

А что вы за ось пользуете?

Разные: https://electronix.ru/forum/index.php?s=&am...t&p=1475072