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.
GKWPGETBITTIME GKWPSETBITTIME Arguments: 2 bytes - bit time (microseconds) 0x0060 = 10,400 bits/sec VSONI GKWPSETPTIMES Arguments: 24 bytes VSI 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. GKWPSETWTIMES Arguments: 30 bytes VSI 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 " " GKWPSETSTARTREQ Arguments: 5 bytes - fast wake up start communication request VSI GKWPSETSTARTRESP Arguments: 8 bytes - fast wake up start communication response VSI GKWPGETNODETYPE GKWPSETNODETYPE Arguments: 1 byte - node type, GKWPMONITOR / GKWPTESTER / GKWPECU VSONI GKWPSETPROTOCOL Arguments: 1 byte - protocol, GKWPKWP2000 / GKWPISO9141FORD VSONI GKWPSETNODEADDR 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.) GKWPSETWAKETYPE Arguments: 1 byte - wakeup type, GKWPFAST / GKWPFIVEBAUD VSI GKWPSETTARGADDR Arguments: 1 byte - address of node to wake up VSI GKWPSETKEYBYTES Arguments: 2 bytes - keybytes to send in (5 baud) wake up process VSI GKWPDOWAKEUP Arguments: 0 bytes GKWPGETLASTKEYBYTES Arguments: 2 bytes - value of keybytes seen in last successful wake up (only currently implement for 5 baud) GKWPSETLASTKEYBYTES Arguments: 2 bytes - value GKWPGETLASTKEYBYTES returns until a VSI successful wake up is seen.
GKWPWAKEFIVE - 5 baud wakeup seen Data: 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 Data: 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 Data: 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.
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)