Comments 21
Зачем выбрали сотую серию? Она уже постепенно сворачивается, а двухсотая имеет лучшие характеристики при той же цене. А вообще — лучше четырёхсотая, с DSP и плюшками, но она немного дороже.
Решил перейти с PICов на что-нибудь серьезное. Сотая серия сразу в глаза бросилась. А теперь уже поздно: макетка и контроллеры куплены.
А на будущее думаю действительно что-нибудь поновее использовать: у 103 CAN и USB на одном таймере висят, что нехорошо (нельзя будет сделать железку, которая подключается к компьютеру по USB и управляет чем-нибудь по CAN). Да и ethernet хочется…
А на будущее думаю действительно что-нибудь поновее использовать: у 103 CAN и USB на одном таймере висят, что нехорошо (нельзя будет сделать железку, которая подключается к компьютеру по USB и управляет чем-нибудь по CAN). Да и ethernet хочется…
Двухсотая серия нога в ногу совместима. Сильно рекомендую на неё перейти.
Мы, кстати, контроллер в мате перепаяли — на пол часа делов.
UFO just landed and posted this here
Пока ещё не разобрался в статье, но заметил интересующий меня ньюанс: используется GPIO_SetBits().
Правильно я понимаю, что эта функция позволяет управлять состоянием GPIO ног? Чья это функция (что за библиотека)? Не возникало ли с ней проблем? Какова её реальная скорость работы (временной лаг и т.п.)?
Правильно я понимаю, что эта функция позволяет управлять состоянием GPIO ног? Чья это функция (что за библиотека)? Не возникало ли с ней проблем? Какова её реальная скорость работы (временной лаг и т.п.)?
Это — обычная обертка над GPIOx->BSRR = GPIO_Pin
Пока нет нехватки ресурсов, можно пользоваться функциями библиотеки. А вообще, конечно, лучше по-человечески все делать. Но лень же, когда ресурсов хватает! (вот так у нас и получается, что каждая новая версия любого софта становится все более и более охочей до ресурсов: лень всему виной!)
Библиотека — STDPeriphLib от ST. Проблем с ней не возникало. Задачи у меня не RT, поэтому я не парюсь о скорости работы (лаги в миллисекунды для моей задачи — не проблема). Конечно, если работать со звуком или видео, надо будет забыть про все эти библиотеки, а то и вообще на ассемблере писать.
Пока нет нехватки ресурсов, можно пользоваться функциями библиотеки. А вообще, конечно, лучше по-человечески все делать. Но лень же, когда ресурсов хватает! (вот так у нас и получается, что каждая новая версия любого софта становится все более и более охочей до ресурсов: лень всему виной!)
Библиотека — STDPeriphLib от ST. Проблем с ней не возникало. Задачи у меня не RT, поэтому я не парюсь о скорости работы (лаги в миллисекунды для моей задачи — не проблема). Конечно, если работать со звуком или видео, надо будет забыть про все эти библиотеки, а то и вообще на ассемблере писать.
Я правильно понимаю, что регистры GPIO доступны просто по адресу GPIOx->BSRR? А кто возвращает в линуксе этот указатель?
Не совсем: у STM32 есть два регистра для записи данных в GPIO (советую почитать reference manual): 32-битный BSRR, позволяющий атомарно установить/сбросить биты порта, и 32-битный (но фактически используются лишь 16 младших бит) BRR, позволяющий атомарно сбросить биты порта.
Сама конструкция структуры порта определяется в заголовочном файле stm32f10x.h, идущем с STDPeriphLib, либо (если не пользоваться этой библиотекой) ее можно определить самому (по reference manual). От операционной системы, в которой код собирается, это, понятное дело, не зависит. gcc для ARM можно в любой операционке установить.
Сама конструкция структуры порта определяется в заголовочном файле stm32f10x.h, идущем с STDPeriphLib, либо (если не пользоваться этой библиотекой) ее можно определить самому (по reference manual). От операционной системы, в которой код собирается, это, понятное дело, не зависит. gcc для ARM можно в любой операционке установить.
Спасибо за направление мысли. C STM32 я не работал. Но судя по коду, доступны 7 независимых портов, представленных регистрами по адресу:
#define GPIOA_BASE (APB2PERIPH_BASE + 0x0800)
…
#define GPIOG_BASE (APB2PERIPH_BASE + 0x2000)
И собственно пачка функций-оберток для работы с ними. Это моё предположение, даташит не читал.
Когда нет операционки, понятно, что работать напрямую можно и нужно. Но когда есть Линукс, неужто он любой программе дает копаться по этим адресам?
#define GPIOA_BASE (APB2PERIPH_BASE + 0x0800)
…
#define GPIOG_BASE (APB2PERIPH_BASE + 0x2000)
И собственно пачка функций-оберток для работы с ними. Это моё предположение, даташит не читал.
Когда нет операционки, понятно, что работать напрямую можно и нужно. Но когда есть Линукс, неужто он любой программе дает копаться по этим адресам?
Дык, линукс здесь не при чем: нам нужно же как-то сказать компилятору об особенностях нашего контроллера — как минимум рассказать о расположении в памяти нужных для работы портов. Поэтому и используется соответствующий заголовочный файл.
Другой вариант — добавить заголовочные файлы для поддержки уймы железа в gcc. Однако, в arm-none-eabi аппаратнозависимых заголовочных файлов нет. Надо бы еще gcc-arm-none-eabi глянуть, как выше советовали. Но чувствую, там тоже такого не будет (а между тем, в sdcc было все необходимое для разработки под уйму PIC'ов).
А вот разработку клиентской части ПО в линуксе действительно будет удобнее делать. По крайней мере, просто сделав cat /dev/ttyACM0 вы уже сможете читать, что же там шлет контроллер на компьютер. Ну и при помощи libusb можно просто работать с железякой в userspace, не заморачиваясь с написанием модуля ядра.
Другой вариант — добавить заголовочные файлы для поддержки уймы железа в gcc. Однако, в arm-none-eabi аппаратнозависимых заголовочных файлов нет. Надо бы еще gcc-arm-none-eabi глянуть, как выше советовали. Но чувствую, там тоже такого не будет (а между тем, в sdcc было все необходимое для разработки под уйму PIC'ов).
А вот разработку клиентской части ПО в линуксе действительно будет удобнее делать. По крайней мере, просто сделав cat /dev/ttyACM0 вы уже сможете читать, что же там шлет контроллер на компьютер. Ну и при помощи libusb можно просто работать с железякой в userspace, не заморачиваясь с написанием модуля ядра.
У меня начинают появляться смутные сомнения, что фраза «программировать микроконтроллеры в линуксе» не обозначала гонять линукс на микроконтроллере… а описанный в статье код запускается сразу после бутлоадера…
Правильно. Если бы я говорил о линуксе на микроконтроллере (кстати, в 128..256кБ полноценный линукс ну никак не запихнуть), то так и говорил бы: «запускаем линукс на микроконтроллере».
А так я сказал «программировать микроконтроллеры в линуксе», т.е. писать для них код и прошивать их из-под линукса. Потому как примеров программирования микроконтроллеров из всяких коммерческих сред под винду — полным-полно, а линукс как-то обделили.
Несмотря на то, что сам код практически ничем не отличается во всех средах разработки, базовый Makefile нужно написать.
А так я сказал «программировать микроконтроллеры в линуксе», т.е. писать для них код и прошивать их из-под линукса. Потому как примеров программирования микроконтроллеров из всяких коммерческих сред под винду — полным-полно, а линукс как-то обделили.
Несмотря на то, что сам код практически ничем не отличается во всех средах разработки, базовый Makefile нужно написать.
Добрый день.
Пытаюсь повторить шаги этой статьи, но где-то застрял.
Использую ubuntu 12.04, STM32F107, ST-LINK/V2.
После установки arm-none-eabi тестовый проект stm32vldiscovery-linux-template стал собираться (получаю .elf файл). Дальше прошиваю его через через gdb и st-util, либо через st-flash, но лампочки не мигают.
Или диоды распаяны на других ногах, или всё-таки что-то не так с прошивкой. Не понял из статьи, в каком месте используется objcopy, например. Буду рад помощи!
Пытаюсь повторить шаги этой статьи, но где-то застрял.
Использую ubuntu 12.04, STM32F107, ST-LINK/V2.
После установки arm-none-eabi тестовый проект stm32vldiscovery-linux-template стал собираться (получаю .elf файл). Дальше прошиваю его через через gdb и st-util, либо через st-flash, но лампочки не мигают.
(gdb) load stm32vldiscovery-linux-template.elf
Loading section .isr_vector, size 0x1d0 lma 0x8000000
Loading section .text, size 0x18b0 lma 0x80001d0
Loading section .init_array, size 0x4 lma 0x8001a80
Loading section .fini_array, size 0x4 lma 0x8001a84
Loading section .data, size 0x2c lma 0x8001a88
Loading section .jcr, size 0x4 lma 0x8001ab4
Start address 0x8000800, load size 6840
Transfer rate: 6 KB/sec, 1140 bytes/write.
(gdb) ?Или диоды распаяны на других ногах, или всё-таки что-то не так с прошивкой. Не понял из статьи, в каком месте используется objcopy, например. Буду рад помощи!
Прошивать надо не сам elf-файл, а пропущенный через objcopy (стадия make all состоит у меня из собственно сборки, objcopy, objdump и size).
Я и сам поначалу с таким сталкивался. Советую внимательно мой Makefile почитать. А еще лучше — для начала целиком мой проектик собрать и прошить (make && make load).
Для прошивки используется st-flash.
Еще, конечно, важно посмотреть схему макетки, т.к. на разных макетках обвес разный, да и подключен он к разным ногам (тех же USART'ов у STM32F107 целых 4 штуки!).
Я и сам поначалу с таким сталкивался. Советую внимательно мой Makefile почитать. А еще лучше — для начала целиком мой проектик собрать и прошить (make && make load).
Для прошивки используется st-flash.
Еще, конечно, важно посмотреть схему макетки, т.к. на разных макетках обвес разный, да и подключен он к разным ногам (тех же USART'ов у STM32F107 целых 4 штуки!).
Спасибо за помощь. Я взял за образец один из мейкфайлов по ссылкам, а не ваш проект, и там не было целей с objcopy. Плюс на моей отладочной плате светодиоды висят на GPIOE.
Ещё видел какой-то более не воспроизводимый баг, когда после записи программы она не запускалась, а при вызове дебага — запускалась.
От безысходности пробовал также запуститься на windows по этому руководству, теперь вернулся мигать диодами на свою чёрную-чёрную консоль.
Ещё видел какой-то более не воспроизводимый баг, когда после записи программы она не запускалась, а при вызове дебага — запускалась.
От безысходности пробовал также запуститься на windows по этому руководству, теперь вернулся мигать диодами на свою чёрную-чёрную консоль.
UPD: поигравшись с библиотекой libopencm3, я решил перейти с STM'овских велосипедов на нее. Обновленную версию проекта разместил в отдельной директории, чтобы не «ломать» всю структуру.
Скоро уже придет железо для проекта. Надеюсь, к концу года уже будет кое-какой «настоящий» рабочий код, а не тестирование отдельных модулей.
Скоро уже придет железо для проекта. Надеюсь, к концу года уже будет кое-какой «настоящий» рабочий код, а не тестирование отдельных модулей.
Sign up to leave a comment.
STM32 + linux