JVS I/O - Revision history

Invzim: /* Physical layer */

2012-09-08T15:13:10Z

Physical layer

@@ Line 8: / Line 8: @@
 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,
 , 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.
 ==Link Layer/Framing/Packet format==

Invzim at 15:46, 3 May 2011

2011-05-03T15:46:39Z

← Older revision		Revision as of 15:46, 3 May 2011
Line 1:		Line 1:
			[[Category:Naomi]]
	==JVS I/O !!THIS IS A WORK IN PROGRESS!! ==		==JVS I/O !!THIS IS A WORK IN PROGRESS!! ==
	This page will eventually document some parts of the JVS I/O protocol.		This page will eventually document some parts of the JVS I/O protocol.
Line 64:		Line 65:
	===ACKs===		===ACKs===
	Acks are always a response to a request. Ack packets have a general status byte, which should be 01.		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.		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:		Wire capture from a Naomi, a request packet with 3 commands - switch input, coin input and analog input:

Invzim at 20:35, 11 April 2011

2011-04-11T20:35:32Z

← Older revision		Revision as of 20:35, 11 April 2011
Line 1:		Line 1:
	==JVS I/O==		==JVS I/O !!THIS IS A WORK IN PROGRESS!! ==
	This page will eventually document some parts of the JVS I/O protocol.		This page will eventually document some parts of the JVS I/O protocol.

Invzim: Created page with "==JVS I/O== 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,..."

2011-04-11T20:35:02Z

Created page with "==JVS I/O== 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,..."

New page

==JVS I/O==
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.

==Link Layer/Framing/Packet format==
[[image: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===
[[image: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]