serin/serout baud values with setfreq 32

[micrometal]

In the manual the notes for the serin command warn against trying to handle "complicated datagrams" at speeds above 4800 baud. I am only moving a handful of incoming bytes into storage to be processed later - nothing complicated there - and I would like to be running at 9600 baud.

More importantly I would like to be using "setfreq m32" - that seems sensible. However the serin/serout command documentation does not list any constants to set the baud rates when running at 32Mhz. Why is that?

 

[J G]

The copy of the manual I have from the Programming Editor V6 has it further down the page under the for all other parts heading as it doesn't apply to older chips - see attached screenshot. If speed and or processing time between receiving bytes becomes an issue, the hardware serial might be useful as I think it has its own (small) buffer it can automatically fill up in the background and according to the manual can cope with higher baud rates.

 

[inglewoodpete]

Yes, it is best that you run the PICAXE as fast as it can go when receiving serial data. This will give it the best chance of your code being able to process the incoming data.

You don't mention which PICAXE you are using. The X2 models offer full background serial data reception into the scratchpad RAM. M2 PICAXEs are not able to buffer serial data beyond two bytes at a time.

Note, though, that use of Debug or SerTxd outputs while debugging are likely to interfere with background serial reception. This is due to internal serial receive interrupts being turned off while Debug or SerTxd commands are being executed.

 

[Flenser]

micrometal,

I am only moving a handful of incoming bytes into storage to be processed later

Your requirement sounds like it could be a good match for using background serial data reception to handle the incoming bytes at higher baud rates so +1 for inglewoodpete's suggestion.

The background serial receive uses the UART hardware on the PIC chip which means the PICAXE firmware needs to use very little CPU to receive the data this way. The significance of this is that all your program has to do is wait for a new byte to be received and copy it into storage.

If you are able to process all the bytes in the time between when the sets of bytes are sent then you may be able to process them directly from the scratchpad buffer where background serial receive saves them without needing an extra step to move them to another storage location.

 

[micrometal]

Thank you @J G and @inglewoodpete and @Flenser for your quick replies. J G - yes, I have seen that info, now you point it out; before I could not see it for looking, as the saying goes!

I am using an 08M2 and still at an early stage of testing out a Bluetooth link. I will probably end up with a 14M2 as I have a very simple function in mind. The upstream link (to an Android 'phone) is working well, and I had the Picaxe link working too once (at 2400 Baud) but something changed and I am having trouble getting back to a known Picaxe/HC-06 interface condition. You have all given me useful information to be getting on with - thanks.

 

[Flenser]

micrometal,

There is good news and bad news.. The bad news is that the background serial receive feature is only available on the X2 chips.
The good news is that with the M2 chips you can still use the UART hardware on the PIC chips with the HSERIN command. The UART hardware on the PIC chips has a 2 character FIFO receive buffer (plus a 1 character serial shift register) but that still gives you around 1ms on average to process each byte @9600 baud.

I have never tested this but I think that if HSERIN will block until the reception of a byte is completed.
Your program can then go away and do something with that byte so long as you get back to another HSERIN before the the hardware UART completes receiving THREE more bytes.
- The first byte received will be written to the 2 character FIFO receive buffer waiting for you next HSERIN
- then the second byte will be written to the 2 character FIFO receive buffer still waiting for you next HSERIN
- but if you don't read that first byte using HSERIN before receiving a third byte is completed then the second byte will overwrite the first byte in the FIFO receive buffer.

So on average you must have no more time between doing HSERINs than it takes to receive 1 byte. i.e. a little over 1ms@9600 baud.

 

[AllyCat]

Hi,

Note that AFAIK all PICaxe M2s appear to have a "bug" in the way that the HSERIN command works. See THIS THREAD and my conclusion in Post #22 (which I might update with more information soon).

I believe I have now "Solved" all the issues and hope to eventually post program code to emulate a much larger buffer, by using interrupts. But it won't be a particularly "simple" program, because of complications with the base PIC "silicon" hardware.

Cheers, Alan.

 

[lbenson]

I have never tested this but I think that if HSERIN will block until the reception of a byte is completed.

HSERIN on the M2s is not blocking (except that in the simulator, it is). If there has been no character received, the variable which is to receive the incoming serial will have the same value which it did before the HSERIN command was issued. Therefore, I set that variable to $ff (which I expect never to receive), and check for <>$ff after the HSERIN. If you expect that you might receive and act on an $ff (and every other character), you can receive into a word set to $FFFF. If a character is received, it will be $00FF.

 

[Flenser]

I made the cardinal mistake of writing my post #5 from memory without checking the manual.

The M2 pic chips have a 2 character FIFO receive buffer, not a 1 character buffer, so I have updated post #5 to reflect this.

 

[AllyCat]

Hi,

- but if you don't read that first byte using HSERIN before receiving a third byte is completed then the second byte will overwrite the first byte in the FIFO receive buffer.

That is not quite correct. When a third "OverRun" byte is received, it (permanently) locks up the "HSERIN" hardware and is not saved. However, the two bytes already in the buffer/FIFO can be recovered, but the hardware will still not receive any more bytes. Thus there is a useful "trick", that if you are (still) receiving bytes into the buffer, there is no need to check the OverRun flag (so that's something that only needs to be done whilst the program is waiting for a byte to arrive).

The only way to restart reception is to Disable the hardware and then Re-Enable it. Unfortunately, it appears the PICaxe HSERIN firmware does this too enthusiastically (i.e. even when it is not needed), sometimes whilst a subsequent byte is being received. That appears to be the source of the "HSERIN Bug" which often prevents it receiving even a second byte reliably (see my link in #7). However, reading the buffer directly with a PEEKSFR command is just as efficient as using the HSERIN command, because both methods must first test that a byte has actually been received, before the buffer (or the returned value) is actually used.

Finally a word of warning, that I've now discovered that the 08M2 runs about 10% faster than the 14M2 when executing this particular type of code. So if the OP is planning to change to a 14M2, it would be wise to check the reliability of your "time-critical" code using that chip (or a 20M2) not an 08M2.

Cheers, Alan.