Posts with «reviews» label

Malduino Elite – First Impressions

A while back, I wrote an article about Malduino, an Arduino-based, open-source BadUSB device. I found the project interesting so I signed up for an Elite version and sure enough, the friendly postman dropped it off in my mail box last Friday, which means I got to play around with it over the weekend. For those who missed the article, Malduino is USB device which is able to emulate a keyboard and inject keystrokes, among other things. When in a proper casing, it will just look like a USB flash drive. It’s like those things you see in the movies where a guy plugs in a device and it auto hacks the computer. It ships in two versions, Lite and Elite, both based on the ATmega32U4.

The Lite version is really small, besides the USB connector it only contains a switch, which allows the user to choose between running and programming mode, and a LED, which indicates when the script has finished running.

Original Malduino Elite sketch and Lite prototype

The Elite version is bigger, comes with a Micro-SD card reader and four DIP switches, which allow the user to choose which script to run from the card. It also has the LED, which indicates when a script has finished to run. This allows the user to burn the firmware only once and then program the keystroke injection scripts that stored in the Micro-SD card, in contrast to the Lite version which needs to be flashed each time a user wants to run a different script.

These are the two Malduinos and because they are programmed straight from the Arduino IDE, every feature I just mentioned can be re-programmed, re-purposed or dropped all together. You can buy one and just choose to use it like a ‘normal’ Arduino, although there are not a lot of pins to play around with. This freedom was one the first things I liked about it and actually drove me to participate in the crowd-funding campaign. Read on for the full review.

The Hardware

Malduino Elite vs USB flash drive

So the Elite board arrived as schedule and I found myself some time to look an it. Despite being longer than the Lite version, it’s still quite small, measuring roughly 4.6 cm x 1.1 cm (around 1.8 in x 0.43 in), which you can easily adapt to an old USB case, although you’ll have to cut some holes for the DIP switches and the Micro-SD card. In the crowd-funding campaign, the original sketch was for a 3 DIP switch version but the final Elite has four, which I found nice. I plugged it in to an old computer, after some consideration about which firmware it could ship with and what it could do to my laptop, and sure enough a red LED appeared. And that was it. Nothing else.

After playing around with the switches and exercising some RTFM, I realised that the firmware it ships with is probably some sort of Q.C. test for the dips, which makes the Malduino output the numbers 1 to 4 (actually simulating a keypress 1 to 4), depending on which switches are ON. So far so good, it works and I’ve seen worse PCB boards than this one. The board has holes for six pins, which I did not trace to the micro-controller and I don’t know what they are for.

The Setup

Setting up the Malduino requires that you have the Arduino IDE installed and up to date. You’ll need to open up the board manager and install the Sparkfun boards since the Elite is programmed as a ‘Sparkfun Pro Micro’ running at 3.3 V and 8 MHz. Then you need to go the Malduino Script Converter website which serves several purposes:

  • It allows to convert scripts between the Lite and Elite versions
  • It allows you to choose your keyboard layout language
  • It auto generates the Arduino project for you to import to the IDE

For the Elite version, just create a simple or even empty script to download the project, since when in ‘normal’ operation you will just flash the Malduino once and then use the Micro-SD card to store new scripts.

A note on flashing, if you are using a Debian-based distribution you might come across some problems like I did and not be able to flash the device. Like the user on this most useful post, my modem-manager was trying to talk with the Malduino after every reset and confused AVRDUDE to death. The solution is to add udev rules to “/etc/udev/rules.d/77-mm-usb-device-blacklist-local.rules”, kudos to [socrim]:

ACTION!="add|change", GOTO="mm_usb_device_blacklist_local_end"
SUBSYSTEM!="usb", GOTO="mm_usb_device_blacklist_local_end"
ENV{DEVTYPE}!="usb_device", GOTO="mm_usb_device_blacklist_local_end"

ATTRS{idVendor}=="1b4f" ATTRS{idProduct}=="9204", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="1b4f" ATTRS{idProduct}=="9203", ENV{ID_MM_DEVICE_IGNORE}="1"

LABEL="mm_usb_device_blacklist_local_end"

The Software

Since I’m running Linux, a quick shortcut to run a command is the ALT-F2 combination. So I script that into a file and save it to 1111.txt. The Elite searches the Micro-SD card for a file corresponding to the current dip switch state. Lets say the dip switch 2 and 4 are ON. In this case, the software tries to find the file named 0101.txt and parse its contents (as in dip switch order 1,2,3,4 and not the binary representation of the number 2 and 4) . When it finishes, the red LED starts flashing quickly. My simple script was:

DELAY 2000
ALT F2
DELAY 1000
STRING xterm
DELAY 1000
ENTER
DELAY 1000
STRING id
DELAY 1000
ENTER

But it was not working. Almost all commands worked but the ALT-F2 combo was not functioning properly. Close, but no cigar. No ALT-F2, no run command window. I’ve already lazy-browsed the source code a bit because I really didn’t have a lot of time on my hands but I needed to figure this out. The offending code was this:

