Do not set pins to the default function before the actual setting is
applied. If a pin setting needs to be done in a certain order, then
this should be done explicitly through multiple calls to
tms570_bsp_pinmmr_config().
Update #4982.
Remove obsolete tms570ls3137_hdk_with_loader BSP variant. With the new
memory origin/size build options this variant is no longer required.
Update #4982.
Change license to BSD-2-Clause according to file history and contributor
agreements. Add Doxygen file comments.
Update #3053.
Update #3707.
Update #4982.
This cleans up outputUsesInterrupts usage with rtems_termios_device_mode
enum values. The outputUsesInterrupts member was typed as an int, named
as if it were a boolean value, and used as if it were a
rtems_termios_device_mode enum. In this patch, values assigned to
outputUsesInterrupts have been converted to the corresponding
rtems_termios_device_mode enum value, conversions from
deviceOutputUsesInterrupts have been made explicit, and uses of
rtems_termios_device_mode enum values with deviceOutputUsesInterrupts
have been converted to booleans.
Hi all, this is my first email patch submission and my first contribution to RTEMS, so please give any
feedback you have!
This patch enables interrupt driven data reception on USART ports on
STM32F4 series chips. This feature is gated behind the config flag
BSP_CONSOLE_USE_INTERRUPTS. If this flag is not set to True, the older
polling implementation will be used. I tested this feature on STM32F401CE
(blackpill) and STM32 Nucleo F411RE boards, with both capable of keeping
up with a 115200 baud continous data stream. With the older polling
implementation, both would drop bytes at 9600 baud. In addition, I
updated the implementation of usart_set_attributes to support changing
the baud rate of the USART port based on the input speed.
Place the vector table in the start section so that the overlay can be
avoided if we execute from internal flash. The problem is that when the
POM is enabled, the ECC cannot be enabled for the internal flash.
With this, it is possible to use GPIOs as CS pins in the LPSPI. To avoid
additional complexity, the GPIOs will have the same limitations as the
native (hardware) CS pins.
The GPIO CS feature adds a number of extra code when starting SPI
transfers on this controller. Therefore it is possible to disable the
additional code by just setting the IMXRT_LPSPI_MAX_CS option to 0. In
that case only native CS pins are supported.
At the moment, this feature is only enabled on i.MXRT1166 by default
because it is not tested on i.MXRT1050. But it should work there too.
Device trees allow mixing different kinds of GPIOs in one property. For
that it is usefull to only provide a pointer to an arbitrary location in
the property and initialize a GPIO from that.