Announced at the 2014 Maker Faire in New York, the latest Arduino WiFi shield is finally available. This shield replaces the old Arduino WiFi shield, while providing a few neat features that will come in very handy for the yet-to-be-developed Internet of Things.

While the WiFi Shield 101 was announced a year ago, the feature set was interesting. The new WiFi shield supports 802.11n, and thanks to a few of Atmel’s crypto chip offerings, this shield is the first official Arduino offering to support SSL.

The new Arduino WiFi Shield 101 features an Atmel ATWINC1500 module for 802.11 b/g/n WiFi connectivity. This module, like a dozen or so other WiFi modules, handles the heavy lifting of the WiFi protocol, including TCP and UDP protocols, leaving the rest of the Arduino free to do the actual work. While the addition of 802.11n  will be increasingly appreciated as these networks become more commonplace, the speed offered by ~n isn’t really applicable; you’re not going to be pushing bits out of an Arduino at 300 Mbps.

Also included on the WiFi shield is an ATECC508A CryptoAuthentication chip. This is perhaps the most interesting improvement over the old Arduino WiFi shield, and allows for greater security for the upcoming Internet of Things. WiFi modules already in the space have their own support for SSL, including TI’s CC3200 series of modules, Particle‘s Internet of Things modules, and some support for the ESP8266.

Hardware and software combined, Arduino does many things right. It lowers the entry level into embedded systems development with a nifty hardware abstraction layer. It aims for cross-platform compatibility by supporting Windows, Mac OSX, and Linux operation systems. It throws out the need for an external programmer to get you up-and-blinkin’ those LEDs quickly.

One thing most of us never cease to curse about, though, is the IDE. Many have cried out wildly against the Java-based text-editor for its cryptic compiling-and-linking process, its inability to accommodate bare C or C++ source files, and (shh!) its lack of Vim keybindings. Fortunately, our cries have been heard, and the like many community-based projects, the community fights back with a custom solution.

Calling all Grumpy Engineers: The Arduino-Makefile

Enter the Arduino Makefile.

What began as [Sudar’s] lightweight program to escape the IDE has become a fully-blown, feature rich Makefile that has evolved and adapted to grow with the changes of Arduino. With a community of 47 contributors, the Makefile enables you to escape from the IDE entirely by writing code in the cushy text editor of your choice and compiling with a simple incantation of make into your terminal, be you in Linux, Mac, or Windows.

Without further ado, let’s take a walking tour of the project’s highlights.

Cryptic Shortcuts–Begone!

For many beginners, writing (or even editting) a Makefile can cause some serious confusion with most Makefile authors’ shameless shortcut use. Make no mistake, the cryptic syntax of many Makefiles forms a concise list of instructions for compiling and linking your executable, but this recipe does seem a bit hard to parse for the uninitiated. What’s more, Makefiles also tend to throw bizarre errors (trailing whitespace anyone?) that are difficult to track down–especially when we want to spend most of our time bringing up embedded systems, not understanding the mechanics and syntax of a Makefile. Fortunately [Sudar] and the rest of the development team have made the interface very human readable.

Their solution: A two-part Makefile. For a simple project, your Makefile need be no longer than this snippet (inspired from the Makefile Examples):

BOARD_TAG    = uno
include $(ARDMK_DIR)/Arduino.mk

Project-specific settings (like which board you’re using) are outlined in this brief Makefile that then includes the larger Makefile which contains the actual nuts and bolts for building your code. The assumption here is that you’ve defined two environment variables, both ARDMK_DIR and ARDUINO_DIR that point towards the (1) Arduino Makefile directory and the (2) Arduino Installation directory. In addition, if you have additional libraries, you can include them with a line in your top-level Makefile that defines the filepath.

 USER_LIB_PATH += /home/my_username/my_libraries_directory

You’ll also need to add all libraries you’re using (both user-added and built-in) to the list of libraries like so:

ARDUINO_LIBS += Wire \
                SPI \
                my_custom_lib

The benefit of a “split-Makefile” setup is that the short, top-level Makefile hides the gritty compiler gymnastics involved in compiling and linking against the default and user-added Arduino Libraries. On the flip-side, this “mini” Makefile becomes a brief, informative summary of a few minor details, such as which Arduino Libraries are being used, that are likely more relevant to the author and future developers.

