Issue 99, October 1998
Networking with DeviceNet—Part 2: A Weather Station Application

Start • Can Chips • Chip Setup • Real Time • Message Flow • Connections • Timers • Analog Input Point • Identity Object • Fragmented Messages • Getting Physical • Applying DeviceNET • Software,Sources

REAL TIME

I can’t help but be excited about writing code for a fast 32-bit CPU after designing 8-bit systems for years. The feeling of power is like the feeling I got from my first car, a ’67 Camaro with a 327 engine.

To make sure the 18.2-Hz BIOS clock interrupt wouldn’t hurt me, I measured its duration by looking at how big a chunk it took out of a tight loop that pulsed an I/O pin. According to my scope, it is just 56 µs, including the time it takes to run my own timer interrupt at INT 1C, which is chained to the BIOS clock interrupt. I use this timer to update my DeviceNet connection timers.

When a DeviceNet message arrives, the 82527 pulls IRQ5 high. According to Intel, the ’386EX has a worst-case interrupt latency of 63 clock cycles, or ~2.5 µs at 25 MHz, neglecting wait states.

So, my DeviceNet interrupt handler has to wait for a maximum of 58.5 µs (i.e., 56 + 2.5) before it runs. This situation happens when a DeviceNet message comes in just after a BIOS clock tick.

The DeviceNet interrupt handler in Listing 1 reads the message-length byte to find out how long the message is and then reads only the data bytes it needs to. Most DeviceNet messages are well under 8 bytes. The most frequent message, the I/O Poll Request, has no data bytes at all!

By the way, check the disassembled machine instructions with your debugger to make sure functions like peekb() are getting expanded inline. Depending on compiler settings, they may not be. For an 8-byte message, the duration of my DeviceNet interrupt handler is 100 µs with peekb() inline or 160 µs otherwise.

These timing measurements show there’s still plenty of time left for processing messages. DeviceNet recommends a response time of 1 ms for I/O Poll messages and 50 ms for Explicit messages. These measurements also show that a faster PC/104 bus wouldn’t help much. Out of the 100-µs total time for the interrupt handler, only about 6 µs (eight bytes at 720 ns per bus cycle) is spent doing bus transfers.

If your CPU is slow, an easy way to get the 1-ms response time for I/O Poll messages is to put the data you want to send in the CAN chip’s mailbox ahead of time, ready to go. When an I/O Poll request comes in, immediately tell the CAN controller to send it. With this strategy, I measured the weather station’s I/O Poll response time at a worst case of 140 µs.

I later changed the code to be consistent with my priority-based event handler, which runs in the main loop. My DeviceNet interrupt handler puts the message into a buffer, sets a bit in a 16-bit event-word to indicate a message is in, and exits.

The bit’s position within the event-word determines its priority. When the main loop detects this bit and no higher priority bits exist, it calls the link consumer to consume the message, gets the data from the Assembly Object, and calls the link producer to produce the message. This orderly approach lengthens the I/O Poll response time to 340 µs, which is still plenty good.