Yeah. I remember in the late 90's early 2000's patiently trying to explain in so many online forums why a simple feedback control with a couple of opamps or even a single transistor was a faster, cheaper & better approach than throwing a microcontroller and digital circuitry at many a n00b's problem.

Today? 90% of those problems would indeed be solved much more easily with a $0.50 microcontroller. Raw speed and price drops pretty much eliminated the benefits of analog circuitry in most applications.

Yeah, today it's the complete opposite. I see so many people on the internet raging about how using an Arduino is stupid when you can do the same thing with standard electronic parts. It's faster and easier to program something than it is to design a circuit, especially when you take debugging into account. Not to mention the fact that microcontrollers are general purpose, so you can have them sitting around ready to go.

It's pretty much impossible to maintain a stock of any other electronic bit you need, other than maybe resistors. I'm not sure why you'd want to either. I have a ton of ICs left over from random projects. I can never find them when I need them, and even if I can find them again, I have to spend a bunch of time re-reading the datasheet.

I've realized that you can accomplish almost anything you'd like with a microcontroller and some mosfets. It might be more elegant to use a ripple counter if you have to drive a whole bunch of elements, but I'd rather just chain a bunch of microcontrollers together.

IMO, you should learn Verilog and use CPLDs for glue-logic scenarios (like ripple counter or whatnot).

Some 74-series chips are still unique and useful. 74LV4060 for example is a good stable clock solution. But your typical "AND-gate" and "XOR-gate" chips seem completely obsolete by CPLD + Verilog / VHDL.

The ispMach 4000ZE costs $1.20 and has a current-draw of ~hundres of uA at 1MHz. Why use a 7400 (NAND-gate) ever again?

http://www.digikey.com/product-detail/en/lattice-semiconduct...

The main problem I have with CPLD's is that they seem to fall into a space much like FPGA's, where there's very limited open source tooling for them. And I'm kindof an open source ideologue, so I try to avoid anything where there isn't a completely open source toolchain.

Then again, maybe I just haven't looked hard enough.

Can you explain your perspective on open source ideology as it applies to hardware design? I see people complain every so often about lack of open source tools for FPGAs and CPLDs and it doesn't make sense to me.

Most people seem happy to use a chip that performs the exact functions they wanted even though it's completely closed/proprietary. But they seem to balk at using a programmable chip where they can choose the functionality but the software that let's them do so is closed/proprietary.

It's a combination of things. For starters, I generally feel that openness in terms of computing, and technology in the more general sense, is a Good Thing for the world at large. The more things are open source and unencumbered by various legal mechanisms (patents, whatever), the more people who can use those tools, build on them, innovate, and participate in the further advancement of technology. Think "virtuous circle".

Beyond that, when tools are Open Source it makes life easier and takes out friction for us as individuals. I hate the idea of ordering up a fancy new chip, getting excited about it, and then finding out that I have to pay a zillion dollars to download and use the programming tools. Or I get the tools and find out that there's some weird "field of use" limitation in the Terms and Conditions. Or worse, I lose my last copy of the software, the manufacturer goes out of business, and then later I find a few of those chips in my parts box and realize I will never be able to use them because I no longer have access to the software. Or maybe I still have the software, but it has a bug that nobody can fix because nobody has the source code.

That we still have to use some chips that are proprietary to some extent is something I accept out of pragmatism, but by the same token, I support efforts like OpenCores, RISC-V, etc. that may eventually lead us to reasonably usable CPU's that don't need binary blobs and aren't full of undocumented features, etc. At least one can hope.

For me, it's countering subversion, being able to fix the tool, being able to extend the tool, and increasing labor supply of contributors with free or cheap tooling vs $100k a seat for some.

Agree'd.

The main thing is that the low-level details of macrocells varies from company to company. And those companies are protective of their designs, so they don't want people figuring out how their devices really work.

So it is a tough spot. Still, Verilog allows you to move your "code" from company-to-company (Xilinx, Altera, and Lattice). So its sufficient.

Thanks for the recommendation. I'll have to try that out. I do have a absolute mess of external clocks sitting around, and a few other ICs that I really like. I like building things though, and I build them in my free time, and I build them for myself. Tossing a micro in allows me to use my time better and use my skills better.

Hobbyist micro-controllers also come in through-hole packages. I can solder pretty much anything that doesn't require a hot-plate, but it's a lot easier to prototype with through hole.

For instance, one of the things I'm building right now is a 4x8 array of 6"x6" flip-flop sign elements that I got as surplus from the highway department. Each element has a dual 68 ohm coil and runs at 24 volts. I'm basically designing a one-off. Rather than getting clever, I just drive the coils with a ULN2803 (one of the parts I keep around), and drive the ULN2803's with arduinos, and tie the whole thing together with a raspberry pi.

It's kind of a mess, but the arduinos mean I don't have to worry about timing, and I can ssh in to the raspberry pi. It's probably an order of magnitude more expensive and less elegant than something an EE would design, but it works, and it probably won't catch on fire.

One of my professors told me:

> Perfection is always the final sacrifice before the alter of completion.

Nothing is ever perfect. You must always sacrifice perfection before a project is complete.

With the cheapness of Arduinos and Raspberry Pis, throwing a bunch of them together is always a potential solution.

---------

EDIT: I'm not sure a CPLD could have stopped the use of the ULN2803, although maybe it could have replaced the Arduinos. If the Arduinos were good enough however, then no harm-no-foul really.

Its just that a CPLD can implement things like a 27-bit shift register over SPI or I2C really easy (assuming you have some Verilog or VHDL coding skills). So maybe you'd be able to do Raspberry Pi -> CPLD -> ULN2803.

