M2 hserout buffering


Senior Member
How background-y is HSEROUT on a 14M2 ?

The limited two-byte hserin buffer is understood and clearly documented, but ....

I'm making a protocol converter for CCTV serial commands; listens for 7/8 byte packets or frames with hserin, manipulates a whole frame of data, and outputs with hserout on a different wired bus. One-way only.

Two areas of interest really ; while a frame is being output, is hserout fully or partly "blocking", is there any hidden buffering? i.e. do we execute the next line of code before all the data is transmitted?
I have an "RTS" control to turn the transmitter on and off (external RS485 hardware) and do not want to turn it off if, say, the last byte is still in the Picaxe buffer.
In reality I will code a short delay anyway, but just trying to establish the basics - should that be at least one- or two-byte transmission times, for example.

Different thought, does the hserin buffer still operate while hserout transmission is in progress? I'm certainly not attempting or expecting full duplex operation, wondering what happens if the next input frame starts to arrive.
In this application, lost or trampled frames aren't a disaster luckily.


Senior Member
Technical's answer is correct, but there is a hidden 'gotcha' !.

The firmware 'gives' the byte to the silicon, but the silicon takes time to send that byte.
If the firmware needs to send another byte before the first byte has been fully sent, the 'hserout' waits for the silicon to be 'empty'.

This means if you are using a slow transmit rate the PICAXE runs slow as well, because it spends a lot of time waiting for the silicon to finish sending.

See the discussion here : http://www.picaxeforum.co.uk/showthread.php?14077-hserout-settimer-and-interrupts-do-they-clash&p=120954&viewfull=1#post120954




Senior Member
Okeydoke, thanks for the previous discussion; I didn't find that before.

For my purposes then, do not disable the external transmitter until at least one character time after hserout has ended, as there will likely be 'one up the spout' still in the tx uart.
I could check the uart busy flag, but a simple delay will do me.

Should incoming data arrive while transmitting (or doing other processing) the 14M2 will buffer up to two chars. If more than two arrive before we read them, too bad it all goes wrong.
I can live with that and don't need elaborate workarounds, the protocol allows detection of corrupt frames and I'll just discard them.


Technical Support
Staff member
Perhaps a good analogy for HSEROUT buffering is helping a builder and his mate build a wall.

The first brick you hand over goes to the builder, the second is taken by his mate whilst the builder is adding the first to the wall. Try and quickly hand over a third and no one can take it; the builder is busy adding the one he has to the wall and his mate already has his hands full.

When the builder has finished laying his brick he takes the one his mate has leaving his mate free to take another form you. When they are both out of bricks the builder takes the next one himself and this cycle continues.

Note that if you quickly hand over two bricks you cannot pass in another without a wait until after the time it takes to lay one brick.

And it will be two time periods before it is guaranteed both bricks will have been laid.

In both cases timed from the point of passing the first over.

So there can be none, one or two "up the spout" at the time you stop handing bricks over.


Senior Member
ah, two! That wasn't clear in the previous thread; but makes sense as it is analogous to the two-byte input.
As I'm dealing in 8-byte packets at relatively low baud, I will allow _at_least_ two whole character times from execution passing on from the hserout


Senior Member
The top seniority on the building site is the builder, he's got a trowel.
Next in line is the builder's mate, he's got a hod.
Bottom of the list is the labourer, he's got a picaxe.

Buzby, ( + Glen Moray )