Does it matter if there is a slight delay before i start getting data from the buffer?
Does it matter if there is a slight delay before i start getting data from the buffer?
Silly question.
Does that empty the buffer?Code:if rcsta.1=1 then rcsta.4=0 rcsta.4=1 endif
nope that clear the overrun error. If you want to clear the buffer, you need to read RCREG 'till RCIF flag is cleared.
Code:TempVar Var Byte RCIF var PIR1.5 WHILE RCIF TempVar = RCREG WEND
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Hmm. I am running that too but only once all the data i want has been received. I dunno.
Ive uploaded the code. Sorry its so long and confusing.
some pause/pauseus may screwup things here.
How do you send the data?
What's the format?
what is the expected results?
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
The PC sends chr(255) chr(chipID) chr(brightness1)... chr(brightness16)
When a 255 arrives the recpos is set to 16. That means it has to wait for an address. If the address matches the chips address then recpos is set to 0 which means 16 bytes are about to come in. It then counts up to 15 as they arrive. Once at 15 it should stop and wait.
If pauses can cause problem then that could be it. I only check for data once every half cycle. Should i check more often? I can check upto 100 times every half cycle. For testing its set to 10 incase you were wondering
which PC software do it?
Are you sure it's 9600 baud and not 250,000 bauds?
So basically it's always a 1+1+16 = 18 data stream?
If so, did you tried with a HSERIN loop? just for debuggig purpose.
Code:DataByte VAR BYTE[18] HSERIN [STR DataByte\18] If DataByte[0]= 255 then DoSomething
Last edited by mister_e; - 2nd December 2007 at 01:36.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Bookmarks