[Solved] Cannot get software uart functioning: Axon-webbotlib-Project Designer

[Ryltar]

Hello,

I am having a bit of trouble with getting a software uart working on the Axon. I'm using webbot's project designer to set up the system initially. In it I set a software uart to send data strings to my SSC-32 to control the robot. It is currently just a simple command of putting all the servos at 1500.

The code compiles fine and the Axon seems to accept it. I set it to transmit data on E2 and have it tied to Timer 5. Looking at the SSC-32, I can see the data light flashing; so I know that data is being transmitted. Strangely the servos don't move at all. When I use the project designer to switch it to a hardware uart (#2) and rewire the bot accordingly, everything works just fine.

I'm trying to get the SSC-32 to run off the software uart because I'm looking to add a Blackfin camera and a Sparkfun Razor IMU to the Bluesmirf and SSC-32 I already have making that 4 uarts I need besides the USB connector. I figured that the SSC-32 would be the best to offload to software because I'm only sending data over the line and not receiving anything.

I've attached the project designer file along with the code I have right now. It is all very simple stuff as I wanted to test out project designer and software uarts before I pull in the more complicated code.

Any help or even just being pointed towards the source of the problem would help me greatly.
Thanks.

[Admin]

hmmmm what is the exact problem you are having? (other than 'it doesn't work' )

I checked your file, and you have the baud at 38400 as a hardware UART.

If you meant to send me a different file, say a software UART, try the slowest baud value your SSC32 can do and see if that works, then work up from there. Also, set the transmit buffer to 80 bytes.

And lastly, I think bluetooth should get the software uart. Why? Because your servo controller will get commands constantly, but your bluetooth probably won't transmit nearly as much data if its just you sending it hyperterminal commands.

[KurtEck]

For the fun of it I thought I would try out the software serial at 38400.  I used an Arduino Mega board as I was curious if I could get it to download with avrdude... So I did a quick program with the project designer.  Created two uarts, 1 hardware and the other software both initialized to 38400 and then I had my main function simply output a string first to the hardware port and second to the software port.
Like:

Code: [Select]

TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart) {

// -------- Start LED-------
// The LED can be manipulated using the calls in led.h

// To turn the LED on:-
LED_on(&led);

// Output to hardware serial port
rprintfInit(&huartSendByte);
rprintf("#0P1500T100\r");

// Output to Software serial port
rprintfInit(&suartSendByte);
rprintf("#0P1500T100\r");


// To turn the LED off:-
LED_off(&led);
// -------- End   LED-------

return 0;
}
I was able to get it tow download to the mega and then I used my "Toy" logic analyzer  ::)and found the software output was totally out to lunch.  You can see this in the below image.

The top line is the hardware output which is correct, the 2nd line is the software one...

Kurt
P.S. - Webbotlib 1.27

[Admin]

At 38400bps, you are asking a regular digital I/O pin to change state at a rate of 78600Hz, at a resolution *much* higher than that - a lot!

Try a much lower baud . . . my bet is that 9600bps is the fastest you'll have luck with. 4800bps is likely to work without a hitch.

[Ryltar]

Oops, sorry about that wrong file. The only difference was the project file was set to be a software uart at E2. Still had the same high baud rate. According to what you said, that is probably the source of the problem so I'll try the slower baud rates and see how it goes. If I get that working, then I'll see if I can figure out software uarts for the bluetooth module.

Thanks

[KurtEck]

At 38400bps, you are asking a regular digital I/O pin to change state at a rate of 78600Hz, at a resolution *much* higher than that - a lot!

Yep, this is perfectly doable, but is a trade off.. I have written bit bang serout functions before that run on 16mhz micro controllers and was able to do a baud rate of 115200.  I have not tried this on AVR, but long time ago had it running on Atmega16 at 19200 for an LCD display... At the baud rate you actually that number of pin changes...  So for a 16mhz processor to do 38400 you have about 417 clocks per bit.

Sorry in advance for the long winded stuff below...
So in the simplest code this is easy, you simply calculate the number of clocks of overhead (things like shifting the register to get the next bit, decrementing count of bits left to output... Than you simply have a hard loop that decrements a counter so many times and then you set or clear the IO bit... Easily to do in 417  actually (416.66) cycles.  Problems with this is that you are eating up your processor looping while it can do other things.  Also any interrupts that are processed during this time, eat up cycles that your loop knows nothing about, which will cause that bit to be longer than it should be, which can cause the data to be incorrect.  These interrupt timing differences can be additive, that is it might work OK if 1 interrupt is processed in the byte, but 2 maybe not.  With 1 stop bit, this can accumulate over bytes as well, that is why some do 1.5 or 2 stop bits, which helps for the receiver to re-sync.

Next approach, is to use a timer.  Not as an interrupt, but simply to time the bits.  That is your loop waits until timerX says it is timeY... This helps minimize the issues with the other interrupts. Still eats up time...

Next approach is to use timer with interrupt.  This allows the code to run other things while waiting for the next bit time, it also helps to minimize issues with other interrupts, but at higher baud rates if the overhead per interrupt is too high than you spend all of your time just getting in and out of the interrupts. Also on some time sensitive things your bit timings may be off as one one interrupt it may have delay of X cycles and on the next interrupt it may have a delay of Y.  I have heard of some people writing their code to have the interrupt happen X time units before they need it, then loop until the right time and then do their work...

Exit long stuff...

I guess if webbotlib can not handle higher than 9600 baud for a software serial output, maybe the project designer should catch that...   Just a thought.
Kurt

[Admin]

I think Webbot would be able to better comment on this, but I'd assume his software UART is fairly intelligent when handling interrupts. It's really a question of is the software UART running in an uninterrupted loop, or do you want your mcu doing many other tasks simultaneously. Only then does the baud rate become an issue.

If it was me, I'd run bluetooth on the software uart as it'll probably send/receive fairly small amounts of data on fairly rare occasions, while the servo controller will be doing something almost non-stop.

[Webbot]

The software uart code uses the timer interrupts to time the next bit to be sent.

If you are also using a hardware uart at a high baud rate then don't forget that the hardware uart is also generating interrupts (and maybe other things are as well). Unfortunately the AVR chips dont let you prioritise the interrupt handlers. So all these interrupts effectively lengthen the bits on the sw uart. Hence a slow baud rate is better as the percentage error is smaller.

I dont want to do processing in the foreground ie with a timer (and all interrupts disabled) as it can kill off other things.

[KurtEck]

Thanks Webbotlib,

I am not sure how much of this is of interest, but.

FYI - I commented out the calls to the hardware serial port to see if it would work on it's own at 38400 and it still had problems.  I looked at it again using the logic analyzer and found the bit periods were off.   At 38400 the bit period should be about 26us and most of the single bit values had a timing of about 31us. 
The code looks like:

Code: [Select]

TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart) {

// -------- Start LED-------
// The LED can be manipulated using the calls in led.h

// To turn the LED on:-
LED_on(&led);
// Output to Software serial port
rprintfInit(&suartSendByte);
rprintf("#0P1500T100\r");
while (uartIsBusy(suart))
;

// To turn the LED off:-
LED_off(&led);
// -------- End   LED-------

return 100000;
}

I wanted the code to have a gap between outputs to make it easy to see on the analyzer...

So I changed the little test program to 9600 baud to see if that works.  It looks like it is getting most of my characters correct, but looking at where the logic analyzer thinks it should be sampling the input it looks like it is borderline.  That is a lot of the transitions are very near the edge of where it thinks the pulse should be instead of the middle.  Not sure if that makes any sense to you.  At 9600 baud each bit should take about 104us.  If I look for example at the first # that is output, The different bits should be:
0 1 1 0 0 0 1 0 0 1  (Start lsb...msg Stop) The measured timings for these bits are:
Start: 76us
2 1s:  193us or 96.5 each
3 0s: 311.5us or about 104
1 1 : 104
2 0s: 208
The stop bit was about 129 which is fine that it is longer...
Next byte was a 0: 0 0 0 0  0 1 1 0 0 1
(5-0: 476.5/5=95,2-1: 208,2-0: 298, 129 for stop...) Again looks like timing for first few bits are off. This appears to be consistent on the other bytes that I checked as well.

Kurt

[KurtEck]

Quick update: I thought maybe a close up of the bit timings from the logic analyzer may help...

The idea is that when the start bit is detected, you should expect that the receiver will query the bits at 1/2 of a bit period and then for each bit at a bit period later...  The little dots show where the analyzer is detecting the state of the bits...
Kurt

[Admin]

Did you ever try 4800bps?

[KurtEck]

Did you ever try 4800bps?

Nope: so far I have not had enough serial things that the 4 UARTS of the Atmega1280 has not been sufficient .

But if he decides to use the software serial port for the SSC-32, the only valid baud rates are: 115200,38400, 9600, 2400... So the next one down would be 2400 baud and that is pretty darn slow... If I were needing it now, I would be digging more into the software serial startup code in uartsw.c.  In particular:

Code: [Select]

void __uartswStartXmit(UART* _uart, uint8_t data){

SW_UART* uart = (SW_UART*)_uart;

// save data
uart->txData = (uart->inverted) ? ~data : data;

// set number of bits (+1 for stop bit)
uart->txBitNum = 9;

const Timer* timer = &pgm_Timers[uart->timer];

// Get current time - 100 clock cycles otherwise the start bit is too long
uint16_t start = timerGetCounter(timer) - 100;
...
There is the fudge factor of 100 here or about 6.25us that is removed from the start bit...  Not sure why...  My guess is removing that -100 would improve it...

Kurt

[Admin]

But if he decides to use the software serial port for the SSC-32, the only valid baud rates are: 115200,38400, 9600, 2400... So the next one down would be 2400 baud and that is pretty darn slow

Yet another reason I'd put the software uart on bluetooth and not the servo controller

[KurtEck]

Yet another reason I'd put the software uart on bluetooth and not the servo controller

No arguments here... Personally I would try to not put anything on the software uart... I would instead look at putting something like the blackfin on SPI or I2C to free up the hardware UART...

But, I was just curious about the code and to try to help to make it better.  I did some more investigating and understand the issue a little better.  One problem that I had when setting up the little test program was when I was using the project designer was I left a bunch of the settings as their defaults, so the software uart defaulted to timer0 which is 8 bits.  So at 9600 baud where each bit takes about 1667 cycles, that wont fit into an 8 bit time with a prescale of 1 so you need to go to a prescale of 8.  So in the case of the line:

Code: [Select]

uint16_t start = timerGetCounter(timer) - 100;The 100 fudge factor turned out to 800 clocks...  I thought maybe simply divide the 100 by the timerGetPrescaler might do the trick, but at times did not appear to help in some cases and the start pulse times was still too short...

Back to playing with my normal stuff
Kurt

[Ryltar]

I was able to get the bluetooth device functioning on the software uart. I took you advice and kept the ssc-32 hardware based. The software uart for the bluesmirf is running at 4800 and seems to be functioning well, though I don't have any data besides successful commands and clean responses to verify it.

So it was definitely a problem of trying to run the software uart at too high a baud rate. Dropping it down fixed it just fine.

Thanks for the help & information.

[Webbot]

@Ryltar - Glad you got it going

@KurtEck - Thanks for all the timing stuff. Very useful. Unfortunately I dont have a logic analyzer so I have to work blind until something works. Not easy ! The hard stuff is that the calls to set the next timer compare value have to go through the library which are a bit bloated compared with just writing the register directly. Equally the interrupt handlers end up pushing/poping lots of registers. This all adds overhead.

Equally (if memory serves) then the 'fudge factor' line:

Code: [Select]

// Get current time - 100 clock cycles otherwise the start bit is too long
uint16_t start = timerGetCounter(timer) - 100;
is because the 'timerGetCounter' has some processing overhead between reading the counter, converting the value into uS, and returning the value in us - ie around 100uS. But you are correct in that this probably needs changing to cope with different prescaler values. This is complex as this extra 'prescaler conversion time' would also need to be taken into account.

The original reason for the software UART was for smaller processors, such as the ATMega328p, where there is only one hardware uart. I think that with an ATMega640 that if you are already using all 4 hardware uarts then there will be so many interrupts going on that it will be difficult to get the software uart timings correct.

But still a lot here for me to digest !! Thanks
 

[KurtEck]

@KurtEck - Thanks for all the timing stuff. Very useful. Unfortunately I don't have a logic analyzer so I have to work blind until something works. Not easy ! The hard stuff is that the calls to set the next timer compare value have to go through the library which are a bit bloated compared with just writing the register directly. Equally the interrupt handlers end up pushing/popping lots of registers. This all adds overhead.
...

You are welcome.
Yep, I know what you mean about  trial and error. My earlier versions I worked through initially by counting all of the clock cycles in each of the code paths... Not Fun.  I still needed to fine tune it and before I had the logic Analyzer, I did it a couple of different ways.  The obvious way was to see if it worked OK with the device I was trying to output to. 

Earlier I purchased Parallax USB Oscilloscope which is pretty limited, but I still use it from time to time when I need to look at analog signals or the like.  The last time I used it was when the sparkfun Regulated explorer was not working with the Axon2 and I found the low voltage was not low enough... 

I also have resorted to connecting the generated output pin to another micro-controller that I run a program on that captures the times when the signals change and keep it in an array and at some point print out the timings...

That is all for now.  Let me know if can help out...

Kurt

[Admin]

The last time I used it was when the sparkfun Regulated explorer was not working with the Axon2 and I found the low voltage was not low enough... 

You mean the voltage coming out the regulator was too low, or going in from the Axon was too high?

[KurtEck]

The last time I used it was when the sparkfun Regulated explorer was not working with the Axon2 and I found the low voltage was not low enough... 

You mean the voltage coming out the regulator was too low, or going in from the Axon was too high?

The voltage regulator on the unit worked fine, but I remember that there was a problem with either the input from the XBEE or the output to the xbee and the voltage was not shifting enough and I either always got a 1 or a 0.  It has been awhile.  When I shifted to using the Selmaware version it worked fine and likewise the Parallax version worked as well...

Kurt

[Admin]

The Sparkfun Explorer is a 5V to 3.3V logic adapter, but *not* a 3.3V to 5V logic adapter. It assumes that 2.8V is high enough for a logic 5V high, which for the Axon it's not.