[umup 0]

Не забывайте, что атомарность надо обеспечивать и для прерываний.

это да, но зачастую удается обойтись даже без запрещения прерываний

Так же как и нет временного детерминизма. Protothreads удобная штука, но это не замена RTOS.

еще не сталкивался с задачами где нужен детерминизм всех потоков точнее 1мс. Даже с двумя параллельными обменами по 1-wire проблем не было - 20 тредов укладывалось в один тик 1мс. Конечно если нужна точность - без прерываний не обойтись, но основным потокам это не мешает.

[Ruslan1 16]

_Артём_, спасибо.

AlexandrY, спасибо.

 

Прямо сейчас меня прельщает то, что, купив плату с линуксом, можно быстро накропать результат, работающий кое-как :) и застолбить место, а дальше уже заняться вылизыванием продукта.

Лично мне, как железячнику, линукс не нравится (был отрицательный опыт на BF533 uClinux - проблемы при сигнализации из ядра в задачу пользователя), но , уверен, это моя проблема а не линукса, думаю опять вернуться в это поле систем "как у всех".

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

 

В-общем, ясно. Если бюджет позволяет- то нужно закладывать что-то, куда можно поставить линукс. Дальше в случае чего никто не мешает снести его и поставить порт RTOS. То есть, в идеале, нужен проц, имеющий несколько вариантов уже портированных систем. У меня было такое с AT91RM9200 - купили плату с линуксом, но собственно линукс использовался для проверки железа, не более- он не тянул по нужной реалтаймовости (на малых тактовых), перешли на юкос и закрыли проблему.

 

Еще раз спасибо, буду копать в сторону low-cost плат-модулей, поддерживающих линукс и еще что-то, желательно побольше последовательных интерфейсов (RS232/485,CAN). Когда-то считал, получалось что своя плата выгодна от десятка единиц (если не-BGA) или штук от 50 (если BGA), до этого проще готовый модуль использовать плюс своя простая плата с специфической обвязкой. Но опять же, индивидуально все это..... Интересно, что из современного с поддержкой линукса без BGA бывает, наверное уже ничего... будем искать....

[sasamy 9]

Хотя с развитием облачных проприетарных технологий, еще не известно какие перспективы у стека линукса.

 

Самые оптимистичные потому что для облачных сервисов как раз Linux в основном и используется.

 

Даже полевые шины типа CAN... линуксу доверить нельзя

 

Расскажите это Volkswagen которые разработали для Linux SocketCAN а General Motors использует его в своих люксовых седанах

http://www.opennet.ru/opennews/art.shtml?num=33943

[Ruslan1 16]

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

По Вашей же подсказке из другой темы пригляделся к LPC43xx

Хм. розничные цены собственно на камень на дижикее не пугают, да и не-BGA еще бывают

LPC4330 (LQFP144) : $12

"портовооруженность" на уровне: 4 UART+ 2CAN. Есть любимый мной External Memory Controller но как все это гнездится в случае 144-пинового крпуса еще не смотрел. Ядро(ядра?) на 120МГц жрет 25 mA/3.3V. Очень напрягает сплошное TBD в разделе даташита "Power consumption", на что рассчитывать неясно. :(

Да и насчет отладочных средств непонятно (с ходу увидел только Keil LPC4357 Eval Board за $385). но уже интересно (может, на будущее, сейчас выглядит как из пушки по воробьям)

Upd: нашел такое за $59. здорово

http://microcontrollershop.com/product_inf...roducts_id=4840

 

[AlexandrY 3]

Расскажите это Volkswagen которые разработали для Linux SocketCAN а General Motors использует его в своих люксовых седанах

http://www.opennet.ru/opennews/art.shtml?num=33943

 

Хм, самое время спросить не работает ли в тех "люксовых седанах" целая туча RTOS на поддержке того самого CAN-а.

Потому как если взять какую-нибудь платформу OMAP5, где аж два Corteх-M4 на подхвате, то оо..очень сложно будет сказать кто реально там чем занимается. ;)

 

 

 

По Вашей же подсказке из другой темы пригляделся к LPC43xx

 

LPC43xx это немного другая тема.

Я больше имел ввиду Vybrid от Freescale.

Модули, кстати, делать на таких чипах будет не очень разумно.

Лучше разработать свою технологическую платформу, которая сможет долго прослужить.

[sasamy 9]

