SERIN2 buffer issues...

[cpayne]

Hi. I am trying to read poll then read the data off a RoboteQ motor controller. I can not use the hardware UART, its already being used for the main com. I have it working OK, its just not working great. It misses every now and again. The issue is any data sent to the RoboteQ is echoed back. So I transmit the request, then jump down and read the request. I think what is happening is I am not always getting down to read the entire echo. I have tried waiting for the carrage return too, with mixed results since there are a couple carrage returns echoed. The RoboteQ is 9600, 7 bit data, 1 start bit, 1 stop bit, even parity. I think I have it set up right. Once it goes into error it seems to keep erroring (timing out). Is there a way to clear the buffer (even though there really isn't any). I don't know I have been messing with this too long have tried a bunch of stuff with no total luck

Here are the relavent pieces of code.

'Roboteq Serial
RoboteQ_Baud con 8276 '9600 baud, even parity
'define ser2_CLROERR 1 (this seemed to have no effect)
define ser2_even 1
define ser2_bits 9 (I have tried 8 here too, same results??)
RoboteQ_TX var PORTC.5
RoboteQ_RX var PORTC.0

mainloop:

Motor_Val_L = 10

'command motor 2 forward (this works fine, it does echo back the command though, I ignor it)
SEROUT2 RoboteQ_TX, RoboteQ_Baud, ["!B", hex2 Motor_Val_L, 13]' endif

'qry the encoder, stores in the mailbox, sends the value back, but is
SEROUT2 RoboteQ_TX, RoboteQ_Baud, ["?Q0", 13]'querry encoder1

'qry to read counter MSB Mailbox
SEROUT2 RoboteQ_TX, RoboteQ_Baud, ["*88", 13]

'this is where I timeout from time to time. I have tried waiting for 13, "8", "*88", all with the same inconsitent results.
SERIN2 RoboteQ_RX, RoboteQ_Baud, 15 ,RoboteQ_timeout2,[WAIT("88"), hex2 Encoder1(0)]

... read other bytes here, don't seem to have as many issues with these, they are called with "*89", "*8A", and "*8B", so I only wait for the last digit, the 88 is hard since its two of the same, sometime I suspect I only get on, other times I get both 8s.

RoboteQ_timeout2_Return:

...

trasmit data back via hserial port. When it does not timeout, the value is correct.

goto mainloop

RoboteQ_timeout2:
high L3
pause 20
low L3
goto RoboteQ_timeout2_Return

[Archangel]

Hi. I am trying to read poll then read the data off a RoboteQ motor controller. I can not use the hardware UART, its already being used for the main com.

Any way you could use the pin you are now using to switch the hardware USART in and out, maybe a couple of transistors? Maybe even just a couple of diodes?

[cpayne]

unfortunately no, I have tried a couple things and it get too complicated. Hserial has can't be inverted and I am going through a level converter. Its on a premade PCB so i really don't want to hang a bunch of transiters to invert it. I am also using the Hserial for my main comm and it gets too complicated trying to mix it all together. I am so close with the non hardware one, I am sure its something simple...

[mackrackit]

SERIN2 RoboteQ_RX, RoboteQ_Baud, 15 ,RoboteQ_timeout2,[WAIT("88"), hex2 Encoder1(0)]

... read other bytes here, don't seem to have as many issues with these, they are called with "*89", "*8A", and "*8B", so I only wait for the last digit, the 88 is hard since its two of the same, sometime I suspect I only get on, other times I get both 8s.

Maybe try a longer period before the timeout, and or use two waits. wait for the first 8 then wait for the second 8.

[Jerson]

The fact that you're polling the pin for serial data in itself is the cause for the behaviour mentioned. SerOut2 is a bit-banging routine as is Serin2. Since your motor controller is echoing back all data sent to it, with some processing delay of its own, I suspect, you are not reading back fast enough to catch the data stream with serin2. Another possibility is that the data has already overflowed and the OERR flag is cleared only when you invoke Serin2.

I can suggest you try a dummy Serin2 after each Serout2 statement. I am not sure if this will help in any way. This would keep the OERR clear if it is the one causing the problems. Other than this, I think, the only way out is to have the hardware USART interrupt to tackle this kind of a situation.

[Archangel]

Here is a thread to chew on:
http://www.picbasic.co.uk/forum/showthread.php?t=5651

[cpayne]

Hi. I tried multiple waits (didn't know you could do this). it works a little better, but still not perfect.

I set it up to snoop the data and post it on hyperterminal.

This is what I get
?Q0 ' echo of my command to post 32bit encoder value into mailbox
0B02 'the encoder value -*88
00 'the 2 digit hex return, its the MSB so its zero in this example, but still can't get it
+ 'confimation sent from controller.

I believe the issue is after I send the request to read the *88 register, by the time i get to the next line I may have missed some of it, I tried just waiting for a CR, but sometime I get down and read the CR before the *88, so then it gets out of sequence. My guess is the controller does not consistently respond back at the same time intertvals, so sometimes I get it all other times its quicker than my program (which is just one line). I also played around with putting a pauseus for different ammounts after the tx before the rx, but it did not seem to help.

Another idea would be just to grab the encoder value versus each bit, but I don't know how to do this. its 32bit hex, but only the significant values are sent so I am not sure what to get. I am just relaying this information back to a VB program that I am sure I could use to convert the number to a decimal. I feel I may miss the first part of the response in some cases too.

Thanks

[cpayne]

Is there a way to reset the OERR flag other than serin2?

does this doe anything. I can find very little info on it, but I saw it in the appendix of the picbasic book. I know the same thing exists for HSERIN, but it has a buffer to overflow, serin2 does not. define ser2_CLROERR 1

what would be your suggestion for a dummy serin statement, should include waits, etc, or just try to capture a single byte regardless of the size?

Thanks

[cpayne]

OK. I have it working pretty good with the dummy receives after each tx to catch the junk and prevent overun. Every once in a while though it gets caught up in itself probably from missing a readding and then over running the buffer. How can I check to see if I am in error state before proceeding to the next set of instructions?

somehting like this won't work (will it) since I am not using the hardware USART
OERR VAR RCSTA.1 ' Alias OERR (USART Overrun Error Flag)

I am using a PIC18F2220 with the internal osc. What would be the way of setting up and checking for an error state and what would be the best way to clear it. With all these dummy serin statements my code space is going to get tight...

Thanks for all the help thus far. I think I am almost there!

[cpayne]

BTW, I don't need to recover the lost data, just reset. Its not a big deal to miss loop of data here and there. THe issue I have is once it starts erroring it kinda cascades and keeps getting worse as I go down the line getting other data readings. Thanks again.