Serin/hserin variable length input allowed?

[kranenborg]

Hello,

I have a question considering the behaviour of serin and hserin for variable-length input (i.e sometimes less bytes are sent than the serin/hserin command expects). Two issues in particular:
- do these commands complete correctly (by filling in remaining registers/scratchpad with zeros)?
- does this even work correctly with background receive for highspeed serin (hsersetup)?

I would like to prescribe the maximum number of databytes that are sent in the system, but allow shorter messages to be sent as well without creating a "hang-up" situation.

Thanks,

Jurjen

 

[Technical]

serin waits for the number of bytes specified by the number of variables to fill. However you could use the timeout (on a 28x1) to timeout after a specified period - at this point the (less than expected) bytes of data received would still be valid

Better still is just to use hserin with background receive. Each byte will be stored in the scratchpad consequatively, so it doesn't matter how many are received. However it can be useful to 'end' each transmission, with, for instance, a CR so the chip knows when the transmission is over.

Have a search in the forum for the VMUSIC2-28X1 interfacing samples, these work like that.

 

[kranenborg]

Thank Technical, I did the search and I'll go through the program

May I assume that your remark <i>&quot;serin waits for the number of bytes specified by the number of variables to fill&quot; </i> also applies to standard &quot;foreground&quot; hserin without timeout (as both serin and hserin use the same RS232 protocol)?

Best regards,
Jurjen

Edited by - kranenborg on 09/08/2007 12:33:09

 

[kranenborg]

I have an additional question concerning the hserin background receive. As I get it from the manual the &quot;hserflag&quot; (indicating that a message is received) is set as soon as the - first - byte is received. This would imply for low datarates it is possible that the full message is not yet received when this bit is set and gets inspected (for example because an interrupt is triggered through SETINTFLAGS). Is my impression correct?

I was triggered by this question because of a comparison with the similar hi2csetup command (slave mode, always operates in background mode). Here a similar hi2cflag is set, but additionally a hi2clast variable gets set as well, indicating (at least as I get it) that the complete message has been sent before the flag and variable have been set. Thus the procedure for setting the flags would be different for hser and i2c.

So the question then remains (for both hser and hi2c) whether the flags get set when the first or the last byte has been received?

Best regards,

Jurjen

Edited by - kranenborg on 09/08/2007 13:31:06

 

[Technical]

Yes to the hserin (not background) question.

You're a little confused with hserin/hi2c.

With hserin:
The flag is set as soon as any byte is received. So further bytes may still be coming.
hserptr is the pointer to the next scratchpad address that is to be written (ie it automatically increments after each byte is received). By reseting to address 0 (or any other value) after processing the data, and then later reading hserptr, you can work out how many bytes have been received since the last reset (ie current hserptr value - start hserptr value).

With hi2c:
The flag is set when any address is written to the PICAXE by the master device.
The hi2clast byte (not a flag) stores the last scratchpad address that was written to by the master device. If two or more bytes have been written, only the last byte written is stored in this byte, ie the previous address is lost.