1. Home
  2. Embedded Programming
  3. Very Slow Circuits (Was: Fast Circuits)

Very Slow Circuits (Was: Fast Circuits)

> How about 1uHz? (or 1nHz or 1pHz?)

>> ... >> For 1uHz, R=1Mohm, C=1F.  That isn't easy, even with an external >> capacitor! >... >I can imagine the utility of 1mHz, may be, even 0.1 mHz in some >extreme cases where you want to take a deep thought between the >clocks. But 1uHz? Can't see how it helps debugging.

Reading 1uHZ as "full stop",...

A few geological ages ago, I was debugging a quite complex system based on a Z80 CPU (Fully static design) Things like an ICE or logic analyzer were luxuries not available to me, so I had to improvise.

One of the things I did was to hook up a couple of logical gates and a flip-flop between the RD & WR lines and the WAIT lines, forcing the CPU into wait state each time it tried to access the bus.

The address and data lines were connected to 3 x 8-bit buffers, multiplexing the 24 bits into a single 8-bit lane.

That lane plus a few control lines went to a CP/M computer printer port, where an interpreted BASIC program read the data and then toggled the flip-flop allowing the Z80 to do one more memory cycle.

The basic program would disassemble the current operation and, if it involved an external memory transfer show exactly what was being read/written and where

Voila! With an investment of a few hours of work I had a system that allowed me to fully trace the program flow and memory access. Could have any number of breakpoints (just keep toggling the flip-flop until reaching a given address, then stop for manual control), count the number of times a branch was taken, etc. Everything in slow motion, of course, but the information I gathered was not available otherwise.

I was forcing wait states, but could have accomplished the same thing gating the CPU clock. Either technique would have been impossible with chips like the

6800/6502 that would loose state if the clock was below a certain minimum frequency, and that could not be kept in wait state for more than a few microseconds.

You can not do the same with a modern controller with on-chip memory, etc. but still, slowing down the processor so that you can, for example, check the state of 10 GPIO pins with your 2-channel scope, is a very valuable feature.

Reply to
Roberto Waltman
Loading thread data ...

I did something similar with a '7180 on an NS32032. The 7180 acted as a "microprocessor supervisor" -- implementing several bits of junk logic, an intelligent watchdog, debug port, status indicator, etc.

Since the 7180 was *way* too slow to respond to the 32k's bus clock, accesses to the 7180 forced wait states (until the 7180 "released" the bus cycle... having read or written whatever data was appropriate for that transaction). I.e., if the watchdog issued a challenge to the 32k, when the 32k wrote it's response to the 7180, the 7180 would stall the 32k's bus while it examined the result and decided whether or not the 32k was "sane" (else it would log the problem and tug on the 32k's RESET line)

Likewise, if the 32k wanted to send a message out the diagnostic port (a serial port *on* the 7180), it fed the message to the 7180 and the 7180 then interacted with whatever device was attached to the port.

Since some of the "junk logic" that the 7180 was responsible for controlled the operation of the main address decoding logic, it was trivial to design that logic (PLA) so that the 7180 filled the

*entire* memory space of the 32k on power up.

This allowed the first stage bootstrap to be "spoon fed" to the 32k from the 7180's internal ROM. Then, the 32k could tell the 7180 (as part of that bootstrap program) to "unmap itself" from the (entire) address space so execution could proceed as intended.

A pleasant side effect of all of this was that you could rewrite the monitor code in the 7180 (during development) to "fetch" the bootstrap code for the 32k via the debug port!

Admittedly, a real kludge. But, when you don't even have a socket for an EPROM on a board, using back doors can be less painful than you would otherwise think! ;-)

Reply to
Don Y

It seems to me, some looping test programs coupled with externally syncing a scope with a 'control' signal could've been just as useful (in examining the width of a port or buffer anyway). Anyway, we used it as a poorman's logic analyzer, in the distant past. lol! I CAN see how a slow clock could be useful too. Especially with limited test equipment.

Reply to
1 Lucky Texan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.