​ ​ ​ ​ SERIN Without Knowing Length?
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 13

Thread: SERIN Without Knowing Length?

  1. #1
    Senior Member
    Join Date
    Feb 2010
    Location
    Don't Mess With My Texas!
    Posts
    2,559
    Blog Entries
    7

    Lightbulb SERIN Without Knowing Length?

    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.
    - Tex
    __________________________________________________ _______________________
    These words are my opinion, WYLION. Any resemblance to truth or fiction is accidental at best.
    "Truth lies dormant in our future history." ― Tex Clodhopper LXVI
    "Confidence is ignorance. If you're feeling cocky, it's because there's something you don't know." ― Eoin Colfer, Artemis Fowl

  2. #2
    Senior Member
    Join Date
    Nov 2009
    Location
    UK
    Posts
    1,166

    Default

    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.

  3. #3
    Senior Member
    Join Date
    Feb 2010
    Location
    Don't Mess With My Texas!
    Posts
    2,559
    Blog Entries
    7

    Default

    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.

    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
    - Tex
    __________________________________________________ _______________________
    These words are my opinion, WYLION. Any resemblance to truth or fiction is accidental at best.
    "Truth lies dormant in our future history." ― Tex Clodhopper LXVI
    "Confidence is ignorance. If you're feeling cocky, it's because there's something you don't know." ― Eoin Colfer, Artemis Fowl

  4. #4
    Senior Member
    Join Date
    Jan 1970
    Location
    Perth, Western Australia
    Posts
    4,453

    Default

    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.

  5. #5
    Senior Member
    Join Date
    Feb 2010
    Location
    Don't Mess With My Texas!
    Posts
    2,559
    Blog Entries
    7

    Default

    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.
    - Tex
    __________________________________________________ _______________________
    These words are my opinion, WYLION. Any resemblance to truth or fiction is accidental at best.
    "Truth lies dormant in our future history." ― Tex Clodhopper LXVI
    "Confidence is ignorance. If you're feeling cocky, it's because there's something you don't know." ― Eoin Colfer, Artemis Fowl

  6. #6
    Senior Member
    Join Date
    Nov 2009
    Location
    UK
    Posts
    1,166

    Default

    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.

  7. #7
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    24,335

    Default

    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.

  8. #8
    Senior Member
    Join Date
    Feb 2010
    Location
    Don't Mess With My Texas!
    Posts
    2,559
    Blog Entries
    7

    Default

    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! )
    - Tex
    __________________________________________________ _______________________
    These words are my opinion, WYLION. Any resemblance to truth or fiction is accidental at best.
    "Truth lies dormant in our future history." ― Tex Clodhopper LXVI
    "Confidence is ignorance. If you're feeling cocky, it's because there's something you don't know." ― Eoin Colfer, Artemis Fowl

  9. #9
    Senior Member
    Join Date
    Feb 2010
    Location
    Don't Mess With My Texas!
    Posts
    2,559
    Blog Entries
    7

    Default

    Wow! Same problem all the way back to when Hippy was a real hippy?

    Sorry, Hippy, couldn't resist! That was back before Hippy got 'assimilated' ...
    - Tex
    __________________________________________________ _______________________
    These words are my opinion, WYLION. Any resemblance to truth or fiction is accidental at best.
    "Truth lies dormant in our future history." ― Tex Clodhopper LXVI
    "Confidence is ignorance. If you're feeling cocky, it's because there's something you don't know." ― Eoin Colfer, Artemis Fowl

  10. #10
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    24,335

    Default

    Quote Originally Posted by Texasclodhopper View Post
    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.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •