Stellaris Launchpad UART and Xbee radio

Cameron Phillips said:

I can see on the oscilloscope that data is coming out.

Does that statement not provide best/brightest clue - and solution - all rolled into one?

Would not a "Scope Capture" of your UART Data Out from the LPad - and a 2nd Capture from the (working) Arduino Data Out - when compared/contrasted - prove most instructive?

It's doubtful that your radio much cares for data's source - if you can get the 2 data trains to "match" - your radio problem should be resolved...

Always a common ground between MCU board and radio is required - and in "hook-up haste" - most always neglected and/or improper.   Power for the radio is also critical - the LPad may not be able to fully/properly power itself AND that radio...

Cameron Phillips said:

I suppose I could compare them but how do I adjust them to be the same?

I suppose I could answer - but then you'd (likely) not follow suggestions - and ask another question.   That's "Krazy Making" - not for me...

"Matching" signal levels/rates - most always occurs AFTER one compares and contrasts the requested scope caps.

Your issue may be:

• mismatched data levels (your radio may seek 5V - your MCU provides just 3V3)
• mismatched data rates (your radio may expect one rate and your MCU provides another)

Either reveals quickly/completely via simple scope caps & comparison.   You stated that you had ONE good scope cap - a 2nd (from your MCU source) is an obvious troubleshooting "next."

I don't believe rudeness was in play.   I do believe asking a question - w/out responding to suggestion - (may) qualify as improper (and even it's not rude)...

I do not know best. I will connect it to an Oscilloscope and I will compare the two outputs but oscilloscopes do not grow on trees so it takes me a few days to get my hands on one. Please if you are not going to help keep your snide remarks to yourself. There are other ways than to be disrespectful to get your point across. Get all of the circumstances before you pass judgement.

Amit-

I changed the the rate to initialize to 9600 in uartstdio.c as shown below.

//*****************************************************************************
//
//! Initializes the UART console.
//!
//! \param ulPortNum is the number of UART port to use for the serial console
//! (0-2)
//!
//! This function will initialize the specified serial port to be used as a
//! serial console.  The serial parameters will be set to 115200, 8-N-1.
//! An application wishing to use a different baud rate may call
//! UARTStdioInitExpClk() instead of this function.
//!
//! This function or UARTStdioInitExpClk() must be called prior to using any
//! of the other UART console functions: UARTprintf() or UARTgets().  In order
//! for this function to work correctly, SysCtlClockSet() must be called prior
//! to calling this function.
//!
//! It is assumed that the caller has previously configured the relevant UART
//! pins for operation as a UART rather than as GPIOs.
//!
//! \return None.
//
//*****************************************************************************
void
UARTStdioInit(unsigned long ulPortNum)
{
    //
    // Pass this call on to the version of the function allowing the baud rate
    // to be specified.
    //
    UARTStdioInitExpClk(ulPortNum, 9600);
}

Cameron Phillips said:

I can see on the oscilloscope that data is coming out

Does your past writing (above) - in any manner - convey that your scope is not, "ready/waiting?"   (it does not)

Now - due to the lack of the (far earlier) requested TM4C UART Scope Cap - your issue has ballooned to 20 posts!

Might this (unneeded) extra time/effort you've caused (by rejecting earlier guidance) reveal the "real" lack of respect?

Ok so I got them both on the Oscilloscope and I can obviously see that the Arduino has much more information being sent and much longer than the Stellaris.

Both of these boards are just sending a simple 1 on the output.

This is the Arudino and it has 500us

This is the Stellaris sending a 1 with the time spacing of 20us

So I see the problem. However they are both set to 9600 baud rate so I don't know what to do.

Here is the code for the Arduino I used.

        #include <SoftwareSerial.h>

        SoftwareSerial xbee(2, 3); // RX, TX
        char c = '1';
        int  pingPong = 1;

        void setup()  {
           Serial.begin(9600);
           xbee.begin( 9600 );
        }

        void loop()  {
          xbee.print( c );
         
          //--- display the character just sent on console ---
          Serial.println( c );
          // flash led each time
     if ( pingPong == 0 )
            digitalWrite(13, LOW);
          else
            digitalWrite(13, HIGH);
          pingPong = 1 - pingPong;
          delay( 1000 );
        }

Cameron Phillips said:

Ok so I got them both on the Oscilloscope and I can obviously see that the Arduino has much more information being sent

OK now - as you note this is immensely helpful - thank you!  

Now (from memory) at 9600 baud each bit should be ~104µS.   May I suggest that you change from sending your "1" to the hex value 0x55 or 0xAA?   Either of these values produce a repeating pattern of 1-0.   (or 0-1)  Both far more recognizable upon the scope.

Clearly your data is far faster on the green (Stellaris) trace.   Note that earlier Amit noted your use of the standard I/O would default to 115K Baud - which is more than 10 times your desired (9600) rate.

You need to read/review the UART API - and discover how to set the baud rate for your MCU...

And thank you for complying w/the guidance - freely passed - bit earlier.   We note that your Arduino produces just under a 4V output swing, the Stellaris is bit above 3V - this may or may not be an additional issue.   (a good read of the radio spec will reveal the acceptable input signal voltage...)

Hi Amit,

That's great detail - should prove helpful to poster - and resulted from poster's presentation of TM4C's UART scope cap.

However - his "working" trace showed signal levels "above" 4V - which you/I know - cannot be matched by TM4C w/out signal buffer... Unknown is the minimum input signal level of his radio - so questions remain...