Raw C and C++ is In–if you prefer such things

Tired of that *.ino file extension? Tired of having to constrain yourself into those setup and loop functions? With the Makefile, you can quickly wish these away and write your code in raw C or C++. You can even neglect to #include <Arduino.h> if you want to work in vanilla C or C++ and disregard the Arduino libraries altogether.

That said, if you’re mixing C and C++, keep in mind that you’ll need to insert guards around your C header files like so:

#ifdef __cplusplus
extern "C" {
#endif

/// the rest of my C header file 

#ifdef __cplusplus
}
#endif

Adding Project Libraries

Possibly my favorite aspect of the Arduino Makefile is its flexibility to accomodate a richer file structure and painlessly split your project into multiple files. Let’s say I have a one-off project where it makes sense to include a custom library. Given the flexibility of the Makefile, you can define:

    USER_LIB_PATH+=.
    ARDUINO_LIBS += my_custom_library

in your project Makefile and produce a directory tree like so.

 ├── main.ino
 ├── Makefile
 ├── my_custom_library
 ├── my_custom_library.cpp
 └── my_custom_library.h

If you need more flexibility, you can also split your source code across several directories, keeping the Makefile in the same directory of your code that acts like a “main.” (In this case, main.ino defines setup  and loop.) To do so, your Makefile will, instead, have:

    USER_LIB_PATH+=../libs
    ARDUINO_LIBS += my_custom_library

in your project Makefile, and your directory structure will look like so:

 ├── libs
 │   └── my_custom_library
 │     ├── my_custom_library.cpp
 │     └── my_custom_library.h
 └── src
  ├── main.ino
  └── Makefile

Finally, we don’t need to constrain ourselves to writing just C++ classes to split projects into multiple files.  Since we’re really working with vanilla C++, you can freely split your project into multiple source (*.c, *.cpp, *.ino, *.pde) and header (*.h, *.hpp) files that live in the same directory as the Makefile, and the Makefile will compile them into one executable.

Other Micros are Fair Game Too

Finally, the Arduino-Makefile is also compatible with a host of other microcontrollers and programmers, not just the ATMEGA328P on the Uno. In short, this feature is an exposition of the features of AVRDUDE, the program for downloading and uploading code to various AVR microcontrollers. Last, but not least, it’s also Teensy-compatible.

Define Our Standard

If you’re looking to get comfortable with the Arduino-Makefile workflow, have a quick look at their examples directory for a host of different use-cases. You can also take a peek at my i2c_demultiplexing_demo source from a couple weeks back for yet another example. At the end of the day, Arduino, with its giant library collection, makes project prototyping fast. For bigger projects, though, we don’t tend to see any standard practices for file organization to make projects easier to navigate. That’s where you come in. With the flexibility of the Makefile, you get it all: the text editor you always wanted, the separate header and implementation files, a clean directory… Now it’s your shot to take this tool and refine your workflow into a method worth sharing with the rest of us.

Over on hackaday.io, [Arduino Enigma] posted the code for his clock that runs on a KIM Uno (the KIM-1 clone we mentioned late last year). Although the KIM Uno has a few demos preloaded (including Microchess and a scientific calculator), all of them take some interaction. The clock makes the KIM Uno a more dynamic desk display since it does something useful without any user interaction (once you set the clock, of course).

The project shows the code stored in ROM, but you can’t directly enter the program into ROM (which is really EEPROM on the host Arduino). The trick is to enter the address (that is press AD and then 0, 4, 0, 0) and then mash down the reset button for about a second. Then you can press DA and enter the hex codes provided (pressing + after each byte). Since the code is in nonvolatile storage, you can start it at any time by setting the time in RAM and executing the code at address 400.

The program is short and sweet, making it is easy to enter and a great opportunity to brush up on understanding your 6502. However, the simplicity means it doesn’t range check your initial time settings, so don’t tell it that it is 32:99 or something like that. The code isn’t commented, but it is pretty simple, once you realize one thing: the first instruction, SED, sets the 6502’s decimal mode so no conversion between hex and decimal is needed.

