Designing and implementing real-time software - where to start?

Hello,

A couple of friends and I are interested in developing a piece of real- time software, which is supposed to run on the LEGO NXT platform. We've already settled on LEJOS and their Java implementation.

We know LEJOS uses fixed-priority scheduling, and judging from a course on real-time software we're taking, that will suffice.

But where do we start? We've been introduced to several scheduling algorithms, worst-case execution time analysis, response time analysis, temporal scopes etc.

We want to document our work in a scientifically correct way, so we're also looking for examples on how that is done in this field.

Up until now, this is what we've done: - Experimented with the NXT platform, sensors and actuators to determine what we can actually expect from it - Implemented small sample applications for LEJOS in Java using the LEJOS Java API

Our intuition tells us we need to do the following to get moving: - Conceptualize our robot construction (defining tasks, task dependencies etc.) - Incrementially build a formal model of our software: defining temporal scopes, try and assign priorities to the identified tasks and do worst-case execution time and response-time analysis, and while doing this try to identify which tasks should be hard-real time (if any)

Any comments on the above or resources on where to read more on the design process is very welcome.

Kind regards, Anders.

Reply to
Anders Sørensen
Loading thread data ...

Putting "Java" and "real time" together in the same statement without a "not" is usually an occasion for hilarity or exasperation. But if the Java run-time supports it you may be able to get by.

You just said the LEJOS environment has fixed-priority scheduling, which certainly implies that the scheduling task has been taken out of your hands.

Usually badly. But if there's a good one out there, I'd love to see links.

Rate Monotonic Scheduling sounds very imposing, and isn't really that hard at all. Dig up a discussion of it, and use it to set your priorities.

To figure out if a task needs to be hard real time just ask yourself how bad the consequences will be if the deadline isn't met. Those deadlines that must be met all the time, every time, are the ones that are hard real time. It is also wise to consider, when you do the analysis, if there is anything that you can do to a task or it's definition to make it _not_ hard real time, and whether a _whole_ task is hard real time, or just a portion of it (consider a serial stream -- dropping a character is way bad, so that's hard real time. But decoding a packet may be an "any old time" thing, so that's not. Hence, you want to collect characters into a buffer in a very high-priority task, but you may want to defer packet parsing to a much lower-priority one).

The most important thing that you can bring to any software effort is discipline. Software projects constantly fail because someone lays down the ground rules for success, and then someone (not always someone else) violates those ground rules. The world is constantly coming up with new ways to succeed, people constantly adopt these new ways, and they constantly fail because of a lack of discipline. Meanwhile, the old ways succeed in the business next door because of the firm exercise of discipline.

--
www.wescottdesign.com
Reply to
Tim Wescott

Quit beating around the bush and do some real embedded work.

VLV

Anders S=F8rensen wrote:

Reply to
Vladimir Vassilevsky

One year ago I wrote library to LEJOS OSEK on LEGO NXT platform which allows to write software in Ada language. More information about this project you can find on my website:

formatting link
and on the project's homepage:
formatting link
.

Maybe you are interested in it.

Good Luck!

--
Piotr Piwko
http://www.embedded-engineering.pl/
Reply to
Piotr

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.