Reading through this good tutorial on setting up the USART on an STM32, the Bus Setup paragraph says that the receiver pin (Rx) should be set as input floating.
I would have thought that because the receiver pin's function is to act as a USART receiver, it should be configured as Alternate Function USART.
Why is the receiver pin (Rx) configured as input floating rather than Alternate Function USART?
Answer
Which STM32 processor are you using? The behavior you describe is typical of many processors, where it's necessary to explicitly connect peripheral drivers to output pins, but where they are implicitly connected to inputs (since such connections are generally inherently harmless). On the other hand, when I was using an STM32L151, I had trouble getting the UART to work until I selected the pin's "alternate function" as the UART. Are you still setting the AFR for that pin to select UART? I wouldn't be surprised if the pin mode can be freely selected as either "input/float" or "alternate function", since the UART wouldn't be driving that pin anyhow, but that it was nonetheless necessary to set the AFR of that pin to the UART, so that the UART would know from which pin it should accept input.
A topology I rather like, but which I haven't seen elsewhere for some reason (even though it seems like the obvious "right" approach) is found in some Microchip parts, where each pin's output has a mux which selects the peripheral which should feed it, but each peripheral's input has a mux which selects one pin to feed it. This allows one peripheral to drive multiple output pins, and allows multiple peripherals to be driven by one input pin. I recognize that in a large part a full crossbar arrangement might be impractical, but nonetheless selecting peripheral inputs that way would seem to have a number of advantages, such as being able to feed a pin both to a UART and to a timer event trigger (thus getting a precise timestamp of when a character arrives, even if the CPU can't service it instantly).
No comments:
Post a Comment