# Get Started

The SANPO robot integration board connects a PC or host controller to CAN, CAN FD, and RS485 joint motors. V6 lets USB serial, Linux SocketCAN, or SPI control the board's four CAN/CAN FD and four RS485 interfaces.

This document applies to the FDCAN upgraded board shipped with V6 firmware. For V4 Standard, CAN-isolated, or RS485-isolated boards, see the [V4 documentation](https://docs.sanporobot.com/v4/en/get_started.html).

## On This Page

- [Product Overview](#product-overview)
- [Choose a Host Interface](#choose-interface)
- [Default Communication Settings](#default-settings)
- [Channel Numbering](#channel-numbering)
- [USB Access](#usb-access)
- [SPI Access](#spi-access)
- [Configuration and Maintenance](#configuration-and-maintenance)

(product-overview)=

## Product Overview

| Item | Description |
| --- | --- |
| Host interfaces | USB serial / Linux SocketCAN / SPI |
| Motor interfaces | 4 × CAN/CAN FD + 4 × RS485 |
| CAN data length | Classic CAN: up to 8 bytes; CAN FD: up to 64 bytes |
| SPI mode | SHORT: 23 bytes; LONG: 73 bytes |
| Offline execution | Store and automatically execute CAN, CAN FD, and RS485 commands |
| Expansion | I2C / ADC / UART / SWD |

Each MCU controls two CAN/CAN FD and two RS485 interfaces and is accessed through its own USB port and SPI chip select. Both MCUs use the same firmware; only the physical interface numbers differ.

(choose-interface)=

## Choose a Host Interface

| Use case | Documentation |
| --- | --- |
| Control CAN or CAN FD from Linux through `canX` | [SocketCAN](socketcan) |
| Send raw RS485 data directly; leave at least 3 ms of idle time between commands, or use the SANPO protocol for continuous high-rate control | [RS485 Raw Passthrough](rs485_passthrough) |
| Control a selected classic CAN channel through USB serial | [SANPO USB to CAN](usb_can) |
| Control a selected CAN FD channel through USB serial | [SANPO USB to FDCAN](usb_fdcan) |
| Control a selected RS485 channel through USB serial | [SANPO USB to RS485](usb_rs485) |
| Control classic CAN from a Jetson, Raspberry Pi, or another host through SPI | [SANPO SPI to CAN](spi_can) |
| Control CAN FD from a Jetson, Raspberry Pi, or another host through SPI | [SANPO SPI to FDCAN](spi_fdcan) |
| Control RS485 from a Jetson, Raspberry Pi, or another host through SPI | [SANPO SPI to RS485](spi_rs485) |

SocketCAN uses the standard Linux CAN interface and does not require SANPO headers. USB serial and SPI extended protocols use these headers:

| Header | Hex | Purpose |
| --- | --- | --- |
| `ST` | `53 54` | Classic CAN standard frame |
| `ET` | `45 54` | Classic CAN extended frame |
| `SF` | `53 46` | CAN FD standard frame |
| `EF` | `45 46` | CAN FD extended frame |
| `RT` | `52 54` | Wrapped RS485 frame |

(default-settings)=

## Default Communication Settings

| Item | Factory default |
| --- | --- |
| Classic CAN | 1 Mbps |
| CAN FD arbitration phase | 1 Mbps |
| CAN FD data phase | 5 Mbps with BRS enabled |
| RS485 | 4 Mbps, one stop bit, no parity, eight data bits |
| SPI | SHORT, 23 bytes |
| USB RS485 replies | Wrapped `RT`; RAW replies disabled |

USB serial and SPI use settings stored by the firmware. SocketCAN is configured separately by Linux with `ip link`. The “serial bitrate” selected in a USB terminal does not change CAN, CAN FD, or RS485 bus settings.

For first use or after changing motors, send these commands as text over USB serial with a `CRLF` line ending:

```text
AT+VER
AT+SETFDCAN?
AT+SETRS485?
AT+SPIMODE?
```

The reply is the version of the installed firmware. For example, the G473 V66 release returns:

```text
V66
```

See [Communication Settings](baudrate_config) for configuration commands.

(channel-numbering)=

## Channel Numbering

One USB serial connection or SPI chip select accesses the two buses managed by the current MCU. Transmit frames may use whole-board interface numbers, but the firmware selects a local interface as follows:

| Channel | Target on the current MCU |
| --- | --- |
| `0x01` or `0x03` | First CAN/CAN FD/RS485 channel |
| `0x02` or `0x04` | Second CAN/CAN FD/RS485 channel |
| `0x00` | Both channels of the selected bus type |

Use `1/2` with the first MCU and `3/4` with the second so the host configuration matches the `CAN-1` to `CAN-4` and `RS485-1` to `RS485-4` silkscreen.

Replies use the local Channel number: `0x01` for the first channel and `0x02` for the second. Feedback from CAN-3, CAN-4, RS485-3, or RS485-4 therefore also appears as `0x01` or `0x02` on the corresponding USB port or SPI chip select.

(usb-access)=

## USB Access

A complete board normally exposes two USB serial ports. Linux also exposes four `canX` interfaces through `gs_usb`. `COM`, `/dev/ttyACM*`, and `canX` numbering does not necessarily follow board silkscreen order. For first use, connect only one motor and confirm the mapping.

- On Windows, use SANPO Studio, a serial application, or a tool supplied by the motor manufacturer.
- On Linux, use USB serial; for CAN/CAN FD you can also use `can-utils` or `python-can` directly.
- Before sending unwrapped RS485 data, enable RAW replies as described in [RS485 Raw Passthrough](rs485_passthrough).

(spi-access)=

## SPI Access

SPI is suitable for periodic control from a Jetson, Raspberry Pi, or another host. Software CS0 and CS1 normally connect to the board's two external chip-select inputs, one for each MCU.

- Use SPI Mode 0, MSB First.
- Factory default is SHORT: exactly 23 bytes per transfer.
- CAN FD or more than 18 bytes of RS485 data requires LONG: exactly 73 bytes per transfer.
- SPI is full duplex. Data read while sending a command may be an older cached reply or all zero; send additional empty frames of the same length to read later feedback.

(configuration-and-maintenance)=

## Configuration and Maintenance

- [Communication Settings](baudrate_config): configure CAN, CAN FD, RS485, and SPI length mode.
- [Offline Batch Execution](batch_programming): store and automatically execute a group of motor commands.
- [Firmware Update](firmware_update): update both MCU devices with ST-LINK.
- [Interfaces and Pinout](board_schematic): view bus, expansion, and MCU pins.
- [Migrating from V4 to V6](v4_to_v6_migration): update an existing V4 host application for V6.

> **Important:** Do not perform a full-chip erase during firmware updates. It removes factory identification, saved communication settings, and offline batches, and factory initialization must then be performed again.