else if(equals(s,e,"F1",<strong>3</strong>)) Keyboard.press(KEY_F1);</pre>

else if(equals(s,e,"F2",<strong>3</strong>)) Keyboard.press(KEY_F2);
...
else if(equals(s,e,"F10",3)) Keyboard.press(KEY_F10);
else if(equals(s,e,"F11",3)) Keyboard.press(KEY_F11);

A custom equals function was receiving size 3 for the strings of the Function keys, like “F2”. It was ok for “F10”, “F11” and “F12”, but failed for the rest of the keys. Changing 3 to 2 did the trick, but my Portuguese keyboard layout started to interfere with other test scripts. So I changed the code to include PT and UK layouts, changing them in a #define at compile time.

It would be cool if it was possible to access the SD card from the computer as a regular USB volume. I don’t know exactly how feasible that is, but it does not come with the current firmware. I still wanted to be able to output the content of an arbitrary file on the SD card to the screen, so I added another script function called ECHOFILEHEX that outputs the content of a file in the SD card as escape characters. For example, if the file a.txt contains “AAA”, the script command ECHOFILEHEX a.txt would output “\x41\x41\x41”. This can be useful to echo binary files into printf or echo -e, in Linux hosts at least.

Meanwhile, I had some trouble reading the original code. You know, we all have different programming styles. Don’t get me wrong, I’ve been known to write some messed-up spaghetti code. I sometimes browse old projects looking for some libs or classes I coded and wonder ‘who the heck wrote this steaming pile of code?’ Me, it was me. Anyway, I started to change a bit here and there and ended up changing pretty much the entire code. That’s the beauty and the curse of open-source. If you’re curious you can check it out here.

Conclusion

All in all, and despite some bumps, I’m quite pleased with Malduino. It is what I expected: an open platform for BadUSB attacks that’s in its infancy. It’s awesome that we can all tinker with it, modify it, make it better or just make it suit our needs. I hope a real community can start so we can see its full potential emerge. My short list includes simulating other USB devices, better SD card management, and expanding the device via the unused pins. What would you add?

It’s a long way to go and a lot can go wrong, so good luck with the project [Seytonic]!


Filed under: Featured, reviews, security hacks

From the New Issue of Make: Our 8 Standout Dev Boards

These eight boards stand out for their advanced specs, built-in offerings, and, in some cases, their innovative interface options.

Read more on MAKE

The post From the New Issue of Make: Our 8 Standout Dev Boards appeared first on Make: DIY Projects and Ideas for Makers.

First Look at ABC: Basic Connections

[Alberto Piganti], aka [pighixxx] has been making circuit diagram art for a few years now, and has just come out with a book that’s available on Kickstarter. He sent us a copy to review, and we spent an hour or so with a refreshing beverage and a binder full of beautiful circuit diagrams. It doesn’t get better than that!

[pighixxx] started out making very pretty and functional pinout diagrams for a number of microcontrollers, and then branched out to modules and development boards like the Arduino and ESP8266. They’re great, and we’ll admit to having a printout of his SMD ATMega328 and the ESP-12 on our wall. His graphical style has been widely copied, which truly is the sincerest form of flattery.

But after pinouts, what’s next? Fully elaborated circuit diagrams, done in the same style, of course. “ABC: Basic Connections” started out life as a compendium of frequently used sub-circuits in Arduino projects. But you can take “Arduino” with a grain of salt — these are all useful for generic microcontroller-based projects. So whether you want to drive a 12 V solenoid from a low-voltage microcontroller, drive many LEDs with shift registers, or decode a rotary encoder, there is a circuit snippet here for you.

One of the things that we like most about the graphics in “ABC” is that they’re not dumbed down — they’re fundamentally just well-done circuit diagrams, but with graphic touches and extra detail where it actually helps to clarify things. This is a middle ground between the kind of schematic you use in a PCB layout program and the kind of diagram you get from Fritzing. In the former, every part has a symbol but multifunction parts like microcontrollers are just represented as squares bristling with pin numbers. In the latter, wiring up an IC is easy because the parts and pins are represented graphically, but you quickly run out of colors for the different wires, and the “breadboard” turns into a rat’s nest with a circuit of any complexity.

“ABC” takes the middle road, using standard circuit diagram style overall, but also the nice graphic representations of the ICs and modules that [pighixxx] is good at. Is a 2N2222 pinned EBC or BCE? You don’t have to look that up, because it’s sketched out for you here. We’d guess that this attractive, but information-rich, style is a great fit for the target audience — people with some electronics experience who do not yet have their favorite transistor symbol tattooed on their forearm. [pighixxx]’s diagrams are simple, easy to understand, easy to use, and pretty to boot.

There is a planned online counterpart to the book, with further elaborations of all of the circuit setups. They’re not finished yet, but they have a lot more of the flavor of the Fritzing-style, this-wire-goes-to-that-hole diagrams. This style does work better in an online format than in a physical book, because you can build up the rat’s nest in bite-sized steps, none of which are too overwhelming. But honestly, for an advanced beginner or intermediate electronics hacker, the book can be treated as stand-alone. The web content may help the rank newbie when they get stuck.

