Serial data problem

[The Master]

Hi. I have a loop which checks pir1.5 to see if any serial data is available. If it is then it loops to get it. Im inputting 18 characters at a time but the last few get missed off. Its random how many but always 1-3.

To start with i would like to know is there a limit to how many characters can be stored in the buffer before it starts losing info?

[mister_e]

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...

[The Master]

Does it matter if there is a slight delay before i start getting data from the buffer?

[The Master]

Silly question.



if rcsta.1=1 then
rcsta.4=0
rcsta.4=1
endif


Does that empty the buffer?

[mister_e]

nope that clear the overrun error. If you want to clear the buffer, you need to read RCREG 'till RCIF flag is cleared.



TempVar Var Byte
RCIF var PIR1.5

WHILE RCIF
TempVar = RCREG
WEND

[The Master]

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.

[mister_e]

some pause/pauseus may screwup things here.

How do you send the data?
What's the format?
what is the expected results?

[The Master]

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

[mister_e]

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.


DataByte VAR BYTE[18]

HSERIN [STR DataByte\18]
If DataByte[0]= 255 then DoSomething

[The Master]

Im sure the PC software is setup correctly. I can change the address of the chip fine (that only takes 2 bytes). The PC software works on other chips too.

I think im gonna try a different aproach. Im going to buffer all the incoming data as fast as i can then deal with it every half cycle

Edit: Yes, 18 bytes for control. 2 bytes for an address reset. When sending 18 bytes it misses out 1-3 bytes

[The Master]

I just tried some test code out



'The main loop
loop:

'Check for serial data
if pir1.5=1 then 'Check if there is any serial data
while pir1.5 'Loop through all the data
indata=RCREG 'Get a byte
select case indata
case 255 'Reset the buffer
recpos=0
case else
if recpos<17 then
inbuffer(recpos)=indata
recpos=recpos+1
else
high porta.1
endif
end select
wend
if rcsta.1=1 then
rcsta.4=0
rcsta.4=1
endif
endif
goto loop


Now, that code *should* wait for a 255. When it gets it it resets recpos to 0. Each byte after that should end up in InBuffer until recpos=17. At that point a light should turn on (porta.1)

The reset part does seem to be working but not all the bytes arrive. The light wont come on until i send another 1-3 bytes.

I should point out im not using the MAX232 chip because they havnt arrived yet but instead i linked into one of Matts boxes which has an alternative solution. I cant see why that would cause a problem but ive just found out that when i set the address it gets set to 1 less than what i actually set it to

[The Master]

Woo. Its all working :D Ive only got 1 output working at the moment though. Ive got to put a loop in to handle all outputs and ive got to put the set address code back in but as it is the attached code is working perfectly.

I only have 1 small problem with it. If i send data too fast then the light flickers slightly. Not enough to be annoying but i doubt the PC would ever send commands that fast anyway