Each part of the time (hours, minutes, and seconds) is stored in RAM at locations 0024, 0025, and 0026. The NEXTD routine uses the X register to scan through each part of the time, adding 1 or 0 as appropriate (stored in RAM location 0029). If the time part matches the corresponding table entry at CARRYT (that is, 60, 60, or 24 also indexed by the X register), then the code does not take the branch to CONTIN and reloads the increment (location 0029) with zero, so the next digits will not advance. If it does match, the increment stays as 1 and the current part returns to a zero value.

You may notice the time is stored back to locations starting at 0024 and 00F9. That’s because 00F9 is where the KIM-1 ROM looks for data to write to the display when calling the ROM-resident subroutine at 1F1F. The X register ranges from 0 to 2, corresponding to the seconds, minutes, and hours. Once all the time is updated, the loop at L1 displays the time and delays for about one second.

A neat piece of coding and a great example of the power of the 6502’s decimal mode. This would look even better with [Scott’s] enhanced version of the KIM-1 UNO.

Visualizing how electronic signals work can be difficult. A physical model can be darn useful in overcoming that difficulty. At a recent workshop entitled “Unboxing Black Boxes” [Julian Hespenheide’s] group created a device to show Baudot Code in operation. This amalgam of wood and Arduino they dubbed émile in honor of Émile Baudot (1845-1903).

Baudot developed his code to transmit telegraph signals from one machine to another, in contrast to Morse code which was principally for human communication. Both codes were used throughout the 20th century. For example, those big clattering, mechanical teletype machines use a minor variation of Baudot code.

Baudot is a fixed length code of 5 bits, as opposed to Morse’s variable length code. Morse has a separate code for each characters while Baudot uses “shift’ codes to change between alphabet and figure characters. For instance, a binary 11 would represent either an ‘A’ or a ‘-‘ depending on the shift state. If the shift code was missed the receiver would get gibberish.

In émile the Baudot code is sent by marbles. That’s right, marbles. There are five marbles, one for each bit in the Baudot code. Each marble rolls in a track toward the Arduino. How does the machine know which marbles to send? “Punch cards”! These are a marvelous aspect of the design.

Each card represents a code. Each position in the card has a gap to allow a marble to pass ( a set bit), or no gap to block the marble (an unset bit). The operator loads 5 marbles and a punch card and launches the marbles via a spring mechanism.

[Julian’s] really created a great visualization of Baudot code with this project! Take a look at émile in action after the break.

Last spring [Mike] built a foam rocket launchpad which was a hit with the kids in his neighborhood. But the launch system was merely a couple of buttons so the early enthusiasm quickly wore off. He went back to the drawing board to make improvements and really hit the jackpot!

The original launch system had one button for building up air pressure with a second big red button of doom for launching the rocket. The problem was a complete lack of user feedback; all the kids could do is guess how long they needed to hold the button to achieve the highest launch. This revision adds flashing LEDs to hold the attention of the wee ones but to also function as a gauge for the new pressure control system. The visually fascinating control board also includes a removable key to prevent accidental launches.

The particulars of this are as you’d expect: it’s a bunch of plumbing to manage the air pressure, an Arduino to control it all, and additional electronics in between to make them work together.

We’re especially impressed by the leap in features and quality from the first version to this one. It’s a testament to the power of quick proofs-of-concept before committing to a more involved build. Great work [Mike]!

We’ve seen rocket launchers for adults and some neat mission control panels but [Mike’s] kid friendly launch controller really is out of this world (sorry, couldn’t resist). You’ll find a video demo of this launcher after the break.

You may wonder why anyone would want to learn Morse code. You don’t need it for a ham license anymore. There are, however, at least three reasons you might want to learn it anyway. First, some people actually enjoy it either for the nostalgia or the challenge of it. After all, . Another reason is that Morse code can often get through when other human-readable schemes fail. Morse code can be sent using low power, equipment built from simple materials or even using mirrors or flashlights. Finally, Morse code is a very simple way to do covert communications. If you know Morse code, you could privately talk to a concealed computer on just two I/O lines. We’ll let you imagine the uses for that.

In the old days, you usually learned Morse code from an experienced sender, by listening to the radio, or from an audio tape. The state of the art today employs a computer to randomly generate practice text. [M0TGN] wanted a device to generate practice code, so he built it around an Arduino. The device acts like an old commercial model, the Datong D70, although it can optionally accept an LCD screen, something the D70 didn’t have.

