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

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

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

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

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

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



Расскажите это Volkswagen которые разработали для Linux SocketCAN а General Motors использует его в своих люксовых седанах
http://www.opennet.ru/opennews/art.shtml?num=33943

По Вашей же подсказке из другой темы пригляделся к 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

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





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

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





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

Тут можно много готовых модулей найти
http://starterkit.ru/html/index.php?name=shop&cat=6
Правда я всё ещё присматриваюсь.


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


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

Сообщение отредактировал Lyubimov - Jul 30 2012, 14:42

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

http://dunkels.com/adam/pt/
http://code.google.com/p/protothread/wiki/UsersGuide
http://atomthreads.com/
http://bsvi.ru/tag/protopotoki/

Сообщение отредактировал ukpyr - Jul 30 2012, 15:39

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

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

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

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

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

Сообщение отредактировал ukpyr - Jul 31 2012, 14:08