How to check 125 logic states...?

Possibly true, but at least bicycles haven't changed in over 200 years,

The basic principles of programmable digital electronics haven't changed since Alan Turing & many others worked them out a long time ago... :-)

Im use to tiniest of pitches :-(

I've just designed a similar system, albeit with fewer (and non-binary) "bits".

I have also done something analagous: measured the outputs of 120 (modulated) photodiode detectors combinatorially, using 16 x BPF-FD-comparator stages (2C16 = 120), but I doubt thats applicable here. besides SREGs are cheap.

Cheers Terry

We get asked to design some interesting stuff, don't we? :-)

Cheers Bob

yep. In this case, I had to replace a quasi-digital MUXing scheme, which had a few minor problems:

1) a reasonable response time (say 50ms), divided by 120 keys, was hard to achieve when the light source is modulated at 100kHz - it allows about 40 pulses 2) the post-mux filter had a Q of 50, which meant it took a long time to react, and an equally long time to shut up again (they did have a blanking circuit for this reason), thus attenuating the hell out of the filter output 3) alas, the high Q meant *any* of the digital edges (eg mux or blanking FET) kicked the thing into oscillation 4) shine an IR remote control any where near it and it went bonkers - very fast edges again set the filter oscillating like crazy 5) the very high Q, combined with a single opamp 2nd-order BPF, required ludicrously high GBW. 12MHz wasnt even close (sensitivity goes as Q^2 IIRC for that topology) 6) to try and tame the quasi-digital MUXing, they dropped all the relevant impedances. Unfortunately this meant using extremely bright light sources and photo-darlingtons. Fine with the LED device, but alas TOTALLY UNWORKABLE with a class-1 (or -2) laser.

Turns out they were digital guys, and casually ignored the laser source until after it "worked" (albeit in a flaky manner). This alone killed the existing project (after someone spent $100,000 having it developed).

I originally got called in to do the laser driver. Once it worked (aint hard), the original "engineers" decided they needed much more laser power, which they just cant have (apparently its bad form to burn holes in peoples optical nerves)

there were a couple of mechanical design issues too - all the aesthetics were done, and some bright spark had decided on green and blue overlays, which we then attempt to shine RED light through. oops, howsabout more gain then....I couldnt get them to change the colouring, but we did reduce the colour "density" to allow more light thru.

So I added 120 bandpass-ish photodiode amps (using an astonishingly cheap photodiode, which Fairchild made specially for us, QSB34CGR), whipped up 16 summing-BPF's + HPF + HPF + DFD + comparators, and off we went.

even with all the analogue, it was cheaper. them photodarlingtons were each about 40c more than the PDs. I also replaced 3 x $15 LED driver chips with 2 SREGs and 12 dual transistors ($1 total), a $50 uP with a $3 up, and a whole lot of $1 LEDs with $0.06 LEDs, and made the new one a just little bit cheaper. Oh, and made it USB too.

PSRR turned out to be a real problem, and meant I couldnt use TL064's, which are almost free, but never mind (turns out they have 10dB GAIN at

100kHz). In the process I found bugger all opamp datasheets with a PSRR-vs-F curve, but got good at measuring it myself.

the 8th-order low-Q filters with 60dB passband gain werent too easy to measure, so I bought a network analyser. by including opamp GBW in my calcs and sims, I got extremely good results (reality = sim = calc), it was just a pain to measure. 500s sweep time + go have lunch = slow way to test 120 filters. not so good for the cholesterol either ;)

I did spend almost a week, near the end, trying to track down an "oscillation" which was actually the response to optical square-waves coming out of my TDS224 D-CRO LCD display. I happened to be standing while moving my notebook, and saw the scope display change as the book moved in front of it. much cursing ensued, and I dug out one of my analogue CRO's - look ma, no wobbly bits. Grrr.....

then the time the MFG accidentally placed 4,000 of the wrong capacitor (oops), that was tricky to find, the units may or may not work, and erratically so. by accidentally making the reset capacitor 100x smaller, it violated the reset-vs-osc timing requirements, and the uP sometimes locked up, depending on temperature, and supply slew rate. oops.

lots of fun. personally, I prefer power supplies.

Cheers Terry

That reminds me of a problem I had a few weeks back...

Debugging a particually elusive fault in a digital system that would only show itself once every couple of days or so. On one of the digital lines I captured an unusual packet about 100ns or so in duration, sinusoidal in shape at 115MHz, and several volts in amplitude. Highly unusual for a low impedance TTL digital line. Some sort of weird DC-DC power supply oscillation I thought?

Of course, it would only get captured on the scope when I wasn't there. This went on for quite some time when I finally managed to capture it on the scope just as I was walking away. After much mucking around I discovered that I could reproduce the problem every time by simply standing up from the chair!

Then the penny dropped. The "packet" of sinusoidal data looked like an LC resonant tank response, and standing up on the chair was generating wideband static noise that could couple into my nearby circuit. Combine the two and you would likely get the response shown. But where was the LC?

As I was investigating the (rather horrible) ground system in the design (not mine), I suspected the LC circuit was a parasitic in the design somewhere. After ruling out many things I finally got down to the scope itself - surely it's not my mega-buck 300MHz Agilent DSO?

Yep, sure enough, short the probe lead out and completely disconnect from the product and the problem persisted! A very nice 115MHz sinusoidal envelope packet of several volts amplitude when I stand up from the chair. Obviously the LC resonant circuit was in the scope probe itself, and the static was coupling into the probe! Different probes produced almost the same result, and so did a piece of RG58 coax.

If you've got a high enough bandwidth DSO, give it a try!

BTW, an anti-stat coat and wrist strap didn't help much either, so much for an ESD safe zone! :->

