SERIN Without Knowing Length?

techElder

Well-known member
#1
Code:
serin [TWOFIFTYMS,BRto],RXPin,BAUD,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc ; 8 bytes
Anyone come up with a way to serin a limited number of bytes, without knowing how many are being sent other than some maximum bytes sent?

The only way I know is to make too big of a buffer and increase the @bptrinc in the serin command. However, then you depend on the timeout to get out of serin.

Something like hserin does with the scratchpad.

Just thought I'd ask. Yeah, I know, just use hserin. And then there are those pesky pin conflicts. Sigh.
 

oracacle

Senior Member
#2
If you were to have an initial serin with the qualifier if you have to which then drop into a fast loop that contains a serin (without a qualifier) with a time out and using @bptrinc. this would place a transmission speed restriction on the sender and would need to ensure that the timeout was long enough to ensure that the next byte is received if it coming - I suppose this would be similar to the OLED firmware iirc. This wold still rely on the @ptrinc buffer style.
 

techElder

Well-known member
#3
It isn't so clear, but there isn't a qualifier; just a timeout with a timeout goto label ("BRto") so, that hurdle is jumped. :D

So, do you think the only way is a do/loop where the timeout label executes an EXIT command? Would this be fast enough @ 32MHz? I don't know either.

It will be over an HC-12 link and probably at 9600 baud to the PICAXE.

Code:
bptr = FIRSTBUFFERBYTE
do
   serin [TWOFIFTYMS,BRto],RXPin,BAUD,@bptrinc
   goto skipIt
   BRto:
      exit
   skipit:
loop until bptr > LASTBUFFERBYTE
 
#4
Tex, Generally speaking, if I'm using a PICAXE for serial data reception, I use an X2. I just don't like the hit-and-miss of foreground serial with or without time-outs - it's too easy to miss data. Timeouts happen at the most inconvenient times!

Having said that, I did use a serial data connection between two M2s (a 08M2 and a 14M2) but I used the serial line as a handshake as well. The slave (receiver) monitored the serial line and only went to the SerIn command when it saw a transition from idle to ready-to-send state. The master, on the other hand, toggled the serial-out line from idle to active, then waited a predetermined period before blurting out the (fixed-length) data packet. But this is between two microcontrollers that I had control of the software AND I used fixed-length data packets.
 

techElder

Well-known member
#5
Yeah, I am actually working on a 20X2 in this project. There are many that would rather have the foreground serin commands, too. And will argue for them.

After Hippy clued me into background receive with hsersetup, I've used it on a 20, 18 & a 40.

Kind of looks like I'm going to byte the bullet and move some pins around to get to my hser pins.
 

oracacle

Senior Member
#6
I would think you can go faster
Code:
bptr = FIRSTBUFFERBYTE
do
   serin [TWOFIFTYMS,BRto],RXPin,BAUD,@bptrinc
loop
   BRto:
          'do stuff here
If I am correct the timeout uses a goto and not a gosub meaning that the will be no issue with stack overflow.
Will it be fast enough? Will it be reliable? Don't know you will have to experiment. For me experimenting to ensure my ideas are going to is one of the best things about being a builder of gadgets. It also why they make thing like breadboards. I have all too often found that something I was thinking was going to work didn't for some reason or another on bread board which saved me from having to redesign a board or try and remove components that have been attached to either PCB or piece of strip board - I have saved a lot of money that way over time.
 

hippy

Technical Support
Staff member
#7
It may be possible to use a SERIN with a timeout in a loop to store to @bptr or @ptr as oracle suggests. You would really have to try it to see if it works and is quick enough.

I would suggest @ptr rather than @bptr because the later could overwrite variables, and using variables could corrupt what was received. It all depends on how much data is received.
 

techElder

Well-known member
#8
I originally leaned to SERIN because I wanted to use either 08M2 or ##X2 and didn't want to get into developing the 2-byte hser background receive. Looks like I need to do that anyway.

Everyone else seems to be using SERIN without problem.

I have managed to isolate the serial input to one routine, so I can detect the processor and add the hardware specific routine as needed. Just wanted to get this prototype tested and working.

The data I/O will certainly be less than 32 bytes, but for now it is less than 16 bytes and more specifically 8 bytes. That's why all the fixed @bptrinc stuff.

I just wanted to be more flexible with one routine to handle all hardware. I don't think speed will be a problem with the HC-12 link.

Sorry for wandering around, but that's what happens before I start coding something. (Again! :D )
 

hippy

Technical Support
Staff member
#10
Everyone else seems to be using SERIN without problem.
Though that will be for fixed length or fixed format messages.

SERIN is not really suited to variable length or unsolicited messages where data may arrive at any time. It may be possible to create a solution using SERIN but HSERIN and background receive using an X2 is what would likely be most appropriate.

HSERIN on an M2 is best suited to receiving unsolicited data of just one or two bytes. HSERIN on an X2 is more suited to longer messages.

The issue of having to rely upon timeouts will also apply to HSERIN unless the messages include some information as to how long those are. Having start markers, data lengths, checksums and end markers are what are usually added to messages to ensure a receiver can reliably identify valid data packets to be extracted from whatever is received.
 

hippy

Technical Support
Staff member
#11
Wow! Same problem all the way back to when Hippy was a real hippy? :D
I'd completely forgotten about that! The CTS proposal of course only works where the sender respects such a CTS signal, doesn't send when it is asserted. HSERIN background receive almost complete avoids the need for CTS as it will receive everything sent. Any CTS needed can be asserted by the PICAXE monitoring how much of the background buffer has been used.
 

techElder

Well-known member
#12
So, in reality and to summarize,

If I want to receive "variable length or unsolicited messages", my hardware is going to have to be an X2 using background hser. I've done that with much faster stuff.

If I want to use a serial protocol that can be common with M2 and X2 hardware, I can use SERIN. However, to do that I have to decide on a fixed length packet format AND handshake (so the message won't be unsolicited) with the sender so SERIN will be prepared to receive the fixed length packet.

Six one way; half a dozen the other, but I really want to make this work with both M2 and X2 hardware.

Really sounds like a plan has formed.

Thanks to all of you for the insight!
 

hippy

Technical Support
Staff member
#13
I think that generally sums it up.

But you don't need a handshake with SERIN so long as the system is designed such that the receiver will be ready to receive before the sender sends.
 
Top