You can see the project in operation in the video below. Once you learn how to read Morse code, you might want to teach your Arduino to understand it, too. Or, you can check out some other Morse-based projects.

In August of 2014, something new started showing up in the markets of Shenzen, the hi-tech area of China where the majority of the world’s electronics components are made. This is the ESP8266, a WiFi SoC (System on a Chip) that can connect to 802.11b/g/n networks on the 2.4GHz band. It can be addressed with SPI or a serial connection, and has an AT command set that makes it behave rather like an old-style modem. Basically, it has everything you would need to connect a device to a WiFi network, with the ESP8266 chip itself handling the complicated business of finding, joining and transmitting/receiving over a WiFi network.

That’s nothing particularly new in itself: WiFi connection devices like the TI CC3000 have been around for longer, and do much the same thing. The difference was the price. While the TI solution costs about $10 if you buy several thousand of them, the ESP8266 costs less than $7 for an individual board that can plug straight into an Arduino or similar. Buy the chip in bulk, and you can get it for less than $2.

The ESP8266 is more than just a WiFi dongle, though: it is a fully fledged computer in itself, with a megabyte of flash memory and a 32-bit processor that uses a RISC architecture. This can run applications, turning the ESP8266 into a standalone module that can collect and send data over the Internet. And it can do this while drawing a reasonably low amount of power: while receiving data, it typically uses just 60mA, and sending data over an 802.11n connection uses just 145mA. That means you can drive it from a small battery or other small power source, and it will keep running for a long time.

It wasn’t an easy ship to write applications for in the early days, though: it was poorly documented and required a dedicated toolchain to work with. This made it more of a challenge than many hackers were comfortable with.  That changed earlier this year, though, when the Arduino IDE (Integrated Development Environment) was ported to the chip. This meant that you could use the much easier to write Arduino functions and libraries to write code for the chip, bringing it within reach of even the most casual hacker.

Why Is the ESP8266 Important?

The ESP8266 almost achieves the holy trifecta of electronics: cheap, powerful and easy to work with. Before this, if you wanted to add a wireless connection to a project, you had to use more power-hungry devices like USB WiFi dongles, or squish everything into a serial connection and use a wireless serial link. Either way added to the complexity of the project: you either needed a system that supported USB and had WiFI OS support, or you had to put up with the limitations of wireless serial links, which typically offer very limited bandwidth. The advent of WiFi SoCs removed these limitations because the SoC did the heavy lifting, and WiFi offered much more bandwidth. And the ESP8266 did this all at a very low cost: do some digging on eBay and you can get an ESP8266 board for less than $2. So, it is no surprise that we are starting to see the ESP8266 showing up in commercial products. 

How Can I Use the ESP8266?

With the popularity of the ESP8266 for adding WiFi to projects, it is no surprise that there are a lot of options for trying it out. On the hardware side, ESP8266 development boards are available from a number of places, including Seeedstudio, Sparkfun and Olimex. Adafruit also has a nice ESP8266 board that breaks out all of the signals for easy breadboard use, and adds a 3.3V output, so it can drive an external device. It is also FCC approved, which is important if you are looking to sell or use the devices you build commercially. Some users have also been building their own development boards, which add features such as LCD displays and buttons.

On the software side, the easiest way to get into the ESP8266 is to use the Arduino compatible mode. This involves loading custom firmware that turns the chip into a mid-range Arduino board, which makes for much easier programming. The people behind this project have produced a list of supported ESP8266 boards: buying one of these will make the installation process easier, as they have noted which data lines in the Arduino SDK correspond to the physical pins on the board. These boards also provide easy access to the reset lines that you have to use to install the Arduino compatible firmware.

This does include some limitations, though: it is rather complicated to upload new sketches over WiFi, and you can’t produce multiple PWM signals, which would make controlling multiple devices difficult. To get access to the full capabilities of the ESP8266, you’ll need to go to the source, and use the SDK that the manufacturers offer. [cnlohr] published an in-depth guide here on Hackaday for bare-metal programming the ESP8266 whih was mentioned earlier. Espressif also offer a pretty good getting started guide that covers creating a virtual Linux machine and connecting this to their chips.

