VPW J1850 specific ioctls ------------------------- #define GDLCGETFOURX 0x11400001 /* 1 [01] */ #define GDLCSETFOURX 0x11400002 /* 1 [01] vsoni */ 1 byte argument - 0 == normal speed, 1 == four times mode Sets the bit rate the dlc will be set to on next initialisation (GINIT) #define GDLCGETLOAD 0x11400003 /* 1 [01] */ #define GDLCSETLOAD 0x11400004 /* 1 [01] */ 1 byte argument - 0 == normal load, 1 == first node load Note that unlike GDLCSETFOURX, the effect of GDLCSETLOAD is immediate. #define GDLCSENDBREAK 0x11400005 /* 0 */ No arguments Causes the channel to transmit a break symbol on the J1850 bus. #define GDLCABORTTX 0x11400006 /* 0 */ No arguments Issues a 'abort transmission' command to the dlc. According to the data book this is one of only two ways to recover from a netfault condition (the other is to reset the chip). Issuing this ioctl after a netfault will cause the channel to resume transmission possibly causing a flood of (up to 125) backed up messages. #define GDLCGETHDRMODE 0x11400007 /* 1 */ #define GDLCSETHDRMODE 0x11400008 /* 1 */ 1 byte argument - #define GDLCHDRZERO 0x00 #define GDLCHDRONE 0x01 #define GDLCHDRTHREE 0x03 #define GDLCHDRONEOBD 0xfe #define GDLCHDRGUESS 0xff Changes how the driver interprets received message bytes to set the hdrlen and hdrbits fields in struct gdatahdr. In GDLCHDRZERO mode and GDLCHDRONE mode hdrlen is always set to the value zero and one respectively. In GDLCHDRTHREE mode, hdrlen is alway set to the value three, unless the message is shorter than 3 bytes long, in which case hdrlen is set to the length of the message (i.e. either one or two). GDLCHDRONEOBD is the same as GDLCHDRONE except for messages that the driver recognises as conforming to J1979, in which case hdrlen is set to three (this mode is useful for when the DLC is connected to a Chrysler J1850 bus). The default mode is GDLCHDRGUESS. In this mode the 'H bit' of the J1850 standard (bit 4 of the first byte of the message (on a scale of bit 0 - bit 7)) is interpreted. If the H bit is set, or the message is shorter than three bytes, hdrlen is set to one, otherwise it is set to three. This mode is compatible with a G.M. J1850 bus and any J1850 bus that doesn't have single byte unconsolidated headers (i.e. respect the meaning of the H bit). In all header modes hdrbits is set to the value of hdrlen multiplied by eight. #define GDLCGETRXMODE 0x11400009 /* 1 */ #define GDLCSETRXMODE 0x1140000a /* 1 */ 1 byte argument - #define GDLCRXDEFAULT 0x00 #define GDLCRXNOIFR 0x01 Changes how the driver receives messages. The default mode is GDLCRXDEFAULT which should be suitable for most applications, therefore most people wont need to use these two ioctls. Mode GDLCRXNOIFR was introduced after it was found that the IFR receive code in the DLC driver was slowing down a particular Chrysler radio flash RAM programming application. The Motorola DLC chip receives IFRs as if they were a separate message to the data they are attached to. In normal GDLCRXDEFAULT mode, under typical conditions when the gryphon DLC driver receives a J1850 message without IFR, as it takes the normal message data from the DLC chip it usually sees that the bus is idle at that point so passes the message along to the user with no delay. When an IFR is attached to the normal data, as gryphon DLC driver is given the normal message data, it sees that the bus is still active so hangs onto the normal data until it has received the IFR and only at that point passes the normal message data and the IFR data encapsulated together in a single gryphon data frame along to the user, again with no unnecessary delay. The driver only adds extra latency in the default mode when it is receiving messages with no IFR attached and for whatever reason sees the bus still active. This normally happens when the driver sees back-to-back J1850 messages, in which case the extra latency will be the time it takes to receive the next message (e.g. a 5 byte message at 10.4K will add about 5 milliseconds of extra latency). I believe the problem was occurring for a different reason in the case of the Chrysler radio programming project, but I never had chance to investigate the problem further (there is a very slight possibility that the J1850 hardware in the Chrysler radio was at fault of course, for instance by leaving trailing junk on the bus after transmitting its message). Note that the problem only affects latency, and not throughput or efficiency, or the correct bug free operation of the driver (even if no more messages are seen on the bus, an internal timer in the driver eventually after 50 milliseconds (currently) tells the driver to give up waiting for an IFR and pass the message along to the user). It also just so happened that the protocol used for programming the Chrysler radio was very latency dependent. If you think you are having latency problems and do not need to receive IFRs, you may like to experiment with selecting 'GDLCRXNOIFR' to see if performance improves (in which case perhaps let me know details of the application). It is not suggested that you use this mode if you don't need to though. Selecting GDLCRXNOIFR breaks IFR monitoring. Implemented generic ioctls -------------------------- GINIT I'm hoping to make this ioctl perform an actual hardware reset of the dlc chip (once Jason gets chance to support this in the programmable logic) - when this happens this would probably be the best way to recover from a netfault condition? -- Update: hardware reset is now supported in new cards / drivers (7th July 1999) GLOOPON GLOOPOFF GGETHWTYPE (GJ1850,GDLC) GGETREG address - 0x00 == Status Byte Register 0x01 == data byte / CCBR from RX fifo value - contents of above GSETREG address - Command (Byte Register) to issue to DLC value - data byte (meaning depends on value of above) (these two are a bit of a stretch of the register concept, I know) GETRXCOUNT SETRXCOUNT GETTXCOUNT SETTXCOUNT GETRXDROP SETRXDROP GETTXDROP SETTXDROP GETRXBAD GETTXBAD GGETCOUNTS GGETBLMON GSETBLMON GGETBITRATE Events ------ #define GDLCRXOVER 0x41 No data Receive Fifo Overrun in the dlc chip. #define GDLCCRCERR 0x42 one byte of data - Completion Code Byte Register of dlc chip CRC error #define GDLCINCOMPBYTE 0x43 one byte of data - Completion Code Byte Register of dlc chip Incomplete byte error #define GDLCBTERR 0x44 one byte of data - Completion Code Byte Register of dlc chip Bit Timing error #define GDLCBREAK 0x45 one byte of data - Completion Code Byte Register of dlc chip Break (a 'break' occurred on the j1850 network) Note: If a break is received whilst the DLC is in four times mode, normal mode will automatically be reverted to and an EVENT_SPD event will be generated, if this happens the speed the chip is set to on the next hard initialisation becomes undefined and applications should probably use GDLCSETFOURX (or the CMD_SET_SPEED wrapper for it) to explicitly tell the driver what it should do on the next hard initialisation before the next hard initialisation. (remember GDLCSETFOURX just sets a variable in the driver, it wont affect communications or anything until the next GINIT). #define GDLCNETFAULT 0x46 one byte of data - Status Byte Register of dlc chip A 'netfault' was detected. (a netfault is detected when, in the course of transmitting, the dlc tries to drive the bus, but cant because of say a short. Once this condition is detected the dlc goes into a state where it wont transmit anything, but seems to be continue to be able to receive (the device driver produces a netfault event every time we get a message and are in this state). This state can only be cleared by a aborttx or a complete reset of chip.) Unfortunately it seems a netfault doesn't generate a interrupt so the device driver will only produce this event when it receives a message from the bus. Short of polling the dlc I'm not sure of a way round this. #define GDLCTXUNDER 0x47 one byte of data - Completion Code Byte Register of dlc chip Transmitter underrun. #define GDLCTXARBLOST 0x48 one byte of data - Completion Code Byte Register of dlc chip Transmitter lost arbitration. (new generic 'init' and 'speed change' events also supported). Note block mode is now supported. The length of messages to and from the DLC driver is currently only limited by the maximum length of a gryphon frame (note I would favour increasing this from 4Kbytes to 6 or 7Kbytes). Stat ---- Meaning of the bits in the stat field of gdatahdr of received messages is as follows (note these aren't relevant when transmitting messages): #define GDLCSTAT_BLOCK 0x80 Clients should normally ignore this bit. (DLC received message as a block mode message, meaning that the message was received using more than one interrupt. This bit is primarily used internally by the DLC device driver.) #define GDLCSTAT_MAYHAVEIFR 0x40 Used internally by the device driver. Clients should ignore this bit. (This bit is set when IFR data is expected to be received, but it is normally cleared once the DLC has successfully received and attached IFR data as 'extradata', before the Gryphon data frame ever gets to the client. It is also cleared if IFR data hasn't been received after a set time-out. The client will typically only ever see this bit set during certain error conditions (such as an error event generated in between reception of normal data and IFR data). As its name suggests, even if this bit is set, it doesn't guarantee that the frame represents a J1850 message with IFR data attached.) #define GDLCSTAT_IFR 0x20 Message contained IFR data. IFR data is shown as 'extradata' in the gryphon data frame. The amount of IFR data is limited by the maximum size of the gryphon 'extralen' field (255). The DLC does not normally show CRC bytes, this applies to both the normal data CRC and any IFR data CRC. #define GDLCSTAT_NB 0x10 /* normalisation bit was set */ This bit is set if the normalisation bit of the J1850 frame was set (active short, logic 1) and cleared if the normalisation bit was cleared (active long, logic 0). Note that the DLC chip assumes the IFR has a CRC byte if the normalisation bit is set, this is the reverse of the method documented as being 'preferred' in the J1850 standard.