John Seamons wrote:
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: (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 

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 

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

time-nuts mailing list --
To unsubscribe, go to
and follow the instructions there.

One potential problem with very high sample rates is that the PLL associated with the 5370's 200MHz vernier oscillators fail to lock if the sample rate is too high.


time-nuts mailing list --
To unsubscribe, go to
and follow the instructions there.

Reply via email to