Jump to content

    
Sign in to follow this  
megajohn

попытка обобщить обертками всякие RTOS

Recommended Posts

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

Поднадоело это, и решил сделать обертки

пока что реализовано для 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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Перефразируя известный анекдот про вес младенцев, могу предположить, что (ИМХО):

- оптимальная OS под каждый девайс - на радость электронщикам;

- везде Linux - на радость программистам;

- единый API на все оси - на радость (только) QA-щикам...

Share this post


Link to post
Share on other sites
собсвенно, как всегда есть шанс изобрести велосипед.

Поэтому спрошу - были ли ли у вас подобные идеи и чем все закончилось.

...

 

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

 

Да, это велосипед.

Еще на заре осей был разработан POSIX API.

POSIX API имеют такие RTOS как eCOS, QNX, RTEMS, Nucleus Plus...

 

А применять макросы для унификации интерфейса - последнее дело, ИМХО.

Неудобно при отладке, да и для анализа неудобно.

 

Share this post


Link to post
Share on other sites

всем спасибо, вечерком посмотрю реализацию API

 

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

Share this post


Link to post
Share on other sites
всем спасибо, вечерком посмотрю реализацию API

 

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

 

 

CMSIS-RTOS это все та же древняя RTX от Keil-а, после рефакторинга.

С довольно ограничеными возможностями.

Брать это за основу или называть стандартом, довольно странно.

И TI и Freescale эту ось в упор не замечают.

Share this post


Link to post
Share on other sites

IMHO, для RTOS самые удачные API у VxWorks - лаконично и поддерживают практически все вещи,

специфические именно для реал-тайм ОС.

 

Их вполне можно взять за основу для OSAL(OS abstraction layer)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this