TS-4900 COM Ports: Difference between revisions

From embeddedTS Manuals
No edit summary
No edit summary
Line 1: Line 1:
This board uses UARTs from both the CPU and the FPGA.  The CPU uart 0 (/dev/ttymxc0) is dedicated to console for Linux and U-boot and not suggested to be repurposed.  The other CPU UARTs for ttymxc1-4 are usable for end applications.  These support up to 5Mb/s UART data.  The CPU UARTs are routed through the onboard FPGA.  This allows these UARTs to support direction control for RS-485 with tshwctl.
This board uses UARTs from both the CPU and the FPGA.  The CPU uart 0 (/dev/ttymxc0) is dedicated to console for Linux and U-boot and not suggested to be reused.  The other CPU UARTs for ttymxc1-4 are usable for end applications.  These support up to 5Mb/s UART data with DMA.


The FPGA also includes 3 extra SPI UARTs like the MAX3100 UART.  It is possible to use the standard max3100 driver with the FPGA UARTs, but only one UART will be accessible.  The FPGA includes one significant difference from the MAX3100 chipset.  A byte should precede other SPI traffic to select which "max3100" core is being addressed.  This is handled automatically by the driver shipped in our BSP.  The MAX3100s also support transmit enable for automatic RS485 half duplex direction control.
The FPGA also emulates a MAX3100 UART interface accessible at /dev/ttyMAX0-2.  These UARTs support a total throughput of about 115200<ref>Idle periods do not count towards the total throughput limitation., but they include hardware that makes implementing RS-485 half duplex software very simple.  If higher throughput is needed, the [[#FPGA_Crossbar|FPGA crossbar]] can be adjusted to use a CPU UART with TXEN support instead.


None of the RS232/TTL ports need special setup, but the RS485 ttymxc3, or ttymxc1 if used for 485 requires some set up.  RS485 half duplex requires toggling a pin to switch between transmit and receive.  The ttyMAX uarts include this as part of the FPGA hardware so no setup is required.  The CPU UARTs do not do this automatically.  The CPU's UARTs are passed through the FPGA to create an automatic transmit enable.  This requires the FPGA to know the bit rate and symbol size.
{{Note|Our SPI interface matches the max3100 almost entirely, except optionally a single 8-bit transaction can be sent to act as a chip select between the three uarts supported on our interface.  The default FPGA supports 3 UARTs on this interface.  This is handled automatically by our driver (max3100-ts).}}
 
RS-485 half duplex's direction control is built into the ttyMAX UARTs.  By default they are connected to the RS-485 ports and no code is required for the transmit enable to toggle.  The CPU UARTs however do not have transmit enable built in.  The FPGA however includes a core that will toggle transmit enable for ttymxc1/ttymxc3, but it needs to know the baud rate, and symbol size (data bits, parity, stop bits).


For example:
For example:
Line 16: Line 18:
</source>
</source>


The tshwctl tool will read the UART settings when it is run and it sets up the FPGA's timing for TXEN.  Your baud rate and mode settings should be set before running this.
The tshwctl tool will read the UART settings from the moment when it is run and it sets up the FPGA's timing for TXEN.  Your baud rate and mode settings should be set before running this.


For 8n1, this will include 8 data bits, no parity, 1 stop bit, as well as one start bit adding up to 10 bits per symbol.  9n1 or parity modes may have more or less bits per symbol.
Using the FPGA for either the ttyMAX uarts, or the CPU uarts, the TXEN timing will happen well under a single bit time <ref>This is a requirement for half duplex MODBUS</ref> of any baud rate possible by the hardware.


The ttyMAX ports will work for most situations, but these ports have a couple limitations.  It can support about two 115200 links saturated with data, but not a third.  This limitation only applies when data is actively being transmitted, not idle UARTs.  The FPGA crossbar allows changing UART mappings so bandwidth can be prioritized.  For example, to switch around ttymxc1 / ttyMAX0, and ttymxc3 / ttyMAX1:
{{:Standard UART Examples}}
<source lang=bash>
# Replace ttyMAX0 with ttymxc1 for RS485 which is BT uart by default
# leave bt uart disconnected since it cannot run with SPI uart
export CN1_67=TTYMXC1_TXEN
export TTYMXC1_RXD=CN2_80
export CN2_78=TTYMXC1_TXD
 
# Replace ttyMAX1 for second RS485 port
export CN1_63=TTYMXC3_TXEN
export TTYMXC3_RXD=CN2_96
export CN2_94=TTYMXC3_TXD
 
# Put ttyMAX1 on CN2_86/88 (replace ttymxc3)
export TTYMAX1_RXD=CN2_88
export CN2_86=TTYMAX1_TXD
 
# Apply all these changes
tshwctl --set
</source>


{{:Standard UART Examples}}
<References />

Revision as of 10:55, 1 August 2017

This board uses UARTs from both the CPU and the FPGA. The CPU uart 0 (/dev/ttymxc0) is dedicated to console for Linux and U-boot and not suggested to be reused. The other CPU UARTs for ttymxc1-4 are usable for end applications. These support up to 5Mb/s UART data with DMA.

The FPGA also emulates a MAX3100 UART interface accessible at /dev/ttyMAX0-2. These UARTs support a total throughput of about 115200Cite error: Closing </ref> missing for <ref> tag of any baud rate possible by the hardware.

All of these UARTs are accessed using the standard /dev/ interfaces. See these resources for information on programming with UARTs in Linux.


Retrieved from "http://docs.embeddedTS.com/index.php?title=TS-4900_COM_Ports&oldid=8984"