Depending the way you implemented it, unless your Oscillator speed and/or baudrate settings are not right, i can't figure out what's wrong.
EDIT: but i already experimented some weird stuff with cheap USB-to-Serial adapters...
Depending the way you implemented it, unless your Oscillator speed and/or baudrate settings are not right, i can't figure out what's wrong.
EDIT: but i already experimented some weird stuff with cheap USB-to-Serial adapters...
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
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
Bookmarks