Dedicated 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 / RS422: A standard for serial communication that allows for long-distance communication and multi-point systems, either in half-duplex, using a single pair of differential signals (RS485) or full duplex using two pairs of wires (RS422).
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 dedicated communication interface, it cannot be used as a general-purpose I/O. It also cannot support the input voltage range of regular I/Os (-25 V to +25 V). 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:
| AT1032S 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 |
| AT1032S 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.
| AT1032S GPIO | CAN 0 | RS485 0 | RS485 1 | RS232 |
|---|---|---|---|---|
| DA24 | CANH | A(+) | ||
| DA25 | CANL | B (-) | ||
| DA26 | A(+) | |||
| DA27 | B(-) | |||
| DA28 | TX | |||
| DA29 | RX |
An RS422 interface can be implemented by combining the two available RS485 interfaces. One pair (A(+) and B(-)) can be used for transmitting data, while the other pair (A(+) and B(-)) can be used for receiving data.
Configuration keyword arguments are validated strictly. A misspelled keyword such as baudrate (instead of baud_rate) raises a validation error rather than being silently ignored, so a typo can never leave an interface misconfigured.
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).
USB device enumeration​
tester.com.usb(id).state() lists the devices currently connected to one of the two front-panel USB ports (id 0 or 1). USB 2.0 and USB 3.0 devices alike are reported since firmware 0.4.6.
- NodeJS
- Python
const { devices } = await tester.com.usb(0).state();
for (const d of devices) console.log(d.manufacturer, d.product, d.serial_number, d.speed);
state = tester.com.usb(0).state()
for d in state.devices:
print(d.manufacturer, d.product, d.serial_number, d.speed)
Each UsbDevice entry has the following fields:
| Field | Type | Description |
|---|---|---|
vendor_id, product_id | number | USB vendor and product identifiers |
device_class, device_subclass, device_protocol | number | Device-level class codes |
usb_version | string | USB specification version, e.g. "3.20" |
speed | string | Link speed in Mb/s as reported by sysfs, e.g. "5000" |
manufacturer, product, serial_number | string | null, optional | String descriptors when the device provides them |
bus, port, address | number | Position on the Linux USB topology |
num_configurations | number | Number of configurations |
interfaces | UsbInterface[] | One entry per interface: number, class, subclass, protocol, num_endpoints (all number) |
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. See USB power supply.