Tee-hee.

The breadth of circuits in “ABC” is fairly wide, covering most of the microcontroller-interfacing problems that we’ve ever encountered. None of the circuits are revolutionary — they’re the tried-and-true, correct solutions to the various problems, rather than anything too hacky or clever. We weren’t surprised by any of the circuits, but we didn’t find anything that we wouldn’t use ourselves either. These are basic connections after all, and a darn solid collection of them.

To sum up, “ABC” is an attractive book in a handy binder format that would make a great collection of solutions for anyone who’s just getting started in the whole “Arduino” scene but who gets hung up on interfacing the chips with the real world. It’s a handy reference for the pinouts of a number of frequently used parts, combined with the resistors, flyback diodes, level-shifting circuits, and whatever else that you’d need to make them work. It’s what we wish our simple circuit diagrams looked like. We like it.


Filed under: Hackaday Columns, reviews

PlatformIO and Visual Studio Take over the World

In a recent post, I talked about using the “Blue Pill” STM32 module with the Arduino IDE. I’m not a big fan of the Arduino IDE, but I will admit it is simple to use which makes it good for simple things.

I’m not a big fan of integrated development environments (IDE), in general. I’ve used plenty of them, especially when they are tightly tied to the tool I’m trying to use at the time. But when I’m not doing anything special, I tend to just write my code in emacs. Thinking about it, I suppose I really don’t mind an IDE if it has tools that actually help me. But if it is just a text editor and launches a few commands, I can do that from emacs or another editor of my choice. The chances that your favorite IDE is going to have as much editing capability and customization as emacs are close to zero. Even if you don’t like emacs, why learn another editor if there isn’t a clear benefit in doing so?

There are ways, of course, to use other tools with the Arduino and other frameworks and I decided to start looking at them. After all, how hard can it be to build Arduino code? If you want to jump straight to the punch line, you can check out the video, below.

Turns Out…

It turns out, the Arduino IDE does a lot more than providing a bare-bones editor and launching a few command line tools. It also manages a very convoluted build process. The build process joins a lot of your files together, adds headers based on what it thinks you are doing, and generally compiles one big file, unless you’ve expressly included .cpp or .c files in your build.

That means just copying your normal Arduino code (I hate to say sketch) doesn’t give you anything you can build with a normal compiler. While there are plenty of makefile-based solutions, there’s also a tool called PlatformIO that purports to be a general-purpose solution for building on lots of embedded platforms, including Arduino.

About PlatformIO

Although PlatformIO claims to be an IDE, it really is a plugin for the open source Atom editor. However, it also has plugins for a lot of other IDEs. Interestingly enough, it even supports emacs. I know not everyone appreciates emacs, so I decided to investigate some of the other options. I’m not talking about VIM, either.

I wound up experimenting with two IDEs: Atom and Microsoft Visual Studio Code. Since PlatformIO has their 2.0 version in preview, I decided to try it. You might be surprised that I’m using Microsoft’s Code tool. Surprisingly, it runs on Linux and supports many things through plugins, including an Arduino module and, of course, PlatformIO. It is even available as source under an MIT license. The two editors actually look a lot alike, as you can see.

PlatformIO supports a staggering number of boards ranging from Arduino to ESP82666 to mBed boards to Raspberry Pi. It also supports different frameworks and IDEs. If you are like me and just like to be at the command line, you can use PlatformIO Core which is command line-driven.

In fact, that’s one of the things you first notice about PlatformIO is that it can’t decide if it is a GUI tool or a command line tool. I suspect some of that is in the IDE choice, too. For example, with Code, you have to run the projection initialization tool in a shell prompt. Granted, you can open a shell inside Code, but it is still a command line. Even on the PlatformIO IDE (actually, Atom), changing the Blue Pill framework from Arduino to mBed requires opening an INI file and changing it. Setting the upload path for an FRDM-KL46 required the same sort of change.

Is it Easy?

Don’t get me wrong. I personally don’t mind editing a file or issuing a command from a prompt. However, it seems like this kind of tool will mostly appeal to someone who does. I like that the command line tools exist. But it does make it seem odd when some changes are done in a GUI and some are done from the command line.

That’s fixable, of course. However, I do have another complaint that I feel bad for voicing because I don’t have a better solution. PlatformIO does too much. In theory, that’s the strength of it. I can write my code and not care how the mBed libraries or written or the Arduino tools munge my source code. I don’t even have to set up a tool chain because PlatformIO downloads everything I need the first time I use it.

When that works it is really great. The problem is when it doesn’t. For example, on the older version of PlatformIO, I had trouble getting the mBed libraries to build for a different target. I dug around and found the issue but it wasn’t easy. Had I built the toolchain and been in control of the process, I would have known better how to troubleshoot.

In the end, too, you will have to troubleshoot. PlatformIO aims at moving targets. Every time the Arduino IDE or the mBed frameworks or anything else changes, there is a good chance it will break something. When it does, you are going to have to work to fix it until the developers fix it for you. If you can do that, it is a cost in time. But I suspect the people who will be most interested in PlatformIO will be least able to fix it when it breaks.

