[time-nuts] 5370 firmware hacking status report

[John Seamons]

Some progress since February's discussion:

My m6800 emulator running the 5370 firmware has been moved from the Linux box to a little 32-bit microcontroller on it's own small evaluation-kit board.
Pictures here: http://jks.com (click on images for larger versions)

You talk to it over an Ethernet connection. The 5370 device bus connects to the general-purpose I/O pins of the micro. Since the micro has 256KB Flash & 128KB SRAM no off-chip memory is required. Everything just fits: emulator, firmware, lightweight TCP/IP stack, minimal C runtime, device drivers, performance hacks, ...

All the front panel controls seem to work as expected. The operator verification section of the manual checks out. The HPIB hardware & remote programming work, but I have a limited ability to test it currently. I have no computer-based GPIB card yet, just a 4396A with HPIB + Instrument Basic (yuk). But I also have a mode that fools the firmware into thinking the 5370 has the HPIB card installed (when it doesn't) and instead sends the transactions over Ethernet (USB also possible). More about this in a bit.

Measurement performance is improved 40% on average and as much as 70% for some functions (see the spreadsheet and charts).

The ultimate goal is to produce a drop-in replacement for the CPU card which would also allow you to toss the ROM card (older 5370s) and HPIB card. You'd get serial, Ethernet and USB connectivity to replace the HPIB.

Now all this is fine, and somewhat amusing, but it's not clear there is any particular advantage. It's not as though there are piles of 5370s lying around with dead or missing CPU cards. Or that it's impossible to deal with HPIB anymore. One interesting possibility is adding new front-panel accessible measurement functions. Since the emulator has complete bus access it can detect new key press combinations before the firmware does and go into a mode where it gathers raw TI samples, processes them, and puts the results in the display. When an existing key sequence occurs the firmware is resumed and it doesn't even know it was paused while the new function was running.

But I discovered something else that's even more interesting (note that I am relatively new to this time-nut stuff, so please correct my nutty mistakes). There was a discussion about how the 5372 is nice because of the high-speed readout option and the lack of dead-time, but how it doesn't match the 5370 one-shot resolution. The 5370 of course has this binary HPIB mode to get raw TI samples sent as fast as possible (roughly 6000/sec). I decided to try the same thing but from C code running on the (much faster) micro. I disassembled the firmware loop that reads samples from the TI count chain registers into the HPIB data-out register. I found that I could move 100K samples/sec out of the TI regs into a memory buffer (not a typo, one hundred K). Adding code to stream 512 samples per Ethernet packet back to a host computer dropped the rate to 80K/sec.

The screen shot of the logic analyzer shows this process. This trace has little jitter so as long as the host on the other end is reasonably fast, and the network isn't loaded, this streaming rate should be sustainable. Obviously there is huge dead-time while the network code runs, but there might be ways around this. I should mention that because I have more processing power now on the instrument side I can do some pre-computation and only send 2-bytes per sample as opposed to the 5370 which sends 5. So 512 * 2 bytes = 1024 bytes/packet.

The last screen shot is of the host side. So far all the TI values seem to be reasonable.