X2 HSERIN Qualifier - only one

[VK4CP]

Hi all

I am using a 28X2 in a project, and wondering why on earth the X2 Hardware serial in only accomodates one qualifier byte?
Why not more qualifiers, like when using the normal SERIN command?

It's such a pity.
My application (reading HEX data from a GPS module, which are not NMEA sentences), has three bytes as preamble, before the actual data packets are sent.

I would have prefered to use the HSERIN, as a background task, but only having one qualifier byte means it cannot be used.

In my mind, this seems like such a major oversight with the the X2 PICAXE.

 

[Svejk]

Most likely is due to the hardware limitation, the native PIC has a 2 byte buffer.

 

[srnet]

You might want to give details of exactly what it is you are trying to do, someone may have a solution for using HSERIN.

Rather than assume the lack of a multibyte qualifier is a 'major oversight' I would be assuming that there is a good reason for it.

 

[VK4CP]

You might want to give details of exactly what it is you are trying to do, someone may have a solution for using HSERIN.

As per above, I am reading a data stream from a GPS.
Due to "byte stuffing", the byte count varies, and is not fixed.
The only constant is the preamble, which is three bytes long, before the actual data.

Reluctantly, I will go back to using SERIN.

I am not looking for a solution to my specific problem, I was just wondering if anyone knew why it was limited to a single byte.

 

[Technical]

As stated above, the internal "silicon" buffering system of two bytes, combined with the option of very high baud rates, means this is the only workable solution for aqualifier.

However in many situations like this people often don't use a qualifier - just accept all data into the scratchpad and then when ready scan the scratchpad buffer manually for your qualifier sequence.

 

[srnet]

Manual page 91;

Users familiar with the serin command will note the hserin command has a
completely different format. This is because the hserin command supports much
higher baud rates than serin, and so is unable to process received bytes ’on the fly’
(e.g. by changing ASCII into binary, as with the serin # prefix), as there is
insufficient time for this processing to occur before the next hserin byte is
received (at high baud rates). Therefore the raw data is simply saved in the
memory and the user program must then process the raw data when all the bytes
have been received.

 

[inglewoodpete]

Use background serial receive! It's a 28x2

As per above, I am reading a data stream from a GPS.

Reluctantly, I will go back to using SERIN.

No need to use hSerin or SerIn or "byte stuffing". Read up on how to use background serial receive into to the scratchpad as mentioned by Technical. You can find the details in hSerSetup. Once you've used background serial reception, you'll never want to use any other method. The scratchpad can receive up to 1024 bytes before you process the received data.

 

[BESQUEUT]

No need to use hSerin or SerIn or "byte stuffing". Read up on how to use background serial receive into to the scratchpad as mentioned by Technical. You can find the details in hSerSetup. Once you've used background serial reception, you'll never want to use any other method. The scratchpad can receive up to 1024 bytes before you process the received data.

I just tried to use background serial receive. To my mind, this is a "circular buffer". So you may be able to receive more than 1024 bytes as soon as you empty buffer quicly than it will be filled.
For example, I was reading VDrive 2 at 9600 bauds and transmiting data at 38400 bauds.
Unfortunately, it seems that "backround receive" only work well when Picaxe is in pause...
So, to my mind, It's not a "backround receive" but a "pause receive"...

Have you ever make this working (without few seconds pause) ?

JYB

 

[inglewoodpete]

I just tried to use background serial receive. To my mind, this is a "circular buffer". So you may be able to receive more than 1024 bytes as soon as you empty buffer quicly than it will be filled.
For example, I was reading VDrive 2 at 9600 bauds and transmiting data at 38400 bauds.
Unfortunately, it seems that "backround receive" only work well when Picaxe is in pause...
So, to my mind, It's not a "backround receive" but a "pause receive"...

Have you ever make this working (without few seconds pause) ?

JYB

I've never seen much evidence of the problem you describe. I never use long pauses in my software because I think it is bad programming practice.

It is important not to run the PICAXE at a slower speed. Use a minimum of 8MHz for 28X1 or 40X1 and 16MHz for a 20X2, 28X2 or 40X2.

Post your minimum working code that demonstrates the problem and forum members may be able to offer further advice.