Questions about OSEK Standards of the ERIKA!

[findfrienda]

Reference Documents:
RD1: Erika's manual : ee_refman_1_4_5.pdf;
RD2: OSEK'S Spec: os233.pdf;

Here, I will list questions about the OSEK Standards which ERIKA's implementation. Pls give helps,thanks!
Q1. Difference of 4 conformance classes between RD1 & RD2.
Question Description:
--- ERIKA's conformance Classes definition(RD1: 2.1.1 Conformance Classes):
"...More than one task with the same priority can coexist at the same time for all the four conformance classes......"
--- OSEK's standard (RD2: 3.2 Conformance):
"...BCC1 (only basic tasks, limited to one activation request per task and one task per priority, while all tasks have different priorities)..."
My Question: How to understand the two definitions above? Does ERIKA's CC is fit for the OSEK Standard's?

[paolo.gai]

Yes, ERIKA Enterprise is OSEK/VDX compliant (just look at the certification http://erika.tuxfamily.org/wiki/index.p ... ifications )

The standard says that you are not required to support more than one task with the same priority in BCC1. But nothing prevents you to do so.

Moreover, all the requirements are stated as minimal requirements. you can always do more if you want to... (for example, there is no limit on the number of task other than the available RAM, whereas the standard says 8 tasks, and so on...)

Ciao,

PJ

[findfrienda]

OK,Thanks!

Another question comes :) !
Now, when I read the source code, I found some key variable is hard to understand. Can give some introductions?

1. EE_th_rnact[] = {};
2. EE_th_nact[] = {};
3. EE_th_status[] = {};
4. EE_th_next[] = {};
5. EE_th_ready_prio[] = {};
6. EE_th_dispatch_prio[] = {};

Please give some help! Thanks!

[paolo.gai]

Hi,

I just put some quick notes on

http://erika.tuxfamily.org/wiki/index.p ... Structures

Ciao,

PJ

[findfrienda]

Thanks to P.J.!

Here are two questions about OSEK standard:
1. About Portablility.
As the OS2.2.3 descripted:"One of the goals of OSEK is to support the portability and re-usability of application software."(OS2.2.3- 1.1 System Pilosophy)
I was doubted:
(1). Dose it means that the app based on ERIAK can run on other OSEK OS, such as ETAS?
(2). If yes, how to implement it? As far as I konw, the code generated by RT-Druid include three parts:oil file; code.c;cfg.h,cfg.c; So, which one of the three part can express this pilosophy?


2. About ORTI file
(1) I read the ORTI file spec and the implementation in ERIKA. I was doubted whether or not it's meaningful to involve ORTI. Beacuse if you wantta use it, you have to open the ORTI configuration macro, which will lead to the complexity and running time to execute the code. While, you need another ORTI file to implement the ORTI debug function. Is it true?
(2) How to produce the ORTI file in ERIKA? By manual or RT-Druid?

Thanks!

[nicola.serreli]

Hi,

Here are two questions about OSEK standard:
1. About Portablility.
As the OS2.2.3 descripted:"One of the goals of OSEK is to support the portability and re-usability of application software."(OS2.2.3- 1.1 System Pilosophy)
I was doubted:
(1). Dose it means that the app based on ERIAK can run on other OSEK OS, such as ETAS?
(2). If yes, how to implement it? As far as I konw, the code generated by RT-Druid include three parts:oil file; code.c;cfg.h,cfg.c; So, which one of the three part can express this pilosophy?

Please, note: "application software". This means that only the application code (code.c, as example) is portable among OSEK OS that supports all features provided by standard an required by the application.
Clearly if the code uses features that are not defined in the standard, those may not be supported/present in other kernels.
Moreover, oil specification declares a set of "standard" elements and attributes but allow to add kernel's specific attributes, then if you compare the oil file for the same application on different OSEK OS, you should find a lot of differences (related only to not standard attributes).
Also Erika requires some not standard attributes and RT-Druid uses them to provide Erika's specific configuration files (eecfg.h and eecfg.c as example). Of course all other OSEK OS have their specific configuration files.

2. About ORTI file
(1) I read the ORTI file spec and the implementation in ERIKA. I was doubted whether or not it's meaningful to involve ORTI. Beacuse if you wantta use it, you have to open the ORTI configuration macro, which will lead to the complexity and running time to execute the code. While, you need another ORTI file to implement the ORTI debug function. Is it true?
(2) How to produce the ORTI file in ERIKA? By manual or RT-Druid?

RT-Druid is able to produce an ORTI file that can be used with Lauterbach. Clearly you can write your file with more or different functionalities.

Best regards,
Nicola

[findfrienda]

There is a doubt ,here. :)

In the file --pkg\kernel\def\inc\ee_common.h--, there exists some codes list here:

Code: Select all

/* Task statuses */
#if defined(__MULTI__) || defined(__WITH_STATUS__)
/* This is needed for initialization purposes 
   in the source code generated by RT-Druid */
#define EE_READY      1
#endif

I was doubted: Does the explanation means that---the ee_common.h file will do according to the RT-Druid's configuration ?

Thanks!

[paolo.gai]

In general they are linked together. The idea here was to limit as much as possible the number of symbols defined in the include files to only the ones really used.

In fact, when I was developing the first versions of ERIKA, I was trying to reduce the footprint as much as I could. And in single stack FP/EDF I found out I could remove the status variable (which was only written and never read nor tested). In multistack FP/EDF for the structure of the code I could not do that. For that reason, the symbols defined were really as minimal as I could.

Nowadays I believe there is not that pressure on the footprint (at least not at the byte level!), so probably if I would rewrite the code today I would have written in a more simpler form... But at the time I wrote that code (2001) it was not like that...

PJ