RTOS for embedded systems

Excellent posts!

And as you pointed out yourself, task scheduling and interrupts can be handled without an RTOS.

One further point to add for your considerations; target market. If the device is going to end up in medical, aviation, or other device which has to submit to rigorous certification; you have to consider whether the RTOS is going to be an impediment.

Issues you will face in a structured environment include polymorphism, determinism, abstraction, inheritance,...and more; most of which if not outright banned, will require effort to mitigate. So if the RTOS you are considering has OOP as part of it's funadamental design - how you are going to deal with that would become an issue.

Thanks (both Anonymous Hero for bright point of view and edignan)

Specially our team working on robotic systems(except humonoids and grand autonomus vehicles not yet ;) ) Prototype phases are usually actualized by the programs like matlab, embedded system design achieved by using C, in case of different teams work on different parts (object oriented work) Cpp.

Now, with our new laboratory, with new gadgets like dmu70, fdm abs-400, faro arm etc. we must decide for future plans(we are a non-profit university R&D team. But thinking about commercial product with industrial cooperation)

Come to our specific problem with SW. We have experienced that all new alike prototypes are(build by student groups) somehow became different from their predecessors. However, its not eligible for our optimization purpose. No one wants to discover america again, but there are lots of columbus's :). We want to establish the standards, certainly includes software. But now too many thoughts(and i love that) about the platform. Some of them argue for java, some of them(include me) for C,C++,Python and the new idea of RTOS.

If we build systems like cell phone that portability has enormous importance there is no way to run away from RTOS and also java. But in robotic area we come to question: why should we do that? Like in the myth of NASA use Fortran than fortran is irrevocable. But what about the case of nasa use fortran because the old engineers are familiar with fortran ? I give this example because s.times there may be examples like blabla uses blabla then we should use that.these are the times that i think while we are developing cleverer robots, human-beings getting half-wit.

I wish that there will be more subscriber and we will discuss inside out

tmain,

Since you already use Matlab, have you considered to go all the way with the design suit?

According to Mathwork, you can use graphics, models, and flowcharts to automatically generate code for DSP. You can also generate the test vectors and iterate all the way back to the model when debugging.

I don't know if that works well. I am interested in doing a project with this myself but I would like to have other people opinions before committing $30K in licenses. (less for a university). I had a post a few days ago but nobody with real experience with this development system commented.

If this works as well as advertised, your people shouldn't have to do much programming anymore. You would likely have to use TI's RTOS to make sure that everything integrates properly.

Since you do not mass produce your equipment, the development time is your major concern. It doesn't matter if you spend $10 or $100 on the DSPs. You might as well make sure that you have enough horse power to run the potentially less efficient program. Your objective is most likely to develop as fast as possible.

By the way, you posted this twice today. Try not to repeat this mistake. ;)

I have to say, if you are already modeling in Matlab, porting that straight into the code is certainly the way to go.

I know of an avionics company that does the control laws for the autopilots that way, buy the full suite and just stay in the Matlab environment.

firstly, marcot sorry for duality ;) matlab is a very functional program and entegrating so many system in an environment. But "go all the way with the design suit" i do not think so. matlab is suitable for prototyping. such as, assume that you have a laser sensor and you can easily connect, and than verify your code is working or not. However going into design, matlab will no longer satisfy your design necessities. E.g while your system is working with some disturbances sensor connection is lost, can you handle that ? You do not know anything about the connection of your embedded suit and sensor. There is only a box with a some(not all) parameters! Matlab can be programmed in an proffessional way(like matlab engineers do) but there is not enough documentation about. Other drawback is, it will get accustomed you to laziness. Especially undergraduate students come to us with connected blocs and they suppose that the are doing engineering! i cannot encourage them for copy&paste, drag&drop engineering. Because i know in real working life when the matlab functions are not compotent or efficient for design they will get lost. Summing up, matlab(and alike programs) can be(should be) auxilarry programs for design process but cannot the main developing environment. ps:i cannot use \newline i don't know the problem :)

tamin,

Thank you for pointing out Matlab's limitations. I will make sure that I do not expect too much from the data monitoring features. I do not intend to use Matalb / Simulink in the final product but need to improve the product development stage at my company. We presently code everything in assembler and spend a lot of time on small bugs. It is also very difficult to get access to internal variables in real time during debugging.

Since we intend to upgrade to C programming, we are considering to go all the way to graphical modeling, TI's RTOS, and Simulink automatic code generation. My question is : Is it a wise choice?

I expect the first project to be challenging but will it be worth it at the end? Will I save time on the next related project?

Regards,

Marco

i did not understand the part

"We presently code everything in assembler and spend a lot of time on small bugs. It is also very difficult to get access to internal variables in real time during debugging."

We use assembly because we can access all internal variables, memory spaces etc. and the most efficient code can be written by assembly. But as you said it takes a lot time for writing and debugging.

With using matlab weeks come to hours for design step. Additionally, all the things are visual and easy to debug.You can embed some codes to your own C program to call only visual plotting, etc tools of matlab(it is beatiful for debugging) you can boot pc systems with real time workshop tool(good way to salvage systems like pentium II,III) and so on...

However in the case of embedded programming, it is a little bit complicated. Especially with data structures, you may struggle a lot. It is hard to understand the generated C code, if you think you can debug from C code.

Finally in your situation, it would be a good choice to use matlab or you can choice ni's Labview(especially for data acquisiton), and open source version: SciLab(i did not used it while at the present i am a linux user, ashame of me :-)

Guest,

It is difficult to build the facility to access internal variables in an embedded system like ours because we didn't develop all the bells and whistle of a commercial OS. I didn't use the ICE from the MFG for various reasons. We simply use a PWM output to generate an analog equivalent of fast moving variables monitored with the oscilloscope in real time and have a table of variables accessible at the keypad for the slow ones.

We started the product line ten years ago expecting it to be a fairly simple power converter but the software section grew more complex every years. We never found the courage and time to re-write the code for a real operating system. We tried a small experiment last year where a "board test" was programmed in C and we imported our assembler I/O routines. This was a nightmare as C's registers allocation was not compatible with the way we had coded our routines. We finally got the small test program to work but are not going to repeat this integration experiment on our old product line.

We are now starting fresh on a new product line and intend to use the latest proven programming technology. That is why I asked the opinion of experienced advanced programming toolbox users. Here is my original question:

http://cr4.globalspec.com/thread/31155/Matcad-DSP-Code-Generation

I am still interested in advises from experienced people.

Thank you.

its a good selection.

You can set up modeling and emulate in the way of graphic in simulink. then work in RTW to produce C code in your RTOS. this can sve much times for develop. iN matlab there are plenty of dsp toolbox and simulink.

I dont know why you use 64x series for control system, it appears IT use c2000 for control system, while 64 Davinci is use for image process.

if data is complex you can use 5000 series.

Labview is also a good select, I was told.

marcot, i think first you should try open source version "Scilab" than if you satisfied with this kind of SW you can purchase matlab or labview. Experts usually prefer labview for data acquisition and observation in real time and matlab for system design ( these sw's can do both da with matlab, design with labview do not be confused ) To come our problem. Are there any suggestions about RTOS vs DSP(plain) ??

In the past, I wrote my own simple RTOS. There have been difficulties with this at the beginnig. After reading a few articles over the years, I intend to use a commercial RTOS on my next project(s). This is mostly to ease the integration of the automatically generated code. This is what another group nearby has been doing for many years and they are happy with their real time Linux.

I think that the breaking point is "how complex are your systems". If all you need is a scheduler and interrupts, you can do it yourself. If you want more exotic task control, use somebody else work.

Regards