Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: попытка обобщить обертками всякие RTOS
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы
megajohn
Приходится прыгать по разным железкам, и у каждой своя Оська.
Поднадоело это, и решил сделать обертки
пока что реализовано для 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
shmur
Сто лет уже так пишем sm.gif Только у нас обертки не макросы, а функции, поэтому каждый порт - это всего лишь набор С файлов, которые и подключаются в проект в зависимости от платформы, а хедер один для всех.
Axel
Перефразируя известный анекдот про вес младенцев, могу предположить, что (ИМХО):
- оптимальная OS под каждый девайс - на радость электронщикам;
- везде Linux - на радость программистам;
- единый API на все оси - на радость (только) QA-щикам...
AlexandrY
Цитата(megajohn @ Jul 2 2013, 16:48) *
собсвенно, как всегда есть шанс изобрести велосипед.
Поэтому спрошу - были ли ли у вас подобные идеи и чем все закончилось.
...

P.S. с таким обобщенным интерфейсом стало приятнее программировать под WinApi


Да, это велосипед.
Еще на заре осей был разработан POSIX API.
POSIX API имеют такие RTOS как eCOS, QNX, RTEMS, Nucleus Plus...

А применять макросы для унификации интерфейса - последнее дело, ИМХО.
Неудобно при отладке, да и для анализа неудобно.
megajohn
всем спасибо, вечерком посмотрю реализацию API

P.S. Вот только бы потом не кусать локти, что взял за основу современный CMSIS-RTOS а все юзают устоявшийся POSIX API
AlexandrY
Цитата(megajohn @ Jul 3 2013, 14:13) *
всем спасибо, вечерком посмотрю реализацию API

P.S. Вот только бы потом не кусать локти, что взял за основу современный CMSIS-RTOS а все юзают устоявшийся POSIX API



CMSIS-RTOS это все та же древняя RTX от Keil-а, после рефакторинга.
С довольно ограничеными возможностями.
Брать это за основу или называть стандартом, довольно странно.
И TI и Freescale эту ось в упор не замечают.
inventor
вставил в параметр макроса при вызове его типа a+b и полдня разбираешься-почему не работает
megajohn
Цитата(inventor @ Jul 3 2013, 17:07) *
вставил в параметр макроса при вызове его типа a+b и полдня разбираешься-почему не работает

это в курсе и исправлю
yuri_t
IMHO, для RTOS самые удачные API у VxWorks - лаконично и поддерживают практически все вещи,
специфические именно для реал-тайм ОС.

Их вполне можно взять за основу для OSAL(OS abstraction layer)
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.