STM32 новичку в ARM что к чему

[AlDr70]

lazarev Тоже подумал о том, чтобы прошить МК отдельно. Без стлинка ничего не прошивал и изучаю "масштаб бедствия". Бинарник где-то в сети видел.

[Мурик]

http://easystm32.ru/useful-things/42-bootloader-stm32
http://radiohlam.ru/?p=1348

[Ярослав555]

Здарова котаны. Есть такой вопросик. В иаре есть три области памяти - глобальные, стек и куча. Вопрос - если я создаю вектор в глобальных переменных, а потом добавляю элементы - они в глобальной области или на куче?

[Reflector]

Ярослав555 писал(а):

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

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

[Ярослав555]

ну было как - под кучу выделено 10кБ оперативки. Через New туда создавались все буфферы обмена, там жили все обьекты классов. Все вроде вмещалось нормально, ничего не падало. Потом я понял, что не смогу обращаться к ряду обьектов через инкремент указателя, т-к они то не по порядку идут. Решили перейти на вектор. И вот, при добавлении уже второго объекта в вектор я ловлю хард-фолт. Было это уже в пятницу вечером, и сильно покопаться не получилось. Но наблюдал такую ситуацию - программа идет в конструктор, там создаются переменные, буферы, выходит из конструктора и на точке с запятой падает в хардфолт. В понедельник копну глубже.

[Ярослав555]

Собственно на свежую голову нашел решение своей проблемы.

Вложения

Heap.png

(37.89 KiB) Скачиваний: 735

[a5021]

Ярослав555 писал(а):

ну было как - под кучу выделено 10кБ оперативки. Через New туда создавались все буфферы обмена, там жили все обьекты классов.

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

[Ярослав555]

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

Добавлено after 8 minutes 46 seconds:
кстати и работа с флешкой, и терминал пользователя, работа с пачкой ацп все написано через классы. с ацп то понятно - один раз написал и создал 4 штуки, а с остальным - по привычке
А память то почти пустая, как оказалось. Причина то совсем в другом была.

[Reflector]

Ярослав555 писал(а):

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

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

Код:

Modbus<Usart2, Dma1Ch5, Timer1> modbus;

void main()
{
    modbus.init();
....

[Ярослав555]

Да, я думал о таком способе. Почему-то с указателями и инитом в конструкторе понравилось больше.

[a5021]

Я понимаю, что не всем суждено родиться циолковскими или менделеевыми, но это же так просто -- взять и посмотреть, что изобретено другими в той области, которую предстоит изучать. Смотрим, что изобрели в STM. Там сначала изобрели SPL, потом HAL -- в обоих случаях процедурно-ориентированные библиотеки. Ну мож это STMicro такие отсталые, а фирмы попродвинутее давно ООП пользуют в микроконтроллерах. Смотрим фрискейловский Kinetis SDK -- тоже почему-то никаких объектов. Nordic MDK/SDK -- ровно та же фигня. Отсутствую классы и в LPCOpen. Нет ничего из ООП и в техасовской Tiva Peripheral Driver Library. Далее копаться стало уже откровенно лень, т.к. тенденция очевидна.

Фанатам ООП в эмбеде: вы кушайте, кушайте кактус. Вам он должен быть особенно полезен.

[Ярослав555]

И тем не менее, ST допилили свой HAL, улучшили совместимость и теперь в C++ режиме не валится сотня варнингов
Была у меня задачка год назад - сделать контроллер-прослойку, у которого с одной стороны проприетарная система, а с другой новый ПЛК. Там даже не то чтобы STM, там AVR 8бит был. И тем не менее с помощью классов и структур я эмулировал поведение 4 старых устройства. В памяти жил набор объектов которые иммитировали с одной стороны поведение как ожидает система, а с другой управляли ПЛК. С одной стороны я был проприетарным слейвом на 485м, а с другой - модбас мастером. И это все я реализовал грубо говоря за месяц.
И таких девайсов надо было десяток, у всех разный набор этих виртуальных устройств внутри - у кого-то 1, у кого-то 4. С разными настройками. Я один раз написал и потом только настройки менял. Я не говорю что без классов этого не сделать, но, как мне кажется, работы тогда надо проделать намного больше. ООП тоже не дураки придумали.
Кстати эти танцы с эмулированиями нам тогда позволили выиграть тендер на переделку большого портового элеватора, а суть была проделать это все без остановки. Сейчас второй такой объект на горизонте, и там уже не модбас с другой стороны, а профибас, который еще разобрать надо и написать...

[arkhnchul]

a5021 писал(а):

Далее копаться стало уже откровенно лень, т.к. тенденция очевидна.

скажем, mbed или platformio - SDK не для какой-то конкретной железки одного производителя - вполне себе плюсовые.

[a5021]

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

Если бы ООП в эмбеде имело хоть какую нибудь ценность, все SDK давно были бы на нем.

[Ярослав555]

a5021 писал(а):

что начинают аруинизировать портовые элеваторы, благо одернуть некому..

Спите спокойно - мой девайс был нужен как переходной этап. Мы поочередно модернизировали все РП без смены системы наверху и остановки. А когда с рп закончили - за сутки поменяли скаду, оно пошло напрямую и сняли мои приборы.
А вот в другом месте (два карусельных весовых дозатора) прекрасно работает. Правда я баги работы с железом пол года вылавливал, ну то такое - не в ООП дело

[a5021]

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

[Ярослав555]

Ну глюки то не у меня, а у иара. И до ооп там даже не дошло - валилось на векторе. И никто не писал что железо глючит. Да и не "усирался" я - глюк вылез в конце пятницы, решение я нашел утром, за полчаса, в понедельник.

[a5021]

Ярослав555 писал(а):

Ну глюки то не у меня, а у иара. И до ооп там даже не дошло - валилось на векторе

Вам следовало бы получше запоминать то, что говорили ранее:

Ярослав555 писал(а):

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

Я понимаю, что художник так видит, но с правдоподобностью надо что-то делать.

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

[Мурик]

будто встроенный язык 1С-Бухгалтерии очень удобен для написания системных драйверов.

Если есть соответствующий компилятор, можно попробовать и посмотреть что получится.
Дрова и на бейсике можно писать и нормально получается.

[a5021]

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