Home » Archived » DSDP - Real-Time Software Components (RTSC) » RTSC and POSIX
|
| Re: RTSC and POSIX [message #307 is a reply to message #297] |
Mon, 13 October 2008 19:00   |
 Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
Michael Ambrus wrote:
> Hi, I'm Michael and I think this stuff is really great.
>
> I'm completely new to rtsc and I'm just starting out to explore (my
> first mission is to figure out all the new acronyms :) ).
> I hear you have ideas about POSIX. I have some experience adapting
> tool-chains to POSIX 1003.1c, perhaps I can help?
>
> Regards
> /Michael
>
>
Thanks!
With regard to POSIX, there are several areas of interest. I've tried to
summarize two below. Your ideas, comments, and contributions are
certainly welcome.
One of the goals of RTSC is to enable embedded developers to create
content that is portable to virtually _any_ execution environment,
including but not limited to POSIX platforms. A common approach to
increasing the portability of a component is to create an "OS
Abstraction Layer" (OSAL, yet another acronym ;) ). The OSAL is called
by the portable code and, as a result, this code will operate in any
environment that the OSAL has been ported to.
The xdc.runtime package
( http://rtsc.eclipse.org/docs-tip/XDCtools_User%27s_Guide#The _xdc.runtime_package)
can be viewed as just such an OSAL. This package provides basic system
services and defines interfaces for "plugging in" underlying
implementations. For example, the xdc.runtime.IGateProvider interface
defines what needs to be implemented to ensure xdc.runtime services are
thread safe.
Why not just use POSIX? As a practical matter, POSIX is just too large
for tiny embedded systems or does not provide enough access to the
underlying HW, especially specialized memories; in order to "fully"
leverage the HW, the app must be non-portable. The xdc.runtime provides
a middle ground that allows greater portable access to the underlying HW.
Although we provide an example POSIX implementation
( http://rtsc.eclipse.org/docs-tip/Extending_xdc.runtime_Gates /Example_1)
of the IGateprovider interface, it would be interesting to have a "POSIX
support package" that also supports memory management, timer services,
etc. Such a package would be used in two different ways:
1. by developers that target applications to POSIX platforms, and
2. by developers that want to "emulate" their system on a POSIX
development workstation and then re-target the code for a more deeply
embedded system that does not or can not support all of POSIX.
We are also considering creating a new package, say "xdc.runtime.knl"
that extends the services provided by xdc.runtime to include threading
services. Again with the idea that components that use xdc.runtime.knl
will be 100% portable to Symbian, POSIX, WinCE, DSP/BIOS, uCOS, ...
|
|
|
| Re: RTSC and POSIX [message #314 is a reply to message #307] |
Mon, 13 October 2008 19:45 |
Michael Ambrus
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
dave russo wrote:
> Michael Ambrus wrote:
>> Hi, I'm Michael and I think this stuff is really great.
>>
>> I'm completely new to rtsc and I'm just starting out to explore (my
>> first mission is to figure out all the new acronyms :) ).
>> I hear you have ideas about POSIX. I have some experience adapting
>> tool-chains to POSIX 1003.1c, perhaps I can help?
>>
>> Regards
>> /Michael
>>
>>
> Thanks!
> With regard to POSIX, there are several areas of interest. I've tried to
> summarize two below. Your ideas, comments, and contributions are
> certainly welcome.
> One of the goals of RTSC is to enable embedded developers to create
> content that is portable to virtually _any_ execution environment,
> including but not limited to POSIX platforms. A common approach to
> increasing the portability of a component is to create an "OS
> Abstraction Layer" (OSAL, yet another acronym ;) ). The OSAL is called
> by the portable code and, as a result, this code will operate in any
> environment that the OSAL has been ported to.
> The xdc.runtime package
>
( http://rtsc.eclipse.org/docs-tip/XDCtools_User%27s_Guide#The _xdc.runtime_package)
> can be viewed as just such an OSAL. This package provides basic system
> services and defines interfaces for "plugging in" underlying
> implementations. For example, the xdc.runtime.IGateProvider interface
> defines what needs to be implemented to ensure xdc.runtime services are
> thread safe.
> Why not just use POSIX? As a practical matter, POSIX is just too large
> for tiny embedded systems or does not provide enough access to the
> underlying HW, especially specialized memories; in order to "fully"
> leverage the HW, the app must be non-portable. The xdc.runtime provides
> a middle ground that allows greater portable access to the underlying HW.
> Although we provide an example POSIX implementation
> ( http://rtsc.eclipse.org/docs-tip/Extending_xdc.runtime_Gates /Example_1)
> of the IGateprovider interface, it would be interesting to have a "POSIX
> support package" that also supports memory management, timer services,
> etc. Such a package would be used in two different ways:
> 1. by developers that target applications to POSIX platforms, and
> 2. by developers that want to "emulate" their system on a POSIX
> development workstation and then re-target the code for a more deeply
> embedded system that does not or can not support all of POSIX.
> We are also considering creating a new package, say "xdc.runtime.knl"
> that extends the services provided by xdc.runtime to include threading
> services. Again with the idea that components that use xdc.runtime.knl
> will be 100% portable to Symbian, POSIX, WinCE, DSP/BIOS, uCOS, ...
Ah, It took me a while to digest what you said and I think we mean two
different things. What I meant was creating a POSIX 1003.1c implementation
altogether from bare-metal and up. I thought rtsc was such a bare-metal OS
abstraction from which you could create a POSIX abstraction, but it seems
it's the other way around?
Bits and pieces from POSIX you have already in the tool-suite; i.e. the
file abstraction. I'm not sure where the boundaries of the CC-Studio
tool-chain, run-time library and this project goes so please apology any
mistakes. Perhaps the mentioned abstraction is part of rtsc?
Here comes a few more newbie questions:
* What does the acronyms RTSC and XDC stand for?
* The modules seem implemented in some sort of meta language. Where can I
learn more about it?
* Where can I get build tools for this language?
* What kind of output is it? (C code perhaps?)
|
|
|
| Re: RTSC and POSIX [message #329 is a reply to message #314] |
Mon, 13 October 2008 23:11 |
Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
Michael Ambrus wrote:
>
> Ah, It took me a while to digest what you said and I think we mean two
> different things. What I meant was creating a POSIX 1003.1c
> implementation altogether from bare-metal and up. I thought rtsc was
> such a bare-metal OS abstraction from which you could create a POSIX
> abstraction, but it seems it's the other way around?
>
Hummm. This is something that I had not considered. It's quite a bit
of work, but it could be *very* interesting. It would provide POSIX
1003.1c functionality to virtually any platform with an RTOS of any kind.
In the case of 1003.1c, the implementation must at some point manage
platform specific registers (to perform a context-switch, for example).
So, either this implementation contains platform-specific
implementations or it relies on a Hardware Abstraction Layer (HAL).
RTSC does not define this HAL, but the xdc.runtime.knl suggestion might
be sufficient.
In other words, if "done right", the xdc.runtime.knl package should
define interfaces that would allow one to create a POSIX 1003.1c
implementation. This implementation would then be portable to any
platform that can support xdc.runtime.knl. Again, if done right, the
interfaces defined by xdc.runtime.knl should be simple enough to be
easily implemented by any "basic" RTOS (DSP/BIOS, Nucleus, ...).
> Bits and pieces from POSIX you have already in the tool-suite; i.e. the
> file abstraction. I'm not sure where the boundaries of the CC-Studio
> tool-chain, run-time library and this project goes so please apology any
> mistakes.
RTSC contains elements that operate on a "rich client platform" like
your workstation as well as elements that run in deeply embedded
devices, so it can be confusing. When someone says they have a RTSC
component (a package), you don't know if they are talking about a tool
or some embedded content. On the other hand, part of the power of RTSC
comes from the tight integration between these two environments.
The following wiki topic might help:
http://rtsc.eclipse.org/docs-tip/Introducing_RTSC
Perhaps the mentioned abstraction is part of rtsc?
>
> Here comes a few more newbie questions:
>
> * What does the acronyms RTSC and XDC stand for?
RTSC == Real-Time Software Components
XDC == XpanDed C
> * The modules seem implemented in some sort of meta language. Where can
> I learn more about it?
The module primer is a good place to start:
http://rtsc.eclipse.org/docs-tip/RTSC_Module_Primer
> * Where can I get build tools for this language?
We're in the process of moving the XDCtools product to
http://www.eclipse.org/dsdp/rtsc/; the RTSC project is in incubation
phase as we do this. However, the tools are freely available from TI
here:
https://www-a.ti.com/downloads/sds_support/targetcontent/rts c/index.html.
(Unfortunately you have to register to get the tools but there is no
other obligation)
> * What kind of output is it? (C code perhaps?)
>
Components are implemented using C but specified using the RTSC IDL.
The tools generate 100% ANSI C from the RTSC IDL.
>
>
>
>
>
>
|
|
|
| Re: RTSC and POSIX [message #335 is a reply to message #329] |
Tue, 14 October 2008 12:25 |
Michael Ambrus
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
dave russo wrote:
> Michael Ambrus wrote:
>>
>> Ah, It took me a while to digest what you said and I think we mean two
>> different things. What I meant was creating a POSIX 1003.1c
>> implementation altogether from bare-metal and up. I thought rtsc was
>> such a bare-metal OS abstraction from which you could create a POSIX
>> abstraction, but it seems it's the other way around?
>>
> Hummm. This is something that I had not considered. It's quite a bit
> of work, but it could be *very* interesting. It would provide POSIX
> 1003.1c functionality to virtually any platform with an RTOS of any kind.
Yes, there's certainly work involved but I think from the bit's and pieces
I've seen so far that you're going into that directions already. The
bottom layer IMO should contain just the low level components that you
have already identified, i.e. memory management, logging, some type of
printf e.t.a.
> In the case of 1003.1c, the implementation must at some point manage
> platform specific registers (to perform a context-switch, for example).
> So, either this implementation contains platform-specific
> implementations or it relies on a Hardware Abstraction Layer (HAL).
Avoiding target specific code entirely is hard, true. However if one
distinguish between "system" (i.e. the "S" part in OS) and focus just on
"operating" (i.e. the innermost part of a kernel) it's my experience that
besides of the modules mentioned above you need only one more: time. With
that defined you have enough to make a dispatcher.
Time awareness is naturally very target specific, but that is afaik the
only exception to the rule.
Parts of the context switch must of course be architecture specific (and
to a certain extent also tool specific), but it need not be specific
towards peripherals. Periherials should in my opinion preferably be
separated into an entirely different module (BSP).
The context switch itself can be more or less transparent itself. There
are several techniques but basically it's the usual trade-off between
speed and maintainability.
Carefully separated, the totality of needed base components can be broken
down in handleable entities and should be quite possible to implement.
> RTSC does not define this HAL, but the xdc.runtime.knl suggestion might
> be sufficient.
> In other words, if "done right", the xdc.runtime.knl package should
> define interfaces that would allow one to create a POSIX 1003.1c
> implementation.
That would be really great. I'd be happy to help.
> This implementation would then be portable to any
> platform that can support xdc.runtime.knl. Again, if done right, the
> interfaces defined by xdc.runtime.knl should be simple enough to be
> easily implemented by any "basic" RTOS (DSP/BIOS, Nucleus, ...).
You mean to implement the mentioned OS:es? That could be done but for me
there exists only one - POSIX :) Call it Linux, QNX, BSD or "rtscX", as
long as there exists a pthread_create and sem_post/sem_wait based on a
good back-end implementation I'm happy. The "back-end" in this context is
what we discussed above - i.e. the kernel base components of rtsc.
It should be said btw that a full implementation of POSIX 1003.1c is not
possible from bare-metal and up. There are aspects in the standard
describing inter-process (i.e. not only inter-thread) interaction. Those
aspects are quite limited however (I think it affects only two or so
functions). The embedded target can be regarded as a process of it's own,
the only difference is that there is no other process to interact with.
Also for any practically usable embedded application one would need
semaphores and queues which POSIX 1003.1c lacks. Taking a small subset of
POSIX 1003.1b would cover that however.
Partly covering a standard API might sound bad, but is from a transparency
viewpoint much better than inventing ones own (or following a less
recognized one). Application code written for a less featured run time
environment can effortlessly be moved to a more featured one, the other
way is often much harder.
>> Bits and pieces from POSIX you have already in the tool-suite; i.e. the
>> file abstraction. I'm not sure where the boundaries of the CC-Studio
>> tool-chain, run-time library and this project goes so please apology any
>> mistakes.
> RTSC contains elements that operate on a "rich client platform" like
> your workstation as well as elements that run in deeply embedded
> devices, so it can be confusing. When someone says they have a RTSC
> component (a package), you don't know if they are talking about a tool
> or some embedded content. On the other hand, part of the power of RTSC
> comes from the tight integration between these two environments.
I understand. These parts easily become intertwined and sorting them out
can be quite hard and confusing (for one reason because there sometimes
exist natural bidirectional dependencies).
> The following wiki topic might help:
> http://rtsc.eclipse.org/docs-tip/Introducing_RTSC
> Perhaps the mentioned abstraction is part of rtsc?
>>
>> Here comes a few more newbie questions:
>>
>> * What does the acronyms RTSC and XDC stand for?
> RTSC == Real-Time Software Components
> XDC == XpanDed C
Ah, ok.
>> * The modules seem implemented in some sort of meta language. Where can
>> I learn more about it?
> The module primer is a good place to start:
> http://rtsc.eclipse.org/docs-tip/RTSC_Module_Primer
>> * Where can I get build tools for this language?
> We're in the process of moving the XDCtools product to
> http://www.eclipse.org/dsdp/rtsc/; the RTSC project is in incubation
> phase as we do this. However, the tools are freely available from TI
> here:
> https://www-a.ti.com/downloads/sds_support/targetcontent/rts c/index.html.
> (Unfortunately you have to register to get the tools but there is no
> other obligation)
Great. I got in and immediately found another acronym I don't recognize :)
* What is SDO ?
>> * What kind of output is it? (C code perhaps?)
>>
> Components are implemented using C but specified using the RTSC IDL.
> The tools generate 100% ANSI C from the RTSC IDL.
>>
Is "RTSC IDL" what the XDC language syntax is called? Is the IDL part in
any way related to the IDL language?
Cheers
/Michael
|
|
|
| Re: RTSC and POSIX [message #340 is a reply to message #335] |
Tue, 14 October 2008 19:26 |
Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
Michael Ambrus wrote:
>
>> In other words, if "done right", the xdc.runtime.knl package should
>> define interfaces that would allow one to create a POSIX 1003.1c
>> implementation.
>
> That would be really great. I'd be happy to help.
>
Excellent. When we have some written designs, I'll post them on the
RTSC wiki. The current thinking is to provide only very basic threading
and synchronization, something that is easily supported by virtually
_any_ RTOS.
>> This implementation would then be portable to any platform that can
>> support xdc.runtime.knl. Again, if done right, the interfaces defined
>> by xdc.runtime.knl should be simple enough to be easily implemented by
>> any "basic" RTOS (DSP/BIOS, Nucleus, ...).
>
> You mean to implement the mentioned OS:es? That could be done but for me
> there exists only one - POSIX :) Call it Linux, QNX, BSD or "rtscX", as
> long as there exists a pthread_create and sem_post/sem_wait based on a
> good back-end implementation I'm happy. The "back-end" in this context
> is what we discussed above - i.e. the kernel base components of rtsc.
>
The only reason for suggesting this was to highlight the possibility of
a 100% portable implementation of pthreads; if it's possible to portably
leverage the HW specific RTOS implementations (that exist on virtually
all CPUs), you can enable pthreads on CPUs that you've never seen (or
want to see).
For example, TI has a number of different processors that require rather
specialized knowledge in order to create an efficient context switch;
e.g., C6000 DSPs, C2000 micro-controllers, etc. On the other hand, TI
does provide an RTOS for all these processors. A similar situation
exists for processors produced by ADI and Freescale. Moreover, building
atop these RTOSs allows code that directly uses these RTOSs to be used
along side of pthread-based code.
On the other hand, finding the right interface that can both support a
pthreads implementation _and_ can be implemented easily by virtually any
RTOS might be harder than simply defining a few "extension points"
within a POSIX package that others can supply (on an as needed basis).
In fact, the more I think about it, creating a portable POSIX package
that defines a few small interfaces required to support HW-specific
operations might be a good way to start. If these interfaces can be
provided by separate packages and are relatively simple, you can imagine
evolving the interfaces to be something that can be provided by an
existing RTOS. Again, the benefit would be the ability to freely mix
POSIX and other RTOS code bases.
> It should be said btw that a full implementation of POSIX 1003.1c is not
> possible from bare-metal and up. There are aspects in the standard
> describing inter-process (i.e. not only inter-thread) interaction. Those
> aspects are quite limited however (I think it affects only two or so
> functions). The embedded target can be regarded as a process of it's
> own, the only difference is that there is no other process to interact
> with.
>
> Also for any practically usable embedded application one would need
> semaphores and queues which POSIX 1003.1c lacks. Taking a small subset
> of POSIX 1003.1b would cover that however.
>
> Partly covering a standard API might sound bad, but is from a
> transparency viewpoint much better than inventing ones own (or following
> a less recognized one). Application code written for a less featured run
> time environment can effortlessly be moved to a more featured one, the
> other way is often much harder.
>
I agree. Accurately supporting a reasonably large subset of POSIX
enables quite a bit of existing code to be quickly reused. It also
allows developers to stick with a well designed stable/safe API.
>
> Great. I got in and immediately found another acronym I don't recognize :)
>
> * What is SDO ?
Ooops, SDO should not be in the docs. It stands for "Software
Development Organization"; an internal group within TI that is
responsible to development of tools and target content for all of TI.
Where did you see this?
> Is "RTSC IDL" what the XDC language syntax is called?
Yes. We also use the term "XDCspec" to refer to this language. The
RTSC-pedia glossary might help decode some of the acronyms:
http://rtsc.eclipse.org/docs-tip/Glossary#RTSC_IDL
>Is the IDL part in any way related to the IDL language?
Hummmm. There are many IDL languages, most quite similar. When we
designed the RTSC IDL, we considered using a "standard IDL" and tried to
express packages and configuration within these IDLs. We concluded that
it was very hard explain the "discipled used" of a standard IDL required
to ensure robust code generation and it was equally hard to ensure the
discipline is always followed. So we decided to create a "custom" IDL
parser (based on Antlr) that contained keywords "package", "module",
"interface", "config", etc.
Having a keyword for packages, modules, and interfaces means there is no
ambiguity about what these entities are. Unlike the situation C
programmers currently face when they use the word "interface"; is it
simply a header with externs, a header that defines function tables to
allow multiple implementations, how is inheritance handled, ...
>
> Cheers
> /Michael
>
|
|
|
| Re: RTSC and POSIX [message #345 is a reply to message #340] |
Wed, 15 October 2008 14:20 |
Michael Ambrus
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
dave russo wrote:
> The only reason for suggesting this was to highlight the possibility of
> a 100% portable implementation of pthreads; if it's possible to portably
> leverage the HW specific RTOS implementations (that exist on virtually
> all CPUs), you can enable pthreads on CPUs that you've never seen (or
> want to see).
I see the point, and it's a good idea. One of the issues with pThreads is
that "real-time" is not really specified. It's just an API and "real-time"
or not is up to the implementation to provide.
> For example, TI has a number of different processors that require rather
> specialized knowledge in order to create an efficient context switch;
> e.g., C6000 DSPs, C2000 micro-controllers, etc. On the other hand, TI
> does provide an RTOS for all these processors. A similar situation
> exists for processors produced by ADI and Freescale. Moreover, building
> atop these RTOSs allows code that directly uses these RTOSs to be used
> along side of pthread-based code.
In the case where you can or would want to use an already existing kernel
to build on top of, then yes.
On the upside is that if you do it for a fairly well established kernel
you will cover a lot of architectures in one go. You would limit the need
of implementing really low-level details. Difficulty in getting it
right/good/efficient and not having to take the maintainability burden is
also good.
On the downside however might be adding and extra license cost to the end
user. Another disadvantage would also be a certain performance penalty.
One could start with defining an API first which the xdc.runtime.knl can
build upon, and allow the implementation of the primitives be implemented
on either various existing kernels, or in case such doesn't exist or for
other reasons isn't suitable, a native bare-metal implementation.
I've taken the liberty of compiling a list of some primitives which I
think is enough in both cases. I've taken the most common approach (event
driven), which I think is necessary to address the broadest range of
"back-end" kernels:
==============
For threading:
==============
thid_t rbka_thread_create(
char *name,
unsigned int prio,
thread_f start_func,
void *inpar,
size_t stack_size
);
int rbka_thread_distroy( thid_t );
int rbka_join( thid_t , void ** );
int rbka_detach( thid_t );
void rbka_yield( void );
void rbka_exit( int );
void rbka_usleep( unsigned int time_us );
thid_t rbka_get_thid( void );
I havn't added API for changing priorities e.t.a. since this could be done
by higher layers (xdc.runtime.knl) via the thread control block (thid_t).
=====================================================
For bare-metal scenarios you would additionally need:
=====================================================
void rbka_kernel_create( void );
void rbka_kernel_destroy( void );
(One might want scheduling principles to be changed. In case this affects
kernel-wide dispatching, they could be added here.)
============================================================ ======
Semaphores - old pSos inspired.
One locking method is enough - all other can be based on this one:
============================================================ ======
unsigned long rbka_sm_create(
char name[4],
unsigned long init_cnt,
unsigned long flags,
unsigned long *id
);
unsigned long rbka_sm_delete(
unsigned long id
);
unsigned long rbka_sm_p(
unsigned long id,
unsigned long flags,
unsigned long timeout
);
unsigned long rbka_sm_v(
unsigned long id
);
The prefix was just for fun :) I played with the words kernel, real-time &
back-end and came up with Real-time Back End Abstraction (pronounced
"Rebecca").
> On the other hand, finding the right interface that can both support a
> pthreads implementation _and_ can be implemented easily by virtually any
> RTOS might be harder than simply defining a few "extension points"
> within a POSIX package that others can supply (on an as needed basis).
> In fact, the more I think about it, creating a portable POSIX package
> that defines a few small interfaces required to support HW-specific
> operations might be a good way to start. If these interfaces can be
> provided by separate packages and are relatively simple, you can imagine
> evolving the interfaces to be something that can be provided by an
> existing RTOS. Again, the benefit would be the ability to freely mix
> POSIX and other RTOS code bases.
I'm not sure I'd recommend mixing API's from a portability standpoint. At
least without some very strict guidelines. The application programmer
could inadvertently end up with non-portable code, creating a dependency
towards a certain run-time environment.
pThreads is not such a big packages as one might think. It's just a large
bunch of functions. Most of them need only implement a few lines of code.
>>
>> Great. I got in and immediately found another acronym I don't recognize :)
>>
>> * What is SDO ?
> Ooops, SDO should not be in the docs. It stands for "Software
> Development Organization"; an internal group within TI that is
> responsible to development of tools and target content for all of TI.
> Where did you see this?
https://www-a.ti.com/downloads/sds_support/targetcontent/rts c/index.html
>> Is "RTSC IDL" what the XDC language syntax is called?
> Yes. We also use the term "XDCspec" to refer to this language. The
> RTSC-pedia glossary might help decode some of the acronyms:
> http://rtsc.eclipse.org/docs-tip/Glossary#RTSC_IDL
I think inventing a yet new acronym would be fun: RIDL (pronaounced
"riddle") ;)
|
|
|
| Re: RTSC and POSIX [message #350 is a reply to message #345] |
Wed, 15 October 2008 16:40 |
Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
Michael Ambrus wrote:
>
> In the case where you can or would want to use an already existing
> kernel to build on top of, then yes.
> On the upside is that if you do it for a fairly well established kernel
> you will cover a lot of architectures in one go. You would limit the
> need of implementing really low-level details. Difficulty in getting it
> right/good/efficient and not having to take the maintainability burden
> is also good.
>
> On the downside however might be adding and extra license cost to the
> end user. Another disadvantage would also be a certain performance penalty.
>
For what it's worth, DSP/BIOS is free. So you'd immediately cover all
TI CPUs. Also, if the interface is "simple enough", free
implementations might be developed by the community.
Overhead might be an issue, depending on the "impedance mismatch"
between the underlying RTOS services and the back-end interface. But,
if the frequency of backend calls can be kept small, the overhead can be
quite small.
> One could start with defining an API first which the xdc.runtime.knl can
> build upon, and allow the implementation of the primitives be
> implemented on either various existing kernels, or in case such doesn't
> exist or for other reasons isn't suitable, a native bare-metal
> implementation.
>
> I've taken the liberty of compiling a list of some primitives which I
> think is enough in both cases. I've taken the most common approach
> (event driven), which I think is necessary to address the broadest range
> of "back-end" kernels:
>
> ==============
> For threading:
> ==============
> thid_t rbka_thread_create(
> char *name,
> unsigned int prio,
> thread_f start_func,
> void *inpar,
> size_t stack_size
> );
> int rbka_thread_distroy( thid_t );
> int rbka_join( thid_t , void ** );
> int rbka_detach( thid_t );
> void rbka_yield( void );
> void rbka_exit( int );
> void rbka_usleep( unsigned int time_us );
> thid_t rbka_get_thid( void );
>
> I havn't added API for changing priorities e.t.a. since this could be
> done by higher layers (xdc.runtime.knl) via the thread control block
> (thid_t).
>
What's the relationship between thread_destroy and join and detach?
Doesn't detach/join "destroy" the thread?
>
> =====================================================
> For bare-metal scenarios you would additionally need:
> =====================================================
> void rbka_kernel_create( void );
> void rbka_kernel_destroy( void );
>
> (One might want scheduling principles to be changed. In case this
> affects kernel-wide dispatching, they could be added here.)
>
>
> ============================================================ ======
> Semaphores - old pSos inspired.
> One locking method is enough - all other can be based on this one:
> ============================================================ ======
> unsigned long rbka_sm_create(
> char name[4], unsigned long init_cnt, unsigned long
> flags, unsigned long *id );
>
> unsigned long rbka_sm_delete(
> unsigned long id
> );
>
> unsigned long rbka_sm_p( unsigned long id, unsigned long flags,
> unsigned long timeout
> );
>
> unsigned long rbka_sm_v( unsigned long id );
>
> The prefix was just for fun :) I played with the words kernel, real-time
> & back-end and came up with Real-time Back End Abstraction (pronounced
> "Rebecca").
>
>> On the other hand, finding the right interface that can both support a
>> pthreads implementation _and_ can be implemented easily by virtually
>> any RTOS might be harder than simply defining a few "extension points"
>> within a POSIX package that others can supply (on an as needed basis).
>> In fact, the more I think about it, creating a portable POSIX package
>> that defines a few small interfaces required to support HW-specific
>> operations might be a good way to start. If these interfaces can be
>> provided by separate packages and are relatively simple, you can
>> imagine evolving the interfaces to be something that can be provided
>> by an existing RTOS. Again, the benefit would be the ability to
>> freely mix POSIX and other RTOS code bases.
>
> I'm not sure I'd recommend mixing API's from a portability standpoint.
> At least without some very strict guidelines. The application programmer
> could inadvertently end up with non-portable code, creating a dependency
> towards a certain run-time environment.
>
Agreed. I was thinking of being able to integrate separately developed
code bases. For example, TI has a fair amount of code written to the
DSP/BIOS RTOS interfaces, including multi-media frameworks. It would be
interesting to allow this code, which only references DSP/BIOS, to be
used by a pthread-based application. The multi-media framework does not
expose any DSP/BIOS APIs, it provides relatively clean APIs to load/run
a variety of algorithms on one or more CPUs. So the application code
can be pure pthread and easily leverage multi-media services.
>> Yes. We also use the term "XDCspec" to refer to this language. The
>> RTSC-pedia glossary might help decode some of the acronyms:
>> http://rtsc.eclipse.org/docs-tip/Glossary#RTSC_IDL
>
> I think inventing a yet new acronym would be fun: RIDL (pronaounced
> "riddle") ;)
>
LOL. This really hits home, the RTSC team is under constant pressure to
"make RTSC simple" and we take a fair amount of heat for creating a
custom IDL. So "riddle" is likely to catch on.
|
|
|
| Re: RTSC and POSIX [message #355 is a reply to message #350] |
Wed, 15 October 2008 18:49 |
Michael Ambrus
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
dave russo wrote:
> For what it's worth, DSP/BIOS is free. So you'd immediately cover all
> TI CPUs. Also, if the interface is "simple enough", free
> implementations might be developed by the community.
That's a big plus.
> Overhead might be an issue, depending on the "impedance mismatch"
> between the underlying RTOS services and the back-end interface. But,
> if the frequency of backend calls can be kept small, the overhead can be
> quite small.
Agreed, I'm not sure it's worth doing the bare-metal implementation for
the overhead penalty only. I might be in some cases, and it certainly
would for CPU's not covered by any other good or well recognized kernel.
The (theoretical) gain has to be held against the amount of work (both new
code and maintenance).
> What's the relationship between thread_destroy and join and detach?
> Doesn't detach/join "destroy" the thread?
pThreads have some features where certain programming models regarding
master/slave concepts are supported, which is hard to mimic without a
relationship between thread creator and any children may have.
The difference is that "destoy" would kill a thread brutally and release
it's resources, whereas detach will release the parent/child relationship
and join would wait for a child to exit on it's own behalf, with the
additional ability to harvest it's return value.
It would perhaps be possible to do without the parent/child relationship
at this level, but it would be harder to implement the pthread layer
fully. One could leave detach/join out to begin with and see just how far
one gets without them.
>> I'm not sure I'd recommend mixing API's from a portability standpoint.
>> At least without some very strict guidelines. The application programmer
>> could inadvertently end up with non-portable code, creating a dependency
>> towards a certain run-time environment.
>>
> Agreed. I was thinking of being able to integrate separately developed
> code bases. For example, TI has a fair amount of code written to the
> DSP/BIOS RTOS interfaces, including multi-media frameworks. It would be
> interesting to allow this code, which only references DSP/BIOS, to be
> used by a pthread-based application. The multi-media framework does not
> expose any DSP/BIOS APIs, it provides relatively clean APIs to load/run
> a variety of algorithms on one or more CPUs. So the application code
> can be pure pthread and easily leverage multi-media services.
Ah, true - that's actually a really good reason.
>> I think inventing a yet new acronym would be fun: RIDL (pronaounced
>> "riddle") ;)
>>
> LOL. This really hits home, the RTSC team is under constant pressure to
> "make RTSC simple" and we take a fair amount of heat for creating a
> custom IDL. So "riddle" is likely to catch on.
:))
|
|
| |
| Re: RTSC and POSIX [message #364 is a reply to message #360] |
Sat, 18 October 2008 01:19 |
Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
Michael Ambrus wrote:
> I could use some feedback about the ideas so far and some hints about
> how to progress...
>
> I'm ready to start a POSIX 1003.1c layer based on xdc.runtime.knl any
> time (I actually need the pThreads layer for a real application ASAP).
> If the suggested API seems OK I should be able to deliver quite soon. If
> not, please suggest another one. Someone would have to start
> implementing the xdc.runtime.knl as I don't have any knowledge of
> DSP/BIOS at all.
>
If you have an immediate need for posix, I wouldn't wait for
xdc.runtime.knl; I can't commit to a date when this package would be
available, it's still just a proposal at this point. Similarly, unless
you have an interest in using DSP/BIOS, I would proceed with your own
API; it looks like most RTOSs can support it.
If your interested in DSP/BIOS as a back-end, I can provide some contact
information to get you the necessary information.
> Before anything else however, I'd have to get informed about the license
> you had in mind community efforts should comply under and what your view
> about how credit/acknowledgment should be handled (example or existing
> files/projects would be good to review additionally).
>
All source code for eclipse projects is (with limited exceptions) under
EPL. The eclipse development process is pretty well described here:
http://www.eclipse.org/projects/dev_process/development_proc ess.php
Code provided from eclipse.org is very carefully reviewed to ensure all
contributions are properly licensed (i.e., EPL) and no inappropriate
copying of other IP has occurred.
> Project management tools, repositories, coding guidelines e.t.a. would
> also be wonderful to get fairly soon.
>
Eclipse infrastructure provides both cvs and subversion support to
projects but it's up to the project lead which will be used for a
particular project. Right now, RTSC has opted for subversion but we
have not yet put our code base on the eclipse server; we're behind in
getting the code base to eclipse legal for copyright checks which is why
we're still in the incubation phase :(
RTSC coding conventions are here:
http://rtsc.eclipse.org/docs-tip/RTSC_Coding_Conventions. While these
conventions should be followed for any code that is part of the RTSC
project, packages that build atop, such as a posix support package, need
not follow these guidelines. In fact, to maintain compatibility with
existing APIs and alternative "code cultures" it may be necessary to
_not_ follow these conventions.
> Anything else one could have any use of knowing? IRC channels perhaps...
>
> Cheers
>
|
|
| |
| Re: RTSC and POSIX [message #375 is a reply to message #370] |
Wed, 22 October 2008 16:17 |
Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
Michael Ambrus wrote:
> dave russo wrote:
>
>> If you have an immediate need for posix, I wouldn't wait for
>> xdc.runtime.knl;
>
> That?s OK. POSIX is a requirement; I however have both application and a
> POSIX 1003.1c kernel ready for one of TI's newer automotive ARM
> derivatives already. The solution saw first daylight just a week ago but
> is based on a kernel running on quite a few embedded targets. I.e. I'm
> not in an immediate hurry, but I would like to get at least an idea
> about the time frames and directions for xdc.runtime.knl (and if
> possible, provide some motivation in case any of your managers are
> reading this). A requirement that will affect our project sooner or
> later however is one of transparency and alternative solutions. This is
> where I would eventually like to see TI?s xdc.runtime.knl and the POSIX
> 1003.1c layer.
>
The idea of xdc.runtime.knl is to define a small base set of threading
interfaces (not implementations) that can be supported by virtually any
RTOS (including an RTOS for non-TI devices). A requirement is that very
small footprint implementations of these interfaces are possible. This
will allow code written to xdc.runtime.knl interfaces to be, in a
practical sense, 100% portable: the code can be used on virtually any
CPU, from 16-bit micro-controllers up (from any manufacturer).
I can't talk to timeframes, but I'll forward the link to this thread to
TI management and, if you can contribute the backend interface you've
created, it will certainly accelerate the process. We need to create
_real_ implementations of the interfaces with different RTOSs to help
"prove" the design.
> What I?d furthermore like know is how I can help, what kind of help
> you?d be willing to accept and off course what you?d be willing to give
> back. I?m naturally very biased into a certain direction, and if I can
> contribute getting you to turn towards POSIX that would be pleasing on
> it?s own terms. I think TI can gain a lot from providing the pThreads &
> POSIX_RT API in the long run, making such an undertaking quite possible
> to motivate.
POSIX is very attractive. I imagine all CPU manufactures would be very
interested in POSIX support for their devices; an entire class of
(posix) standards-based applications can be supported on any platform
with sufficient memory.
From the RTSC perspective, it is also very interesting: portable
components that are used in more resource constrained platforms that
need threading services can be seamlessly leveraged. In other words,
instead of the immiscible groups of components that need threads (posix,
DSP/BIOS, PROS, ...) that exists today, we can enable all these
components to be easily used in a single system. This squarely hits one
of the primary objectives of RTSC: to enable the kind of component
mix&match the Java community enjoys with components implemented in C.
|
|
|
Goto Forum:
Current Time: Thu Nov 14 07:50:38 GMT 2024
Powered by FUDForum. Page generated in 0.06214 seconds |
] 
Search
Help
Register
Login
Home
