Re: Computational limits of the ARM7 processor
Posted: 18 Jun 2012, 22:34
hippicurean,
have you done some basic benchmarking to get a feeling for your algorithm? How many iterations per second you can expect on "bare metal" NXT? I'd suggest something like this:
Try for N big enough that you get a couple of seconds. Keep the inner loop clean: No USB/BT communication, no hardware interaction, no timing in there. Then you can estimate how many calls per sec (and obviously how many ms per call) your core algorithm takes (at least for faked / constant input values).
Consider doing the same for a version of you program WITHOUT the algorithm (replace with dummy call), but with all sensor/motor reads and USB polling. Compare the results (and tell us, I'm curious).
Do you know how exactly the firmware of nxtOSEK works, or what code is produced by Simulink? Are there hardware/software interrupts? Is there an event loop running, is there a task scheduler active? If you can, find out whether all interrupts trigger/fire as they're supposed to. Maybe try to beep every time, optionally with varying frequency. You should be able to pick up variations in sound/frequencies, and you don't need displays or USB to find out what's going on then.
Within many programming environments, it's difficult to have tight inner loops executing forever. Are there any calls to free CPU time or similar things you could insert into your loop? Things like
The very first thing you should know when you're talking about delays as short as 0.000001 (and hence high iteration frequencies) is whether nxtOSEK and your program can handle it, so go benchmark / measure. You'll get a better feeling for what's going on.
have you done some basic benchmarking to get a feeling for your algorithm? How many iterations per second you can expect on "bare metal" NXT? I'd suggest something like this:
Code: Select all
measure start time
repeat N times
{
one iteration of your algorithm WITHOUT reading sensor/motor data
}
measure end time
Consider doing the same for a version of you program WITHOUT the algorithm (replace with dummy call), but with all sensor/motor reads and USB polling. Compare the results (and tell us, I'm curious).
Do you know how exactly the firmware of nxtOSEK works, or what code is produced by Simulink? Are there hardware/software interrupts? Is there an event loop running, is there a task scheduler active? If you can, find out whether all interrupts trigger/fire as they're supposed to. Maybe try to beep every time, optionally with varying frequency. You should be able to pick up variations in sound/frequencies, and you don't need displays or USB to find out what's going on then.
Within many programming environments, it's difficult to have tight inner loops executing forever. Are there any calls to free CPU time or similar things you could insert into your loop? Things like
doEvents, processEvents, wait, sleep, ...? If they are to slow, only call them every Nth iteration.The very first thing you should know when you're talking about delays as short as 0.000001 (and hence high iteration frequencies) is whether nxtOSEK and your program can handle it, so go benchmark / measure. You'll get a better feeling for what's going on.