• Please review our updated Terms and Rules here

TTL-logic tester

fjkraan

fjkraan

Experienced Member
Joined
Jul 30, 2003
Messages
179
Location
Netherlands
This subject isn't very vintage itself, but it could be useful in repairing vintage
hardware.

Last week I created a simple TTL-I.C.-logic tester based on an Arduino and a Python script.
Currently it only tests 18 different I.C.s from the 7400 series, having 14 and 16 pins.
The chip-definition is in a separate text file, adding new I.C.s is as simple as creating
a Boolean expression for its output pins.

The tester hardware part is build on an Arduino UNO, but any 5 Volt Arduino will
probably work too. There are just about enough pins for testing 20 pin I.C.s, but
most of then are not simple gates.

The software part is a +200 lines Python 3 script and a text based I.C.-definition list.

https://github.com/electrickery/logicTester

Planned extensions are testing for clocked logic, but I havn't defined a concise
notation, or created any code for this.

Current (v1.1) I.C.-list (actually tested): "7400", "7402", "7404", "7407", "7408", "7409", "7410", "7411", "7420", "7421", "7427", "7430", "7432", "7433", "7438", 74125", "74132", "74138"

Greetings,

Fred Jan
 
Fred, is this any different from the IC testers that are present on many older EPROM programmers. My SuperPro, for example, can test both CMOS and TTL ICs.
 
Chuck(G) said:
Fred, is this any different from the IC testers that are present on many older EPROM programmers. My SuperPro, for example, can test both CMOS and TTL ICs.
Click to expand...

Somewhat:
* It isn't present on my EPROM programmer,
* It is simple and cheap,
* It is open source,
* It is easy to upgrade,
* I made it myself and it was fun to do.

Greetings,
Fred Jan
 
That would be good option, I have quite some of those in unknown quality. Would need another algorithm than defining pins by boolean logic.
Just now I ran into an 74LS85, finding a serious limitation in my approach:).
 
Chuck(G) said:
You may want to consider expanding your code to do common low-capacity 16K/64K/256K DRAMs as well.
Click to expand...

Floating around various forums and whatnot is the "Dramduino" code; I checked the modifications I made to have it work for 16k chips into Github a while back. Of course, a fun gotcha with the most common 16k parts is their requirement for three different supply voltages.

An objection to this code that was raised in a thread here a while back is that this is going to drive the chips very slowly, since it uses the fairly glacial arduino pin manipulation commands. (IE, there's probably a significant chance of false "negatives", IE, declaring a chip bad when it's not, because this code is so slow it's out of spec per the datasheets.) One thing I might do since I've been teaching myself how to use the direct port manipulation commands and embedded assembly the last few days is rewrite it to do that instead. I've verified you can indeed bang up to 8 pins at once at a full 16mhz using those techniques.
 
Chuck(G) said:
Why not use a cheap Blue Pill for this? Runs at 72MHz, IIRC. If you like the Arduino IDE, there are tools for that.
Click to expand...

Well, the reason I'm using 8-bit Atmel for the project I'm doing the assembly language shenanigans for is ultimately I want to embed what I'm working on into a PCB board, and the bare Atmel CPUs come in a number of convenient through-hole DIP packages and are plenty cheap. I could just stick a socket for a whole Blue Pill on the board, I guess, the price difference is a wash, but it's kind of a hack. Using the Arduino IDE is mostly just a matter of "it's there", and there's also a *lot* of freely available code floating around to borrow from.

(Also, testing on a knockoff Arduino Nano, which costs about the same as a BluePill, is kind of convenient.)

Video timing generation for Atmel seems to be pretty well baked and speed isn't important for setting up the timers; the only thing that I need cycle-accuracy for is keeping up with the pixel clock during active video output, and testing indicates one little snippet of embedded assembly should do the needful. Might need a faster CPU for VGA but at the moment I'm looking to emulate late 1970's-level video outputs in NTSC composite and so far it looks like I have plenty of headroom.

(AVR tops out at 20mhz but, knock on wood, I think I might actually be able to get away with running the CPU at half the pixel clock with an external divider, which would put 800x600 within stabbing distance.)

.... anyway, sorry, I digress. The OP might well be interested in the Blue Pill. I am myself, actually, but for the *next* project...
 
Another option for more speed is the PIC32 available in 28 PDIP. Originally, I used the PIC32MX in 64-pin QFP with a PGA-type adapter, which also had all of the bypass caps on it. Very cheap. I liked the architecture, but thought that the world was going ARM (and still do), so I switched to the STM32F4 and F7 devices. The PIC32MX did have one thing that the ARM chips lacked--a parallel "master port" that would make a great bus interface.
 
I'm all for switching to a bigger hammer when you need one, but don't underestimate what you can do with the little one. ;)

For laughs I just decided to scientifically compare the dumbest possible case of inline assembly verses native Arduino port twiddling and this is what I found. This loop:

Code: 
  while (p--) {
    PORTB=SRZERO;
    PORTB=SRONE;
  }

Executes in exactly the same amount of time as this (not counting the setup outside the loop, which should be 2 additional cycles not counting any setup overhead):

Code: 
    asm ( 
    "lds r24, (SRONE) \n"
    "lds r25, (SRZERO) \n"
  : : : "r24","r25" );

   while (p--)
   asm (
    "out 5, r24 \n"
    "out 5, r25 \n"
    "out 5, r24 \n"
    "out 5, r25 \n"
    "out 5, r24 \n"
    "out 5, r25 \n"
  : : : "r24","r25"
  );