Bottom Line

If you want to experiment with a different way of building programs — and more importantly, a single way to create and build — you should give PlatformIO a spin. When it works, it works well. Here are a few links to get you started:

Bottom line, when it works, it works great. When it doesn’t it is painful. Should you use it? It is handy, there’s no doubt about that. The integration with Code is pretty minimal. The Atom integration — while not perfect — is much more seamless. However, if you learn to use the command line tools, it almost doesn’t matter. Use whatever editor you like, and I do like that. If you do use it, just hope it doesn’t break and maybe have a backup plan if it does.


Filed under: Arduino Hacks, ARM, Hackaday Columns, reviews, Skills

Hands On With The First Open Source Microcontroller

2016 was a great year for Open Hardware. The Open Source Hardware Association released their certification program, and late in the year, a few silicon wizards met in Mountain View to show off the latest happenings in the RISC-V instruction set architecture.

The RISC-V ISA is completely unlike any other computer architecture. Nearly every other chip you’ll find out there, from the 8051s in embedded controllers, 6502s found in millions of toys, to AVR, PIC, and whatever Intel is working on are closed-source designs. You cannot study these chips, you cannot manufacture these chips, and if you want to use one of these chips, your list of suppliers is dependent on who has a licensing agreement with who.

We’ve seen a lot of RISC-V stuff in recent months, from OnChip’s Open-V, and now the HiFive 1 from SiFive. The folks at SiFive offered to give me a look at the HiFive 1, so here it is, the first hands-on with the first Open Hardware microcontroller.

Before I dig into this, I must discuss the openness of the HiFive 1, and RISC-V in general. Free Software and Open Hardware is a religion, and it’s significantly more difficult to produce Open Hardware than Free Software. No matter how good or how Open the design is, the production of the first Open Source microcontroller will generate far too many comments from people who use the words ‘moral imperative’ while citing utilitarian examples of why Open and Libre is good. You should ignore these comments, but not just because these people have only read the back cover of the Cliff’s Notes for Philosophy For Dummies.

The Openness of the HiFive 1 and RISC-V

The biggest selling point for RISC-V chips is that there are no licensing fees, and this microcontroller is Open Source. This is huge — your AVRs, PICs, ARMs, and every other microcontroller on the planet is closed hardware. You can’t study the silicon. If we’re ever going to get a completely Open Source computer, it has to start somewhere, and here it is.

With that said, this is an Arduino-compatible board with an FTDI chip providing the USB to serial conversion. If we had a facepalm emoji, we’d use it here. An FTDI chip is not Open Source, and they have designed drivers to break chips that aren’t theirs. The design files for the HiFive 1 were made with Altium, a proprietary and non-Free software.

This was the best picture for this section of content.

Will Stallman ever say the HiFive 1 is Free as in speech? Absolutely not. Instead, the HiFive 1 is an incrementally more Free microcontroller compared to a PIC, ARM, or AVR. There will be people who will argue – over the Internet, using late-model Intel processors with Management Engines — this is insufficient to be called Free and Open Source. To them, I will simply link to the Nirvana fallacy and ask them to point me to a microcontroller that is more Free and Open Source. Let’s not cut down the idea of an Open Source microcontroller because it’s not perfect on the first release.

Hardware Teardown

So, what’s in the HiFive 1? The spec sheet is simple enough, the datasheet is complete enough,  although there are some caveats:

  • Microcontroller: SiFive Freedom E310 (FE310)
    • CPU: SiFive E31 CPU
    • Architecture: 32-bit RV32IMAC
    • Speed: 320+ MHz (the stock frequency seems to be about 256 MHz, this can be changed)
    • Performance: 1.61 DMIPs/MHz
    • Memory: 16 KB Instruction Cache, 16 KB Data Scratchpad
    • Other Features: Hardware Multiply/Divide, Debug Module, Flexible Clock Generation with on-chip oscillators and PLLs
  • Operating Voltage: 3.3 V and 1.8 V
  • Input Voltage: 5 V USB or 7-12 VDC Jack
  • IO Voltages: Both 3.3 V or 5 V supported
  • Digital I/O Pins: 19
  • PWM Pins: 9
  • SPI Controllers/HW CS Pins: 1/3
  • External Interrupt Pins: 19
  • External Wakeup Pins: 1
  • Flash Memory: 128 Mbit Off-Chip (ISSI SPI Flash)
  • Host Interface (microUSB): Program, Debug, and Serial Communication

Basically, the HiFive 1 is the SiFive FE310 microcontroller packaged in an Arduino Uno form factor. The pin spacing is just as stupid as it’s always been, and there is support for a few Adafruit shields sitting around in the SDK.

There are no analog pins, but there are two more PWM pins compared to the standard Arduino chip. The Arduino Uno and Leonardo have 32 kilobytes of Flash, while the HiFive 1 has sixteen Megabytes of Flash on an external SOIC chip.

