“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.

Pmod

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.

mikroBUS

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.

Seeed’s Grove

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.

Arduino

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.)

Miscellany

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.

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!

Thumbnail image courtesy of [Raspberry Pi Controller].

In case you missed it, the big news is that a minimal Arduino core is up and working on the ESP32. There’s still lots left to do, but the core functionality — GPIO, UART, SPI, I2C, and WiFi — are all up and ready to be tested out. Installing the library is as easy as checking out the code from GitHub into your Arduino install, so that’s exactly what I did.

I then spent a couple days playing around with it. It’s a work in progress, but it’s getting to the point of being useful, and the codebase itself contains some hidden gems. Come on along and take a sneak peek.

The Core

An Arduino isn’t worth very much unless it can talk to the outside world, and making the familiar Arduino commands work with the ESP32’s peripheral hardware is the job of the core firmware. As of this writing, GPIO, WiFi, SPI and I2C were ready to test out. GPIO means basically digitalWrite() and digitalRead() and there’s not much to say — they work. WiFi is very similar to the ESP8266 version, and aside from getting the ESP32 onto our home WiFi network, I didn’t push it hard yet. When other libraries come online that use WiFi, I’ll give it a second look.

SPI

The SPI routines in the ESP32 Arduino port both work just fine. I tested it out by connecting a 25LC256 SPI EEPROM to the chip. The ESP’s extremely flexible hardware peripheral routing matrix allows it to assign the SPI functions to any pins, but the Arduino implementation is preset to a default pinout, so you just need to look it up, and hook up MOSI to MOSI and so on. As of now, it only uses one of the ESP32’s two free SPI units.

With SPI, some of the weirdness of using Arduino on a powerful chip like the ESP32 start to poke through. To set the speed of the SPI peripheral, you can use the familiar SPI_CLOCK_DIV_XX macros, only they’re scaled up to match the ESP32’s faster CPU clock speed. The end result is that SPI_CLOCK_DIV_16 gives you a 1 MHz SPI bus on either the 16 MHz Uno or the 240 MHz ESP32, which is probably what you want for compatibility with old code. But 240 divided by 16 is not 1. In retrospect, the macros would be better defined in terms of the desired frequency rather than the division factor, but you can’t go back in time.

There were also two extra definitions that I had to add to the program to make it run, but they’ve both been streamlined into the mainline in the last eighteen hours. That’s the deal with quickly evolving, openly developed software. One day you write that the macro MSBFIRST isn’t defined, and before you can go to press, it’s defined right there in Arduino.h. Great stuff!

I2C: The Wire

The I2C (“Wire”) library has also gotten the ESP32 treatment, and worked just as it should with an LM75 temperature sensor. This is my standard I2C test device, because it lets you read a few registers by default, but you can also send the sensor a few configuration options and read them back out. It’s not a particularly demanding device, but when it works you know the basics are working. And it did.

The ESP’s dedicated I2C pins are on GPIO 21 and 22 for data and clock respectively. Some I2C implementations will use the microcontroller’s pullup resistors to pull the I2C bus lines high, so I tested that out by pulling the 10 KOhm resistors out. The ESP stopped getting data back instantly, so that answers that. Don’t forget your pullup resistors on the I2C lines and all is well. Otherwise, it’s just connecting up two wires, double-checking the I2C device address, and reading in the data. That was easy.

External Libraries

More than half of the reason to use Arduino is the wide range of external, add-on libraries that make interfacing with all sorts of hardware easy and painless. Many of these libraries are built strictly on top of the Arduino core, and should “just work”. Of course, when you’re actually coding this close to the hardware, nothing is going to be as portable as it is a few layers of abstraction higher up on your desktop computer. Let’s go test this hypothesis out.

El Cheapo IL9341 TFT Display

Since the SPI library works out of the box, the other various libraries that depend on it should as well, right? Well, kinda. I wasted an afternoon, and still failed. Why? I have a cheapo ILI9341 screen that only works with an old TFTLCD library, rather than with the nice Adafruit_ILI9341 libs. The former is so full of AVR-specific voodoo that it completely fails to compile, and is probably easier to re-write from scratch for the ESP32 than make work in its present form. The Adafruit library compiles fine, because it only depends on the SPI library, but it doesn’t work with my lousy screen.

Going repeatedly back and forth between these two libraries, my LCD experiment ended in tears and frustration: I couldn’t make either of them work. I scoped out the SPI data on a logic analyser, and it looked good, but it wasn’t drawing on the screen. At this point, a full line-by-line protocol analysis would have been needed, and that’s a few days worth of work. If I just wanted a running ILI9341 driver, I would go grab [Sprite_tm]’s NES emulator demo and use the one there, but it’s not Arduinified yet, so it’s out of bounds for the scope of this article.

DHT22 Humidity and Temperature Sensor

Seeking a quick-and-dirty success, and beaten down by hours of hacking away for naught, I pulled a DHT22 sensor out of the eBay bin, and cloned Adafruit’s DHT library. Of course it didn’t compile straight out of the box, but there were only a couple of things that were wrong, and both turned out to be easily fixable.

ESP32’s Arduino didn’t have a microsecondsToClockCycles() function yet so I commented it out, multiplied by 240 MHz, and left a hard-coded constant in my code. This value was just used for a timeout anyway, so I wasn’t too worried. There are also some timing-critical code sections during which the Adafruit code uses an InterruptLock() function to globally enable and disable interrupts, but these functions weren’t yet implemented, so I just commented it all out and crossed my fingers.

After reassigning the data pin to one of the ESP32’s free ones (GPIO 27, FWIW), it compiled, uploaded, and ran just fine. I now know exactly how hot and humid it is up here in my office, but moreover have had a quick success with an Arduino external library, and my faith is restored.

