Quote:
|
Originally Posted by ericand
I'm thinking it is much smaller than that. At most I would expect it to be 26.2ms. What I fear is that the master processor is setting the NEW_SPI
flag every 26.2 ms and assuming that the response will follow the setting
of NEW_SPI by some amount much less than 26.2 ms.
As you say, some testing is in order. We have an interrupt driven clock that we will use to get some numbers for the loop timings. We'll probably use the dashboard to capture the data.
I may need to check to see if we can do something like write the data to the eeprom even if we have been disabled by a code error. That brings up another question,
Can the processor detect when it is disabled by experiencing a code error?
|
In my testing, it has consistently been half of a second.
An easy way to do this test would be to put a while(1) loop in the main program loop, hit the reset button and see how long it takes before the BLROD comes on.
Good luck!
__________________
CMUCam not working? Tracks sporadically? Try this instead:
http://www.falconir.com!
PM me for more information if you are interested (it's open source!).
Want the FIRST Email blasts? See here:
http://www.chiefdelphi.com/forums/sh...ad.php?t=50809
"The harder the conflict, the more glorious the triumph. What we obtain too cheaply, we esteem too lightly; it is dearness only that gives everything its value."
-- Thomas Paine
If it's falling apart it's a mechanical problem. If it's spewing smoke it's a electrical problem.
If it's rampaging around destroying things it's a programming problem.
"All technology is run on 'Magic Smoke' contained within the device. As everyone knows, whenever the magic smoke is released, the device ceases to function."
-- Anonymous
I currently speak: English, some German, Verilog, x86 and 8051 Assembler, C, C++, VB, VB.NET, ASP, PHP, HTML, UNIX and SQL 