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 минут на исправление уже созданной им ранее модели, далее процедура знакомая и быстрая.
ЧПУ станок нарежет столько деталей, сколько нужно. В этом время этот слесарь занят следующей моделью.

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

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

Синглтон позволяет сам контроллировать вызов своей инциализации, причем делать это лишь один раз.

Вот на реализации этого и страдает мое чувство прекрасного. Он каждый раз проверяет - создан ли объект, и если не создан - то создает. То есть программа может годами работать после запуска, все инициализации давно прошли, а он продолжает тратить время на ставшие уже ненужными проверки при каждом обращении к каждой сущности. Я понимаю, что это тяжелое наследие моего ассемблерного прошлого, что ресурсов у современных МК завались, но побороть себя пока не могу. Хотя с проблемами порядка инициализации сталкиваюсь постоянно, да. Пока я думаю о запихивании всего в один класс Application - там порядок вызова конструкторов однозначно определен порядком объявления, а уж наличие в программе одного объекта Application я как-нибудь вручную обеспечу.

[Forger]

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

Редкая проверка битового флага отнимает совсем немного времени

К тому же далеко не везде и не так уж часто нужно проверять факт существования некоторых сущностей.

Вот пример: синглтон rtos - класс Kernel.
При создании мьютекса в конструкторе вызывается инициализация Kernel.
Т.е. проверка только на этапе запуска системы (я динамически практически никогда не создаю объекты rtos).
По сути в данном случае все эти проверки производятся только при подаче питания.

Код

void Kernel::initialize(void)
{
    if (!isInitialized)
    {
        __disable_irq();
        initializeHardware();
        initializeModules();
        isInitialized = true;
    }
}

Код

class Mutex
{
public:
    Mutex(void)
    {
        Kernel::getInstance().initialize();
        handle = xSemaphoreCreateMutexStatic(&controlBlock);
    }
....

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

В начале так делал, но еще на этапе проектирования возникли проблемы с областями видимости одних модулей с другими - ведь они ничего друг о друге не знают.
Костыли с дополнительными методами решали проблему (передача в модули ссылок на другие объекты), но такие костыли лучше сразу выкинуть, ибо они еще хуже, чем все это ваять на голом С.
Синглтоны, имхо, тут оказались самым уместным решением.
И обязательно - возможность отложенной инициализации, у меня каждый модуль имеет метод initialize(), пусть пустой, но он должен быть.
(в будущем это даст возможность запихать их в container и инициализировать все скопом через foreach).

Самые тяжёлые - ошибки в проектировании, так как они обнаруживаются на поздних этапах разработки и влекут за собой значительную переработку проекта...

Ну, "не так страшен черт, как его малюют"

Ну или костыли,которых не любят все.

Никто не любит костыли, просто, многие ленятся отказаться от них

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

Хорошее владение инструментом возникает только в процессе пользования инструментом, по щелчку пальца такие навыки не приходят.
Не стоит бояться новых инструментов, уверяю вас - привыкание приходит быстро

Иными словами - вот человек неверно спроектировал проект. И что? При переходе на С++ ошибки исчезнут? Думаю их добавится.

Разумеется! Тупой переход с C на C++ в лоб ничего полезного не даст, а даже наоборот.
Потребность в новом инструменте возникает тогда, когда накопленный опыт + старый инструмент уже не дают нужного результата.
Но, чтобы опыт рос, нужно развивать соотв. навыки, самое простое - делать много разных проектов.
Но делать с таким расчетом, что накопленные навыки (библиотеки) могут пригодится в других проектах.

На плюсах даже подход меняется..

Именно! Думать начинаешь иначе, поэтому ошибок проектирования возникает в разы меньше (разумеется, нужно почитывать книжки умных дядек).