OSDev

Спасибо! Подскажите тогда, какая плата для начальных экспериментов лучше: STM32F429I-DISCOVERY или stm32vldiscovery? Первая плата имеет экранчик и много доп.оборудования, вторая проще; первый M4, а второй M3.

_________________
Волна поднимается

Ну, я б лично с STM32 вообще не связывался бы. Единственное их достоинство -- низкая цена, а вот в остальном... Багов многовато, да и просто странностей хватает. Кривые вещи есть и в UARTах, и в I2C, и даже GPIO у них дурные; такое впечатление, что разработчики свои служебные обязанности у них под какой-то дурью выполняют. Как по мне, лучше NXP (например, LPC1788 или 4088), а из старых -- NXP же (LPC2478, скажем) или некоторые Atmel'ы, особенно SAM9G45 (кажись, так обзывается -- лениво смотреть, а голова давно уже дырявая). Вообще, у атмеловских "классических" АРМов самая приятная периферия из всех, с чем приходилось встречаться -- правда, у ранних дофига разных ошибок (у упомянутого G45 как раз почти все их вычистили -- в отличие от, например, 9261). Ну а какой именно из перечисленных брать -- без разницы, по большому счёту. В любом случае придётся разбираться с одними и теми же вещами, и сложность у них в общем и целом одинакова, ну а периферия так вообще должна по большей части совпадать (ну, конечно, из того, что у них у обоих есть). Так что смотрите по деньгам и по своим целям.

Я как раз сейчас сам с STM32 работаю, можете чуть поподробнее описать то, что вам в них не понравилось? года два назад работал и с LPC1788. Конечно есть разница, но так резко не могу сказать. Хотя в LPC я юзал из интерфейсов только SPI (ну и ножки как входа, дисплейный интерфейс, но он в STM32 недавно только появился и вот с чем соглашусь по части неудобств - документирован плохо). Сразу оговорюсь, не холивара ради спрашиваю, а просто интересно узнать, что по вашему мнению не так (особенно с GPIO)?

Из того, что помню наизусть:

1. У GPIO нет нормальных прерываний. Есть дурацкий механизм EXTI или как там его -- ну, кто постоянно работает с STM32, знает, как он точно называется. Он очень ограничен по своим возможностям (нельзя, например, сделать генерацию прерываний по изменению бита 0 порта А и бита 0 порта В -- ему подавай разные биты). У LPC1788 и изрядной части других только у двух портов есть прерывания, зато на каких угодно ногах этих двух портов. У старых Atmelов ещё лучше: там у всех разрядов всех портов прерывания, у почти всех настраивается открытый сток и т.д. и т.п. -- в общем, максимальная гибкость.

2. I2C в STM32 не позволяет сначала прочитать принятый байт и лишь после этого сказать контроллеру, продолжаем мы операцию или завершаемся. У NXPшных процов это делается без проблем, а соответственно, куда больше гибкости при организации обмена.

3. UARTы по-дурному обрабатывают бездействие линии. Обнаруживать сие состояние они обнаруживают, но признак его обнаружения сбрасывается при считывании регистра данных. Поэтому если сложится такая ситуация, что обнаружение бездействия совпало со считыванием последнего полученного байта, обнаружение бездействия будет потеряно. Grindars (мы с ним вместе работаем, но, к моей радости, с STMками приходится мучиться ему) из-за этого кучу времени потратил, пытаясь понять, почему время от времени глючит обмен между STM32L151 и радиочипом.

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

5. Примитивный контроллер USB, сваливающий большинство функций на программиста (а не реализующий их в железе, как, например, у NXP).

6. Ну и обилие ошибок в железе. Они у всех имеются, но STMки ставят рекорды по их количеству.

Всё сие усугубляется неважнецкой документацией и отвратительными примерами, библиотеками и прочим -- в последних багов выше крыши, особенно для достаточно сложных устройств (хотя тамошние быдлоиндусы ухитрились, например, поддержку SPI сделать криво -- перепутали где-то |= и &=, похоже, со всеми вытекающими -- это было обнаружено посредством дизассемблирования ихнего кода).

