This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CAN1 and UART on the LM4F232

Dear Sir/Madam,

When using the CAN controller for CAN1 and the UART in the same project, I noticed the UART init uses GPIO Port A (pin 0 and pin 1).
But at the same time, CAN1 uses these pins as Tx and Rx. Might this be causing trouble for the CAN functionality on these pins ? 

UART: 

// Enable GPIO port A which is used for UART0 pins
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

// Configure the pin muxing for UART0 functions on port A0 and A1.
GPIOPinConfigure(GPIO_PA0_U0RX);
GPIOPinConfigure(GPIO_PA1_U0TX);

CAN :

// Enable the alternate function on the GPIO pins.
GPIOPinTypeCAN(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);

// The GPIO port and pins have been set up for CAN. The CAN peripheral must be enabled.
SysCtlPeripheralEnable(SYSCTL_PERIPH_CAN1);

// Configure the GPIO pin muxing to select CAN0 functions for these pins.
// This step selects which alternate function is available for these pins.
// This is necessary if your part supports GPIO pin function muxing.
GPIOPinConfigure(GPIO_PA0_CAN1RX);
GPIOPinConfigure(GPIO_PA1_CAN1TX);

Thanks in advance for your time.

  • Do note that PA0 & PA1 may be configured "either" as UART0 or as CAN1 - you cannot employ these pins to achieve both functions at/near the same time.  (unless you re-configure those pins dynamically - and can avoid line-driver issues/conflicts)

    PA0/PA1 "normal/customarily" default into UART0.  You can avoid this UART/CAN conflict by choosing PB4/PB5 - which may configure into CAN0.

    Your code shows PA0/PA1 configured both as UART and CAN - this cannot be!  (last programming line {CAN here} wins) 

    Should you plan to use interrupts - likely best to avoid use of UART0 & CAN1 (both upon PA0/PA1) - instead using PB4/PB5 for CAN0 - as suggested.

    Appears that a valid CAN transceiver is required if you seek to transact w/another, remote CAN device.

    ARM in general - and Stellaris in specific - have a vast supply of UARTs and CAN I/O - best to recognize (as you've done) and then avoid (as proposed here) any potential conflicts...  As always - KISS best/fastest path to your success...

     

  • Thank you for your quick and usefull reply.

  • Thank you for your equally quick reply and verification - always appreciated.

    W/in the MCU datasheet exists a comprehensive listing of "pins and possible functions."  Our group copies/pastes this into a word-processor program - and then color highlights each pin grouping by functionality.  (there also exists a pin-configurator program - but we do not find this as detailed nor as useful...)

    Following our color-coding guide - you can quickly/easily identify where your "peripherals of interest" lie.  And - avoid the conflict you earlier noted.

    Final point - you are not restricted to "harvesting" needed peripheral pin functions - from one (the same) MCU Port.  For example - we choose SPI pins from across multiple ports - so that we could extract the best "match" of functions for each project.  So long as you properly GPIOPinType() and GPIOPinConfigure() - this works well and has never (imho) received the public mention (applause) it merits.  (I've noted this several times this/other forums - most often to little response...)

  • I find the GPIOPinType() and GPIOPinConfigure() functions very useful and they help a lot. I don't know who created these functions, but I also applaud these people on their work and making embedded software easier to use for everyone.

  • Andries Danau said:
    who created these functions

    StellarisWare was originated by programmers @ LMI - and subsequently expanded by TI. 

    Cautionary note - not all Stellaris (the dreaded NRND M3s) accept GPIOPinConfigure() - SW-DRL-UG sounds this alarm...

  • Thank you for the nice tool.