MY thought is with a RTOS, we can move it over to a larger machine with more computing power and not worry about porting too much.
If you haven't written it with an RTOS and you haven't already ported the RTOS to you different platform that task is almost harder than porting the code in the first place. I speak from experience of managing programmers who insisted it was simple and ended up taking four times longer to port the RTOS than it took to write the code originally.
What do you do when the performance is not fast enough?
Review the code for speed improvements, there are always some to be made. If that won't cut it, you sack the guy who chose the original processor.
Code written in C is quite portable, what takes the time is adapting to the different hardware environment you find in a bigger system. But it is not too big a task, you haven't wasted that time / money.
"Fundamentally no, multitasking from an RTOS is implemented by using interrupts. These are set to go off at a certain regular time and the ISR looks at what task needs running next and swaps that in. This is called preemptive multitasking."
Sorry to jump in kinda late here. I recall earlier this summer there was a thread on an Event Scheduler for the Arduino. I have the link to the thread at home.
I am picturing it something like this conceptually in loop, this being the first time I've tried to capture this idea.
I think it is also inlfuenced by a series of articles I've been reading in Elektor magazine "Here comes the bus!" discussing a RS485 based network and how to allocate bus time to the different devices that may be connected.
So conceptually:
You set up your tasks to run on a predermined schedule, so is like multitasking but is not using any interrupts. All tasks I would imagine would have to be written to start, stop, and re-start if needed during their allotted time, or if ran long than the next task would start late - but if finished sooner, things would have a chance to get caught up again.
You have a 5mS and a 10mS time tracker.
Longer tasks get 10mS to run, shorter tasks get 5mS. Or maybe do something with flags to indicate if a 10mS task can start on an earlier boundary if tasks are behind schedule. As I said, just getting this down for the first time.
void loop(){
elapsed_time = current_time = previous_time;
if 10mS (tbd) elapsed: // do odd # tasks
task_tracker=task_tracker+1;
previous_time = current_time
switch(task_tracker){
case 1:
// code
break;
case 3:
//code
break;
:
:
case n-2:
//code
break;
case n:
//code
break;
}
if 5mS (tbd) elapsed: // do even # tasks
task_tracker = task_tracker+1;
switch(task_tracker){
case 0:
// code
break;
case 2:
//code
break;
:
:
case n-2:
//code
break;
case n:
//code
break;
}
}
[code]
The article(s) Iam reading have gotten to the point (I am only up to June) of sending 16 byte messages, part of the message is data to allow the master to ping a slave early if it determines that it needs more data sooner.
For my example, I was envisioning perhaps reading a bunch of sensors perhaps that were independently taking measurements or status, short ones might a simple "I'm here" in response to an hourly query to determine system configuration changes, followed by "I'm on", "I'm off", kind of response, others might be "events detected at times x,y,z,a,b,c" or "data collection: temp, humidity, light level" kind of thing.
Kinda mixing network statusing vs multitasking; master keeping track of multiple things either way.
"Here comes the bus!" discussing a RS485 based network
Thanks for alerting me to this Bob.
I just downloaded all 8 articles and read them, very interesting to see someone going through all the same design decisions I did.
I think though that they have a major flaw in their selection of a magic byte (0xAA) as the sync character. They admit this and say another synchronizing method will have to be found but the project keeps going on. At some point it will be too difficult to make the change.
If you have any serious interest in this sort of thing email me as I've been working on designs for about a year now (I'm not very fast :)). I have an article on the subject coming up in EEtimes and I've just finished a PCB that should allow Arduinos to communicate using a robust RS485 network with little or no code overhead on the Arduino.
Yes, I'm interested, but I was thinking more to adapt it to wireless. giantsfan3 in Hong Kong wants to get some kind of "recognize the xbees" in a room thing going, I am interested in similar but using inexpensive 434 MHz Rx/Tx modules, or maybe transceivers. Still in the thinking about it mode.
I snuck ahead & read the end of Septembe, looks like it goes into October still, so could be a year long article they have planned.
Hey, what would someone do in the situation where the only need for speed is for a display, say instead of 2.8" at 10fps, an actual 7" 30fps but with the same hardware requirements for everything else
I don't understand the question - not sure how 2.8 inches and 10 frame/sec (??) and 7 inches and 30 frame/sec (??) apply to the context of
multitasking, RTOS, etc.
Say for example a project I have for my car, I have my arduino doings ligh control, temperature , volatage and various other monitoring
the interface is a 2.8 " touch screen lcd that the max draw rate is 10 frames per second if im lucky, so my interface is simple and nothing moves fast, but even drawing a page is noticable
the arduino is capable of working with that screen but I can't seem to find a compatible larger screen module, that would be capable of fluid motion, perhaps live feed from something like a backup camera
I believe the ceiling is the processing power and speed of the arduino which can neither process that much or get it to the screen fast enough
How would I approach something like this, since I assume I would need some sort od device that does rtos to handle that
except all I need is the graphics, not the rest that comes along with a bigger processr including the headache lol
If anything an RTOS will make code slower as it just creates more work for the processor.
You won't do better that some well-written procedural code with a few appropriate interrupts.
Your problem may be the processor speed and it may be your code, that depends on what you are trying to draw, how you are drawing it and what support you get from the LCD controller in terms of primitive drawing procedures. If you are drawing every pixel yourself that would take a long time.
However what usually causes flicker and bad-looking redraws is the fact that you have to write into the display RAM while it's being displayed. The best way to do it is have two memory buffers and swap between them, however this has to be implemented at a low level by the LCD manufacturer so there's probably not much you can do in that regard.
In the old days with CRTs you would wait for the H or V retrace period and write into screen memory then. I don't know if that has any equivalent with LCDs though.
perhaps live feed from something like a backup camera
Not one chance in hell of doing the through the Arduino.
void process1 () {
if (millis() - last_millis() > some-time) {
//do other stuff
}
}
The next level up is probably what I said before, a system of software timers with callback functions.
But the right approach depends a lot on what you actually need to do.
Note that technically nothing will be "concurrent", but it may appear to be so depending again on what you need to do.
______
Rob
Is this correct? I would expect process1 to run to completion before process2 is invoked etc?
That's right, it's up to the programmer to ensure each "process" doesn't hog the system and doesn't take too long. (I just noticed a typo, the last one should be process3).
So running to "completion" really means "test something and maybe do something then return" as the last process does, it only does any work every "some-time".
Of course this is not multi-tasking, but to the outside world it may look like it depending on the jobs that needs doing.
You can have multiprocessing by the simple expedient of having multiple processors working together. There was a post a while back about someone (I forget the exact link) who had a whole heap of boards stacked, most of which with their own processors on board to handle the mundane tasks assigned to them. They communicated via I2C to pass messages back and forwards.
I think this is quite a workable way of getting more processing power, without the overhead of some sort of RTOS. In any case, multitasking, or multiprocessing eventually hits some sort of bottleneck (eg. access to RAM, EPROM, display screen, disk) where it is only feasible for one processor (or process) to be doing it at once. Then you have to control those accesses with semaphores etc. and the thing starts to become a mess.
For one of the examples given earlier (car control with LCD screen) that is a good case of where the LCD controller could be a separate processor chip, whose only job is to keep the screen nicely updated.
We have been working in another thread on a "blink two LEDs" example, which demonstrates the general idea of doing multiple things "at once".
The other thing you could consider, which would have a low overhead, is some sort of coroutine concept (like Lua has) where you have a yield/resume idea. You could conceivably implement something along those lines, but I tend to think that the shortage of RAM is going to mitigate against it somewhat.
dannix:
Is this correct? I would expect process1 to run to completion before process2 is invoked etc?
You are correct. But if you break the task down into small pieces each "process" could just do one small useful thing (like check a switch, test if an LED need to change state etc.).
Graynomad:
That's right, it's up to the programmer to ensure each "process" doesn't hog the system and doesn't take too long. (I just noticed a typo, the last one should be process3).
So running to "completion" really means "test something and maybe do something then return" as the last process does, it only does any work every "some-time".
Of course this is not multi-tasking, but to the outside world it may look like it depending on the jobs that needs doing.
Rob
Ah that's ok. I read it as if it was a simple solution to actually perform multitasking. I'm new to all this and have just rid my design of Delay() having learned this multitasking problem the hard way. As it goes I'd abstracted as you suggested thinking it would multitask...