Lessons from the Libraries

I suspect that these two examples are going to be representative of the ESP32-Arduino experience for a little while. Oddball hardware is going to take some time to get supported. Highly optimized libraries with cycle-correct timings or other microcontroller-architecture specific code in them will need to be ported over as well, despite being “Arduino” code. If you’re a code consumer, you’ll just have to wait while the wizards work their behind-the-scenes magic.

But there will also be a broad group of libraries that are written in a more-or-less device-independent way, and these should be easy enough to get working within fifteen minutes or so, as with the DHT sensor library. If you’re willing to compile, read the errors, and comment out or fix whatever shows up, some codebases will work in short order.

What’s Next? Turning Servos

Given that the Arduino-ESP32 port is brand new, indeed it’s still in progress, there is a lot of work for the community to do in getting it up to speed. Suppose that you need to drive a lot of servos, but the “Servo” library isn’t implemented yet. You’re an impatient coder. What to do? Get hacking!

The good news is that the Arduino-ESP32 libraries themselves are full of hints and examples for getting started. Open up the ESP32-specific directory that you cloned from GitHub. The usual *.cpp files provide the standard Arduino core functionality. The esp32-hal-xxx.h and esp32-hal-xxx.c files are chip-specific, and a tremendous help in taking advantage of the chip’s stranger options. For instance, esp32-hal-matrix.* gives you nice and easy access to the pin-routing matrix, which is a daunting task if you’re starting just from the datasheet.

But let’s get back to servos. The ESP32 chip has an intriguing hardware LED PWM peripheral that lets you assign up to sixteen channels to individual LEDS, specify the PWM frequency and bit-depth, and then control them by appropriately setting bits in hardware registers. If you think this would be hard to do by hand, you’d be right. The esp32-hal-ledc.* files provide helper functions to set up the hardware PWM generator, and with these libraries, getting a 16-bit LED fade in straight C or “Arduino” is easy. But our sights are set on servos.

To drive a hobby servo, one needs pulses between 1,000 and 2,000 microseconds each, repeated every twenty milliseconds or so. Setting the repetition rate to 50 Hz takes care of the first part, and each count is 20 ms / 65,635 ticks long, or roughly 0.3 microseconds. Setting the PWM width value to something between 3,300 and 6,500 generates pulses in the right ballpark, and my servo ran jitter-free (and a clean signal was confirmed on the oscilloscope). Here’s all it took:

#include "esp32-hal-ledc.h"
void setup() {
   ledcSetup(1, 50, 16); // channel 1, 50 Hz, 16-bit depth
   ledcAttachPin(22, 1);   // GPIO 22 on channel 1
}

void loop() {
   for (int i=3300 ; i < 6500 ; i=i+100){
    ledcWrite(1, i);       // sweep the servo
    delay(100);
   }
}

That wasn’t so hard, was it? It’s not “Arduino”-style — there’s no objects or classes or methods anywhere in sight — but thanks to a straightforward and well-written hardware abstraction layer, using the very complicated peripherals is made pretty simple. Kudos to [me-no-dev] for his work on the back-end here. The HAL inside the Arduino libraries is currently the best source of code examples on many of the chip’s more esoteric and interesting peripherals.

Conclusion?

The short version of my dive into Arduino-esp32 is that there’s a lot here, even though it’s not done yet. Blinking LEDs and other simple GPIO is a given, and the core communication libraries that are already implemented worked for me: GPIO, WiFi, SPI, and I2C are up and running.

Non-core libraries are hit and miss. I suspect that a lot of them will work with just a little bit of tweaking. Others, especially those that are architecture-dependent, may not be worth the effort to port and will need to be re-written. The ESP32 has a bunch of interesting and innovative hardware peripherals onboard and there’s certainly no Arduino libraries written for them yet, but there’s some great HAL code hidden away in the Arduino-ESP32 codebase that’ll give you a head start. We could get lost in there for hours. Time to get hacking!

The ESP32 is still a new chip, but orders should be coming in soon. Have one? Want to see us put other libraries or languages through their paces? Let us know in the comments.

Nicole Grimwood is working towards a dual degree in engineering from Columbia University and liberal arts from Scripps College.

Read more on MAKE

The post Interview: NIcole Grimwood on Electronics (and Cake) appeared first on Make: DIY Projects, How-Tos, Electronics, Crafts and Ideas for Makers.

If you work with a bunch of sticky-fingered co-workers, your desk is going to need protecting -- especially when you're away at lunch. This 3D-printed sentry gun from Swiss engineering student Kevin Thomas is motion-activated and fires a 6-round clip of rubber bands at anybody foolhardy enough to come within range. It's controlled with an Arduino chip running Thomas' version of the open-source Project Sentry Gun software. And if you don't want to let the sentry gun have all the fun, you can also switch it from autonomous mode and manually aim it using a joystick. With all the eyes you'll put out and SBC violations you'll incur with this menacing mechanization, you and the HR department are going to become such good friends.

Via: The Next Web

Source: Thingverse

We are happy and proud to announce that  David Cuartielles, co-founder of Arduino and CEO of Arduino Verkstad, got this year’s prize from the Swedish Electrical and Computer Engineers’ National Association (Svenska Elektro- och Dataingenjörers Riksförening) SER. The association awards an engineering student and a senior engineer that works with electrical, data and IT technology. The senior engineer has to lead an important role in smart and sustainable technological development:

This year the award goes to David Cuartielles from Malmö University for his open source platform Arduino, which is based on easy to use hardware and software to develop interactive projects.

This award – David said – has been possible thanks to the kind support of the Arduino family, Malmö Högskola and most importantly, the open source community.