JVS I/O

From Pcbotaku wiki
Jump to: navigation, search

JVS I/O !!THIS IS A WORK IN PROGRESS!!

This page will eventually document some parts of the JVS I/O protocol.

Sniffing the traffic is trivial, since it is multipoint. All you need is a RS-485 interface, and hook up the datalines and GND. RS-485 USB interfaces are readily available on ebay, and shows up as a serial port under windows/linux.

Physical layer

The physical layer is a 4 wire operation, with two lines used for RS-485, sense and GND. USB A/B connectors are used, but this is just the connector. The RS-485 part is standard RS-485, 115200, N, 8, 1. The topology is multi-point, so care has to be taken to avoid packet corruption when there are concurrent senders - this is done at the link layer. The sense line is point-to-point.

JVS Physical pinout

USB pin USB Color JVS Signal RS485 Signal
1 Red Sense N/A
2 White DATA- A
3 Green DATA+ B
4 Black GND GND

Link Layer/Framing/Packet format

Jvsio-packet.png

SYNC

0xE0 signifies start of frame. To cope with E0 appearing in the payload, 0xD0 is defined as an exception byte. 0xD0 is discarded, and the next byte +1 is the actual payload byte. 0xE0 payload, would be encoded as [0xD0 0xDF], 0xD0 payload is [0xD0 0xCF]. A function to read payload off the wire could look like this:

int getjvsbyte()
{
    unsigned char b;
    b=getbyte();
    if ( b==0xd0 ) // special case to deal with syncbyte 'e0' appearing in payload
        b=getbyte() +1;
    return b;
}

NODE

Node is the destination address. Node 0 is the master node, and the one that sends out requests to slaves. Slaves, or I/O boards, are numbered 1-31.The I/O board furthest away from the master, physically, has the lowest id. The special node 0xff is a broadcast, i.e. all slaves should process it.

Byte # / Size

Number of remaining bytes in frame, including checksum.

Checksum

All bytes from node to last bytes of payload are added togehter, modulo 256. This is compared to the last byte of the frame, if they don't match - simply discard the packet. Only payload bytes are added.

Request/Ack scheme

All communication is initiated from the master with a Request packet, either a broadcast to all slaves, or a specific slave. All requests, except the RESET request have accompanying Acknowledge packet. A packet may contain more than one requests, in which case the Ack packet will contain more than one report.

InitializationInitialization

Jvsio-topology.png At powerup the master sends a RESET request, telling all slaves to go to their uninitialized state, with no node id and sense output line to high. The spec says you should send this packet twice.

After the reset request, the master starts to initialize the slaves with node numbers. It starts with node #1, and continues until all slaves have addresses set. This procedure serves the same purpose as DHCP in the IP world.

A slave should ignore the the address offered if the input sense is high. That way, the last I/O board gets the first address - 1 – since it has no eastbound neighbors. The slave that picks up the request sends an ACK back to the master, and pulls it’s output sense to 0.

If the masters input sense, after receiving an ack for slave id #1, is not 0 after 1ms, it sends out a new set address set request with an increased node number for the next slave. This continues until either id>31, or sense is 0.

[E0][FF][03][F0][D9][CB] - Broadcast, reset all I/O boards
[E0][FF][03][F1][01][F4]  -  broadcast, register I/O board 1
[E0][00][03][01][01][05] - to master, empty ACK message, I/O board 1 is now initialized

After slave initialization, what generally follows is a

  • I/O board ID request
  • I/O board Command version request
  • I/O board JVS version request
  • I/O board JVS communication version request
  • I/O board capabilities request

Requests

The master node (id 0) always initiates communications, in the form of a commands in a request packet. Slaves will never send anything unless it is initiated by a request - this way communication is deterministic, and contention is avoided. Request frequency is normally about 60 pr second, and to avoid delays, several commands can be muxed into a single packet. There are no delimiters between commands, so in practice only commands/replies with well defined sizes are combined together.

ACKs

Acks are always a response to a request. Ack packets have a general status byte, which should be 01.

After the status byte, a report status follows, the translation doesn't make a whole lot of sense, but as the status byte, it should be 01: You have 1 status report pr command request.

Wire capture from a Naomi, a request packet with 3 commands - switch input, coin input and analog input:

[E0][01][08][20][02][02][21][02][22][08][7A] 

Accompanying ACK with a report status pr request:

[E0][00][1E][01][01][00][00][00][00][00][01][00][00][00][00][01][14][00][13][00][13][00][13][00]14][00][14][00][14][00][14][00][BF]