Hi guys,
I am trying to use Erika Enterprise as standalone RTOS.
There are different implementations of the RTOS, but they are not documented:
as - AUTOSAR
edf - ?
fp - ?
frsh - ?
hr - ?
oo - ?
Which one we should choose? Which are the specifics of each one?
I am using a dsPIC33 with xc16 on Linux.
I had a basic boot, and tick timer working, but the scheduler does not enter onto the tasks.
Any advice?
Kind Regards,
EE as standalone
Moderator: paolo.gai
-
- Newbie
- Posts: 4
- Joined: Mon Nov 07, 2016 12:51 pm
EE as standalone
--
Rafael Campos Las Heras
@ Treetech Sistemas Digitais
Rafael Campos Las Heras
@ Treetech Sistemas Digitais
-
- Newbie
- Posts: 4
- Joined: Mon Nov 07, 2016 12:51 pm
Re: EE as standalone
I found the Wiki page that explains the RTOS implamentations:
http://erika.tuxfamily.org/wiki/index.p ... _Structure
http://erika.tuxfamily.org/wiki/index.p ... _Structure
--
Rafael Campos Las Heras
@ Treetech Sistemas Digitais
Rafael Campos Las Heras
@ Treetech Sistemas Digitais
-
- Newbie
- Posts: 4
- Joined: Mon Nov 07, 2016 12:51 pm
Re: EE as standalone
I had it working with __FR__ implementation.
IT was a hand modified ALARM define :)
Anyway, any advice of the kernel implementation to be used?
Kind Regards,
IT was a hand modified ALARM define :)
Anyway, any advice of the kernel implementation to be used?
Kind Regards,
--
Rafael Campos Las Heras
@ Treetech Sistemas Digitais
Rafael Campos Las Heras
@ Treetech Sistemas Digitais
-
- Full Member
- Posts: 166
- Joined: Tue May 10, 2011 2:05 pm
Re: EE as standalone
Hi,
the page you found is quite explicative, in addition a what you find there I can add that HR: is an hierarchical resource reservation scheduler. Another scheduler for research purpose.
I want only to add some more information regarding dsPIC33 architecture:
if I remember correctly all the kernels have been ported on that architecture, but AUTOSAR extensions (mostly of the requirements that AUTOSAR add to OSEK, are related a o"protection" features for code reliability, that simple cannot be implemented without specific hardware support like MPU that are not available on dsPIC33).
I would say that in normal embedded domains the kernels that make sense to be tested are FP (fixed Priority), for the really small overhead in terms of code and executions time, and oo (OSEK) kernel, that is standard and proved to be industrial ready.
Unfortunately OSEK Consortium closed, so there is no more official website with all the documentation, but on the web they can still be accessed. For example here:
http://www.irisa.fr/alf/downloads/puaut ... /os223.pdf
Bye,
Errico
the page you found is quite explicative, in addition a what you find there I can add that HR: is an hierarchical resource reservation scheduler. Another scheduler for research purpose.
I want only to add some more information regarding dsPIC33 architecture:
if I remember correctly all the kernels have been ported on that architecture, but AUTOSAR extensions (mostly of the requirements that AUTOSAR add to OSEK, are related a o"protection" features for code reliability, that simple cannot be implemented without specific hardware support like MPU that are not available on dsPIC33).
I would say that in normal embedded domains the kernels that make sense to be tested are FP (fixed Priority), for the really small overhead in terms of code and executions time, and oo (OSEK) kernel, that is standard and proved to be industrial ready.
Unfortunately OSEK Consortium closed, so there is no more official website with all the documentation, but on the web they can still be accessed. For example here:
http://www.irisa.fr/alf/downloads/puaut ... /os223.pdf
Bye,
Errico