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

[Мурик]

У меня не работала отладка.

Не знаю как в кейле, в EmBitz отладка работает как с новой прошивкой, так и с той что в отладчике по умолчанию.

[VladislavS]

[uquote="Мурик",url="/forum/viewtopic.php?p=3515057#p3515057"]так и с той что в отладчике по умолчанию.[/uquote]Ты правда думаешь, что все китайцы одинаковы и зашивают одинаковую прошивку в одинаковые свистки?

[AndTer]

Есть несколько свистков, из разных магазинов. Все обновил, все работают.
Может есть и другие какие.

[Мурик]

VladislavS во всех что покупал с Китая была прошивка V2.J17.S4.

[Ярослав555]

у меня не свисток, у меня "белый обмылок", с гребенками на пузе. пока нет времени с ним играться. разгребу проект и наверное скажу пусть фирма оригинальный покупает.

Добавлено after 1 minute 10 seconds:
там кстати по ногам на гребенке не все в порядке - на оригинале сигналы выводятся, для "особых" случаев. А китайцы их на землю засадили.

[lazarev]

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

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

[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 давно были бы на нем.