х-м-м, вот читаю все, что вы написали и понимаю, что со многим согласен и сам сталкивался. Просто видать я не с таким уж большим количеством МК работал (особенно разных производителей), что считал многие из этих неудобств какой-то неотьемлемой частью мира МК (не полноценный комп же, ну значит помучаться надо ).
А вот где у меня было мучение, так это когда я с нашими Cortex-M3 начал работать К1986ВЕ92 (Миландр разрабатывает), их тогда как раз только выпустили и мы заложили их в изделие, заказали бесплатные опытные образцы... ух, эррата впечатляла. Ну и отвалившаяся крышка проца тогда вызвала шок, никогда наверное не забуду.

SII,
Два вопроса:
1. Какой микроконтроллер на ядре ARM с аппаратной поддержкой USB и встроенными ЦАП/АЦП представляется наилучшим выбором?
2. Каково соотношение цены между STM32 и аналогичными по возможностям контроллерам других производителей? ЕМНИП STM32 - одни из наиболее доступных по цене.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Насчёт встроенных ЦАП и АЦП скажу так: они, похоже, везде поганые. Так что, если нужна достаточно высокая точность или приличная скорость, хошь-не хошь, а ставь внешний. У нас встроенный (как раз в STM32L) используется в рыбацких эхолотах, где точность роли не играет, да и частота отсчётов тоже относительно невелика (в более древних моделях -- на Атмеге-162 -- вообще компаратор использовался с интегратором на конденсаторе). Но вот в продвинутой модели, что сейчас лепим, с этим уже анус получается, и будем ставить внешний (там идея сделать уже нормальную цифровую обработку сигнала со всеми вытекающими, но это и процессор другой по производительности нужен, и памяти существенно больше, ну и АЦП другой, с реальной частотой выборок хотя б в 1 МГц -- у нас сигнал сам около 250 кГц). В другом приборе (контроль органических примесей в воде), где стоит LPC1788 (и планируется 4088 -- из-за того, что в последнем исправили-таки один гадский баг в хост-контроллере USB, который и у NXP, и у других фирм лет 10, если не больше, присутствовал), используются только внешние ЦАП и АЦП, поскольку там нужна достаточно приличная реальная точность (12 бит хватает, но настоящих, а не липовых, забитых шумами самого преобразователя или ещё чем неустранимым -- технически стоит 16-разрядный АЦП).

Насчёт USB. Если достаточно 1.1, то NXPшные точно работают без всяких проблем, заводятся с полпинка (я хост под флэшку поднял за полдня, причём отталкивался от примера для другого контроллера, да ещё сделанного в IAR, а у нас Keil -- т.е. пришлось ещё адаптировать под нашу специфику), документация более-менее вменяемая, сами контроллеры -- тоже. С хостами 2.0 сам не сталкивался, поэтому не скажу, но они в микроконтроллерах не так уж часто попадаются, хотя в АРМовских микропроцессорах (тот же контроллер, но без встроенной флэш-памяти) это обычное явление. Но STM в этом плане, судя по отзывам в интернетах, находится в полнейшей заднице -- похоже, что у них реально всё криво сделано.

Ну а по цене STM32 действительно лидер, наверное -- потому и настолько популярны. Для эхолотов они выбраны были в т.ч. по этой причине (ещё одна -- энергопотребление, STM32L -- как раз низкопотребляющая серия, хотя "гекконы" -- EFM32 -- пожалуй, получше будут, но их не так просто достать, как мне кажется -- во всяком случае, несколько лет назад это было сделать тяжело). Вот в другом приборе стоимость проца роли не играет, поскольку сам прибор как самолёт стоит -- не бытовая электроника, а промышленная, да и основная часть себестоимости всё равно приходится на реактор и прочую специфическую фигню, а не на электронику; NXPшный был выбран потому, что у него полно ног (корпус на 208 выводов) и все нужные, не очень нужные и совсем не нужные интерфейсы присутствуют. Например, есть до сих пор реально не используемый Ethernet -- хотя на процессорной плате вся разводка под него сделана, т.е. технически использовать можно, просто программной поддержки нет (я USB-то никак не добью, чтоб он работал не "в принципе", а для конечного пользователя -- вынужден выполнять работу электронщика и разводить 100500 экспериментальных эхолотов, и на программирование чего-либо серьёзного просто времени нет).