embedded RTOS
27 отговора
1076 прегледа
embedded RTOS
Niakoi zanimaval li se e s RTOS za embedded? Az popadnah na niakolko biblioteki kato JacOS i SALVO, no vse neshto im kuca, i realno ne moga da gi izpolzvam. Imate li niakakvo info po vaprosa. Imam dosta vaprosi, na koito ako nameria otgovor shte sam blagodaren........
Re: embedded RTOS
Ами ако става въпрос за микроконтролери, то там няма реална OS. Всичките "операционни системи" са един вид framework-ци, където не можеш да зареждаш и изпълняваш код realtime. В началото на програмата просто пускаш на фреймуърка началните адреси на ф-иите (нишките), които искаш да се изпълняват паралелно и то си ги върти.
Re: embedded RTOS
Ми уточни малко за какво става дума...
Тежката артилерия мисля, че се нарича VxWorks.
Потърси за OSEK...
Тежката артилерия мисля, че се нарича VxWorks.
Потърси за OSEK...
Re: embedded RTOS
Znachi, RTOS se definira po malko po razlichen nachin, neshto ot roda na minimalno vreme za reakcia na sistemata pri dadeno vhodno vazdeistvie.....
V sluchaia obache men me interesuva multitasking-a, ne tochno vremeto. Imam jelanie da si napisha edna prostitchka multitasking OS za embedded /za konkretno prilojenie/. Samo, che ponastoiashtem ne moga da si obiasnia kak stava prevkliuchvaneto na zadachite. Predpolagam shte kajetye "prosto", naistina e prosto ako prevkliuchvaneto stava v kraia na vsiaka zadacha, koeto stava po-skoro state mashina. A kak stava prevkliuchvaneto /predavane na upravlenieto na kernela i minavane kum druga zadacha/ po sredata na niakoi task i posle vrushtane v sushtoto miasto na napusnalia task. Shte copna edin primer za da sam po-iasen:
void Task1( void )
{
for (;;) {
//......... code
OS_Delay(10, Task1a); //tuk se predava upravlenieto na kernela
}
}
void Task2( void )
{
for (;;) {
OS_WaitBinSem(BINSEM1_P, Task2a); //tuk se predava upravlenieto na kernela
//......... code
}
}
void Task3( void )
{
for (;;) {
//......... code
OS_Yield(Task3a); //tuk se predava upravlenieto na kernela
//......... code
OS_Yield(Task3b); //tuk se predava upravlenieto na kernela
}
}
I sega konkretnia vapros: Kak izglejdat tezi funkcii s parametur eticket?
V sluchaia obache men me interesuva multitasking-a, ne tochno vremeto. Imam jelanie da si napisha edna prostitchka multitasking OS za embedded /za konkretno prilojenie/. Samo, che ponastoiashtem ne moga da si obiasnia kak stava prevkliuchvaneto na zadachite. Predpolagam shte kajetye "prosto", naistina e prosto ako prevkliuchvaneto stava v kraia na vsiaka zadacha, koeto stava po-skoro state mashina. A kak stava prevkliuchvaneto /predavane na upravlenieto na kernela i minavane kum druga zadacha/ po sredata na niakoi task i posle vrushtane v sushtoto miasto na napusnalia task. Shte copna edin primer za da sam po-iasen:
void Task1( void )
{
for (;;) {
//......... code
OS_Delay(10, Task1a); //tuk se predava upravlenieto na kernela
}
}
void Task2( void )
{
for (;;) {
OS_WaitBinSem(BINSEM1_P, Task2a); //tuk se predava upravlenieto na kernela
//......... code
}
}
void Task3( void )
{
for (;;) {
//......... code
OS_Yield(Task3a); //tuk se predava upravlenieto na kernela
//......... code
OS_Yield(Task3b); //tuk se predava upravlenieto na kernela
}
}
I sega konkretnia vapros: Kak izglejdat tezi funkcii s parametur eticket?
Real-Tiime UML
Аз съм разглеждал SALVO която е за PIC-ове. Обаче личното ми мнение е, че за толкова малки микроконтролери е тъпо да се облагаш на някаква конкретна ОС. Защото паметта им е толкова малко, че ако програмираш 1-2 седмици можеш да им я запълниш до дупка. Аз предпочитам всичко да си правя сам.
За реалното време:
Ако става дума за реакции в точно определено време(интервали) просто си ползваш таймерите, като от прекъсванията викаш критицхноте операции. Можеш в един таймер нагласен да свършва сравнително бързо, да си сложиш колкото искаш броячи, които ги декрементваш при всяко прекъсване и когато се нулират викаш задача: така синхронизираш с един таймер много задачи искащи различно време.
За Multitasking:
Ами бих ти преоръчал един модел на Rational Rose, тези дето са разработили UML. Има специална редакция на UML за real-time. Може и сам да го търсиш в Google, но ето от мен един линк:
[линк]
В техния модел има едно понятие Capsule, която представлява грубо краен автомат (finite state machine), дето притежава някакъв брой пощенски кутии (message box). Крайния автомат чете какво има в пощенските кутии, прави нещо, праща съобщение до други капсули,, и минава в друго състояние. После излиза (return). Главната пограма в един безакраен цикъл вика капсулите, които вършат предходното за всеки такт/повикване, помнейки си номера на последното състояние за да могат да се върнат в него при следващия такт.
Крайния автомат на C се реализира лесно чрез дълъг switch-case по номера на състоянието (ще се сетиш и за други начини).
Има и tool-сове за UML, но аз ползвам само идеята и структорния им подход, без да се втелявам много в стандартите. Всичко си правя на ръка. Критичните по време операции ги правя чрез таймери и прекъсвания, а останалото моделирам чрез капсули, като ги въртя в безкраен цикъл в главната програма.
Препоръчвам ти моя подход, особено ак се занимаваш с малки микроконтролери като PIC и AVR.
Ало ти е интересно, мога да напиша малко код, но стига, че стана дълго.
За реалното време:
Ако става дума за реакции в точно определено време(интервали) просто си ползваш таймерите, като от прекъсванията викаш критицхноте операции. Можеш в един таймер нагласен да свършва сравнително бързо, да си сложиш колкото искаш броячи, които ги декрементваш при всяко прекъсване и когато се нулират викаш задача: така синхронизираш с един таймер много задачи искащи различно време.
За Multitasking:
Ами бих ти преоръчал един модел на Rational Rose, тези дето са разработили UML. Има специална редакция на UML за real-time. Може и сам да го търсиш в Google, но ето от мен един линк:
[линк]
В техния модел има едно понятие Capsule, която представлява грубо краен автомат (finite state machine), дето притежава някакъв брой пощенски кутии (message box). Крайния автомат чете какво има в пощенските кутии, прави нещо, праща съобщение до други капсули,, и минава в друго състояние. После излиза (return). Главната пограма в един безакраен цикъл вика капсулите, които вършат предходното за всеки такт/повикване, помнейки си номера на последното състояние за да могат да се върнат в него при следващия такт.
Крайния автомат на C се реализира лесно чрез дълъг switch-case по номера на състоянието (ще се сетиш и за други начини).
Има и tool-сове за UML, но аз ползвам само идеята и структорния им подход, без да се втелявам много в стандартите. Всичко си правя на ръка. Критичните по време операции ги правя чрез таймери и прекъсвания, а останалото моделирам чрез капсули, като ги въртя в безкраен цикъл в главната програма.
Препоръчвам ти моя подход, особено ак се занимаваш с малки микроконтролери като PIC и AVR.
Ало ти е интересно, мога да напиша малко код, но стига, че стана дълго.
Re: Real-Tiime UML
10x b33. Interesno mi e opredeleno, izlojil si i cenni strategii :) Mislil sam dosta po vaprosa i sam stigal do podobni reshenia. Vse pak vaprosa s prekusvaneto na zadachite po sredata im i vrushtaneto obratno na sushtoto miasto za men ostava nereshen. Problema e po skoro teoretichen.
Re: embedded RTOS
check
Wind River's INTEGRITY
ili
Green Hills
tia sa dvete the best companii v sveta na RTOS
Wind River's INTEGRITY
ili
Green Hills
tia sa dvete the best companii v sveta na RTOS
Re: Real-Tiime UML
Разбирам те какво искаш, и това би могло да го прави някоя RTOS. Всички процесори след прекъсване в стека(хардуерния) пазет адреса на връщане и флаговете. RTOS трябва да ги запомни, заедно с контекста на прекъснатата нишка. После взема друга нишка, възтанавява нейния контекст и прави return към спряната и инструкция.
Всичко това значи, че всяка нишка трябва да си имат свой (софтуерен)стек, и компилатора на C да се съобразява с това. Нааример, SALVO, която е за PIC поддържа компилатора на Microchip, но не поддържа примерно компилатора CCS C, понеже последния маже големи бози.
Значи ако искаш сам да направиш такова нещо, трябва да го правиш на ассемблер основно. После трябва да добавиш помощная библиотека за C която, е API. Трябва да подмениш и стартуп-кода (това което работи преди да се предаде управлението на main()) понеже там се инициализира стека и динамичната памет за malloc/free. Изобщо може да се наложи преписване на някои библиотеки за C компилатора дето ще ползваш.
Изках да каже, че е досто трудоемко да се направи RTOS. А дали е оправдано? За голями процесори да, но за малки като AVR и PIC се съмнявам. Това е лично мнение.
Заради това, в предишния постинг ти казах как аз предпочитам да рабиотя: без никаква RTOS, ами на гол процесор си правя всичко. Никой не ми прекъсва ниски, аз сам си излизам от някоя, като си запомням до къде съм стигнал, та да мога да се върна. Използването на UML освен модел за програмата ми дава и стандард за писане на документация, което е полезно понякога.
За по-голями процесори има смисъл от RTOS, Знаеш, че Microsoft за целта подават embeded версии на Windows NT/2k/XP. Изолзват се при специализирани компютри за самолети, автомобили, медицинскс апаратура.
Обаче в нашата бананова република чак такива сложни работо не се правят. Ние пишем за PIC и управляваме прахосмукачки :)
Всичко това значи, че всяка нишка трябва да си имат свой (софтуерен)стек, и компилатора на C да се съобразява с това. Нааример, SALVO, която е за PIC поддържа компилатора на Microchip, но не поддържа примерно компилатора CCS C, понеже последния маже големи бози.
Значи ако искаш сам да направиш такова нещо, трябва да го правиш на ассемблер основно. После трябва да добавиш помощная библиотека за C която, е API. Трябва да подмениш и стартуп-кода (това което работи преди да се предаде управлението на main()) понеже там се инициализира стека и динамичната памет за malloc/free. Изобщо може да се наложи преписване на някои библиотеки за C компилатора дето ще ползваш.
Изках да каже, че е досто трудоемко да се направи RTOS. А дали е оправдано? За голями процесори да, но за малки като AVR и PIC се съмнявам. Това е лично мнение.
Заради това, в предишния постинг ти казах как аз предпочитам да рабиотя: без никаква RTOS, ами на гол процесор си правя всичко. Никой не ми прекъсва ниски, аз сам си излизам от някоя, като си запомням до къде съм стигнал, та да мога да се върна. Използването на UML освен модел за програмата ми дава и стандард за писане на документация, което е полезно понякога.
За по-голями процесори има смисъл от RTOS, Знаеш, че Microsoft за целта подават embeded версии на Windows NT/2k/XP. Изолзват се при специализирани компютри за самолети, автомобили, медицинскс апаратура.
Обаче в нашата бананова република чак такива сложни работо не се правят. Ние пишем за PIC и управляваме прахосмукачки :)
Re: Real-Tiime UML
В предишния постинг казах мнението си за RTOS, а сега искам да ти покажа как бих написал твоя пример на ръка без никаква RTOS (на гол процесор). По този начин работят и моите колеги, понеже си имаме работа само с малки микроконтролери PIC.
Сигурен съм, че знаеш как да си го направиш сам, обаче го давам за да е ясно какво имам в предвид да се работи без RTOS. Върши работа за прахосмукачки :) И не е никак трудно, че да си блъскаме главата с някоя RTOS.
.
Както виждаш не съм защитил инкрементването(декрементването) на семафора, понеже достъпа до него е само от Task1 и Task2. Обаче ако го мърдаш от някой хардуерен интерупт, очевидно трябва да заградиш достъпа до него чрез Disable/Enable Global Interupts за да не стане някой фал.
Текста показва крайните автомати, за които говорех. Тези Task-ове са крайните автомати на капсулите (не съм демонстрирал само използването на message box). Отделните състояния (case-овете) трябва да са сравнително кратки, за да може в main() адекватно да се циклят останалите задачи. Понеже е псевдо-паралелно. Ако има нещо по-дълго, то се накъсва изкуствено на малки парчета-състояния.
За критичите по-време неща: Те са или реакция на I/O портовете на процесора или нещо за което се мери точно време. Реализира се в съответните прекъсвания по най-бързия начин. За по-бавната част се праща Message към някоя капсула (Task) която покъсно ще го извърти от главната програма.
Не съм дал пример за Message Box, но сигурно е ясно. В най-простия случай пощенската кутия може да е един байт на който се вдигат/свалят/четат битовете. За по-сложен случай може да си дефинираш
struct Message { int Msg; void* pdata; };
и после да си направиш кутията чрез цикличен списък,
struct MessageBox {
int Count;
int In;
int Out;
struct Message Box[5];
};
Пишеш си (знаеш как) помощни функции, като
void ResetBox(struct MessageBox *mbox);
bool IsEmpty(struct MessageBox *mbox);
bool IsFull(struct MessageBox *mbox);
void WriteMessage(struct MessageBox *mbox, int Msg, void* pdata);
void ReadMessage(struct MessageBox *mbox, int* Msg, void** ppdataa);
Сигурен съм, че знаеш как да си го направиш сам, обаче го давам за да е ясно какво имам в предвид да се работи без RTOS. Върши работа за прахосмукачки :) И не е никак трудно, че да си блъскаме главата с някоя RTOS.
// Да предположим, че Timer1 прекъсва през 1ms
static int Task1_dellay = 0;
// Interrupt
void Timer1Interrupt() {
// ...code
// Обработка на Dellay за Task1
if (Task1_dellay > 0)
Task1_dellay --;
// ...code
}
typedef enum tagT1S { T1S0, T1S1, ... T1Sn } Task1States;
static Task1States Task1State = T1S0;
typedef enum tagT2S { T2S0, T2S1, ... T2Sn } Task2States;
static Task2States Task2State = T2S0;
typedef enum tagT3S { T3Suspend=-1, T3S0=0, T3S1, ... T3Sn } Task3States;
static Task3States Task3State = T3Suspend; // първоначално Task3 е спряна, и
static Task3States Task3SavedState = T3S0; // ще тръгне от T3S0 като се събуди
int BINSEM1_P = 0;
void Task1() {
switch (Task1State) {
case T1S0:
// ...code
// Сега ще чакаме 10ms
Task1_delay = 10;
Task1State = T1S1;
return;
case T1S1:
// Чакаме да минат 10-те милисекунди
if (Task1_dellay == 0) {
// Готово, минали са минимум 10ms
Task1State = T1S2;
}
return;
case T1S2:
// Тук ще събудим (resume) Task3, понеже е спряна
if (Task3State == T3Suspend) {
Task3State = Task3SavedState;
}
// ...code
return;
...
case T1Sn:
BINSEM1_P ++; // Вдигаме семафор
// ...code
return;
}
}
void Task2() {
switch (Task2State) {
case T2S0:
// Тук чакаме семафора да се вдигне
if (BINSEM1_P > 0) {
// Семафора е вдигнат, влизаме
BINSEM1_P --;
Task2State = T2S1;
}
return;
case T2S1:
// ...code
return;
...
case T2Sn:
// Тук ще спрем Task3, ако е в resumed състояние
if (Task3Stete != T3Suspend) {
Task3SavedState = Task3State;
Task3State = T3Suspend;
}
// ...code
return;
}
void Task3() {
switch (Task3State) {
case T3Suspend:
// exit imediately
return;
case T3S0:
// ...code
return;
...
case T3Sn:
// Може Task3 сама да се успи
Task3SavedState = T3S0; // от тук ще продължим
Task3State = T3Suspend;
}
}
// Главна програма////////////////////////////
void main() {
// първо има някаква инициализация
InitAfterReset();
// После безкрайно циклим задачите
for (;;;) {
Task1();
Task2();
Task3();
// ...code
TaskN();
}
}
.
Както виждаш не съм защитил инкрементването(декрементването) на семафора, понеже достъпа до него е само от Task1 и Task2. Обаче ако го мърдаш от някой хардуерен интерупт, очевидно трябва да заградиш достъпа до него чрез Disable/Enable Global Interupts за да не стане някой фал.
Текста показва крайните автомати, за които говорех. Тези Task-ове са крайните автомати на капсулите (не съм демонстрирал само използването на message box). Отделните състояния (case-овете) трябва да са сравнително кратки, за да може в main() адекватно да се циклят останалите задачи. Понеже е псевдо-паралелно. Ако има нещо по-дълго, то се накъсва изкуствено на малки парчета-състояния.
За критичите по-време неща: Те са или реакция на I/O портовете на процесора или нещо за което се мери точно време. Реализира се в съответните прекъсвания по най-бързия начин. За по-бавната част се праща Message към някоя капсула (Task) която покъсно ще го извърти от главната програма.
Не съм дал пример за Message Box, но сигурно е ясно. В най-простия случай пощенската кутия може да е един байт на който се вдигат/свалят/четат битовете. За по-сложен случай може да си дефинираш
struct Message { int Msg; void* pdata; };
и после да си направиш кутията чрез цикличен списък,
struct MessageBox {
int Count;
int In;
int Out;
struct Message Box[5];
};
Пишеш си (знаеш как) помощни функции, като
void ResetBox(struct MessageBox *mbox);
bool IsEmpty(struct MessageBox *mbox);
bool IsFull(struct MessageBox *mbox);
void WriteMessage(struct MessageBox *mbox, int Msg, void* pdata);
void ReadMessage(struct MessageBox *mbox, int* Msg, void** ppdataa);
ако ти се чете литература по възпроса
намери си книгата "Системно програмиране за едночипови микрокомпютри" на Милен Луканчевки. Има я в книжарницата на ТУ София.
В нея се разглежда разработката на мултитаскинг ядро на C за 8051 но има доста информация и за принципите като цяло.
Препоръчвам ти я!
Успех!
М/у другото за какъв процесор ще пишеш?
В нея се разглежда разработката на мултитаскинг ядро на C за 8051 но има доста информация и за принципите като цяло.
Препоръчвам ти я!
Успех!
М/у другото за какъв процесор ще пишеш?
Re: embedded RTOS
да - минималното време за реакция се нарича - ROS, а максималното - TOS, и заради това комбинацията от двете се нарича RTOS.
Re: ако ти се чете литература по възпроса
Tx /thanks, ne trasmit :)/ b33, davash mi dopulnitelno niakoi idei, v momenta sum rojdennik /razbiraite na piana glava, buhal :), stori mi se b33, che vmukvate malko ruski dialekt, no moje i da se burkam/ i ne se zadulbochih v napisanoto /no offence/ , no utre shte hvana podrobnostite. Inache sum nadcenen, za koeto blagodaria :). Tepurva se ucha na C i hvashtam dosta nedostatuci.... :( /kade sam az che da kritikuvam..../ , no povecheto mi prilojenia sa time critical, a roveneto v asemblerskia kod ne mi dava koi-znae kakvi priemushtestva ot pisane na C. Vse pak sum reshil da se osuvarshenstvam :) I poneje ne mi stiga akula za sophisticated programi na C, potursih niakoi/neshto otkril veche Hammerica, koeto za neshtastie se okazva GOLIAM kompromis....
DarkLord, stana mi drago da chuia imeto Milen Lukanchevski, Lichno go poznavam. Shte pogledna kakvo e pisal ex-kolegata:). Za sujalenia specialnostta mi ne se dopirashe do programiraneto i sega se ucha samostoiatelno i razbira se vkluchaia vasha pomosht :)
Blagodaria, nazdrave! Veselo posreshtane na novata!
DarkLord, stana mi drago da chuia imeto Milen Lukanchevski, Lichno go poznavam. Shte pogledna kakvo e pisal ex-kolegata:). Za sujalenia specialnostta mi ne se dopirashe do programiraneto i sega se ucha samostoiatelno i razbira se vkluchaia vasha pomosht :)
Blagodaria, nazdrave! Veselo posreshtane na novata!
Re: ако ти се чете литература по възпроса
Propusnah, procesora za sega e PIC16, gorkite mnogo zian ot kum stack i prekusvania ..... ama imam development za tiah. Inache assemblera i za 51 i Z80 mi e poznat :)
Nazdrave!
Nazdrave!
Re: ако ти се чете литература по възпроса
Ot dosta wreme polzwam ucOS/II - RTOS kojato w nachaloto beshe open source i freeware. I sega e open-source, no poluchawash source ako si kupish knigata na awtora - Jean Labrosse se kazwa, a knigata e "uCOS/II - The Real Time Kernel". ucOS/II ima kum 50-60 porta za razlicni CPU-ta i e uzasno dobra, sertificirana e za health-critical applications. Az sum i prawil tri porta - za TI DSP TMS320VC33, HITACHI H8/S 2144 i TI MSP430 - na poslednija orjazoh taskowete ot 64 na 8 max- subira se w okolo 4 K code i 600 Byte RAM.
Knigata e uzasno dobre napisana, njama nishto obshto s bozata, kojato e sutworil (ili prepisal) onja bulgarin - Milen Lukanchevski. Ima dobre objasneni principite na RTOS, podrobno objasnenie na funkciite na ucOS/II. Ako knigata na Jean Labrosse te interesuwa, imam ja na PDF i DOC.
Knigata e uzasno dobre napisana, njama nishto obshto s bozata, kojato e sutworil (ili prepisal) onja bulgarin - Milen Lukanchevski. Ima dobre objasneni principite na RTOS, podrobno objasnenie na funkciite na ucOS/II. Ako knigata na Jean Labrosse te interesuwa, imam ja na PDF i DOC.
Re: ако ти се чете литература по възпроса
Книгата на този човек ме интересува. Как мога да я получа?
Предварително благодаря за съдействието.
Предварително благодаря за съдействието.
Re: ако ти се чете литература по възпроса
В irc.bookwarez.net #bw-tech я има, можеш да си я дръпнеш от там.
MicroC-OS-II;_The_Real-Time_Kernel,_2nd_Ed_(1998).zip
866 кб е
Just a human.
MicroC-OS-II;_The_Real-Time_Kernel,_2nd_Ed_(1998).zip
866 кб е
Just a human.
Редактирано от Matrix_N на
Re: ако ти се чете литература по възпроса
Междодругото, искам да попитам, какъв компилатор използвате за Пик микроконтролерите ? ( ако случайно е фрее де
)
Just a human.
Just a human.
Re: ако ти се чете литература по възпроса
Не съм руснак - 100% българин съм!
Сторило ти се е така от водката. Ако си пил Сталинская, след 3-тата ще започат да ти се привиждат руснаци със сигурност!
Майтап, де :)
Сторило ти се е така от водката. Ако си пил Сталинская, след 3-тата ще започат да ти се привиждат руснаци със сигурност!
Майтап, де :)
Re: ако ти се чете литература по възпроса
Аз ползвам CCS C който не е много free, но ако искаш мога да ти го дам free :) Обаче == 4.35Mb и ще трябва да го zip-вам на парчета за пощата. Освен това i-neta изобщо не ми е бърз.
Между другото, CCS C никак не ми харесва. Не е ANSI C, изобщо няма линкер и *.obj, асемблера се пише само inline (не можеш да ползваш MPASM и да линкваш MPLINK). Голяма боза, но е евтин ($170) и простичък - сигурно за това много хора го ползват. Аз го ползвам, защото нямам по-хубав.
Иначе това което имам компилира за всички серии, включително 18-та, но без dsp-тата.
Най-добри са според мен компилаторите на Microchip (ползвал съм една бета версия за PIC18, но я изгубих без да искам, а вече я няма на сайта им). Иначе тези на Microchip са скъпи ($300-$400), и трябват отделни компилатори за разичните серрии на PIC.
Търсил съм и нещо за Linux, обаче по последна моя информация дават само асемблер - нямат още C. Ако искаш търси в Google за Linux, може да не съм видял добре.
Между другото, CCS C никак не ми харесва. Не е ANSI C, изобщо няма линкер и *.obj, асемблера се пише само inline (не можеш да ползваш MPASM и да линкваш MPLINK). Голяма боза, но е евтин ($170) и простичък - сигурно за това много хора го ползват. Аз го ползвам, защото нямам по-хубав.
Иначе това което имам компилира за всички серии, включително 18-та, но без dsp-тата.
Най-добри са според мен компилаторите на Microchip (ползвал съм една бета версия за PIC18, но я изгубих без да искам, а вече я няма на сайта им). Иначе тези на Microchip са скъпи ($300-$400), и трябват отделни компилатори за разичните серрии на PIC.
Търсил съм и нещо за Linux, обаче по последна моя информация дават само асемблер - нямат още C. Ако искаш търси в Google за Linux, може да не съм видял добре.