Communication Interfaces
Although the native AT1000 I/O allows for a lot of flexibility, and if speed do not matter, it's possible to emulate any communication protocol (a.k.a. bitbanging) there are some situations where you may want to use a dedicated communication interface.
Dedicated communication interfaces offer several advantages, mainly:
- Speed: Dedicated communication interfaces are optimized for speed and can handle high data rates, making them ideal for applications that require fast data transfer.
- Reliability: They provide consistent performance and reduce the likelihood of data loss during transmission.
- Ease of use: Dedicated interfaces often come with built-in libraries and support, making it easier to implement communication protocols without having to worry about timing and signal integrity.
Supported communication interfaces​
The AT1000 supports the following communication interfaces:
- I2C: A two-wire, half-duplex communication protocol used for connecting low-speed devices.
- SPI: A four-wire, full-duplex communication protocol used for high-speed data transfer.
- UART: A serial communication protocol used for asynchronous data transmission.
- CAN: A robust vehicle bus standard designed to facilitate communication among various microcontrollers and devices without a host computer.
- RS232: A standard for serial communication transmission of data.
- RS485: A standard for serial communication that allows for long-distance communication and multi-point systems.
Pin alternate functions (multiplexing)​
The communication protocols are multiplexed with the existing I/O pins (with the exception of RS232 that has dedidcated pins).
When a pin is used for a specific purpose, it cannot be used as a general-purpose I/O, and more importantly, it cannot support the high voltage range of regular I/Os (+/- 25V). Disabling the communication interface will restore the pin to its original I/O function and voltage range.
The following table summarizes the multiplexing of the GPIO pins with the communication interfaces:
| AT10032S GPIO | SPI 0 | JTAG 0 * | SWD 0 * | I2C 0 | UART 0 |
|---|---|---|---|---|---|
| DA16 | MOSI_0 | TDI_0 | SWDIO_0 | SDA_0 | TX_0 |
| DA17 | MISO_0 | TDO_0 | RX_0 | ||
| DA18 | SCK_0 | TCK_0 | SWCLK_0 | SCL_0 | |
| DA19 | TMS_0 |
| AT10032S GPIO | SPI 1 | JTAG 1 * | SWD 1 * | I2C 1 | UART 1 |
|---|---|---|---|---|---|
| DA20 | MOSI_1 | TDI_1 | SWDIO_1 | SDA_1 | TX_1 |
| DA21 | MISO_1 | TDO_1 | RX_1 | ||
| DA22 | SCK_1 | TCK_1 | SWCLK_1 | SCL_1 | |
| DA23 | TMS_1 |
JTAG and SWD are not currently supported and will be implemented in a future release. The AT1000 device is designed to support JTAG and SWD protocols, but the implementation is not yet available in the current version of the API. Please check back for updates on this feature.
| AT10032S GPIO | CAN 0 | RS485 0 | RS485 1 |
|---|---|---|---|
| DA24 | CANH | A(+) | |
| DA25 | CANL | B (-) | |
| DA26 | A(+) | ||
| DA27 | B(-) |
RS232 signals are available on a dedicated port on the front panel of the AT1000 device. Thus, the RS232 interface does not share GPIOs with other interfaces.
What about USB and Ethernet?​
USB and Ethernet are not considered communication interfaces in the same way as the others listed above. They are directly managed by the underlying linux system, and are mainly used for transferring data to and from the DUT (device under test).
One important test-oriented feature of the USB ports is the ability to power cycle the USB devices. This is done by controlling the power supply to the USB ports, allowing you to turn them on and off programmatically. This feature is particularly useful for testing scenarios where you need to reset or power cycle a device under test (DUT) connected via USB.