Всем привет!

Не бейте сильно, только. Вот хочу перейти на АРМ, имею пару отладочных платок (STM32 Дискавери и китайскую ourstm). В планах собрать консоль управления некой железкой в виде кнопочек и лампочек по USB и I/O, типа большого "джойстика". На AVR я бы сделал что-то вроде state-машины и обрабатывал состояния в цикле. Ну тут типа прогресс не стоит на месте, куча всяких RTOSов и прочее.
Посоветуйте как лучше поступить. Желательно получить ответ не как мне будет проще делать, а как кошернее и правильные. Дабы развиваться самому.
Заранее спасибо!

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

Если есть желание осваивать ОС, то купите DevKit с предустановленным Линуксом. Например:

www.starterkit.ru

Просто там куча параллельных задач, таких как управление блоком питания, кучка ШИМов, обработка драйверов периферии. Обработчики событий разных, это не просто джойстик

абсолютно так же, тем более если писать под GCC. Только придется подключить стандартные либы от STM32, с ними работа с периферией ненамного сложнее чем на АВР без либ. Для параллельности можно использовать Protothreads - абсолютно кроссплатформенная штучка, очень легкая

Сообщение отредактировал zöner - May 1 2012, 13:49

Ни один еще проект с арм-ами пока не делал без freertos, везде она облегчает жизнь. Очень советую применять ее.
А так же проекты-примеры из IAR, и с stm.com выручают.

сколько памяти съедает сама РТОС ?

По разному: scmRTOS в >2kB flash помещается.

У дураков мысли сходятся, но, тем не менее, бОльшего минимализма я ещё не видал.

+1 про protothreads.
Само по себе число параллельных задач мало о чём говорит. В большинстве случаев можно обойтись простым Super Loop легко и непринуждённо. Соответственно, protothreads в этом очень помогает.

Добрый день!
Я лично проходил все это тернистым путем. Моими учителями были уважаемые участники данного форума, других интернет-сообществ, различные FAQ, UM и т.д. и т.п.

Но если быть более точным, то начинал с ARM GCC (WinARM) в 2008 г. на LPC2468. Затем на год все забросил. Снова вернулся с тем же компилятором. Потом снова бросил. Опять вернулся) В начале 2012 года все новогодние праздники угробил на серьезный разбор как инструмента (компилятора, линкера, скриптов), так и самого МК.

Тут использовался и Кейл, и GCC. Удалось написать свой загрузчик (проект забросил, не до него сейчас), который может грузить hex (именно этот формат) как с сети, так с SD-карты, так и по последовательному каналу.

Сгородил что-то типа маленького UDP-стека. Кривого и убогого.

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

Сейчас плотно мучаю ARM9.

Вот такой запутанный путь. Поэтому, извините, я Вам дать совет, как правильнее идти, не могу

Сам до сих пор плохо понимаю, как это оно - правильно идти)))

WinARM по-любому хорошая тема была. Жаль, что оно всё не выжило. Ягарто, как бы Клён его не хвалил, всё равно фигня.

А вот интересно - вопрос любителям freertos - сколько она производительности проца съедает?
Она пытается вытеснять задачу по каждому прерыванию или только по сис. таймеру? Что если в системе есть высокочастотные прерывания?
На сколько тактов увеличивается время работы ISR-ов?

По своему опыту использования uCOS знаю, что она (в недоработанном своем виде пытается вытеснить задачу по любому прерыванию и та же задача, но запущенная под ней, расходует примерно на 10% больше проиводительности, чем если бы была запущена без ОС.

Дык это же профайлером вычисляется всё.

Если-б у меня была эта ОС, я бы не спрашивал.

Все сильно зависит от архитектуры процессора, порта ОС на эту архитектуру и, конечно, правильности применения данной ОС.
Насчет uCOS не согласен. Она будет пытаться перепланировать задачи при выходе из прерывания ТОЛЬКО в том случае, если в прерывании была вызвана функция C_ISR_ENTER(). Если необходимо 1000 раз выполнить прерывание без перепланирования и только на 1001-й передать управление другой задаче, так и вызовите C_ISR_ENTER() только на 1001 раз. Тогда и оверхеда не получите.
С Cortex'ами, например, еще проще. Там даже не надо системе говорить, что началось прерывание. В любой ПРАВИЛЬНО портированной ОС перепланировка будет вызвана при выходе из прерывания ТОЛЬКО в случае активации в этом прерывании каких-либо механизмов межпроцессного взаимодействия, таких как взведение семафоров, флагов, передача сообщений и т.п.
Так что при правильном использовании ОС оверхед минимален.