I'm using the FRDM-K66F board and running the freertos_uart demo project. It works well enough through UART0, but this is carried through the USB debug connection and I need to look at the signal on the wire. I changed the demo project to use UART1 instead by the following steps:
1. Connect pins A9 and A11 to UART1 TX and RX by updating pin_mux.c
2. Change the DEMO_UART* symbols to refer to UART1 instead of UART0
3. Connect J1 pin 4 to pin 2 on the DE9 serial connector.
4. Connect J1 pin 2 to pin 3 on the serial connector.
5. Connect J3 pin 12 to pin 5 on the serial connector.
I can see that pin 2 on the serial connector is where I want to transmit because my script that watches the port picks up the noise when I disconnect and reconnect that wire. I've stepped through the code and see that the UART_WriteNonBlocking function is entered and eight characters are written to the D register on each pass until the last one which only has seven. So it seems we've done the right thing, but nothing is seen on the other end. I can see also that the UART1 driver IRQ handler is invoked.. This really looks like a pin issue. When I get to the receive part of the demo, the software always ends up terminating on a timeout on the event group wait.
Any experience with this out there?
已解决! 转到解答。
Hi Jeremy Anderson:
I did a quick test according to your modifications. I tested with my uart-to-usb , and it can work on my side.
My modifications :
1. pin_mux.c
void BOARD_InitPins(void) {
CLOCK_EnableClock(kCLOCK_PortC); /* Port B Clock Gate Control: Clock enabled */
PORT_SetPinMux(PORTC, PIN3_IDX, kPORT_MuxAlt3); /* PORTB16 (pin E10) is configured as UART0_RX */
PORT_SetPinMux(PORTC, PIN4_IDX, kPORT_MuxAlt3); /* PORTB17 (pin E9) is configured as UART0_TX */
}
2 freertos_uart.c
#define DEMO_UART UART1
#define DEMO_UART_CLKSRC SYS_CLK
#define DEMO_UART_CLK_FREQ CLOCK_GetFreq(SYS_CLK)
#define DEMO_UART_RX_TX_IRQn UART1_RX_TX_IRQn
Have a great day,
Daniel
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
hOne more note on this. I found that the data I was getting on the console side was inverted when using UART1. I set the TXINV bit in register C3 and everything looks good from the transmit standpoint. I still don't get anything back on the receive pin (J1-2). Why would UART1 present mark for space with respect to UART0?
OK, thanks Daniel. I see what is going on now. The TTL levels at the pins present inverted values when connected to the RS-232 lines on my docking station serial port. This turns out to have been a matter of my own ignorance, now remedied. Thanks for the help!
Hi Jeremy Anderson:
I did a quick test according to your modifications. I tested with my uart-to-usb , and it can work on my side.
My modifications :
1. pin_mux.c
void BOARD_InitPins(void) {
CLOCK_EnableClock(kCLOCK_PortC); /* Port B Clock Gate Control: Clock enabled */
PORT_SetPinMux(PORTC, PIN3_IDX, kPORT_MuxAlt3); /* PORTB16 (pin E10) is configured as UART0_RX */
PORT_SetPinMux(PORTC, PIN4_IDX, kPORT_MuxAlt3); /* PORTB17 (pin E9) is configured as UART0_TX */
}
2 freertos_uart.c
#define DEMO_UART UART1
#define DEMO_UART_CLKSRC SYS_CLK
#define DEMO_UART_CLK_FREQ CLOCK_GetFreq(SYS_CLK)
#define DEMO_UART_RX_TX_IRQn UART1_RX_TX_IRQn
Have a great day,
Daniel
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
OK, partial answer. My eyes are going, but sending the same message over the UART0 link results in a coherent transmission, whereas UART1 ends up sending an extra byte and none of it makes any sense. It looks like noise might be an issue since this is a kludged up experiment.