самое время спросить не работает ли в тех "люксовых седанах" целая туча RTOS

 

обязательно работает, только это не означает что

 

Даже полевые шины типа CAN... линуксу доверить нельзя

 

Потому как если взять какую-нибудь платформу OMAP5, где аж два Corteх-M4 на подхвате, то оо..очень сложно будет сказать кто реально там чем занимается. ;)

 

а вы посмотрите для чего они там используются - тогда невероятных предположений поубавится :)

 

 

 

[Lyubimov 0]

По Вашей же подсказке из другой темы пригляделся к LPC43xx

Хм. розничные цены собственно на камень на дижикее не пугают, да и не-BGA еще бывают

LPC4330 (LQFP144) : $12

"портовооруженность" на уровне: 4 UART+ 2CAN. Есть любимый мной External Memory Controller но как все это гнездится в случае 144-пинового крпуса еще не смотрел. Ядро(ядра?) на 120МГц жрет 25 mA/3.3V. Очень напрягает сплошное TBD в разделе даташита "Power consumption", на что рассчитывать неясно. :(

Да и насчет отладочных средств непонятно (с ходу увидел только Keil LPC4357 Eval Board за $385). но уже интересно (может, на будущее, сейчас выглядит как из пушки по воробьям)

Upd: нашел такое за $59. здорово

http://microcontrollershop.com/product_inf...roducts_id=4840

Тут можно много готовых модулей найти

http://starterkit.ru/html/index.php?name=shop&cat=6

Правда я всё ещё присматриваюсь.

 

По мере роста опыта и сложности проектов сначала всё делал на C. Потом попробовал FreeRTOS, с ходу не хватило ума разобраться, зато перешёл на Protothreads - имхо вещь просто отменная для тех, кто не хочет заморачиваться с ОСРВ, а суперциклы и ветвления становятся чересчур громоздкими. А теперь уже перешёл на scmRTOS, ибо шашечки C++ очень помогают, а всякие штуки типа файловой системы, ж/к дисплеев и прочих приблуд в наших проектах не нужны. Хотя как заметили выше, для FreeRTOS есть много готового кода. В общем, каждому по потребностям. Кстати, если вам интересна "популярность" той или иной ОС, можете поглядеть на https://www.google.ru/trends

Тоесть из вашего опыта следует, что при использовании РТОС программы становились более компактными и их было проще сопровождать?

В scmRTOS 31 поток, вам их хватало?

 

Protothreads. Не требует портирования, работает из коробки на всех архитектурах. Атомарность обеспечивается кооперативностью ОС, соответственно нет разного архитектурно-зависимого мусора типа планировщика, сохранения состояния/стеков и т.д.

А где вы черпали информацию по этой теме?

Изменено 30 июля, 2012 пользователем Lyubimov

[ukpyr 0]

:) гугл + самостоятельное копание:

 

http://dunkels.com/adam/pt/

http://code.google.com/p/protothread/wiki/UsersGuide

http://atomthreads.com/

http://bsvi.ru/tag/protopotoki/

Изменено 30 июля, 2012 пользователем ukpyr

[_Pasha 0]

А где вы черпали информацию по этой теме?

Это все очень далеко от темы. Да и вообще, называть десяток макросов осью, слишком громко. :)

Но работает. Когда надо поболее риалтаймовости, прототреды выполняются из прерываний...

[Lyubimov 0]

А каким образом вы применяли ОС? Сколько потоков вам требовалось? Сильно ли приходилось дорабатывать её? Осложнялась ли работа с периферией?

[ukpyr 0]

мне пока хватало 12 потоков.

удобно разбивать программу на независимые модули - работа с индикацией, клавиатурой, связь, работа с автоматикой (state machine любой сложности, с таймерами реализуется элементарно).

 

Для обслуживания событий с дискретностью 1мс не требуеся никаких прерываний - хватает одного системного таймера на 1кГц, с программным опросом флага переполнения.

 

к работе с периферией наличие ОС не имеет почти никакого отношения. Вся работа с периферией выносится в отдельные функции/макросы, в результате все элементарно портируется на другие архитектуры (напр. портировал один проект (~14K Flash, AVR-GCC/ARM-GCC) с Atmega16 на STM32F100 за один вечер, причем сохранилась возможность компиляции под АВР).

Изменено 31 июля, 2012 пользователем ukpyr