Dave :)

It'd be even worse with the humidity often down below 30% in the weather we're having in Sydney at the moment! I'm getting tired of throwing sparks when I get out of the car or brush past something earthed.

Bob

mine is only a 100MHz/1Gs/s scope, so I wont see that. I could on my

500MHz analogue scopes, but I have to go digging to find them, and they are too heavy to pick up with one hand :(

but 10pF rings at 115MHz with 190nH. I've seen way more than my fair share of probes telling lies. Have you read linear tech's AN-47?

plus, of course, what can you expect from a windows-based scope.....

Cheers

Terry

Lol, i know PIC asm and I know z80 asm. Beleive it or not I even know the current intel instruction set!!! You think pic is bad, try intel celeron etc!!! After that, PIC is a godsend!

I couldn't give a shit, I write software for whatever is put in front of me. I just think that blatenly bagging one particular architechture because one does not like is like a bad tradesman blaming his tools. Each has pro's and cons, either outweighed by the job at hand.

architechture

Everyone's entitled to their opinion, Andy.

I fondly recall working with 6809s and 68000s. lovely, lovely instruction sets. the intel stuff is pig-ugly by comparison. PIC asm is also pig-ugly, but in a misshapen, dwarven kinda way.

often the biggest pro a particular micro family has is "I know how to use these and their toolset". picking an unfamiliar micro/development set can add a lot of time, hassle and cost to a project. I had the misfortune to use the Hitachi SH2 and toolset for several years, and the compiler *sucked*

I've worked with lots of different micros, but I generally dont write any code, so it doesnt concern me much, although I generally have to specify the code, which requires a reasonable degree of understanding of the micro. as such my personal preference is for 8051 cores for weeny stuff, there are lots of cheap ones around and I've been using them for a long time.

I always felt PIC data was written for programmers rather than engineers

- they seemed to make it hard to find meaningful electrical data, if there even is any! ditto their mnemonics, which is moot when using C.

about the only constraint I have though is a wont use micros without multiply instructions. I had a job a few years back where I had to fix somebody elses design of a micro-controlled smps using an AVR; making a closed-loop controller without a multiply instruction was a real PITA.

Cheers Terry

I had no real problems at all with PIC assembler, and I thought it was actually good in many respects, so I can't see what all the fuss is about really with one instruction set vs another, you just get used to it. Every micro has their own set of quirks, I have never found one that doesn't.

The biggest problem I find is not the instruction set, but the tool chain and evaluation boards etc.

People rave on about the AVR and how fantastic it is, but my first experience with an AVR was a nightmare, I wanted to throw the damn thing out the window. The Atmel STK500 demo board/programmer is a horrible abortion of jumpers and wiring, and it didn't even work out of the box with the chip I wanted to use, I had to modify the programming jumper cables, that is after I figured it all out myself because the documentation was wrong. Then I found you can lock out the serial programming port if you accidently program the oscillator register incorrectly - frigg'n brilliant when your chip is soldered on the board and you are using the internal oscillator. Not to mention GCC for the AVR which people rave on about because it's free and best thing since sliced bread. If you can get that working out of the box you are damn lucky. I'd happily pay the $100 or whatever for a commercial C compiler to save my sanity.

Dave :)

There used to be the old trick of decoupling an emitter resistor in an RF amp with a 1000pF cap with about 1/4 inch leads so that it resonated at about 140 - 150MHz. Gave a crude but useful frequency controlled gain (quite broadband though).

-- Sell your surplus electronic components at

Search or browse for that IC, capacitor, crystal or other component you need.

yep.

we paid a small fortune for the sHitachi tools, and they sucked. there was no way to get the compiler to predictably use the multiply instruction. I could do things like change a text string in some of the user interface code, and it would change which multiplies in the hi-speed control loop code would use MUL, and which would call the 2us multiply routine. seriously bizarre, and the sHitachi apps engineers couldnt help either. in the end I wrote all of the hi-speed code in ASM.

I know plenty of people who think GCC is great, but they all tend to be computer scientists, who are happy to spends weeks or months learning how to configure the damned thing.

Cheers Terry

Exactly. In the real world you often have only days to come up with a solution, so dicking around with tools is just not an option.

By far the worst offender in this respect though are VHDL synthesis and simulation tools for FPGA's. These mammoth pieces of insanely complex software hardly ever just work. 90% of your development time is spent fighting the tool chain and making it all work. Just installing the thing takes you a week.

Dave :)

Perhaps that is why i dont mind PIC asm!! Its probably for this reason also that I think hardware engineers should never be allowed to write a single line of code!!

hmm, not good.

when your chip is soldered on the board

I had no problems, but debian is mostly like that.

didn't you get one bundled with the stk500?

--

Bye.
   Jasen

it depends. programmers who are used to PC-like environments are usually amazingly bad at low-level microcontroller-type code; I've seen some real howlers (like the guy who used 32-bit integers for boolean flags in C, for code running on an 8051), and one expects them to invariably choose the most complex method to solve any given problem.

I suspect its too much abstraction; in the microcontroller world, one generally has very tight control over the hardware, which is the exact opposite of the PC world. and of course 64 bytes of RAM is a luxury.

its also why I prefer asm to C, because C allows you to "forget" (more accurately, deliberately hides) a lot about the system you are coding for. then again, its not like I code spreadsheets etc.

it also encourages sloppy, obtuse programming.

good microcontroller programmers should be treasured, they are hard to find.

Alas, crap programmers are dime-a-dozen, and techs/unis spew out thousands of them every year. Thats one of the reasons I chose H/W - fewer EE grads each year really know h/w, and essentially no CS grads.

(its worth noting that many H/W engineers suck too. that bell curve...)

Cheers Terry