The HiFive 1 supports 3.3 and 5V I/O, thanks to three voltage level translators. The support for 5V logic is huge in my opinion — nearly every dev board manufacturer has already written off 5V I/O as a victim of technological progress. The HiFive doesn’t, even though the FE310 microcontroller is itself only 3.3V tolerant. It should be noted the addition of the voltage level translators add at least a dollar or two to the BOM, and double that to the final cost of the board. It’s a nice touch, but there’s room for cost cutting here.

Other than that, the only other chip of note on the board is the FTDI FT2232HL, a well-supported but most certainly not Free and Open Source USB to UART chip. This is a two-port chip that provides programming, serial, and debug connections simultaneously.

Getting Started With The HiFive 1

The folks at SiFive realize documentation and SDKs are necessary to turn a chip into a development board. To that end, they have a bare-metal SDK and support for the Arduino IDE. The board itself comes with a bootloader, and when you plug the HiFive 1 into a USB you get the equivalent of the Blink sketch from the Arduino. Yes, you too can have Open Source blinkies. What a magical time to be alive.

Right now there are two methods of programming the HiFive 1. The Freedom E SDK, and the Arduino IDE. The Arduino IDE appears to be dependent on the Freedom E SDK, so either way, you’ll have to get the SDK running.

Right now, the SDK only works under Linux (and OS X, and possibly Cygwin), but support for Windows is coming. For Linux users, the getting started guide is more than sufficient, although it will take quite a while (at least 30 minutes) to build all the tools.

Once the Freedom E SDK is installed, support for the Arduino IDE pretty much falls into place. You’ll have to futz around with the Boards Manager, but with a few clicks, you get something fantastic. You can blink an LED with Open Source Hardware.

 Actually Programming the Thing

Blinking an LED is proof enough this can be programmed, but what about the vast SDK we had to install before getting the Arduino IDE working? Here, too, it’s pretty easy to get the SDK up and running:

For this example, I simply changed the ‘hello world’ program shipped with the SDK to a ‘hello Hackaday’ program, compiled it, and ran it. Yes, someone as dumb as me can compile and upload a program to the HiFive 1.

This Stuff is Still New, Okay?

Before receiving the HiFive 1, I originally planned to benchmark this dev board against other small, common dev boards. The SDK comes with a Dhrystone program, making this the obvious choice. The results were not good, but this isn’t a reflection of the power of the FE310 microcontroller. Allow me to present the shocking infographic you should not pay attention to:

Ignore this infographic

This test used this Dhrystone Arduino sketch with the Arduino Micro, HiFive 1, and the Teensy 3.6. As you would expect the Arduino Micro performed poorly (but still ten times faster than a mainframe from 1988), and the Teensy 3.6 was extremely fast. According to this benchmark, the HiFive 1 did terribly at barely twice the computing power of the Arduino while running 16 times faster. If this benchmark was accurate, it would immediately spell the end of the RISC-V ISA.

The above benchmark is not accurate, and the poor Dhrystone performance was due to incorrect assumptions about the timer’s frequency. I plopped this problem up on the SiFive forums, and a patch was available in a few hours. What does the real benchmark say?

That’s a fast microcontroller. RISC architecture is gonna change everything.

love this test. Beginning this review, I originally planned to run a few benchmarks on an Arduino, a Teensy, and the HiFive 1, throw together a graph and spend a hundred or so words on the results.  I got so much more.

Right off the bat, we can see the HiFive 1 is fastReally, really fast. Right now, if you want to build a huge RGB LED display, you have one good option: the Teensy 3.6. If you need a microcontroller to pump a lot of data out, the Teensy has the power, the memory, and the libraries to do it easily. In this small but very demanding use case, the HiFive 1 might be better. The HiFive 1 has more Flash (although it’s an SPI Flash), it has DMA, and it has roughly twice the processing power as the Teensy 3.6. This could be very, very cool, and I can’t wait to see the real life examples of how much the HiFive 1 can push out of its pins.

There’s your hundred word review on the performance of the HiFive 1 based on synthetic benchmarks. However, getting this benchmark working revealed far more about the state of the HiFive’s software, and how much support SiFive is throwing at it.

Admittedly, I do have a very early version of this board, and the CrowdSupply campaign for the HiFive 1 was only funded last week. No one would expect one of the three demo apps shipped with a newly released board with a mature architecture to be completely broken (unless it’s an Allwinner chip, but whatever). Very few people would expect the devs to get a patch out in less than 24 hours in response to a random person on a support forum.

All of this circles back to a single observation on the HiFive 1: It’s new. The HiFive 1 and all RISC-V microcontrollers don’t have a vast market share, user base, or decades of work behind them. However, the SiFive team seems to be taking their work seriously. They’re fixing the problems they have, and they’re constantly pushing out new documentation. This is great, and a very good indication of how much support the RISC-V chips from SiFive will have.

Chips As A Service

I should note that the folks at SiFive aren’t in the business of building RISC-V Arduino boards. They’re in the business of making chips for people. This is custom silicon we’re talking about here.

