Comments 36
Впору создавать сайт с реестром и кратким описание мелких ошибок в документации и либе драйверов от STM.
Мне интересно было бы понять и разобраться с тем как поднимать связку stm32+freeRTOS+lwip на gcc, а то наш контроллерный программист использует iar, который в качестве IDE ну уж очень слабенький.
По мне так проще было бы прикрутить тулчейн на основе gcc к QtCreator и получить кроссплатформенную среду. Но в сети как-то маловато руководств, есть некие шаблоны, но лично мне слабо понятно как общий шаблон для stm32f4xx натянуть на конкретную плату.
По мне так проще было бы прикрутить тулчейн на основе gcc к QtCreator и получить кроссплатформенную среду. Но в сети как-то маловато руководств, есть некие шаблоны, но лично мне слабо понятно как общий шаблон для stm32f4xx натянуть на конкретную плату.
Ну так IaR тулчейн вас не заставляет использовать IaR IDE. Я лично так и делаю, собираю одним тулчейном, программирую же всегда в другой IDE.
Другой вопрос — дебагинг.
Другой вопрос — дебагинг.
А где можно взять iar под macosx или linux?
И ещё хочется код прошивки и клиента одним компилятором собирать.
И ещё хочется код прошивки и клиента одним компилятором собирать.
Сам тулчейн можно под wine попробовать погонять.
Про клиента вы ранее не говорили. Он у вас тоже на ARM Cortex-M4?
Про клиента вы ранее не говорили. Он у вас тоже на ARM Cortex-M4?
Обычное приложение, общающееся с контроллером по ethernet. Поэтому есть соблазн код сетевого протокола сделать общим. Да и клиент вполне себе компилируется и работает под arm.
Ну в таком случае GCC чуть ли не единственный полноценный вариант. Есть у него только вопросы по оптимизации и т.п., но если не критично, то отличное решение.
Я так понимаю, что IAR делает просто более компактный код или он реально для Cortex M4 генерирует более быстрый код? Наверняка все можно подкрутить флагами компиляции до одного уровня?
P.S.
А интересно, как поживает clang-arm-none-eabi?
P.S.
А интересно, как поживает clang-arm-none-eabi?
Есть много статей по поводу сравнения, я лично вынес для себя, что IaR по футпринту делает код меньше. У меня на практике было так, что еле влезали в Flash контроллера, поэтому подобная оптимизация была очень нужна.
По поводу производительности… Не думаю, честно говоря, что сильно отличается на большой системе. В отдельных небольших юз-кейсах — скорее всего есть отличия, но в общем…
clang'ом не пользовался, но вот armcc очень даже не плохо, на мой взгляд :)
По поводу производительности… Не думаю, честно говоря, что сильно отличается на большой системе. В отдельных небольших юз-кейсах — скорее всего есть отличия, но в общем…
clang'ом не пользовался, но вот armcc очень даже не плохо, на мой взгляд :)
Насчёт кроссплатформенности мало что подсказать могу, но вот под Windows есть очень хорошая IDE от CooCox. Настраивается в два клика, удобный редактор, под рукой удобная подробная справка по регистрам целевого МК. Бесплатная. Единственный минус — нет поддержки STM8.
Насчёт связки stm32+FreeRTOS+lwip — lwip не использовал, но FreeRTOS прикручивается довольно просто. На эту тему уже есть довольно много статей, но если кто-нибудь хочет — могу написать ещё один топик.
Пока искал другие ссылки, нашел вот эту. Возможно поможет с Вашей проблемой.
Насчёт связки stm32+FreeRTOS+lwip — lwip не использовал, но FreeRTOS прикручивается довольно просто. На эту тему уже есть довольно много статей, но если кто-нибудь хочет — могу написать ещё один топик.
Пока искал другие ссылки, нашел вот эту. Возможно поможет с Вашей проблемой.
Перенос из одной IDE в другую — довольно муторное занятие. Может пройти всё гладко,
а может и нет. У разных тулзов здорово различается «нижний» уровень.
— синтаксис ассемблера (секции, атрибуты символов)
— «среда исполнения» и стд. либы
— синтаксис скрипта линкера для сборки
— ну и работа с заливщиком-отладчиком
Поэтому в CMSIS например просто сдалали разные подкаталоги под EWARM/GCC/KEIL/и.т.д.
Уровень "*.с" практически одинаковый, не считая готовых либ. Да, у IAR действительно
слабенький IDE. И по сравнению с ним IDE-шка в CooCox (Eclipse) — просто праздник какой-то.
НО! У IAR:
— могучая либа (готовых strxxx/printf/и.т.д.) в нескольких вариантах
— встроенный CMSIS
— отличный отладчик на кучу донглов
а может и нет. У разных тулзов здорово различается «нижний» уровень.
— синтаксис ассемблера (секции, атрибуты символов)
— «среда исполнения» и стд. либы
— синтаксис скрипта линкера для сборки
— ну и работа с заливщиком-отладчиком
Поэтому в CMSIS например просто сдалали разные подкаталоги под EWARM/GCC/KEIL/и.т.д.
Уровень "*.с" практически одинаковый, не считая готовых либ. Да, у IAR действительно
слабенький IDE. И по сравнению с ним IDE-шка в CooCox (Eclipse) — просто праздник какой-то.
НО! У IAR:
— могучая либа (готовых strxxx/printf/и.т.д.) в нескольких вариантах
— встроенный CMSIS
— отличный отладчик на кучу донглов
к QtCreator прикрутить нормально не получилось — сложности с отладкой по JTAG. Но удалось прикрутить к Eclipse со всеми возможными плюшками — по шагам ходит, периферию показывает и т.п.
Полезный пост, добавил себе в закладки.
У меня также интересный случай был с FLASH latency. Надо бы тоже описать.
У меня также интересный случай был с FLASH latency. Надо бы тоже описать.
Есть сообществу интересно, то могу написать подробную статью по работе с MicroSD памятью через SPI. Материала на эту тему довольно много, но качество меня не радует.
Обязательно пишите.
Как раз на эту тему появилась вечером статья habrahabr.ru/post/213803/.
А нет ли где подробного описания процесса снятия ReadOut Protection с STM32F1* и STM32F0*? А то сейчас это похоже умеет делать только ST'шная утилита, а под линуксом st-link не позволяет. Вот бы допилить туда эту фичу =)
Проблема STM32Fxxx в том, что при записи во флэш контроллер останавливается полностью. А максимальное время записи там большое. Особенно если нужно стирание выполнить сначала. В результате на практике использоваться флэш для записи каких-то данных невозможно (ну, либо система должна быть некритична к большим паузам в работе, что редкость)
Часто используют для обновления прошивки, а данные куда-нибудь на внешнюю eeprom.
Не такая уж и большая редкость. В двух последних моих проектах как раз использовал встроенный Flash.
И ещё — на сколько я помню чудеса с оптимизация и битами вызваны тем, что вы что-то не так делаете :)
Если буквально следовать документации то всё работает. Помню, что там были какие-то примечания в совершенно неочевидных местах.
Если буквально следовать документации то всё работает. Помню, что там были какие-то примечания в совершенно неочевидных местах.
А в errata ничего по этому поводу нет? У них бывает, что флаг выставляется не сразу и надо подождать несколько циклов прежде, чем его начинать мониторить.
Почти наверняка где-то оно есть, но проблема в том, что угробив два дня я так ничего и не нашел. Зато теперь (я надеюсь) — у других разработчиков такой проблемы не возникнет, т.к. эта статья гуглится первой строчкой по всем запросам, которые я вбивал когда искал сам.
Это не errata. Это кривость документации — всё раскидано по массе разделов с кучей примечаний.
Да, именно поэтому я не успокаиваюсь (да и не только я, я думаю), пока прошивка не будет нормально работать с -O2. Решение, предложеное в мануале с -O2 работать отказалось, именно потому я и написал этот пост. По моему мнению использовать флаг занятости (BSY) для контроля окончания операции в принципе не правильно. Например часто такое вижу в статьях, где используется SPI. Для контроля окончания операции фактически всегда есть специальные флаги, именно для этого и предназначенные.
Sign up to leave a comment.
STM32 — правильно используем встроенный flash