Hi Nathan and others,
I thought I would continue this discussion on a more appropriate thread. Not much to do about reset of Roboclaw...
Acidtech wrote:
Hservo code uses the hardware pulse generation function of the 3687. So the only interrupt is the one to start each pulse. The interrupt triggers 300 times a second ...
...This is enough to mess with any high speed bit-banged asynchronous serial. So you need to use the hardware serial port to talk to asynchronous serial devices when using HSERVO unless you lower the baud rate and even then you should have checksums or parity checking to correct for any bad bits. This is a limitation of bitbanged async serial.
Exactly! Which is why it is difficult to get too high speed async serial devices to work...
That is why I first tried to disable all of the servos (i.e. if there are no servos who need pulses than I thought maybe no interrupts. But I know that did not work on bap28... Probably won't work on Arc32 either especially with the timer tick stuff, which I appreciate.
There are some options available to you to make it more reliable. I have done one method, which is to use another timer to clock the pulses for the communications instead of hard wait loops. There are issues, that I can go more into if anyone is interested. This is discussed and code posted in a few different Lynxmotion threads.
Other option: Have your system interrupt handlers somehow update your wait timing loops. Could be tricky. i.e. somehow your interrupt handler knows that you are in a wait loop and that something like ER3 has the loop count in it and decrement it by an appropriate amount...
Other option for serout as you are in control: Before you start to output the next character, know that you have enough time before the next system interrupt happens, else stay in stop bit... Several ways to implement this... But again this would only work for output as you are in control, where on input the device is in control.
Acidtech wrote:
Kurt,
Another way to disable hserial interrupts is to use sethserial 0 or sethserial2 0. By setting to 0 the hardware serial interrupt is disabled. Then just sethserial baudrate again to re-enable hserial. Then you don't need the I/O line to the XBee RTS line.
Thanks for the suggestion. However I believe that the XBEE would then throw away any data that it received while in that state, where with the RTS line, the xbee will simply buffer the data up for me, until I am ready to receive it.
Kurt