KWP ioctls

Parameters marked with 'VSONI' are only guranteed to be updated during the next (hard) initialisation. (VSONI = Value Set On Next Initialisation.) Unfortunately due to the nature of the keyword card, it can't be guaranteed that 'VSONI' parameters wont be updated until initialisation, they probably wont, but client code should not rely on this. Given this, certain parameters may cease to be 'VSONI' parameters in future driver versions in order to try to reduce the amount of confusion here.

Parameters marked with 'VSI' are changed immediately. (VSI = Value Set Immediatedly). This document uses this marking just confirm to the reader that the parameter isn't a 'VSONI' parameter, and they do not need to initialise the channel for the change to take effect.

All integers in arguments are in x86 byte order.


Arguments: 2 bytes	- bit time (microseconds) 0x0060 = 10,400 bits/sec


Arguments: 24 bytes

		0,1	- P1 rx min  (half milliseconds, 'x86' byte order)
		2,3	- P1 rx max	"		"
		4,5	- P1 tx		"		"

		6,7	- P2 rx min	"		"
		8,9	- P2 rx max	"		"
		10,11	- P2 tx		"		"

		12,13	- P3 rx min	"		"
		14,15	- P3 rx max	"		"
		16,17	- P3 tx		"		"

		18,19	- P4 rx min	"		"
		20,21	- P4 rx max	"		"
		22,23	- P4 tx		"		"

The first two values for each P time specify a valid range that is used by
the device to interpret the byte traffic from the bus.  The device may
indicate a timing violation error to the user should it see traffic violating
this range.  The third value for each P time is the time the device should
use when transmitting.  For normal use the third value should be somewhere
in between the first two values.


Arguments: 30 bytes

		0,1	- W1 rx min  (half milliseconds, 'x86' byte order)
		2,3	- W1 rx max	"		"
		4,5	- W1 tx		"		"

		6,7	- W2 rx min	"		"
		8,9	- W2 rx max	"		"
		10,11	- W2 tx		"		"

		12,13	- W3 rx min	"		"
		14,15	- W3 rx max	"		"
		16,17	- W3 tx		"		"

		18,19	- W4 rx min	"		"
		20,21	- W4 rx max	"		"
		22,23	- W4 tx		"		"

		24,25	- W5 rx min	"		"
		26,27	- W5 rx max	"		"
		28,29	- W5 tx		"		"


Arguments: 5 bytes	- fast wake up start communication request


Arguments: 8 bytes	- fast wake up start communication response


Arguments: 1 byte	- node type, GKWPMONITOR / GKWPTESTER / GKWPECU


Arguments: 1 byte	- protocol, GKWPKWP2000 / GKWPISO9141FORD


Arguments: 1 byte	- node address
VSONI  (slight bug here, the value thats used for wake ups _may_ also be
	updated if some of the other ioctls are used, as well as on
	initialisation.  The situation is complicated by the fact that the
	card asks for node addresses just as part of its initialisation,
	and I'm not exactly clear what it does with them or what it wants
	them for when the parameters envolved for the wake up stuff
	(including node addresses) are set up elsewhere.  I could hack
	round this in the driver, admittedly.  Actually all this is a
	little insignificant anyway, as all the keyword VSONI values get
	updated if the J1850 channel gets initialised (and vice versa).
	I guess I'll mention that at the top of this document, in which
	case this comment can probably be deleted.)


Arguments: 1 byte	- wakeup type, GKWPFAST / GKWPFIVEBAUD


Arguments: 1 byte	- address of node to wake up


Arguments: 2 bytes	- keybytes to send in (5 baud) wake up process


Arguments: 0 bytes


Arguments: 2 bytes	- value of keybytes seen in last successful wake up
			(only currently implement for 5 baud)


Arguments: 2 bytes	- value GKWPGETLASTKEYBYTES returns until a
VSI			  successful wake up is seen.

KWP events

GKWPWAKEFIVE		- 5 baud wakeup seen

	byte 0	- 5 baud address	   (tester)
	byte 1	- sync byte		   (ecu)
	byte 2	- first keybyte		   (ecu)
	byte 3	- second keybyte	   (ecu)
	byte 4	- inverted second keybyte  (tester)
	byte 5	- inverted address	   (ecu)

	byte 6	- status 0 = timing good

Note any length of data should be tolerated by client.  Currently implemented
lengths are 1 (i.e. an unsuccessful wake up) and 7.  Longer data lengths may
occur in the future if more information is appended to this event.

GKWPWAKEFAST		- fast wakeup seen

	byte 0	  - the WuP as interpretted by a uart, i.e. usually 0xf0
	byte 1-5  - the start communication request message.
	byte 6-   - the start communication response message

Again, any length of data should be tolerated by client.

GKWPBUSIDLE		- intermessage time elapsed since last byte

	byte 0,1  - time expired (in units of half milliseconds,
		    network byte order).

In addition to the events above, acknowledgements from the card's dual port ram communication mechanism also generate events. These can be distinguished by the fact the most significant bit of the event number is set. Normal users should either not enable event numbers greater than 127, ignore these events, or contact Gryphon development if their application needs any functionality these events may offer.

KWP stat bits

GKWPSTAT_KLINE		Message on K line (rx and tx)
GKWPSTAT_LLINE		Message on L line (rx and tx)
GKWPSTAT_ERR		General bus error (rx only)
GKWPSTAT_CSERR		Checksum error (rx only)
GKWPSTAT_CONTENTION	Bus contention detected (rx only)
GKWPSTAT_BLOCK		Message received over multiple interrupts (rx only)