megajohn 3 2 июля, 2013 Опубликовано 2 июля, 2013 · Жалоба Приходится прыгать по разным железкам, и у каждой своя Оська. Поднадоело это, и решил сделать обертки пока что реализовано для TnKernel, частично под TI SYS/BIOS, SmartDSP, WinAPI в чем суть. #define TASK_CREATE(handle,func,priority,stack_size,param,attr) из названий все понятно для TnKernel будет реализовано в #define TASK_CREATE(handle,func,priority,stack_size,param,attr)\ { static unsigned int stack_##handle[stack_size]; \ int ret = tn_task_create(&handle,func,priority,&stack_##handle[stack_size-1],stack_size,param,(attr & SUSPEND_FLAG)?TN_TASK_IDLE:TN_TASK_START_ON_CREATION);\ ASSERT( ret == TERR_NO_ERR ); } для WinApi будет реализовано в #define TASK_CREATE(name,func,priority,stack_size,param,attr) \ static Swintask tsk##name;\ tsk##name.handle=(HANDLE)_beginthreadex(0,stack_size,func,param,(attr & SUSPEND_FLAG) ? /*CREATE_SUSPEND*/0:0,&tsk##name.threadID );terminate=false;\ name=&tsk##name;\ strcpy_s( tsk##name.caption, 20, #name );\ MSG msg;\ PeekMessage(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE) и т.д. и софт становится мультиплатформенным #include <rtos\rtos_cmn.h> TASK_HANDLE my_task; //------------------------------------------------------------------------------ TASK_RETPARAM my_func( void* in_arg ) { TASK_LOOP { ... ToDo ... SLEEP( 100 ); } TASK_RETVAL; } //------------------------------------------------------------------------------ void app( void ) { TASK_CREATE( my_task, my_func, 12, 1000, 0, START_FLAG ); TASK_DELETE( my_task ); } ну и пример для пересылки сообщений #include <rtos\rtos_cmn.h> TASK_HANDLE task_send, task_recv; QUEUE_HANDLE que; //------------------------------------------------------------------------------ TASK_RETPARAM send_func( void* in_arg ) { TASK_LOOP { QUEUE_RESULT result; void* ptr = MALLOC( ... ); ... ToDo ... QUEUE_PUSH_INFINITE( que, ptr, result ); } TASK_RETVAL; } //------------------------------------------------------------------------------ TASK_RETPARAM recv_func( void* in_arg ) { TASK_LOOP { QUEUE_RESULT result; void* ptr; QUEUE_POP_INFINITE( que, &ptr, result ); if( QUEUE_POP_IS_SUCCESS( result ) ) { ... ToDo ... printf( "%s\n", ptr ); FREE( ptr ); } } TASK_RETVAL; } //------------------------------------------------------------------------------ void app( void ) { QUEUE_RESULT result; QUEUE_CREATE( que, 10, result ); ASSERT( QUEUE_CREATE_IS_SUCCESS( result ) ); TASK_CREATE( task_send, send_func, 12, 1000, 0, START_FLAG ); TASK_CREATE( task_recv, recv_func, 12, 1000, 0, START_FLAG ); } собсвенно, как всегда есть шанс изобрести велосипед. Поэтому спрошу - были ли ли у вас подобные идеи и чем все закончилось. Результаты своих трудов прикладываю P.S. с таким обобщенным интерфейсом стало приятнее программировать под WinApi rtos.rar Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
shmur 0 2 июля, 2013 Опубликовано 2 июля, 2013 · Жалоба Сто лет уже так пишем :) Только у нас обертки не макросы, а функции, поэтому каждый порт - это всего лишь набор С файлов, которые и подключаются в проект в зависимости от платформы, а хедер один для всех. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 3 июля, 2013 Опубликовано 3 июля, 2013 · Жалоба Перефразируя известный анекдот про вес младенцев, могу предположить, что (ИМХО): - оптимальная OS под каждый девайс - на радость электронщикам; - везде Linux - на радость программистам; - единый API на все оси - на радость (только) QA-щикам... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 3 июля, 2013 Опубликовано 3 июля, 2013 · Жалоба собсвенно, как всегда есть шанс изобрести велосипед. Поэтому спрошу - были ли ли у вас подобные идеи и чем все закончилось. ... P.S. с таким обобщенным интерфейсом стало приятнее программировать под WinApi Да, это велосипед. Еще на заре осей был разработан POSIX API. POSIX API имеют такие RTOS как eCOS, QNX, RTEMS, Nucleus Plus... А применять макросы для унификации интерфейса - последнее дело, ИМХО. Неудобно при отладке, да и для анализа неудобно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 3 июля, 2013 Опубликовано 3 июля, 2013 · Жалоба CMSIS-RTOS http://www.arm.com/products/processors/cor...ce-standard.php Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
megajohn 3 3 июля, 2013 Опубликовано 3 июля, 2013 · Жалоба всем спасибо, вечерком посмотрю реализацию API P.S. Вот только бы потом не кусать локти, что взял за основу современный CMSIS-RTOS а все юзают устоявшийся POSIX API Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 3 июля, 2013 Опубликовано 3 июля, 2013 · Жалоба всем спасибо, вечерком посмотрю реализацию API P.S. Вот только бы потом не кусать локти, что взял за основу современный CMSIS-RTOS а все юзают устоявшийся POSIX API CMSIS-RTOS это все та же древняя RTX от Keil-а, после рефакторинга. С довольно ограничеными возможностями. Брать это за основу или называть стандартом, довольно странно. И TI и Freescale эту ось в упор не замечают. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
inventor 0 3 июля, 2013 Опубликовано 3 июля, 2013 · Жалоба вставил в параметр макроса при вызове его типа a+b и полдня разбираешься-почему не работает Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
megajohn 3 3 июля, 2013 Опубликовано 3 июля, 2013 · Жалоба вставил в параметр макроса при вызове его типа a+b и полдня разбираешься-почему не работает это в курсе и исправлю Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yuri_t 0 4 июля, 2013 Опубликовано 4 июля, 2013 · Жалоба IMHO, для RTOS самые удачные API у VxWorks - лаконично и поддерживают практически все вещи, специфические именно для реал-тайм ОС. Их вполне можно взять за основу для OSAL(OS abstraction layer) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться