Arduino Versus Logic: The Coil Gun War Continues

Looks like another shot has been fired in the simmering Coil Gun Control War. This time, [Great Scott] is taken to the discrete woodshed with a simplified and improved control circuit using a single CMOS chip and a few transistors. Where will it end? Won’t somebody think of the children?

The latest salvo is in response to [GreatScott]’s attempt to control a DIY coil gun with discrete logic, which in turn was a response to comments that he took the easy way out and used an Arduino in the original build. [Great Scott]’s second build was intended to justify the original design choice, and seemed to do a good job of explaining how much easier and better the build was with a microcontroller. Case closed, right?

Nope. Embedded designer [fede.tft] wasn’t sure the design was even close to optimized, so he got to work — on his vacation, no less!’ He trimmed the component count down to a single CMOS chip (a quad Schmitt trigger NAND), a couple of switching transistors, the MOSFETs that drive the coils, and a few passives. The NANDs are set up as flip-flops that are triggered and reset by the projectile sensors, which are implemented as hardwired AND gates. The total component count is actually less than the support components on the original Arduino build, and [fede.tft] goes so far as to offer ideas for an alternative that does away with the switching transistors.

Even though [fede.tft] admits that [GreatScott] has him beat since he actually built both his circuits, hats off to him for showing us what can likely be accomplished with just a few components. We’d like to see someone implement this design, and see just how simple it can get.

23 thoughts on “Arduino Versus Logic: The Coil Gun War Continues

  1. While I have no beef whatsoever with making things using microcontrollers unnecessarily (Make stuff in whatever way works best for you the maker after all) but mad props for optimizing the design like this! Optimization is as awesome as making, IMHO =)

  2. A silly “battle” to try to fan into flame. A microcontroller often wins for the ease of making changes via firmware. Using discrete components (the hardware solution) is usally a win when either sheer speed or cutting cost is the priority. But the bottom line is to get the job done, especially for us folks here. My hat is off to good work of either style, such as this right here.

    1. If the task is already well defined like in this case, and the only expansion would be adding more stages, then the microcontroller has no advantage. By the time you finish building the circuit, the discrete analog solution is ready to go, while the MCU still needs to be programmed and debugged. A potentiometer is faster to turn than re-flashing new values for the timers.

        1. Yeah, but then you have to set up your ADC and program in the whole routine and by the end of it you find yourself reading data sheets and googling for code examples for the whole afternoon to get it up and running.

          1. Perhaps the first time you do it. When you have done it once it would be a simple case of copy and paste for any future cases, providing your not too sloppy with your code.

          2. That’s assuming you’re using the exact same MCU each time, so all the setup registers and values are identical.

            And the ADC readout itself can be done in many different ways. Do you do it with interrupts, do you busy-wait until the reading is complete? Do you poll for a flag while the rest of the code is running? It depends on what you’re trying to achieve, so there’s no drop-in piece of code that you could paste into your new project and avoid the whole fiddly bit.

          3. “Doesn’t seem to be putting many people off.”

            People who don’t know analog electronics don’t know any better, and people who do know analog electronics don’t think about how complex it would be with a MCU because they chose the appropriate method for the problem at hand.

        1. Ditch the pots, connect the arduino to a PC and edit the parameters that way, and store them in flash without reprogramming :D

          Connecting to a PC also allows you to download logs (usage, misfires etc…)

          You can also use the Arduino for automatic testing and take appropriate action when things go wrong.

          If this is going to be battery powered, you might want to monitor the battery, maybe indicate how many shots you have left.

          The Micro allows you to add new features without necessarily adding more circuitry

          1. You can always add the micro to the analog solution to provide the datalogging features and battery meters etc. The main function of the circuit should imho be independent, so that if your arduino sketch bugs out or the MCU craps itself due to EMI the main action still works and doesn’t do anything spurious.

            As we’ve learned from car manufacturers: it’s a stupid idea to integrate your ECU and your entertainment center in the same SoC.

          2. Dax, there doesn’t seem to be a reply button to your post :(

            I agree, anything which could be potentially unsafe needs to be at least semi-autonomous. The number of times I’ve seen a desk with a pool of ink on it because someone breakpointed or paused the code in a place where it has begun printing, leaving the DMA controller still running on the emulator….

  3. It appears that the digital logic could be implemented in the CLC peripheral of newer PICmcu’s (the xpress board that was being given out has 4 of them.) Then you could have the best of both worlds, logic & firmware in a single device.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.