The easiest parallel to draw is between SiFive and OSH Park. These companies don’t have their own manufacturing capability; the value is in connecting end users (engineers, startups) to manufacturers. OSH Park connects you to a board house that really knows purple, and SiFive connects you to a chip fab. In the case of the FE310, that’s TSMC.

For anyone who wants silicon you can study, this is great. No, it’s not as simple as sending a board off to a fab house, but it’s a start. The fact that SiFive chose to start with Open Hardware is great, and we can’t wait to see the other hardware made with their sweat and hydrofluoric acid.

It’s a Beginning

At the base level, the HiFive 1 is a powerful microcontroller with a lot of Flash, with support for hundreds of Arduino libraries. That’s great, and alone this might be worth the $60 price of admission.

However, the big story here is the Openness of the HiFive 1. Is it completely open? No. the HiFive 1 itself uses an FTDI chip, and I’ve heard rumor and hearsay the FE310 chip has proprietary bits that are ultimately inconsequential to the function of the chip. A strict interpretation of Open Hardware will not allow this board to be called Open Hardware. Those who advance this interpretation are dumb, and to counter this argument I will quote the man himself:

…We need to distinguish levels in the design of a digital product (and maybe some other kinds of products). The circuit that connects the chips is one level; each chip’s design is another level. In an FPGA, the interconnection of primitive cells is one level, while the primitive cells themselves are another level. In the ideal future we will want the design to be free at all levels. Under present circumstances, just making one level free is a significant advance.

– Richard M. Stallman, Free Hardware And Free Hardware Designs

A design that fails to be completely Open does not deserve to be grouped with designs that are explicitly closed.

Nevertheless, this is the best we have so far, and it is only the beginning. We’re going to have more microcontrollers that are more Open, but until then, the HiFive 1 is actually a pretty cool board.


Filed under: Microcontrollers, reviews

Review: HUZZAH is the ESP8266 WiFi Setup You Need

A little board that adds WiFi to any project for a few hundreds of pennies has been all the rage for at least half a year. I am referring to the ESP8266 and this product is a marrige of one of those WiFi modules with the support hardware required to get it running. This week I’m reviewing the HUZZAH ESP8266 Breakout by Adafruit Industries.

If you saw the article [cnlohr] woite for us about direct programming this board you will know that a good chunk of that post covered what you need to do just to get the module into programming mode. This required adding a regulated 3.3V source, and a way to pull one of the pins to ground when resetting the power rail. Not only does the HUZZAH take care of that for you, it turns the non-breadboard friendly module into a DIP form factor while breaking out way more pins than the most common module offers. All of this and the price tag is just $9.95. Join me after the break for the complete run-down.

The Hardware

This board is about 1.5 inches by 1 inch… like two postage stamps side-by-side. It hosts the FCC and CE approved module which we first heard about in December. These modules need a 3.3v supply and there is a regultor on board which can supply up to 500mA (the module can consume as much as 250mA) and can be fed by a battery, USB power, or any other 5V supply. As I mentioned earlier you need to pull a pin low during reset to put the module in programming mode. There are two switches on the board that facilitate this, hold the user button down and press reset and you’re ready to flash.

On a breadboard you’ll have two rows not covered by the board on one side, and one row on the other. The board doesn’t have a USB-to-UART bridge but we’re fine with that. On one end of the board you’ll find the common pinout for a USB-to-serial programming cable. Above you can see the programming cable Adafruit sent me with these samples. To the right I tried out my 5V Sparkfun FTDI board and as advertised, the HUZZAH can be programmed with either 3.3v or 5V logic levels.

The one thing I noticed is that the two buttons are a bit tricky to get at with the programmers connected, especially the FTDI board. For the second module I may supply my own right-angle header to get around that. Of course doing so would cover part of the breadboard so this is probably six of one, half dozen of the other.

I love it that they supply the pin headers but don’t solder them. Sometimes I prefer pin sockets or unpopulated pads, and this makes it easy for me to make that choice like the right-angle one I mentioned above. It’s something small but I also appreciate that the pinheaders in the package were not the minimum number necessary for this board — there were a few extra pins. You need to break them off and sometimes they can break one pin over from where you expected. If it were the minimum number you would either start over or solder a single pin at the end of the row (not ideal). If you screw up snapping these you could conceivably use a set of three pins and the rest as one unit to fix your mistake. Maybe I’m weird but it’s the small things in life!

Programming Options: NodeMCU and Lua

The board ships with this firmware on it. I was up and running with the Lua interpreter within three minutes of the package arriving at my door. Seriously, it took me longer to figure out if the USB-to-serial was green or white for TX/RX than it did to connect to my local WiFi Access point. Adafuit’s ‘Hello World’ walkthrough gets you going if you haven’t given this a try before.

Programming Options: Arduino IDE

Adafruit has a Board Manager for Arduino IDE. Perhaps this is common knowledge but I don’t often work with this IDE and it’s the first time I’ve run into it. What can I say, it kicks ass!

