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

[AlDr70]

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

[Мурик]

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

[Ярослав555]

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

[Reflector]

[uquote="Ярослав555",url="/forum/viewtopic.php?p=3521713#p3521713"]В иаре есть три области памяти - глобальные, стек и куча. Вопрос - если я создаю вектор в глобальных переменных, а потом добавляю элементы - они в глобальной области или на куче?[/uquote]
Как элементы могут быть в глобальной области, если по мере их добавления вектор может расширяться? Можно, конечно, подсунуть ему аллокатор который из пула память выделяет, но это явно не твой случай.

[Ярослав555]

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

[Ярослав555]

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

[a5021]

[uquote="Ярослав555",url="/forum/viewtopic.php?p=3521804#p3521804"]ну было как - под кучу выделено 10кБ оперативки. Через New туда создавались все буфферы обмена, там жили все обьекты классов.[/uquote]
Какая блестящая идея -- набить мк классами через new, чтобы аж из ушей полезло. Не останавливайтесь. Треш и угар должны быть перманентны.

[Ярослав555]

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

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

[Reflector]

[uquote="Ярослав555",url="/forum/viewtopic.php?p=3523305#p3523305"]Почему так. для простоты масштабирования, модбас был написан в виде класса. В конструктор класса передается подчиненная периферия - юарт, дма, таймер. Там же происходит изменение некоторых полей структур, сконфигурированных в кубе. Т-е конфа из куба мне нужна, т-к я пока не намерен делать все вручную, но кое-что я меняю в зависимости от сохраненных настроек юзера. Именно поэтому, экземпляр мне нужен в глобальной области видимости (чтобы полить из таймеров-прерываний), а вызов конструктора мне нужен после того как куб прописал все поля в структуры, т-е из самого мейна или позже.[/uquote]
Передавай свои юарт, дма и таймер в функцию инициализации, а не в конструктор, тогда никакое динамическое выделение памяти будет не нужно. А еще лучше сделать на шаблонах:

Код: Выделить всё

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]

[uquote="a5021",url="/forum/viewtopic.php?p=3523337#p3523337"]Далее копаться стало уже откровенно лень, т.к. тенденция очевидна.[/uquote]
скажем, mbed или platformio - SDK не для какой-то конкретной железки одного производителя - вполне себе плюсовые.

[a5021]

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

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

[Ярослав555]

[uquote="a5021",url="/forum/viewtopic.php?p=3523649#p3523649"]что начинают аруинизировать портовые элеваторы, благо одернуть некому..[/uquote]
Спите спокойно - мой девайс был нужен как переходной этап. Мы поочередно модернизировали все РП без смены системы наверху и остановки. А когда с рп закончили - за сутки поменяли скаду, оно пошло напрямую и сняли мои приборы.
А вот в другом месте (два карусельных весовых дозатора) прекрасно работает. Правда я баги работы с железом пол года вылавливал, ну то такое - не в ООП дело

[a5021]

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

[Ярослав555]

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

[a5021]

[uquote="Ярослав555",url="/forum/viewtopic.php?p=3523859#p3523859"]Ну глюки то не у меня, а у иара. И до ооп там даже не дошло - валилось на векторе[/uquote]
Вам следовало бы получше запоминать то, что говорили ранее:
[uquote="Ярослав555",url="/forum/viewtopic.php?p=3521804#p3521804"]Но наблюдал такую ситуацию - программа идет в конструктор, там создаются переменные, буферы, выходит из конструктора и на точке с запятой падает в хардфолт. В понедельник копну глубже.[/uquote]
Я понимаю, что художник так видит, но с правдоподобностью надо что-то делать.

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

[Мурик]

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

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

[a5021]

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