I remember back in Intro to CompE, we did the first project using handful of 7400s to build seven segment display driver using a bunch of switches to control the input 3-bit value. It required more chips and breadboard real estate than we had so we were only required to count up to 6. Immediately after that, we got our FPGAs and did the same project but with a button that would increment the 8-bit counter. The coding took about 10mins in verilog compared to the hours of logic diagramming and wiring.

Of course those 2 GHz octocore computers with 4 GiB of RAM have no chance in hell to react to impulses within nanoseconds or operate anything at 100 MHz. All sacrificed at the altar of throughput.

Well, that's true. Cellphone chips don't do that.

But lets say... a 1GHz DSP (specialized chip designed to perform "digital signal processing") implementing an optimized FIR or IIR filter most certainly react within nanoseconds and pick out signals in the 100MHz range.

That's still a general-purpose processor too. Switch to FPGAs or even ASICs (the fastest and most expensive of digital-logic designs), and you can probably get even faster.

----------

Analog can only get better accuracy by literally creating temperature-controlled cases for various components. (Think I'm kidding? https://www.vectron.com/products/literature_library/OCXO.pdf) Analog hit the noise-floor decades ago.

a dedicated 2-3GHz processor can definitely receive a signal, turn it into an interrupt, and respond to it within nanoseconds. it's the OS that prevents that from happening.

> it's the OS that prevents that from happening.

Not quite. Its more about the difficulty of writing the code. A lot of OSes aren't realtime which can be part of the problem, but a careful administrator can tune Windows or Linux to be "more realtime".

Consider this: most hardware is set up to DMA to RAM through the northbridge. It never touches the CPU, the hardware just writes the data directly to RAM (indeed: this is a good thing. When the CPU is executing from L1 cache, it isn't touching the RAM anyway).

Then, the CPU gets an interrupt, and then it can read from RAM.

It takes roughly 60 ns alone to access DRAM on a modern processor (https://software.intel.com/sites/products/collateral/hpc/vtu...), plus whatever time it took for the DMA to happen.

NOW the CPU finally has the data in its cache and can start calculating.

------------

To fix this issue, you DMA directly onto the CPU's cache itself.

http://www.intel.com/content/dam/www/public/us/en/documents/...

That takes special device drivers, a lot of optimizing, a lot of thinking about latency.

Obviously I'm talking about code that is only using L1, and touching only registers.

I see your point, but raise you this thought:

Exactly what "received signal" exists inside of a CPU's L1 cache and register?

In practice, any I/O of a modern CPU / Microprocessor is going to run through the Northbridge and most likely be dumped into DDR3 / DDR4 RAM. That's already 60ns of delay minimum that you've introduced into the system and you haven't even done any math yet!

Building a digital system that responds within nano-seconds is difficult, while a purely passive LRC filter... taught in maybe ~2nd year or ~3rd year Electrical Engineering classes, can indeed respond within nanoseconds!

--------------

I guess what I'm saying is... building Digital systems that respond within nanoseconds is certainly possible, but its specialized knowledge and requires specialized CPUs (aka: a Digital Signal Processor). Most programmers don't need to do that after all (write a damn login page again)

I'm not exactly an expert on the ways of the DSP. I just know people who moved in that direction. Its an intriguing field and takes lots of study to be effective.

I don't think we were talking about DSP... at least when I originally replied I was making the official point that a high frequency CPU doing single-clock-cycle reads of GPIOs, can respond in nanoseconds. I think you are talking about something different...

The GPIOs are pins that are directly attached to the CPU. They are accessible by the CPU without requiring access to cache.

Not denying that it's hard to do on a general purpose Intel CPU with its absurdly high clock rate. But anybody with a fast oscilloscope can tell you that fast microcontrollers have that kind of response time, too (10s of ns), because ops take a clock cycle, and 100MHz = 1ns.

They tried this on an AM335x, a modern ARM Cortex A8 used on the BeagleBone Black for example. Clocked at 1 GHz and doing nothing else other than toggle a GPIO pin - it took 200 ns. This is for a fully integrated SoC. Merely due to various levels of interconnect within the CPU.

Here is the slide for reference:

http://imgur.com/a/sWyH5

That's with an OS (right? You left out the necessary context), and it's not a fast processor.

> 100MHz = 1ns.

You've misplaced a decimal point.

1GHz == 1ns.

100MHz is 10ns.

>There are lots of textbooks that showed you how to get 6.5 digits (21-bits) or 7.5 digits (23-bits) of accuracy using normal parts machined to 1% precision.

Do you happen to know the name of any of these books? I would love to play around with something like that.

In Chapter 5 in "The Art of Electronics 3rd Edition", Horowitz offers an analysis on the 6.5 and 7.5 digits of accuracy attained from the Agilent DMM.

http://www.keysight.com/en/pd-1000001296%3Aepsg%3Apro-pn-344...

Chapter 5 is all about precision, Chapter 8 is all about noise.

In essence, you run a worst-case error analysis over your circuit. In many cases, 1% errors can be attenuated into smaller errors with good design. If you aren't careful however, then errors grow bigger instead.

---------

On a tangent, but somewhat related note for those software people...

The methodology is kinda similar to error analysis with Floating Point arithmetic btw. You think about where error happens, and whenever possible, try to "squash" the error instead of making it grow bigger.

All double-precision Floating Point math has an error of +/- 1 bit 53-bits over. The question is what do you do with that error, and how can you prevent it from moving up. If you do things like sort your numbers from smallest to largest (in magnitude) before adding them up, and prevent subtraction (or addition of a negative number) at all costs, you can actually make your errors smaller.

If you're not careful about the order of operations... errors grow exponentially (and even faster than that with subtraction!). On the other hand... if you are careful about things... errors shrink exponentially!