I hate setting up tool chains for new chips. With this you add a web address and port number, restart the IDE, and use the board manager to add support for this board. Sweet!

That turns this into an Arduino compatible board which solves something that has long bothered me. I’ve seen a ton of really simple Arduino projects that use the ESP8266 externally. Last month’s porting of the Arduino framework for these chips, coupled with this ready-to-go hardware does away with that nonsense. Seriously, the vast majority of those projects need little to no computing power and will work like a dream when directly programmed onto this chip.

To prove my point, I knocked out this quick binary counter that uses five LEDs as outputs. I’m not leveraging any of the WiFi features on this, but the compiled binary is 174,358 bytes and the Arduino IDE reports this board has a max capacity of 524,288 bytes. It five I/O used for LEDs there are still four more digital pins, the two UART pins, and an ADC input.

Programming Options: esptool

Arduino will overwrite NodeMCU but that’s easy to reflash. I followed [cnlohr’s] direct programming guide to write the binary using esptool. Both this method and the Arduino method are directly programming the EEPROM on the module. This is exactly the same method you’d use if you wanted to develop natively using the Espressif or the Open Source SDKs. Here’s the commands I used to reflash the NodeMCU firmware:

sudo python esptool.py --port /dev/ttyUSB0 write_flash 0x0000 /home/mike/Downloads/nodemcu_latest.bin

Get the NodeMCU binary from their “latest” folder of github repo.

Conclusion

“Buy as many of these as [Phil] will make for us.” That’s what I’ve asked [Julian], the Hackaday Store manager to do. You should be able to get the Hackaday black version of this in a few weeks. Adafruit is currently sold out but I’m sure they’re racing to remedy this.

These are amazing little boards. The price of $9.95 is crazy considering what you get for it. I’m talking about the entire ecosystem which gives you multiple flavors of programming environments. Adafruit has done a lot to contribute to the code and knowledge base here, but a mammoth portion of this is community developed and I think coming in low on the price is one more way Adafruit has chosen to be a good guy in this ecosystem. The board has a ton of I/O for what it is, and if that’s not enough just, implement I2C, SPI, or UART to couple a beefy uC to the connectivity this one brings to the party. I see zero downside on this board. It’s as close to perfect as you can get.


Filed under: Arduino Hacks, Hackaday Columns, reviews

Arduino vs. Phidgets vs. Gadgeteer

A few days ago, we saw a dev time trial between the Arduino and Phidgets, a somewhat proprietary dev board that is many times more expensive than an Arduino. The time trial was a simple experiment to see which platform was faster to prototype simple circuits. As always in Hackaday comments, there was a ton of comments questioning the validity and bias of the test. Not wanting to let a good controversy go to waste, [Ian Lee] tossed his hat into the ring with the same dev trial with the Gadgeteer.

The Gadgeteer has the same design philosophy as Phidgets: modular components and a unique software system -the Gadgeteer is based on .NET Micro Framework – that allows you to get up and running quickly. Unlike Phidgets, the Gadgeteer is priced competitively with the Arduino, and the mainboard is priced within an order of magnitude of a single ATMega chip.

[Ian] pulled off three project with the three development platforms: blinking a LED, moving a servo, and building a pedometer with an accelerometer. For each trial, the time taken and the price of all components were added up. Here’s the relevant graph:

According to the tests, the Gadgeteer won by a large margin. We’re not going to call this a definitive test, and no sane person should think it is. It does, however, highlight the benefits of a well-designed ‘module-based’ development system combined with a good IDE: the Gadgeteer is consistently faster than Phidgets, and just a bit more expensive than an Arduino.

While a time trial consisting of one developer writing code to blink a LED, move a servo, and read a pedometer is hardly enough to make any conclusions, it does demonstrate that the Gadgeteer isn’t that much more expensive than using an Arduino. We’ll leave the rest of the discussion to the commentors below.


Filed under: reviews, Software Development

Arduino vs. Phidgets – Dev Time Trials

Is developing on an Arduino too slow? Are Phidgets too expensive? When might you use one or the other? Hackaday regular [Ken] breaks down what he learned from three experimental time trials.

The main development differences between Arduino and Phidgets are a mix of flavor preferences and some hard facts. The Arduino is open source, Phidgets are proprietary. Arduino requires a mix of hard- and software where Phidgets only needs (and only allows) a connection to a full computer but enables high level languages – it is expected to get the job done sooner and easier. And finally, Arduinos are cheap, Phidgets are 3-5x the cost.

The three time trials were common tasks: 1. Blink an LED. 2. Use a pot to turn a servo. 3. Build a pedometer. For [Ken], the Phidgets won in each of the three experiments, but not significantly: 37%, 45%, and 25% respectively. The difference is only minutes. Even considering time value, for most hackers it is not worth the cost.

In context, the advantages of a mildly more rapid development on the simplest projects are wasted away by needing to rebuild a permanent solution. Chained to a PC, Phidgets are only useful for temporary or fixed projects. For many of our readers that puts them dead in the water. Arduinos may technically be dev kits but are cheap enough to be disposed of in the project as the permanent solution – probably the norm for most of us.

