|
It happens...more often than not.Originally Posted by Kamikaze47
You hear 'I need sub-nanosecond accuracy to time my slot cars!'...come on...do you really?
Well if I knew what the trigger and the items involved were, I might have a better idea laying in the back of my head on how to compensate...My main worry was about missing interrupt events. But I guess as long as the interrupt does trigger - say a millisecond late, that shouldn't impact the performance.
|
Ok, i've got 3 interrupts at the moment.
- USB interrupt that just does a USBSERVICE to keep the USB alive - i'm not sure how often this triggers - i heard somewhere that it was every few milliseconds, but that could be wrong.
- INT0 interrupt hooked to the clock line of a PS2 keyboard (High-Low transition means theres a new bit to capture) - don't want to miss any of these bits.
- TMR0 interrupt that triggers every 6mS to scan a grid of buttons.
"I think fish is nice, but then I think that rain is wet, so who am I to judge?" - Douglas Adams
|
That's a bit of a tough one. I've heard anywhere from 10ms all the way up to 250ms (I don't believe that one for a second, or 4 service interrupts)
Only takes a split uSec to handle this one, if all you do is read and store, then return.- INT0 interrupt hooked to the clock line of a PS2 keyboard
Could probably extend this out a bit, or maybe put the work off to a 2nd PIC talking serial to the 1st PIC.- TMR0 interrupt that triggers every 6mS to scan a grid of buttons.
This almost sounds like a game controller, like for a flight sim...
Also, as you read the I2C doc's, keep in mind that the PIC controls everything about the I2C when in master mode. The device being talked to only does something after the PIC makes it do it. Therefore, if the PIC starts something, and then has to wait for a bit to continue doing something, the device will just sit there and happily hang out and wait for it.
|
Interesting. So the PIC implementation of I2C may be useful. I'll have to try it.
Unfortunately, i've only just ordered the EEPROM chip today, so I have to wait for it to arrive to try it out
The reason the timer interrupt is 6mS is because it takes 2 of these interrupts to read 1 row of the matrix, and there are 6 rows, so it takes 72mS to read the entire matrix.
"I think fish is nice, but then I think that rain is wet, so who am I to judge?" - Douglas Adams
|
I2C is Synchronous in nature. So things only happen when the clock is toggled.
If the I2C routines get interrupted, it won't matter, because the clock won't toggle either.
SERIN/OUT requires certain timing between the bits, and fails when interrupted because that timing changes.
I2C won't care.
<br>
DT
|
Oh cool. Good to hear.
Thanks DT and skimask for ur help.
"I think fish is nice, but then I think that rain is wet, so who am I to judge?" - Douglas Adams
|
My PBP manual says:
"The timing of the I2C instructions is set so that standard speed devices
(100kHz) will be accessible at clock speeds up to 8MHz. Fast mode
devices (400kHz) may be used up to 20MHz. If it is desired to access a
standard speed device at above 8MHz, the following DEFINE should be
added to the program: DEFINE I2C_SLOW 1"
My 48Mhz OSC is obviously not "up to 20Mhz".
Do you think it still run at 400kHz by default with a 48Mhz OSC?
"I think fish is nice, but then I think that rain is wet, so who am I to judge?" - Douglas Adams
Members who have read this thread : 0You do not have permission to view the list of names.
Posting Permissions
Bookmarks