Implementing an HSERIN timeout greater than ~30 s @ 8MHz

[John Chris]

Hi there,

By placing an HSERIN command within a loop, one can effectively get away from the limitation imposed on the 'timeout' value (limited to approximately ~32s (65k ms) at 8 MHz).

My question is, as I have implemented the looping in the code shown below, what is the estimated magnitude of the delay time between HSERIN commands ? (I could test this using a timer and sertxd to the terminal windows, however, it seems to me that the time required to execute the additional debug code is not insignificant in comparison with the time I would be trying to measure)

Code:

AwaitDataRequest:
INC counter_c
IF counter_c <= 4 THEN
HSERIN [timeout_SYS_data_prompt,AwaitDataRequest],0,nb_SYS_data_prompt
ELSE
RETURN
ENDIF

...

RETURN

Thanks,

Chris
________

 

[womai]

I don't think you have to worry in your case, since you only want to receive a single byte. The hardware serial in the PIC has a receive buffer that depending on the exact model can hold one or a few bytes (I believe the 18F series is only one byte), so as long as the Picaxe does not receive more than one byte while the program is not on the serin command it will simply get buffered, and then read when you get back to the serin.

By the way, a cleaner implementation would be using the backround hserin; data gets written into the scratchpad without user intervention. You then simply check the hardware serial status flag and/or the value of the hserptr to see if data has already come in. That way you can even receive longer data streams without having to worry about losing a byte.

You can see some example of this in the firmware of my Picaxe scope (admittedly a large program, but the part where serial receive data is handled is short):

http://www.pdamusician.com/lcscope/design_firmware.html

and direct link to the program code:

http://www.pdamusician.com/lcscope/files/lcs_1m_firmware_v1_3_28x2.zip

Wolfgang

 

[John Chris]

Wolfgang,

I appreciate the reply. The value of 'nb_SYS_data_prompt' is typically 6 to 10 bytes. From your description, it would seem doubtful that this many bytes would be buffered.

I have played around with the background receive ... good point. At a certain point during the development of the project I am working on, it made more sense to use the manual receive. I suppose that, in my case, if I could switch between manual and background, I could make this small change. This (switching between manual and background in same program), however, is strongly advised against.

Thanks,

Chris

 

[John Chris]

Do we expect that the delay is on the order of us ? 10s of us ?

If the transition were experienced in the middle of an incoming serial data string, would we, with knowledge of the baud rate, the estimated duration of the transition, be able to estimate the number of bytes that were expected to be transmitted during the transition?

Perhaps we could then compare this number to the number of bytes that the hardware serial is expected to buffer, as Wolfgang has suggested.

Thanks,

Chris

 

[womai]

No, 6-10 bytes won't get buffered by the hardware.

So I see two options:

(1) convert the code to background serial receive. Once that is done you probably never look back, since it's so convenient!

(2) at least one byte can always get buffered by hardware. So you want to make sure that the maximum gap between hserins is less than the time it takes to receive one byte. Without detailed analysis it seems you execute 4 commands after the timeout - a jump to the label, an inc, an if, and the next hserin. Execution speed is approx. 6000 commands at 8 MHz on a X2 Picaxe (a bit slower than non-X Picaxes), so that amounts to ~0.7ms execution time. One data byte is actually 10 bits sent (1 start bit, 8 data bits, 1 stop bit), so the maximum usable data rate would be approx. 14 kbaud if I calculated correctly. I wouldn't go beyond 9600 baud to be on the safe side. Depending on how the hardware implements the receive, you may be able to actually receive almost two bytes before running into trouble, but I'm not sure about that. You could run at a higher clock frequency to push the achievable data rate.

Wolfgang

 

[John Chris]

Thanks, Wolfgang. This makes sense. I appreciate the help.

Chris

 

[hippy]

For completely unsolicted data, when you might not know when it will arrive or how much there will be, using HSERIN background receive is almost certainly the only way to do it reliably.

HSERIN clears the internal byte received flag and then prepares to receive the number of bytes asked for and there will always be a possibility that a byte is received just before the flag is cleared and that byte is then lost forever.