As it stands, [James]’s first version of this tool is probably not what you want to use if you’re dumping a lot of NAND flash modules. His Arduino code reads the NAND using the notoriously slow digital_read() and digital_write() commands and then dumps it over the serial port at 115,200 baud. We’re not sure which is the binding constraint, but neither of these methods are built for speed.
Instead, the code is built for hackability. It’s pretty modular, and if you’ve got a NAND flash that needs other low-level bit twiddling to give up its data, you should be able to get something up and working quickly, start it running, and then go have a coffee for a few days. When you come back, the data will be dumped and you will have only invested a few minutes of human time in the project.
With TSOP breakout boards selling for cheap, all that prevents you from reading out the sweet memory contents of a random device is a few bucks and some patience. If you haven’t ever done so, pull something out of your junk bin and give it a shot! If you’re feeling DIY, or need to read a flash in place, check out this crazy solder-on hack. Or if you can spring for an FTDI FT2233H breakout board, you can read a NAND flash fast using essentially the same techniques as those presented here.
If you want to measure humidity (and temperature, and maybe even barometric pressure) in a device that you’re building, have a look at this comprehensive test of seven different options. We’re going to summarize the results here, but you’ll really want to read up on the testing methodology — it’s great science hacking. Did you know about using saturated salt solutions to produce constant humidity levels for calibration? We didn’t.
The so-called DHT22 module doesn’t fare all that well, with one of six that [Robert] tested being basically horrible, and three of them breaking within two years of use. The one that works well, however, is pretty good. Feeling lucky?
The Bosch BME280 looks great. It costs a bit more as a bare part, and a few times more than mounted on a friendly module, but it seems to be very reliable. And you get a barometer thrown in for the extra work. Indeed, it performed so well that Hackaday contributor [Nava Whiteford] put the part under a scanning electron microscope to figure out what’s going on.
The other sensors were fine, with the HTU21D and SHT71 being standouts for their ultra-fast response. For the full details, go click on that link at the top. Having just installed a sextet of DHT22s in our house last year, we’re left with that sinking feeling that we may have gotten what we paid for, which wasn’t much. At least they’re all still running.
SKiDL is very, very cool. It’s a bit of Python code that outputs a circuit netlist for KiCAD.
Why is this cool? If you design a PCB in KiCAD, you go through three steps: draw the schematic, assign footprints to the symbolic parts, and then place them. The netlist ties all of these phases together: it’s a list of which parts are connected to which, the output of schematic capture and the input for layout. The ability to generate this programmatically should be useful.
For instance, you could write a filter circuit generator that would take the order, cutoff, and type of filter as inputs, and give you a spec’ed netlist as output. Bam! In your next design, when you need a different filter, you just change a couple of variables. Writing your circuits as code would make arranging the little sub-circuits modular and flexible, like functions in code.
At the very least, it’s an interesting alternative to the mouse, click, drag, click paradigm that currently dominates the schematic capture phase. Just as some of you like OpenSCAD for 3D modelling, some of you will like SKiDL for circuit design.
We’ve become so accustomed to the circuit diagram as the means of thinking about circuits that we’re not sure that we can ever give up the visual representation entirely. Maybe designing with SKiDL will be like sketching out block diagrams, where each block is a bit of Python code that generates a circuit module? Who knows? All we know is that it sounds potentially interesting, and that it’ll certainly be mind-expanding to give it a try.
Give it a shot and leave feedback down in the comments!
Transistors versus MOSFETs: both have their obvious niches. FETs are great for relatively high power applications because they have such a low on-resistance, but transistors are often easier to drive from low voltage microcontrollers because all they require is a current. It’s uncanny, though, how often we find ourselves in the middle between these extremes. What we’d really love is a part that has the virtues of both.
The ask in today’s Ask Hackaday is for your favorite part that fills a particular gap: a MOSFET device that’s able to move a handful of amps of low-voltage current without losing too much to heat, that is still drivable from a 3.3 V microcontroller, with bonus points for PWM ability at a frequency above human hearing. Imagine driving a moderately robust small DC robot motor forwards with a microcontroller, all running on a LiPo — a simple application that doesn’t need a full motor driver IC, but requires a high-efficiency, moderate current, and low-voltage-logic compatible transistor. If you’ve been here and done that, what did you use?
Years ago, the obvious answer to this dilemma would be TIP120 or similar bipolar junction transistor (BJT) — and a lot more batteries. The beauty of old-school Darlington transistors in low-voltage circuits is that the microcontroller only needs to produce a small current to push relatively large currents on the business end. With BJTs, as long as you can get over the base-emitter junction voltage (typically under one or two volts) you just pick the right base resistor and you’re set. This is in contrast to FETs of the day which require a given voltage to pass a current through them. Gate voltages for the big FETs are optimized for the 4-5 V range which is lousy if you all you have is a LiPo battery.
While the power Darlington is easy to drive, it has a few drawbacks. First is the voltage drop through the device when it’s conducting. Drop one or two volts on the transistor and you’ve pretty quickly got a few watts of power going to waste and a hot chip. And that’s assuming that you’ve got the voltage drop to spare — a volt or two off of the 3.6 V on a LiPo battery pack is a serious loss.
With apologies to [Adam Fabio], the BJT is off the list here. It’s easy to drive at low voltages, so it would work, but it won’t work well because of stupid quantum mechanics.
MOSFETs should be great for driving small motors, on paper. They have incredibly low on-resistances, easily in the milliohms, and they can turn on and off fast enough that the PWM will be efficient and noiseless. The flaw is that garden-variety power MOSFETS, for driving big loads, tend to have similarly large gate threshold voltages, which is a showstopper for low-voltage circuits. What can we do?
If the motor were being driven by a higher-voltage source, and you were switching the MOSFET on the low side, then you can use the motor’s power supply to drive the MOSFET, switching it on and off with whatever is handy — a small-signal BJT is just about perfect here. That’s the classic solution, illustrated here. As long as the motor voltage is high enough to fully open the MOSFET, you can just use that for the switching voltage.
In the actual application that spurred this column, I wanted to use a LiPo cell for the motor and the logic, but I ended up doing something ridiculous. I started off with a go-to MOSFET from my 5 V logic days, the IRF530, but it barely turns on at 3.3 V. So I cobbled on a 9 V battery to provide the switching voltage — purely to drive the MOSFET into full conduction. This 9 V “high” voltage is switched by a 2N2222 small-signal BJT and seems to do the job just fine. It works, but it’s a horrible hack; I wanted to drive everything off the LiPo, and failed.
Big power MOSFETs, in addition to having a higher gate voltage, also have some capacitance that needs to be overcome to turn them on and off. Between the fully-on and fully-off states, they get hot, so it’s important to push enough current into the gate fast enough that they transition quickly. Thus, big power MOSFET circuits use a gate driver circuit to drive them. A low-voltage gate driver, paired with my IRF530, would certainly be an option here. But all this just for a medium-sized DC motor? Seems like overkill.
Once we embrace complexity, there are small H-bridge and push-pull driver ICs that might fit the bill, and they’ve naturally got MOSFETs inside. Now that I think about it, I’ve built small-motor H-bridges from N/P complementary pair MOSFET chips in the past, and they work for low voltages. Somewhere in my pile I have some IRF7307s that will just barely do the job. I’d be ignoring one of the two paired FETs, but who cares?
Taking the next step in IC complexity, the various stepper-motor driver ICs can usually push and pull an amp or two, and operate on low voltages. You could conceivably drive a DC motor off of one phase of a stepper controller, but that just seems wasteful. But something like (half of) a TB6612 would work.
On the other hand, the fact that these various gate-driver, H-bridge, and stepper controller ICs can handle the currents I want with low logic voltage thresholds suggests that there should be at least a few monolithic, and cheaper, MOSFETs that can switch a few amps around on low voltages. Where are they hiding?
So what would you do when you need to push up to two amps DC in one direction at LiPo battery voltages, with low loss, driven (potentially by PWM) from a 3.3 V microcontroller? Feel free to take this as a guideline, and deviate wherever you’d like from the spec if it brings up an interesting solution.
Whatever you do, don’t give me current figures out of a datasheet headline that are based on microsecond pulses, only to find out that it’s outside of the part’s DC safe operating area. I’ve been down that road before! It never ceases to amaze me how they design parts that are rated for 100 A at 10 microseconds that can only handle 300 mA steady state.
This has to be a common hacker use case. Does anyone have the MOSFET I’m looking for? Or do you all just use motor driver ICs or tack random 9 V batteries into your projects? (Ugh!)
[CNLohr] needs no introduction around these parts. He’s pulled off a few really epic hacks. Recently, he’s set his sights on writing a simple, easy to extend library to work with the HTC Vive VR controller equipment, and in particular the Watchman controller.
There’s been a lot of previous work on the device, so [Charles] wasn’t starting from scratch, and he live-streamed his work, allowing others to play along. In the end, [Alan Yates] and [Ben Jackson] stopped by and gave some oblique hints and “warmer-cooler” guidance. A much-condensed version is up on YouTube (and embedded below). In the links, you’ll find code and the live streams in their original glory, if you want to see what went down blow by blow. Code and more docs are in this Gist.
In the end, it all ended up being a lot of hard work because the Watchman controller needs to send its orientation and accelerometer data wirelessly, and this means compressing a lot of data down into a tiny trickle. All possible tricks were used, including variable-length fields where one bit indicates whether the next byte still belongs to this sample or the next, and packing the data into a frame from both ends. We see why figuring out the protocol drove [Charles] nuts! His dissection begins ten minutes into the summary video.
Besides the hints, the community involvement, and sheer persistence, [Charles] was also helped by being able to generate his own data. Instead of relying on the placement of the device in space, an AVR blinked IR LEDs into the controller to generate known timing deltas. Remember this general technique if you’re reverse engineering anything.
We think the Vive is very cool, and we’ve covered hacks into it before. From [Trammell Hudson]’s early hacks to this recent jaw-dropping drone orientation demo, hackers have been figuring out how to use the Lighthouses on their own. Now [CNLohr] (and the community) have decoded one of the last remaining parts of the OEM hardware. Woot!
“The great thing about standards is that there are so many to choose from.” Truer words were never spoken, and this goes double for the hobbyist world of hardware hacking. It seems that every module, every company, and every individual hacker has a favorite way of putting the same pins in a row.
We have an entire drawer full of adapters that just go from one pinout to another, or one programmer to many different target boards. We’ll be the first to admit that it’s often our own darn fault — we decided to swap the reset and ground lines because it was convenient for one design, and now we have two adapters. But imagine a world where there was only a handful of distinct pinouts — that drawer would be only half full and many projects would simply snap together. “You may say I’m a dreamer…”
This article is about connectors and standards. We’ll try not to whine and complain, although we will editorialize. We’re going to work through some of the design tradeoffs and requirements, and maybe you’ll even find that there’s already a standard pinout that’s “close enough” for your next project. And if you’ve got a frequently used pinout or use case that we’ve missed, we encourage you to share the connector pinouts in the comments, along with its pros and cons. Let’s see if we can’t make sense of this mess.
FTDI TTL Serial
The de-facto standard for a hacker’s TTL serial pinout is definitely the layout that FTDI uses for their USB/TTL serial cables. Said cable is just so handy to have on hand that you’d be silly to use any other pinout for the job. And the good news is that the rest of the world has basically joined in. From the Chinese “Pro Mini” cloneduinos to the Hackaday Edition Huzzah ESP8266 board, and from Adafruit’s FTDI Friend to Modern Device’s USB-BUB, almost everyone uses this pinout. A victory for the common man!
There is one slight point of contention, however, and that’s whether pin 6 is DTR or RTS#. We never use either, so we couldn’t care less, but if you’re counting on your programmer sending the DTR signal to enter programming mode on the device (we’re looking at you Arduino!) then you’ll want DTR on pin 6, and the original FTDI cable, ironically, has the “wrong” pinout. Perhaps that’s why Sparkfun avoided the whole debacle and went their own way, breaking out every signal off the FTDI chip into their own unique configuration.
If you’re only going to break out TTL serial lines, you’d be a fool to use any other pinout.
Modules and Other Communications
Unlike the case with simple serial, connecting various kinds of modules to mainboards is a difficult problem. Creating a single pinout or connector specification for many potential protocols or arbitrary signals is a Herculean task. Surprisingly, it’s been done a few times over. Here are some notables.
Digilent makes a wide range of FPGA demo boards, and they needed an in-house standard pinout that they could use to plug into various add-on peripheral modules that they sell. Thus Pmod was born. It has since become a full-fledged, and trademarked, open standard that you can use in your designs. Here’s the PDF version of the specification for you to print out, so you know they mean business.
There are a few aspects of Pmod that we think are particularly clever. First, the number of pins involved is “just right” at six, and it’s easily expandable. They use standard 0.1″ pitch pins and headers. Two lines carry power and ground, leaving four free pins for SPI, UART, or whatever else. The specification is that all power and signal voltages are 3.3 V because they’re designed for FPGAs after all. You can mix and match if you know what you’re doing, but they won’t let you call it Pmod(tm).
If you need more than four signals, there’s a twelve-pin version which is just two six-pin Pmods stacked into a double-row header. The extra power and ground are redundant, but it makes a twelve-pin output very flexible, because nothing stops it from being used as two sixes. The standard also says that the twelve-pin headers are to be spaced at 0.9″ center-to-center, so you can even connect two of them together when you need sixteen board-to-board signal connections. We like the modularity and expandability.
Pmod connectors are multi-protocol, but for each protocol there is a single pinout. So there’s an SPI Pmod and an I2C Pmod, and the pins are always in the same place. There isn’t a Pmod standard for every conceivable application, of course, so there’s a GPIO pinout that gives you free rein over what goes where. We think that it would be nice if some additional notable protocols (I2S? one-wire? servos? analog stereo audio?) were included in the specs, but the community can also handle these lower-level details.
In our eyes, Pmod is nearly perfect. It uses cheap hardware, is easily expandable, and the smallest incarnations are small enough to fit on all four sides of a one-inch-square board. If you’re willing to pay the brand-name premium, Digilent makes an incredible range of modules. We want to see more hackers outside of the FPGA scene get on it.
What Digilent is to development boards in the US, MikroElektronika is in Europe. While Pmod aims to be capable of doing anything, Mikro-E’s mikroBUS connector wants to do everything, which is to say it has I2C, SPI, UART, two voltages, and even a few extra signals all on the same pinout. Physically, it’s two single rows of eight pins, spaced 0.9″ apart side-to-side, which means it fits into a breadboard nicely. Here’s the spec in PDF.
The tradeoff here, relative to Pmod, is that a lot of pins go unused on any given design. With (only) one “analog” channel, you wouldn’t choose mikroBUS to send stereo audio, whereas nothing stops you from calling the Pmod’s GPIO lines analog and sending four channels of sound. But that mikroBUS gains is fool-proofness. (Well, they could have also made it asymmetric…) There’s no chance of a newbie plugging an SPI module in where an I2C module is expected and scratching their heads. With mikroBus, it should just work.
Microchip has added a mikroBus port to their Curiosity boards, and MikroElektronika makes a ton of modules. If your audience consists of beginners, and one footprint for all protocols, it’s worth considering.
Meanwhile in China, Seeed Studios makes open-source modules, and makes them cheap. Their Grove connector uses only four pins, with power and ground among them. The have standard pinouts for UART, I2C, and for servo motors. Sensors and other analog peripherals are allocated one “primary” pin and one “secondary” and it’s assumed that you know what you’re doing. The idea behind their system is that you add a shield to your microcontroller board, and they break out the relevant pins into these four-pin Grove headers.
This is great for small things and I2C devices, which is Seeed’s catalog, but there just aren’t enough signal pins to run SPI or an analog RGB LED, for instance. But because of the small number of pins, they use very inexpensive polarized cables and shrouds that you can’t plug in the wrong way, and that take up relatively little board space. That’s Grove’s design trade-off.
Servo Motor control
Hobby servo motors need three wires: voltage, ground, and a signal to tell them where to point. There are three distinct ways to arrange these wires, but Futaba, HiTec, Tower, GWS, and JR servos all chose to put them in SVG (or GVS) order, and there’s no reason to buck the trend. (Airtronics, what were you thinking?!)
SVG is also a handy pinout to use for all sorts of one-signal sensors or actuators where space is a premium, and we’ve seen this in a few designs (here and here, for instance). But we’re torn. Relative to the Grove, for instance, you’re just saving one pin. Even the Pmod would work with only three pins’ overhead. Is that worth complicating your life with another pinout? If you need a lot of powered one-signal devices, or servos, it probably is, and you can hardly beat SVG or GVS, whichever way you look at it.
Viewed in the light of any of the other module interconnection systems, the Arduino is the worst of all worlds. It’s monolithic like mikroBUS, but it’s gigantic — you have to build a 55×73 mm board and accommodate 30 pins and pass-throughs if you’d like it to be stackable. The pins have a funny spacing (that gap!), that doesn’t fit any normal protoboard. Nobody goes through the trouble of building a shield just for an I2C connection. No wonder most Arduino projects look like a breadboard hedgehog. About the only good thing we can say about it is that it’s hard to plug one in backwards.
There’s also the tiny little factor that there’s a million Arduino shields out there, a huge community built around them, and widespread support for them. Which turns out to trump all of the reasonable design concerns. (Shakes head.)
Of course, there are other very specific pinouts that one might encounter, like the old ESP-01 module, or the XBee, or the nRF24. Adapting modules to fit boards is always going to be a pain, because the manufacturers will pick whatever suits them on that day. Programmer pinouts for specific microcontrollers are a similar story, as is JTAG, which is a beautiful standard with a dogs’ breakfast of pinout possibilities. (We could do a whole column!)
Faced with this inevitability, and the need for many one-off adapters, what can you do? What we do is buy a lot of those cheap “Dupont” female-to-female cables, get the connections working and tested, and then tape them permanently together and label them. It’s not as pretty as a dedicated PCB adapter, but it’s quick and easy and gets you moving on to what you wanted to do in the first place.
Wrapup and Recommendations
The goal of connectors, and their standards, is putting parts together. If you’re designing a sensor module with more than a couple components, and you want it to be maximally easy for yourself and others to hook up to whatever mainboard they’ve got, this is no easy task. The end result is a proliferation of translators, adapter boards, hats, shields, capes, or whatever else. We have a drawer and a half full, and we bet you do too.
We’d be happy to see the world settle on Pmod for most needs, honestly, and we’d even throw away our beloved FTDI serial pinout in the name of standardization (or make an adapter). We can also see the need for exceptions like SVG / servo connectors when small sensors or multiples are in play. There will always be the need for dedicated on-board connectors as well, of course. Nobody said hardware was easy.
What’s your solution to the ultimate connector conundrum? Are there important connector systems that we’ve left out? What are their design tradeoffs? How stoked would you be if things could just plug together? Let us know!