[Ken] points out that for the software crowd that abhor electronics, Phidgets plays to their preferences. Phidgets clips together their pricey peripherals and the rest is all done in code using familiar modern languages and libraries. We wonder just how large this group could still be; Phidgets might have been an interesting kit years ago when the gulf between disciplines was broader but the trend these days is towards everyone knowing a little about everything. Hackaday readers probably represent that trend more than most, but let us know if that seems off.

[Ken]’s article has much more and much better detailed explanations of the experiments and the tradeoffs between the platforms.

If you enjoy watching parallel engineering, see the time-lapse video below for a split screen of the time trials.


Filed under: reviews, Software Development

The PICnDuino Review

For those of you that can’t make a decision between buying an Arduino and a PIC processor, [Brad] has come up with a novel solution, the PICnDuino. We’ve featured him before with his [Retroball] project, but this time Brad has been full funded on Kickstarter, and is pre-selling boards for delivery in March.

[HAD], specifically I, was fortunate enough to be sent one of the boards to try out early. I’ve worked with an Arduino before, but never a PIC processor, so read on to see if it was actually as easy as the tutorial video (at the end of the article) would have you believe it is to get started.

I was sent both a black board fully populated, as well as several blanks in the various colors pictured below.  After loosely attaching the headers, I found that the oscillator on the bottom makes the board sit up a bit when placed into a breadboard. This is actually a clever design feature to make sit up a bit to allow USB attachment while breadboarded. After a quick physical inspection, the real trick would be seeing if it worked as advertised.

The first challenge for me was that, according to the documentation, this board runs in Windows or a virtualisation environment. I normally run Ubuntu, so, grabbing my wife’s circa 2000 vintage XP notebook, I downloaded and Amicus and Arduino software as explained in the video tutorial. The tutorial really spells out how to get the software running. This would be great for a total beginner, and made it so I didn’t have to even poke around for where to get the software.

The only issue I had connecting to the board(s?)was that I had to manually install the Amicus18 USB driver. I’m a total noob when it comes to the PIC processor, and only have limited experience with the Arduino, but once the driver was updated, it was quite easy to get everything going.

After programming a “blink” sketch using it as an Arduino, I then flipped a switch and opened the Amicus IDE. Programming the PIC was also simple, although I had to use a and modify a program called “LED_Flash” to match the video instead of the “blink” program as described in the tutorial. It was a bit strange to see the built in blinking light for the Arduino still working while the PIC was being programmed, as well as both built-in lights blinking slightly offset while running simultaneously.

The documentation is extremely well done for a product that won’t even be available for delivery until March 2013. I’m really excited to play with it more, and I think it will be a great tool for people to either run two processors simultaneously, or just have the option of learning to program both a PIC and (n) Arduino. So check it out here, and get it shipped worldwide straight out of Australia!

Side note, bonus points if you can tell from the two pictures what kind of computer I used for this review!


Filed under: arduino hacks, reviews

Wearable Fabric on the Arduino Store

We are happy to announce the first wearable kit on the Arduino Store . This kit has been made by Plug’n'Wear specifically for us. All fabrics in this kit are produced in Italy, and strongly related to a textile family business. If you want to get deeper into the story of this product have a look at Riccardo Marchesi presentation (still in Italian, soon to be traslated!) at World Wide Rome 2012.

Read over for Kit’s features

This kit features:

  1. 1x Circular Stretch Sensor Designed by Hannah Perner-Wilson, this circular knit stretch sensor works perfect when you need to detect tension in many projects.
  2. 2x Textile push button to make easy digital inputs in cloth, scarfs o bags.
  3. 2x Spools of Conductive thread, ready to be hooked over a sewing machine
  4. 2x Soft potentiometer kit will let you import analog data into your wearable project: this kit includes 1 meter of knitted conductive tape and a metal ring. Watch it in action (see video)
  5. 10x 1k ohm resistor
  6. 10x 10k ohm resistor
  7. 1x Textile perfboard is going to change the way you think of wearable circuits. You can sew or even solder components (SMD & through-hole) on this . It can be easily cut or sewn with a standard sewing machine. Washable. Size: 15 cm x 15 cm (6″ x 6″) / Pitch: 2.54 mm (0.1″)
  8. 1x Knitted Coated Copper Tape. Small conductive tape made of coated copper fine wire (112 micron). Flexible, easy to cut, sewable with a standard sewing machine, It can be easily welded ( The coating will melt and tape will be soldered). The surface of this tape has a good insulation thrughout its lenght. Resistance: 107 Ohm/m. Width: 9 mm (0.35″)
  9. 1x Analog Textile Press Button, working with a resistive principle (resistance goes down when you press it). It works as a bend sensor as well. By connecting more sensors together it is possible to make a matrix analog switch. Sensitive area 40mm x 40mm (1.57″x1.57″)
  10. 2x LilyPad LED Bright White A simple, very bright, 250mcd, white LED LilyPad

source: [arduino store]