What this is doing is toggling a single bit on a port on and off by writing complementary values to the 8-bit port register. (In this case it's the "video" output to a CRT, combined via resistors to a sync pin that's driven by timer interrupts for horizontal and vertical.) I'm eyeballing this by looking at the pixels on a CRT, but it looks like both loops are about nine cycles. (The C-one gives me white and black pinstripes with about a 2/3 duty cycle, while the C-one gives me three 1 pixel-clock-wide white stripes separated by one-pixel-wide black stripes, and a black stripe that looks about three pixels wide. The horizontal line area occupied by both is the same.) This basically confirms that for my project I can do five "things" for each one-byte character position on a CRT line without even having to go to assembly for the loop. (or having to unroll it.) That actually seems pretty darn good to me.

The thing I'm going to be doing with this is twiddling the load line on a shift register and sending a clock tick to an address counter (driving external RAM for an arbitrarily large frame buffer) so maybe it's kind of analogous to a "chip tester" application? Anyway, with this sort of performance it looks to me like you could probably do something like a DRAM tester that would run "pretty fast", maybe around an effective 3-4 mhz-ish (figuring for sending a CAS, RAS, and read/write operation) if you did it with embedded assembly, which is worlds faster than Arduino "pin" commands will give you. Even just using the direct port write should get you into the ballpark of the datasheet, at least.

Anyway. :) I'll freely admit that another big reason I've decided to just keep muscling through with Avr 8 is the sunk cost of already having installed the tools and learned enough to hammer on them like a befuddled ape. Personally I find that it can often be the case where it's easy to waste more time trying to find the "best" solution to a problem than it would have taken to have just done the job with whatever's lying around.
 
Eudimorphodon said:
I'm all for switching to a bigger hammer when you need one, but don't underestimate what you can do with the little one. ;).
Click to expand...

Says he to the guy who did the AT-XT converter with an 8 pin PIC. :)

For me, it's just that silicon is so blooming cheap nowadays, why not use the biggest hammer that makes sense? I use the Blue Pill for the IR-to-PS2 keyboard interface. It would be mostly a matter of code to convert that to an IR-to-USB keyboard. Could I do it with an ATMega8? Sure, but why bother? I've got a bunch of AVR parts, from the ATTiny to the ATMega, but I can't rationalize the design effort.

I use the STM32F407 180MHz boards for lots of things, since a board is about $10 and includes RTC, LCD interface, 4-wire SDIO, USB OTG....lots of memory and 5V tolerant GPIO, etc. Even if I use only a quarter of the capabilities for a project, it's still cheaper for me than building something up from scratch and then have to redesign when I want to add functionality.

Silicon is stupid cheap on the low end. Just ask the guys who stick those sub-nickel MCUs in everything under the sun...
 
Chuck(G) said:
For me, it's just that silicon is so blooming cheap nowadays, why not use the biggest hammer that makes sense?
Click to expand...

But what if you don't get anything from the bigger hammer? That's mostly my point.

I did actually spend a lot of time looking for example video counter code for the BluePill (I do have a couple sitting in an envelope), and what I found was that even when you moved into low VGA resolutions it seemed like there were more, and better, code examples for AVR than there were for BluePill. On both CPUs the standard practice is to just program the timers, wake up on line interrupts, and "do something" to make the lines happen during the active area, so the limiting factor is if the CPU in question can "do the thing" for each line fast enough. The Atmel *is* kind of borderline, speedwise, but it is capable.

(If I were planning to try to use internal memory on the CPU instead of external parts then, sure, I'd already have packed up the AVRs, but since I just need to twiddle some bits a hybrid of using a little Assembly in the one spot I need it seems like a perfectly reasonable compromise.)

... but, really, it's all about the codebase. If the argument is that a faster CPU automatically lets you be lazier (and I'm all about lazy!) TV-out seems to be a counter-example. There are working Arduino TVout sketches that are only "dozens" of lines long and were easy to hack, for the BluePill not so much. (The code for the "BlueVGA" library is, ironically, packed full of inline assembly and *much* harder to follow than, say, Nick Gammon's AVR VGA library, which is entirely in C.) Maybe I'm just having unusual difficulty navigating the BluePill landscape as a novice, but accessibility and good documentation really do count when you're starting on a project.

(I have no doubt I'll be all-in on the BluePills once I actually use them for something *else*, but they don't seem like the silver bullet I wanted for *this*.)
 
Well, to be fair, on any of the higher-level MCUs, you should be prepared to do a bunch of reading. The family manual for the STM32F4 series runs to 1745 pages. The F7 manual is nearly 2K pages.

I think that the F1 manual is 1128 pages long.
 
Yeah. That’s why I’d still say there’s a case to be made for a brain dead little CPU that you can spend a few hours skimming the manual and poking at examples and take away enough to do the job. The structure of the AVR seems remarkably well suited for “cycle-counting” applications, with many byte-manipulating instructions guaranteed to execute in one tick and the large number of registers to keep constants in. One article I read about doing video generation on the STM lamented how “asynchronous” it was with different instruction times depending on, for instance, if the code was running from flash or RAM, and the DMA engine also isn’t a lot of use for what I want to do.

(Well, actually, I was thinking I could maybe “compile” my commands for the external chips and have the DMA engine fire them out... but there’s a serious learning curve there...)
 
You must log in or register to reply here.
Back
Top