The third option is to flash NodeMCU to the ESP8266 module. This turns it into a Lua interpreter. Scripting can be done in real-time to prototype your program, then flashed to the EEPROM to make your program persistent and remove the need for a serial connection.

Beginners will be comfortable with both the Arduino and NodeMCU approaches, but experienced users should be able to wade straight in and start writing code for this cheap, powerful and fairly easy to use chip.

“It’s only software!” A sentence that strikes terror in the heart of an embedded systems software developer. That sentence is often uttered when the software person finds a bug in the hardware and others assume it’s going to be easier for fix in software rather than spin a new hardware revision. No wonder software is always late.

[Clint Stevenson] is his own hardware and software guy, as are most of us. He wanted to use the less expensive HC-SR04 ultrasonic rangefinder in a prototype. Longer term he wanted to have the choice of either a Parallax PING or MaxBotix ultrasonic sensor for their better performance outdoors. His hardware hack of the SR04 made this a software problem which he also managed to solve!

[Clint] was working with the Arduino library, based on the Parallax PING, which uses a single pin for trigger and echo. The HC-SR04 uses separate pins. Originally he modified the Arduino library to accept the two pin approach. But with his long term goal in mind, he also modified the HC-SR04 sensor by removing the on-board pull-up resistor and adding a new one on the connector side to combine the signals. That gave him an SR04 that worked with the single-pin based library.

We’ve seen Parallax PING projects for sensing water depth and to generate music. These could be hacked to use the HC-SR04 using [Clint’s] techniques.

[Arduino and HC-SR04 photo from http://www.blaxlab.com/%5D

[jmilldrum] really gets a lot of use out of his Si5351A breakout board. He’s a ham [NT7S], and the Si5351A can generate multiple square waves ranging from 8 kHz to 160 MHz, so it only stands to reason that it is going to be a useful tool for any RF hacker. His most recent exploit is to use the I2C-controllable chip to implement a Fast Simple QSO (FSQ) beacon with an Arduino.

FSQ is a relatively new digital mode that uses a form of low rate FSK to send text and images in a way that is robust under difficult RF propagation. There are 32 different tones used for symbols so common characters only require a single tone. No character takes more than two tones.

The Si5351A can easily handle the encoding job. Since the output is a square wave, you do need a low-pass filter to put it on the air. [jmilldrum] also used some relatively small amplifiers to get the output up to 20 watts.

You might remember, we’ve talked about [jmilldrum’s] work with the Si5351A before. We also recently were talking about hams experimenting with digital modes and this is a great example, both by the developers of FSQ and [jmilldrum] for implementing it with an Arduino. If you want to learn more about FSQ, see the video below.

The USB interface is being increasingly used as a power supply and charging port for all kinds of devices, besides data transfer. A meter to measure the electrical parameters of devices connected to a USB socket or charger would be handy on any hacker workbench. The folks at [electro-labs] designed this simple USB power meter which does just that.

The device measures voltage and current and displays them, along with the calculated power, on the small 0.5″ OLED display. The circuit is built around an ATmega328. To keep the board size small, and reduce component count, the microcontroller is run off its internal 8MHz clock. A low-resistance shunt provides current sensing which is amplified by the LT6106 a high side current sense amplifier before being fed to the 10 bit analog port of the ATmega. A MCP1525 precision voltage reference provides 2.5V to the Analog reference pin of the microcontroller, resulting in a 2.44mV resolution. Voltage measurement is via a resistive divider that has a range of up to 6V. An Arduino sketch reads voltage and current data on the analog ports and displays measurements on the display. The measured data is averaged to filter out noise.

The OLED display has a SPI interface and requires the u8glib library. The project uses all SMD parts, but is fairly easy to assemble by hand and could be a nice starter project if you want to wet your feet on surface mount assembly techniques. It’s designed using SolaPCB EDA software, and the source files for schematic and board layout are available as a ZIP archive. Download the BoM and Arduino code and you have everything needed to build this nifty device.

Thanks to [Abdulgafur] for sending in this tip. And if you are looking for a more comprehensive solution, check the awesome Friedcircuits USB Tester which we reviewed earlier and is available in the Hackaday Store.