After more than a week of frustration I became aware of the fact that HSERVO cannot be enabled while also sending SEROUT commands to an SSC-32 at 38.4K baud rate. I was encountering numerous problems in which the serial string being sent to the SSC-32 was becoming corrupted causing undesired and random movements. The issue seems to stem from the fact that HSERVO is interrupt based which can cause the SEROUT command to become slightly delayed or disrupted. The problem went away however when the HSERVO functions were all removed from the program or when the SSC-32 SEROUT commands were communicated at 9600 instead of 38.4K.
While I’m glad to finally understand what my problem was I now need to know how I can accomplish communications to the SSC-32 and HSERVO simultaneously without the serial string being affected. A baud rate of 9600 instead of 38.4K does seem to avoid the problem but I’d prefer to keep a faster communications rate and would like to avoid any possibility of the serial string becoming corrupted.
Any suggestions on the best way to utilize an SSC-32 and HSERVO simultaneously? Also, I’d appreciate if anyone can shed more light on specifically what causes the problem I was seeing earlier. Thanks.
You can try 19200 baud, its generally fast enough for servo commands. At least that’s my experience when sending long serial strings.
Besides that, you may need to add a pause, 10-20ms should suffice.
10-20ms wouldn’t really be noticeable, but should fix this issue.
Since it seems to be a limitation with the uprocessor, you’re kind of stuck with either using the lower baud or a pause. A pause should work fine though, even at 20-30ms it should still be short enough you wouldn’t notice this hick up. And it should allow you to keep your higher baud rate.
I noticed i needed to add a 10ms pause when using both serout and hserout, one right after another on the basic nano. So i’m just assuming this will help you, i make no guarantees.
Whoops! My mistake. I meant to post this to the “Bot Board & BASIC Atom / Pro” section as I’m using a BASIC Atom Pro 28. Is it possible to move a thread to another section?
Yep, I have run into this, also with HSERIAL or even simple overflow interrupts for timers and the like.
If the only serouts you need to do is to the SSC-32, than you can move the SSC-32 to the hardware serial port (pins 14 and 15 of BAP28) and use hserout instead. Of course if you are using a PS2 this can be a problem. On some baps/ps2s I could do this by moving the PS2 to pins 0-3 and enable the pull-up resistor for the DAT line. Sometimes the internal pull-up was not sufficient and I had to solder in a pull-up. It was easy inside of the Lynxmotion receiver.
Why this happens. Not sure how much detail to put here, so I hopefully won’t go to overboard here…
When you output async characters, what typically happens is the receiver gets the beginning of the start bit (either going low or going high depending Normal/inverted…) and then given the baud rate calculates how long to delay for 38400 each bit is about 26.04us or at 16mhz about 417 clock cycles. So the receiver tries to sample in the center of a bit or about 208 clock cycles after the start was detected… So from this assuming the receiver side is perfectly in synch with the transmitter which is never a good assumption than on the BAP you have to be accurate to about 200 clocks.
On the transmitter side, the code assuming has no interrupts, works by, first output the start bit, than loops 8 times for each of the data bits (lsb first) and delays a bit width number of clocks (often a quick decrementing loop that takes 8 clock cycles), than sets the output high or low and goes to the next bit… Finally it goes to the stop bit and outputs it and loops again to start the next byte to be output and since the code was properly tuned should output pretty accurate characters. Now along comes an interrupt. Suppose right after the first bit is output an interrupt happens, that takes 200+ clock cycles, that will extend which ever bits timing by the amount of time and shove the other bits out. At that point when the receiver side samples for a bit it could be actually sampling the previous bit and things are screwed up. Why it still works at 9600 is that each bit is 4 times as long so you have maybe 800 clocks to play with per bit and since the reception of each byte sort-of re syncs the source and destination as long as you don’t screw up too much on a single byte you are fine. However if the BAP is on the receiving side and it had an interrupt while it is receiving bytes, it is possible that the BAP will miss the start bit of the next byte and really get screwed up. This is why on some machines (like PCs) you can configure the serial port for 1 1.5 or 2 stop bits, which allows you to extend the amount of time between bytes which allows the receiver a better chance of re-syncing at a cost of speed…
Note: If your program has a simple basic interrupt handler for example for TimerA overflow, it will cause these types of problems: The response time to start an interrupt is between: 15-37 clocks, a return takes 10 and the interrupt handler pushes/pops 7 32 bit registers each push/pop is 10. So you without doing anything you are taking 165+ clocks and it a minimum you have to reset whatever triggered the interrupt and do the work.
Sorry about this ramblings, it would be much easier to show with a diagram or looking at the output form a logic analyzer…
