BasicMicro - Forums

Can I use HSERIN on a BAP28 at 57,600? I am using it with a "BlueSmirf" modem, which is rather a pain to reprogram.

Also, do timeouts work with SERIN? I have tried to use them in the past, it seems to trash a lot of the data being read.

Thanks,
DPT

Nathan can obviously answer this better than I can. But if my memory is correct, the generated baud rate for the 16mhz processor for the baud rate generator is something like 2.1% off which is not good. I know when I use XBees I avoid this and instead use 62500 instead...

The newer SERIN code, I know is better than it used to be at higher baud rates. I believe timeouts do work... But as always if your code is not sitting in a SERIN when the data starts, it won't properly receive it.

Kurt

Hi Kurt:

Does this mean I can run into problems if the timeout occurs after data has been read? (e.g. stray interrupt or something?)

Also, I have version 8.0.1.7 of the IDE, I assume this is reasonably up-to-date?

Thanks,
DPT

Actually you are using something ancient. You should move over to Studio. I am currently running version 2.0.0.13. I don't remember which build it was, but I finally got tired of not being able to output at 115200 to the SSC-32 and measured the generated outputs at different baud rates and deduced an off by 1 error in the timing code. Nathan fixed it and things are a lot nicer now

Yes when you are using bit bang code to read or output stuff to an async serial port any interrupt that happens on the processor can cause the data to be corrupted. That is the nature of the beast. Some other processor code bases error the other way and disable interrupts while they are outputting, but that causes problems as well, like missing characters from the hardware serial port because you did not process the interrupt soon enough... Everything is a set of trade-offs. On my XBee code, I played games of turning off the CTS or was it RTS line which told the XBEE not to send any more characters. I tried using the appropriate parameter to SERIN, but the problem is, that the XBEE may send up to 2 additional characters after that line has been changed, which you will then lose...

Kurt

Using hardware serial on 16mhz AtomPros the error for 57600 is 3.6%(55555bps instead of 57600bps). This is a large amount of error. I recommend not using async serial with errors above 2.5%. However on a 20mhz AtomPro the error is only 1.4% which works fine.

2.5% is the uper cutoff because there are 10 bits(100%/10=10%) then there is sender error and receiver error(10%/2=5%) then there is over error and under error(5%/2=2.5%). As long as you are under 2.5% you should be able to communicate reliably. 3.6% error may work in some situations(where the sender and receiver error cancel out). Assuming the device you are attached to is running perfect rates you can get away with higher error on your side. This isn't a good assumption though.

The possible hardware rates are determined by MHZ/(32*n). n is 1 and up. If you are using a USB2Serial adapter or using a board with builtin USB2Serial you can run some non standard rates which are very fast(625kbps or 500kbps are the highest possible).

_________________
Tech Support
Basic Micro - Robotic Technology Evolved

Hi Kurt,

Still a little confused:
1) Does SERIN use Interrupts to enforce timeouts?; and if so
2) If the input data is present at the time SERIN is called,
do I need to worry about a stray interrupt going off
during the subsequent code? If so, what will happen?
I would assume that if the timeout occurs in the middle
of a SERIN my data will be toast, hopefully that won't
occur to much....

Also, sound like its time to update my IDE

-DPT

1) Nope - I believe it uses some form of count down timer... Again Nathan can answer better as he has the actual code
2)If the data has already started (IE you already got the start bit), that byte of data will not be read correctly. Depending on timing to the next byte, they may all get off...

I don't remember if the timeout value is used for the whole serin time, or per byte wait. i.e. - does it reset when you receive a byte...

Kurt

1. timeouts in serial are from a count down timer. We do not use any hardware features(eg timers or interrupts) in the software serial commands.

2. If you start serin after you already started get the start bit you will most likely end up with garbage. There is no buffering with software serial. You must already be waiting for the start bit before it starts coming in or all your timeings for that byte(and possible those following that byte) will be a mess.

_________________
Tech Support
Basic Micro - Robotic Technology Evolved