Anyone have experience with OSEK??

[jnz]

Anyone have experience with OSEK? Nutshell overview? Pros/Cons?

Anything at all would be handy. Thanks.

[electrojit]

Not much but had some exposure long back...

1) It can not support dynamic creation of Task - Tasks needs to be defined before compilation for static scheduling and determinism
2) OIL Configuration file needs to be created - with Alarms(kind of timer interrupt), Events, Resources and Tasks
3) Four different kind of Tasks based on multiple activation, suspend support

That is very much in nutshell... if you have some more specific doubt please be elaborate, I or someone might be able to help...

There was one OS named PICOS18 - loosely based on the OSEK standard but without full OIL Configuration. I guess its now offline but you might find it online somewhere.

ERIKA enterprise http://erika.tuxfamily.org/drupal/ also has one such OS.

Few more such OSEK kind of OS were listed here: http://www.sonsivri.to/forum/index.php?topic=31484.0

One of our board member Mr.jlb http://www.sonsivri.to/forum/index.php?topic=31533.0 can also help you.

Regards,
electrojit

[jnz]

Thanks a ton!

Basically, I have a non-RTOS project that's far too developed to switch now, but I realized about 60% through that I had created a lot of OS elements myself and probably should have just started with an RTOS! But for the next project, OSEK is being used by the large companies in this same application so I figured they must know what they are doing.

Not creating dynamic tasks isn't really an issue, I know everything this thing does going in at the start. But I'll have to look more into OIL.

It seems there are a ton of OSEK-compatible OSes available. I'll have to look and see what the real differences are. For whatever project I go to next, I'm also looking at switching from the PIC series controllers to something better supported and more powerful. Mostly better supported. Also an issue with the OSEK OS, I'll need to find one that carries the most support via the distributor or community.

IIRC, OSEK is slightly odd because tasks are not called with arguments, rather the OS rely's on "mailboxes" and "messages" so a message can be internal from task to task or external from task to physical layer/off-board. It's sort of an odd concept to me.

[nick58]

I personally worked with commercial and in-house developed OSEK compliant RTOSes and perhaps the best thing for them was the standardization - you develop some software components for one product, relying on the few OSEK primitives, and you can easily port that code to another product.
From there on, there is a lot and if it goes to the "pros" or "cons" depends on your application and the size of your organization... OSEK is standard for RTOS developed by automotive OEMs in Europe for usage in ECUs. The standard was developed at a time where software in ECUs was small, hardware was more expensive and the expectations of the industry were for reliability, predictability/determinism and very small footprint. These objectives which are OK for all of us, actually are extremely high for automotive and their implementation in OSEK results in longer learning curve and it takes longer time to achieve something... For a team, possibly distributed, with randomly skilled engineers who develop small pieces of functionality for  project taking 2-3 years, such speeds and costs may be OK. For a single person, working on high pace project, who is more interested in being flexible than being punctual about everything - there are much more convenient options nowadays...

[jnz]

I personally worked with commercial and in-house developed OSEK compliant RTOSes and perhaps the best thing for them was the standardization - you develop some software components for one product, relying on the few OSEK primitives, and you can easily port that code to another product.
From there on, there is a lot and if it goes to the "pros" or "cons" depends on your application and the size of your organization... OSEK is standard for RTOS developed by automotive OEMs in Europe for usage in ECUs. The standard was developed at a time where software in ECUs was small, hardware was more expensive and the expectations of the industry were for reliability, predictability/determinism and very small footprint. These objectives which are OK for all of us, actually are extremely high for automotive and their implementation in OSEK results in longer learning curve and it takes longer time to achieve something... For a team, possibly distributed, with randomly skilled engineers who develop small pieces of functionality for  project taking 2-3 years, such speeds and costs may be OK. For a single person, working on high pace project, who is more interested in being flexible than being punctual about everything - there are much more convenient options nowadays...

Pretty much exactly where I landed with that.

I'm the single person in our electrical dept. I'm responsible for absolutely everything, and switching chips or even going to ANY RTOS is a big deal, so going all out to OSEK or AutoSAR without being a teir-one supplier to an automotive company was a pretty stupid idea really! I'm glad I read enough to come to my senses on that. For what I'm doing with "sort-of" diagnostic tools, any common RTOS would be a better choice over OSEK.

The only issue is, still one person, so dumping what I have and moving over to a new toolchain, new micro, new tools, new RTOS, new drivers and stacks, all at once is... concerning. But, in all likelihood, ARM M-series, here I come.

[Elmer]

jnz,

Funny to read your last post, it's pretty much exactly where I found myself a couple of years back, except we were two electrical guys not one. I did all the micro programming thou, and as such had the deciding vote. I don't think we ever did a micro job that was not PIC based since I had a great deal of experience with them, but I always dreamed of moving away from them over to Cortex-M, for numerous reasons I won't list here. After much too long, after I changed job, I finally made the switch to STM32 and today I only use PICs in special low-power applications or if I want a SOT-23 sized micro like their 10F series.

We were probably 6-7 employees in the entire company at that time, with most of the guys on CNC, and moving away from what worked in the electronics dept. was simply not an option during those years, as you say, everything new becomes a major decision.

[jnz]

jnz,

Funny to read your last post, it's pretty much exactly where I found myself a couple of years back, except we were two electrical guys not one. I did all the micro programming thou, and as such had the deciding vote. I don't think we ever did a micro job that was not PIC based since I had a great deal of experience with them, but I always dreamed of moving away from them over to Cortex-M, for numerous reasons I won't list here. After much too long, after I changed job, I finally made the switch to STM32 and today I only use PICs in special low-power applications or if I want a SOT-23 sized micro like their 10F series.

We were probably 6-7 employees in the entire company at that time, with most of the guys on CNC, and moving away from what worked in the electronics dept. was simply not an option during those years, as you say, everything new becomes a major decision.

Went big;   Dumped pic. Got STM32 dev boards, Keil Pro with the middleware, Segger J-Link Ultra, a few third party stacks etc etc. Keil as most people who use it will admit isn't the best IDE out there, but it's far from the worst! It at least consistently works (cough... MPLABX).

So glad I did. I'm just now laying out a small volume product and it's just so much faster to have RTX and middleware up and running day one. I can't believe I wasted so much time on PIC for main micros. I don't care what anyone says, their CAN peripheral is absolute garbage among every software issue they have. Oh well, live and learn.

Still one person team but I can tackle RTOS, USB OTG, File System, etc now with almost no real effort. Everyone talks a big game about this or that, but at the end of the day, you need to get product out the door.

As for the original topic.... OSEK sucks. Unless you need actual OE validation and testing which almost no one does, just use a generic RTOS.

Fwiw.... The PIC 10F series is kinda cool.