Suggestion: HSEROUT functional extension

Hello,

I really like the HSERIN use of the scratchpad memory in order to allow the reception of a number of bytes. In particular the background serial receive option allows flexible, variable-sized dataframes to be used, in particular if the message length itself is included in the dataframe.

What I feel is lacking a bit is a similar flexiible approach for HSEROUT, since the current implementation of this command requires you to specify the number of bytes as a named list. This makes handling of variable-sized somewhat awkward; either you specify a single command with the maximum size and possibly send a lot of dummy bytes, or you use an if-then-else structure with a number of HSEROUT commands with different parameters list lengths in order to simulate to some extent variable sized message sending.

What I would really appreciate is the functional companion of the "HSERIN spaddress, count" command, namely "HSEROUT spaddress, count" (where count can be a variable, of course). This option would allow a process to first construct a message of any size in the scratchpad memory with starting address spaddres and then another, independent process could send this variable-sized message with a single command. This would allow really flexible high-speed transmission as well as efficient coding.

Would there be some spare bytes of flash memory, for example in the future 20X2 , to implement this functional extension?

Best regards,
Jurjen

Doesn't this already do what you want?

Thanks technical, it does probably.
I had thought of it earlier but I made the mistake of thinking that baudrate was bytes per second and thus the surrounding code would relatively take too much time. With bits per second and running at high clock frequency this will not be a problem as the code overhead implementing the loop will probably be small.

Best regards,
Jurjen

The good thing about high-speed serial is that the byte is sent as soon as it is dropped in the send 'mailbox' and sent autonomously to what the PICAXE is doing. While it is being sent the PICAXE program can continue and post the next data as soon as it can minimising inter-byte gaps. The high-speed serial is double-buffered so a byte to send can be posted to be queued-up while the previous is still in the process of being transmitted.

Higher PICAXE operating speed and lower baud rates will gain the most benefit in minimising inter-byte gaps.

Hippy, that is very useful information since this means that if the inter-byte gaps can be minimized through (local) high speed execution of the loop the total transmit time becomes easily predictable as the latter will be governed basically only by the baudrate. The loop code time can then be modeled through a relatively small offset.

I appreciate this info because I am currently designing a fast and extended version of my SerialPower network architecture for X2 (and X1) picaxes which will allow much higher transmit rates as well as variable-sized messages (each message containing between 1 and 32 databytes as described by the first "descriptor" byte of the message). The timeslot size should depend on the message size as well (with short messages requiring only short timeslots) in order to allow maximum network bandwidth. This requires the timing of the transmit loop to be well known. A 20X2 could execute the loop as proposed by technical locally at 64 MHz (other parts of the code may be executed at a slower pace sice the current drawn at 64MHz is considerable).

Many thanks for this information!

Best regards,
Jurjen

hserial vs serial

So, if there is:

hserout 0, (b1)

this byte will quickly be sent into the transmit register of the EUSART, and the program leaves this command and moves on while the EUSART is sending the data. Correct?

Unlike normal serout (and sertxd), which stays on the command while it sends (bit-busts?) the data out. Correct? If not (for sertxd), does it use a (pin-selectable) UART? (still stays on the command while it sends?)

Yes, the program continues while the byte is being sent; it is hardware controlled rather than software bit-banged.

The pins used for high-speed transmit and receive are fixed by chip hardware and cannot be changed.

I've often wondered (but never tried):-
Does the firmware hold the output string in a buffer and check for Tx register status before sending next character to TSR?
If so, how big is the buffer?

Technical will have to field that one, but my take on it -

The output text is already in Program Memory so 'buffered' there, the HSEROUT command extracts one byte of text or gets a variable value, waits for TXSTA<TRMT> to go high ( buffer empty ), writes TXREG, then continues with next byte, variable value or next Basic command.

When TXREG is written the hardware takes over, copies TXREG to TSR, clears TXSTA<TRMT>, and the byte is output, so the Firmware's free to put another byte in TXREG immediately ( while the byte is being sent ), which will be transferred to TSR as soon as the stop bit of the previous byte has been sent.

Worse case then : a first byte in TSR is being output, the second is stored in TXREG waiting for TSR to empty, the Firmware has the third byte ready but is blocked until TXREG moves to TSR.

The buffer is therefore two bytes ( TSR and TXREG ), in as much that the Firmware can send two bytes without any blocking occuring.

So that suggests a 'background' routine transferring byte(s) to the TXREG and waiting for the 'busy' (in the loose sense) bit to be cleared.

So you guess that 2 bytes are banged out 'instantly' then it goes into a wait-for-clear-bit routine for the rest of the byte string. Sounds fair enough.
Not important, just a casual meander.

So the program moves from the multi-value hserout command when the EUSART is holding 1 byte in the TXREG and is part-way through transmitting a byte from it's TSR.

Sorry, I don't follow.
But anyway, hippy is hypothesising.
I didn't want to start a big long discussion , I was just curious.
Its of no real consequence.

The firmware only transfers the byte if the hardware lets it (ie the buffer is empty). So if you have a long 'hserout' data string it is not all done in the background - the bytes are sent as and when the buffer is available, so the hserout command effectively 'finishes' and moves onto the next command when the last two bytes have been transferred to the buffers, which is still quicker then waiting for those bytes to be completely finished before moving on.

Thanks tech. Nice to know. I had visions of a interrupt based thing, but then I have a lot of strange visions....
No need to carry on, as I said just a casual attack of curiousness.