viaspringboard.com

Cryptography for Springboard: Hashlet

Previously I’ve described here the ProtoSpring board to support quicker prototyping with  Springboard. Since then it was put to good use for just that: I’ve tested how the I2C bus works, and created a new device.

The inspiration for that new device comes from Tindie, the indie hardware marketplace (where ProtoSpring is listed as well). Browsing existing hardware I’ve found Hashlet, a secure authentication cryptographic device made for BeagleBone Black and Raspberry Pi by Cryptotronix. It looked interesting, it’s open source hardware, and I hope that Springboard users can take advantage interesting too, so decided to make a “remix” of the original board. It’s also good process to learning about hardware too! 🙂

A working Hashlet for Springboard, serial #1

Hashlet is based on the Atmel ATSHA204A chip, which is a “secure authentication and validation device”, with use cases such as:
• Network and Computer Access Control
• Key Exchange for Encrypted Downloads
• Authenticated/Encrypted Communications for Control Networks

The chip’s using the I2C bus, or a single-wire interface. Since Springboard front pin headers already give access to the I2C-0 bus and they are broken out on ProtoSpring, I chose that version of the chip. I2C is pretty simple in theory: just need a ground line, a clock line, and a data line to communicate; devices have addresses and can be talked to individually, while multiple devices can be on a single bus. In practice there are a lof of subtleties, though.

First run on the prototyping board

Prototyping Haslet with the ProtoSpring board

Since the chip required pretty much no additional electronics, it was pretty easy to set up. ProtoSpring also had a SOIC24 area, where I could fit the SOIC8 version of the chip. It worked, though barely. Looks like the SOIC24 footprint in the KiCad libraries are wider than the SOIC8, so the leads were just about touching the pads.

Other wires are connected to a socket that slid onto the pins I’ve already added (for another project) to ProtoSpring. This way the chip can be easily disconnected from the board, even if it stays soldered on.

Since it was my very first time with the I2C bus, I needed a bit of help with initial debugging: used Dangerous Prototypes’ BusPirate v4 board, which worked like a charm (after a firmware upgrade:). BusPirate could identify the chip, and begin to talk to it a bit, which is enough to know we are on the right track. It also has an “I2C sniffing” mode to log all the data passing through the I2C bus – unfortunately that function does not work at the high speed of the I2C on Springboard (100/400kHz, sniffing works up to ~75kHz).

Hardware Design

The electronic schematic is pretty simple, there’s only one incoming pin header, the ATSHA204A chip, and a debug pin header.

Hashlet for Springboard circuit diagram

It cannot be much more straightforward, and there are not many free parameters that I could adjust about the schematic. The only part that I could really adjust is the pinout of the debug  connector. There I used a recommendation I’ve read only about interleaving the clock (SCL)  and signal (SCA) lines with the power. This also helped a bit with the PCB layout.

PCB front layout and and functional description

The PCB is quite simple too, though there’s a lot more freedom for the designer. I wanted to make it as small as practically possible, but still making it useful. Most of the dimensions is set by the board-to-board connect header (2×7 set of 2.00mm pins), and the debug pins (1×4 row of 2.54mm/0.1″ pins). The IC sits squarely in the center. The PCB is has 2 layers, the top power plane is ground, the bottom is VCC (which is 3.3V in this case, that being the only power line available on this connector).

A couple of little features were added  for usability. I’ve added a hole (4.5mm dia) that can be used for keychain-mounting the final device. There’s also a labeling area, where the user can mark each device for distinguishability.

The whole design took about 2 days going back and forth about some layout choices. The source code (including the Gerber files) is available on Github, and is under CC-BY-SA-3.0 as the original Hashlet.

The final version, or v1, was printed by Seeed Studio’s Fusion PCB service. Took about a week together with delivery. Here’s the result:

Hashlet board view and somparison with a standard SD card

The assembly is not too bad, though I think I have a bit to learn to make good-looking surface-mount solder joints. 🙂

Software and usage

Cryptotronix has also written software to talk to the Hashlet and utilize all its functions over the I2C bus. Kudos for that, looking at the device spec sheet, I can barely imagine how big work that must have been…

Before I could use that, though, had to get through some hardware issues. By default the Springboard BSP sets the I2C bus to high speed (ie. 400kHz), and there I had difficulty reliably communicating with the Hashlet. After some discussion with the engineers, they gave me the right u-boot setting to switch to normal speed (ie. 100kHz). In the u-boot menu have to:

setenv wmt.i2c.param 0:0,1:0

To keep this setting over reboots, also have to do a “saveenv” afterwards. The meaning of the code is to set both the I2C-0 bus, and the I2C-1 bus to normal speed. Setting the former to normal, while keeping the latter at high speed would be “0:0,1:1”. The default is “0:1,1:1”.

With this change the communication became rock solid, and could start to experiment with the hashlet.

Testing the software, console log for a few commands

It can provide a random number source, can run MAC and HMAC-256, can store one-time-writable bits, and a lot more (see the Github repo’s description).

Future

Hashlet for Springboard is now available on Tindie.

I can think of a few hardware design improvements. Josh, the original designer of the Hashlet reminded me that it’s always good to have some decoupling capacitors on the power line. Also could add spots for optional extra pull-up resistors for possibly reaching 400kHz (one of the semi-hidden nuances of the I2C bus to get them right). Trying out the keychain hole, it could be possibly smaller a bit, and the PCB itself could be made thicker (e.g. 2mm instead of the default 1.6mm) for more mechanical strength if I think it will be used with keychains…

On the software side, I really hope to enable Hashlet on the upstream kernel, not just the BSP’s 3.0.8 version. I have an experimental patch to use VAB-600 with the latest kernel that goes some way towards this goal (enabling the board and the I2C bus), but the I2C-WMT driver still seem to need some work… Cryptotronix is also working on a kernel driver so the chip can be used without dedicated software (if I got that right), and that would be awesome for unlocking more of the potential of this board…

What would you use the Haslet for? Is there any other hardware you made for Springboard? Would love to hear anything interesting you made, just leave a note in the comment section!

Merry Christmas and Happy Hacking!

ProtoSpring, part 3: manufacturing and demo

After coming up with the idea in part 1 for ProtoSpring, the prototyping board for Springboard,  and creating the PCB in part 2, this final segment shows the end-result and a demo application – using GPIO to control a 7-segment display from an Android app!

Finished Prototyping Board

After finishing the v1 of the PCB, I’ve exported the Gerber files from KiCad and sent them to Seeed Studio. Looking at their specifications, some of the filenames they require were different from the ones KiCad creates by default (the board outline and the drill files need different extensions). It’s a bit weird,  but it’s easy enough to adjust before submission.

The board fits on a 5 cm x 10 cm base, has 2 layers, standard 1.6mm thickness, and didn’t bother changing the PCB colour to save some money on the manufacturing (though I bet the others looks very good too). The printing took less than a week together with shipping from Shenzhen to Taipei, and got 5 boards for about US$20:

ProtoSpring board straight from manufacturing

The board feels really nice and solid, and I’m almost surprised that it worked out so well on the first try (this is my first ever PCB!) After reviewing it, I’ve added a few changes for future print runs:

• moved a few of the ground-plane vias so they are not underneath any silk-screen text, that’s better for readability
  • changed the “2” in I2C into superscript, because it’s nicer (superscript font size is 60% of the base font of 0.03″)
  • added a “tested” silk screen pad to the the bottom, because it’s nice! The pad can be made with GIMP and imported by Bitmap2Component; size is determined by the fact that the import is 300dpi (i.e. a 300px width is 1 inch on the board)
  • moved the wires for the power and reset buttons, so they don’t cut a ground plane into half near the mounting screw

These are pretty much just cosmetic changes, but they feel right!

While the board was printing, I’ve ordered the required components from Mouser, and that package arrived just before the PCB got here. It was a great feeling that everything fit. Here’s how the board looks  assembled (with a few extra 0.1″ male headers for testing).

ProtoSpring with headers and other components mounted

The surface mount components are soldered really badly, hopefully next time it will be nicer. I was considering replacing the 0603 size components (two capacitors, a resistor, and an LED) with larger pieces on the PCB (0805, or 1206), but finally I kept them, just have to learn to do things better. Now I can test my reflowing skills fixing these ones up.

The board slides onto the Springboard front I/O pins very well, I guess the positioning was correct after all.

ProtoSpring attached to the Springboard

The first thing is to test the important parts of the wiring: the power lines and the GPIO! The test were done with a BusPirate v4, PirateScope, and the demo app on the Springboard Android system to toggle the GPIO channels.

Testing ProtoSpring GPIO lines

So far so good, we have a working board, now time for a demonstration.

Demo: SpringTap

I did realize quite quickly that coming up with a project is difficult, when the purpose is just coming up with a (or “any”) project. After a bit of brainstorming arrived to an idea of controlling a 7-segment display with the GPIO channels interactively from an Android app.  This probably covers the most common interesting use case of interactive physical computing – and everyone loves blinking lights! 🙂

Probably the GPIO channels could have controlled the display’s LEDs directly (it’s only 10mA each), but I like transistors and felt that it would be more correct too, so ended up with this design:

SpringTap wiring of the 7-segment display (click to enlarge)

All the parts required for this end up around $1.50 (or 45TWD). I bought a bunch of other components as well for some future projects I have in mind, and to “breadboardify” the prototyping board, but those are all optional.

Shopping at the electronics market

By the way, useful thing I’ve learned at the store today: “common anode” is 共陽, while “common cathode” is 共陰. That comes handy, when the parts’ part numbers are not easy to look up so I actually need to speak the language to distinguish between two components. I got the XDK-5161 BHLA common anode 7-segment displays (now I know that “B” means “common anode”, “A” in front as AHLA is “common cathode”).

Making into a breadboard for reusability

For reusability I breadboardified one side of the prototyping board, using single lines of 5-pin sockets. In hindsight, this is probably not a great idea. These sockets require thicker pins, and I ended up with a lot of debugging to find pins that look like they connect but in fact they don’t (e.g. the 7-segment display connected better after its pins were slightly bent inwards before plugging in).

Working in the electronics workshop

Another lesson learned from the setup is that the 10 lines for a prototyping board might not be enough for even some simple projects. Instead of just plugging in components, I had to solder the resistors onto the transistors’ base, otherwise I didn’t have enough sockets to just plug them. Maybe a 10 cm x 10 cm board, or creating all-separate pins instead of the current 5-together rails could be a good idea for version 2. I’ll wait for some feedback on that one, it’s not very difficult to change either way.

Testing the wiring using GPIO

After confirming the wiring with the GPIO test app, time to get down into programming the Android app that will drive our display.

Programming SpringTap in Android Studio

Keep in mind that it’s a marketing guy’s level of programming, and all done in about a day with a lot of copy paste, but the end result is SpringTap: the screen is divided into 9 different, vivid coloured segments, and as mouse is moved over them, the 7-segment display shows which segment the mouse is in:

The segments lighting up when the cursor is in the different areas of the screen

And here’s the end result:

The source code of the demo app is available on Github, and it’s using the VIA SmartETK to control the GPIO pins, the API manual for that is online, though it is not the final version, the API is still evolving.

Getting your own ProtoSpring

If after all this you are interested in getting your own ProtoSpring, there are two ways:

First, because the design is under CERN Open Hardware License, you can print it yourself: the schematics and PCB are available on Github, the version in this article is v1. The Bill of Materials is shown in the Readme and in the schematics.

Second, if you just want to get one, I’ve listed the board on Tindie, the indie hardware marketplace. For this November to promote prototyping, it will be listed at material cost only ($5 for the board, and about $15 for the parts and sockets, especially the sockets), with free shipping. It can’t get much easier than this!

Lesson learned

What a ride this was… Did my first PCB, printed it, assembled it, and created an app and interactive computing setup. It’s an amazing experience, and shows how easy it is now to expand existing hardware with additional accessories, on demand. If you want to make your own extension board for the Springboard that does something different, here’s a blueprint of the things you need to do. If you do that, would love to hear about your project!

Now, onto the next electronics project….

ProtoSpring, part 2: schematic revision and PCB

In the first part of this series I’ve outlined the idea of making a prototyping extension board for the Springboard, and finished with a rough schematic. Since then I’ve revised the schematic based on experience, and laid out the prototyping board PCB.  By the end of this write-up we’ll have a complete design, ready to send to manufacturing.

Before I dive in, probably the single most important lesson learned is to keep in mind all different stages of a board design. There’s a lot of back and forth between schematic, components, footprint, layout, manufacturing specs. The tools help making the right decisions, and often when something feels difficult it is because I’m doing it wrong…

Finding crucial parts

After making the basic schematic I realized that there’s one type of component on the board that can make or break the entire project: the board-to-board connectors. To interface with the Springboard needed to find 2mm pitch, dual row, through hole, perpendicular mounting female receptacles. I couldn’t find anything like that in the local electronic stores. After an hour of search online they did turn up, fortunately both Digikey and Mouser had the required 3×2, 4×2, and 7×2 connectors by 3M.

Finally found the correct 2mm, double row, perpendicular, through-hole connectors I needed

I got a bit lucky too, because these ones can be ordered piecemeal, while other pin count versions (e.g. the 10×2) require minimum order of 300 pieces. This is one of the first example of the importance of choosing components. Of course, if these were 0.1″ (2.54mm) connectors then there wasn’t any problem finding them in the first place, but then they would probably not fit on the Springboard itself…

To choose a fuse I took inspiration from Arduino. Their earlier boards used resettable polyfuses, so I chose one from the same line from Littlefuse, with 1A hold current and 1.8A trip. They have a pretty big footprint (1206).

The only other components I needed to check were the decoupling capacitors. I used a 10uF tantalum (polarized) and 0.1uF ceramic (non-polarized) capacitors. The standard capacitor footprint is 0603 size, and I was wondering why I couldn’t find a polarized capacitor footprint for that size in the KiCad library? When I searched Mouser for capacitors it turned out that the 0603 tantalum capacitors are pretty darn expensive, while actually the larger 1206 size is much cheaper – and it has a polarized footprint in the default KiCad libraries! Again, the wisdom of other engineers guide me home (when I listen)…

Revising the schematic

The schematic revisions were not done in one go, but as I learned from the PCB layout. I’ll still summarize things in one go for clarity.

Revised ProtoSpring Prototyping Board Schematics (click for full size)

The very first thing I needed to add is the breadboard connectors. KiCad makes it pretty much impossible to create the correct layout, unless they have the logical units assigned to them on the schematic. So I added a new element for each row of the breadboard: 5V/GND on one side, group-of-5 pins, another group-of-5, 3.3V/GND on the other side. That’s the large block on the bottom of the schematic.

Had some typos in the GPIO pins that I realized when wiring up the PCB.

I’ve also redefined the pin numbering on the incoming connectors. Before I used the same number here as it is on the Springboard’s pin definition in the docs for the front panel, GPIO, and audio pins, meaning “pin 1” on one side is “pin 1” on the other. This didn’t take into account that one is a source, other is the receiver and their layout is actually mirrored, making the numbers different. I struggled with the PCB layout but I realized because I was trying to “transform” the receiving connector. In the end I went back to their default alignment and redefined the pins instead. Output the netlist, load the netlist again, and everything should be connected correctly. Some of the other connectors were adjusted to be more logical too.

PCB layout

Needed to make some new footprints for the 2mm pin arrays, fortunately that’s pretty easy. Taken the example from the existing pin arrays, matched to their documentation from Mouser, and was done in a short time.

Creating footprint for the 2mm connectors

Placing these connectors is pretty much the only critical alignment issue I had. The locations can be read off the documentation:

Pin positioning for the Springboard (click to enlarge)

The centers of the headers are 11, 75, 87mm  from the left edge. The distance inwards is defined by the size of the pin header assembly, and they list 4.9mm from the front to the first row of pins. I’ve placed it the pin array 3.5mm inwards, leaving a bit of gap. Will see from the first production run whether this needs to be adjusted.

That gap is quite small, though, and I ended up with a Ground pin on the GPIO connector that I couldn’t possible connect to the rest of the ground plane. Fortunately through the other connectors there are 4 other Ground connection between the boards, so I set that Ground to no-connect. Should not affect functionality

PCB layout end result with all layers (click for full size)

In the footprint designer then placed the pins with appropriate spacing between the groups. The sizing and spacing information I got from the Electronics Stack Exchange,  and modified a little to fit on the 100x50mm board that I was aiming for. The pin spacing is 0.1″, and the unit of spacing is 1 pin. There’s a gap of 1 unit between the power pin group and the central group (smaller than the Stack Exchange post), and the middle gap is 2 units.

I’ve set up some custom design rules to help with the layout. The power lines (5/3.3V) had wider trace, and the breadboard pins between themselves too (0.800mm instead of the default 0.254mm).

Most of the routing was done manually. I’ve used FreeRouting autorouter from Github for the GPIO and audio pins. It came up with very similar design than I did first manually, but a bit better distributed – except for 2 cases of design rule violations that I fixed by hand. I know that generally shouldn’t have bunch of parallel lines to avoid crosstalk, In this case I kind of had to, and since most of such lines are used for digital I/O I’m hoping that the crosstalk will have negligible effect.

The unused areas on the front and back were set to be both ground planes. The breadboard pins act like cross-plane vias for most of the board, but I’ve put some vias around the GPIO pins for better cross-plane connectivity and better fill in some areas. This might be overkill for the board, but we’ll see.

I found that KiCad can do 3D rendering of the board as well. Here’s how it looks just for reference.

Fun! 3D rendering of the resulting board, front on top, back below. Note: some 2mm pitch pins don’t have the right pin count on these pictures because I haven’t modified their the 3D file

I’ve added the Open Source Hardware logo to the back, using the scalable KiCad version of the logo I’ve found online. I was thinking to add a “tested” patch because it looks good and it’s good to use, but that these silk screen logos seem to be quite a bit of work. Maybe later…

Next step

Design finished, Gerber files exported, now the design is ready for manufacturing. I was considering OSH Park in the US and Seeed Studio in Shenzen for that that. OSH Park is a community printing service and it’s really cool that I can upload my Gerber files and their site shows how the board and the different layers will look like. Very good for sanity check…

OSH Park rendering of the board Gerber files pre-order

Seeed is closer to here and seems cheaper/faster too. They somehow ask for different Gerber file naming convention (for the drill files and the edge cut in particular). Will have to do a bit more research.

The next step is check everything one more time, submit for manufacturing, and order the components in the meantime. In a future post will show the result and hopefully the boards in use. Now time for coffee…

ProtoSpring, part 1: Idea and Schematic

I was looking for a project to showcase how easy it is to extend the functionality of the Springboard platform, drawing inspiration from the expansion board that is bundled in the kit.

Springboard and expansion board (top), from klinger.net

The expansion board connects to the main board with a couple of pin headers (power, GPIO, sound) and cables (USB) to break out some of the functionality to easy to access connectors, such as the regular speaker and mic plugs, two USB, on-off button. It should be easy to replace that board with another to provide different functionality, so I’ve come up with an example.

Idea

Based on my experience with prototyping on breadboards I thought a breadboard extension could go a long way to help Springboard with hardware projects. Thus the idea of ProtoSpring was born: break out most of the same lines that are accessible on the headers, and arrange a practical grid structure to mount components on. Here’s an artist’s impression of how it might look:

An artists impression of the ProtoSpring board layout

Of course this can be done in many different ways, and I’ve seen prototyping boards with a large variety of specialized regions, for example space for SMD components, different buses… This version 1 of ProtoSpring will probably be the simplest usable design I can come up with.

Schematic

I’m using KiCad for electronic design, mostly picked up while doing, and by Contextual Electronics’ KiCad video series.

Since I don’t expect many components on the board, just wires, basically, I could just go straight into PCB layout mode and draw it from scratch. What I’ve learned from discussing electronics with people doing this for a living it does help to still do a schematic, even if it’s very simple. Good to keep things organized and understood.

The schematic in this case has two main parts: the input connectors, and the output connectors to hook up ProtoSpring to the Springboard. The breadboard structure will still need to be drawn one-by-one (unless I come up with a better way of representing its lines).

The pinout of the front panel, GPIO, and audio headers come from the VAB-600 documentation. I added two fuses for the 5V and 3.3V power lines (just in case!). I’m using KiCad’s labeling function to give names to the pins and no need to pull wires across the board to connect the different pins: nodes labeled the same are considered to be connected.

ProtoSpring Prototyping Board Schematics (click for full size)

On the output side I was hesitating whether to add breakout section for the front panel and the sound, but since I can’t predict how people will use the board later I might as well just add them, and keep them simple.

The main attraction is power and the GPIO pins. I thought I give a pair of pins for each GPIO channel instead of just a single pin, in case they are used in more than one part of the protoboard. I’ve kept the I2C pins singular, though. I’d guess their signal is used at maximum one location at a time.

The files so far are online in a Github repository,  and the PDF version of the schematic is on Slideshare (can download too) (Updated with new version!).

Next step

The next step is now figuring out suitable footprints for the elements, and start laying out the board. This will be written up in part 2, so stay tuned! Edit: Part 2: revision and PCB is now live.

Do you have any suggestions on how the protoboard should look like? Something I should include? Would love to read your comments below!

At a Freescale developer event in Taiwan

Here at VIA we like to learn from others, and our ecosystem is full of very successful examples we can learn from. Just like we were very happy to see RaspberryPi in Taiwan recently, this week we’ve joined the “Designing with Freescale” developer event in Hsinchu.

Freescale developer event in Hsinchu, Taiwan

Hsinchu is probably a very good choice of a place, as it has the largest concentration of technology companies and industrial research in Taiwan. This is in some contrast to that local tech startups are concentrated in the capital, Taipei. There’s a lot of difference in scale and resources; at different scale teams require different things (naturally).

This developer event was focused in getting across the vision and expertise of Freescale, from their microcontroller line (and vision of their use in IoT) to their powerful ARM microprocessors. VIA has a couple of very successful boards that use Freescale in the core, like the recent VAB-820 and was very interesting to put things into context. Lots of companies, other Freescale partners represented themselves, and was eye-opening to hear how differently people approached the same hardware because they wanted to use them differently.

A day of technical talks

Besides the technical talks, there were almost a dozen stalls with partners exhibiting their solutions. I think the main keywords were Internet of Things and Home Automation. Lots of experimentation is going on in that space and while the starting point is pretty much the same for everyone, the solution they come up with have a crazy variety. Can’t wait to see more of these ideas in action and in the devices and buildings around me.

Product showcasing

Talking to different teams I was amazed how different paths teams take. Almost as many different attitudes to licensing, hardware choices, business models, customer relations as people I met. This chaotic environment on the other hand inspires a lot of exploration. Ever since the event I’m rehashing what our team can learn from the real-time OS vendors, the digital signage companies in Singapore, component makers, large scale IC manufacturers, all of whom had interesting insights to offer.

Looking at the big picture on the apropos of this event, not every company is aiming at enabling a thriving ecosystem around what they offer, it is a major undertaking. But when it works, it’s a sight to behold, and a much needed force multiplier for all partners involved. We are very glad to be part of it and contribute!

VIA is in a very special position, though. It had evolved a lot in the last two decades or so, and doing vastly different things now than used to. When I’ve talked to them, people wondered at this event why are we there. A bit of intro to our vision, to our online store, and to this site, and I invariably received big nods of understanding. It felt very good to get on the same page this quickly, while it is very much an opportunity: we need to communicate clearer not just to our customers, but to our industry partners as well to unlock the potential that an ecosystem brings. Lots to do ahead!

Onboard connector: PCI Express Mini Card

I’ve been converting a lot of our boards’ documentation from PDF to web accessible form. It is a very hands on project, and I have a better feel for the hardware options available. One of the parts I’ve discovered to be potentially quite interesting is the onboard PCI Express Mini Card slot on the VAB-600 (as well as on a few other boards).

mini-PCIe related parts on the VAB-600 board

After asking around in our engineering department, it turned out that this slot (in short form “mini-PCIe”) was added with a few very specific application in mind, especially networking related.

Differences

The first thing that took a bit of clearing up is that such mini-PCIe slots can have quite a bit of variation in how are they wired. Besides the PCI bus, there are other (USB, I2C, …) lines defined, and one can come across a few different variations: • fully implemented PCI bus and other buses (I guess it’s quite rare in embedded) • no PCI, but still have USB, I2C,…. • custom PCI where pins normally belonging to other buses are redefined • everything redefined to custom connections… Springboard belongs to the second category: no actual PCI bus, but still have all the other connections, and designed mostly for the USB interface.

mini-PCIe connector schematics

This enables using internal USB devices that don’t take up external connector space, and are also quite a bit more rugged. Cards that I’ve heard to potentially work include 3G/GPS (like VIA’s EMIO-2550), Wifi, Bluetooth functionality, as well as very basic USB extension board. For more details, you can check the actual pinout either in the Springboard User Manual, or the VAB-600 wiki page.

Makers

What makes this quite excited about this connector, that someone could design any other type of extension card that fits onto the specified 51x30mm area and communicates over USB only: Arduinos, TV-tuner, mesh networking, virtual keyboard/mouse, … The limit (besides the physical space available) is one’s imagination. One can create the relevant hardware, mount it on the board that can be safely enclosed, and the capabilities of the Springboard can be extended. In a way, this is quite a bit maker friendly. The specifications of the PCI Express Mini Card are relatively straightforward, even if quite a lot to digest. After a few days most of the things do make sense for me now, and can’t wait to design something cool for my springboard. It also helps if a piece of hardware works across different devices. In the VIA lineup the APC Rock, VAB-820, and VAB-1000 also has suitable connector.. The APC Rock only accepts half-sized mini-PCIe cards, while the others accept both half- and full-sized ones. Outside of VIA I’ve seen quite a few more ARM boards that have mini-PCIe as well, though some are weirder than others. The Freescale Embedded Board Solutions list have a bunch of boards that mention mini-PCIe, there’s Matrix (with the card hanging off the board, not sure how does that work), and Sabre Lite (I think through a daughter card).

Future

I’m spending time designing a USB or I2C enabled mini-PCIe, hopefully one that does something useful, and can be used in a real computing setting. Have you ever created a mini-PCIe card? Let me know, how did it go! Are you an user of mini-PCIe? I’m curious what are the pros and cons you found using it!

Smart Garden Showcase

The VIA Smart Garden is a small Springboard controlled garden, that was developed as a automation demo. It was was mentioned on this blog before, though very briefly. Later this month, along other VIA products, the Smart Garden will visit the Embedded Systems Expo & Conference in Japan. This is a good opportunity to take another look at the project and and give a more complete picture of how was it made.

Hardware

The Smart Garden uses a lot of small equipment. The choice of those hardware, and the way to control them is the key to makeing this project useful and interesting.

Smart Garden prototyping setup

The shopping list is:
• Arduino relay board, here we’ve used the Keyes Funduino 4-channel opto-coupled relay board
• USB powered spotlight, any model will do
• USB powered fan, any model will do, we had an Eiffel tower fan, so it doesn’t need any scaffolding, bought from PC Home
• Mini water pump, uses up to 2A@5V
• Mini garden plumbing
• USB power supply at 5V, used for the water pump
• Humidifier/fog creator WB-P2425FX, uses 24V
• wall power supply at 24V, used for the humidifer
• a VIA VAB-600 Springboard
• Plants (I believe these were Syngonium podophyllum, though anything sturdy will do – hardware hacking is hard on plants!)

Optional parts include a Wi-Fi router for networking, display for atmospheric background, and speakers for ambient frog croaks.

Hardware assembly

Controlling the garden hardware (light, humidifier, water, and fan) was done with an Arduino relay board. Originally we wanted to build a custom relay board, but this was just much simpler and well tested. The included opto-couplers are a nice bonus, those protect the Springboard from any electrical problems in the garden.

Smart Garden hardware control

The most complex part was arranging power for the different parts of the project.

The relay board receives its 12V from the Springboard, which uses a 12V supply and has 12V power-out as well (the white connector on the bottom side of the Springboard on the picture). The USB lamp and fan receive their 5V supply from the GPIO pins, ground is also through these pins. The water pump has to have its own power supply because it draws 2A  current, which is more than what is allowed from the GPIO pins. The humidifier also has a separate power supply because of its 24V requirements.

When all of these were sorted, 4 GPIO pins from the Springboard were connected to the relay board, ready to turn the equipment on and off, and create “weather”!

Software

The next step was to set up the software for the Smart Garden. Springboard has both Linux and Android support. For this project, the choice has fallen on Android. There’s a lot of interest in Android automation solutions and we wanted to show VIA’s capabilities.

The control software takes care of a few separate things: controlling the hardware, providing a user interface, and managing multimedia.

The hardware control of the GPIO pins is done using the VIA Android Smart ETK, which exposes those pins through an API to apps running on Springboard.

Controlling the Smart Garden over the web

Then there are two user interfaces, one is through the built in web server of the Smart Garden Android app which allows it to be displayed over the network, on a website. Multiple devices can connect, monitor and control the garden’s hardware. The control is done through an intuitive graphical environment that feels very cozy. For example when the light is turned on, status updates are reflected in all connected browsers.

Optional ambient background and control panel

The other interface is the screen plugged into the Springboard, which displays a variety of wallpapers, as well as control buttons to turn the lamp (“Sunshine”), fan (“Wind”), pump (“Wind”), and humidifier (“Fog”) on or off. As an added bonus, the app also plays some nature sounds such as frogs croaking or birds singing, which I found as a very nice touch. 🙂

Here’s a quick look at the Smart Garden in action:

Future

Connected devices that constitute the Internet of Things have practically infinite potential. This project for example could evolve to include sensors such as ambient light or soil moisture sensors, and automate plant maintenance with a feedback loop. It could also include a webcam to virtually visit your garden wherever you are in the world, or take snapshots of your plants growing. There are also talks about scaling the garden up and allows it to take care of the maintenance of the greenery in front of the VIA building…

How about you, do you have any plants at home that need a bit more care?

A big thanks to Max Chen and Terry Hong who built this Smart Garden!

Enabling Arch Linux ARM on Springboard

Arch Linux is my favorite Linux distribution of the half the dozen I’ve used. It has cutting edge packages, a rolling release (instead of fixed releases it keeps everything always up to date), the best package manager I’ve seen (pacman), an amazing community & wiki — and also ARM support. This last point does matters for Springboard and is the main topic of this post.

The original Linux Development Package for the Springboard uses Debian, and after all the exploration I did recently, I wanted to figure out if I can install Arch Linux instead. This write up is a hopefully detailed, and definitely very technical guide to what I have done to get there.

A quick intro: the VIA Springboard is a Pico-ITX form factor (10cm x 7.2cm) 800MHz ARM Cortex-A9 SoC with 4Gb integrated storage, IGb RAM, HDMI out, 8xGPIO, and support for TTL/LVDS screens too, including touch-screens.

The ingredients

Preparation

On the hardware side I needed:
• Springboard
• an SD card ( above 1Gb should be already good)
• a male mini-USB to female USB converter
• an USB hub
• USB keyboard and mouse
• screen, (and because I use VGA screen, a mini-HDMI to VGA converter)

On the software side let’s start with the Linux Development Package v1.00.00 from the software development packages page. It’s a zip file which has all the kernel source, the toolchain, the installation files, as well as the documentation to how to use all these. Highly recommended to poke around in there, see what’s available.

Kernel compilation

Based on my experiments, for Arch Linux to work I had to to recompile the kernel. The detailed description on how to do that is in the Development Guide pdf inside the dev pack (for convenience, it’s online too).

First I needed the cross-compiler toolchain for ARM (in the BSP/ToolChain directory in the dev pack). To make it easier to install it I’ve made an Arch Linux User Repository (AUR) package called arm-toolchain-springboard.

The BSP/Kernel_Source_Codes directory in the dev pack has the kernel sources (3.0.8), the graphics kernel modules precompiled (binary only), and the basic config file (VAB-600_Linux_defconfig). I have unpacked the kernel sources and the graphics modules in the same directory, and copied the configuration to “.config”. I usually do my changes with “make menuconfig”.

Kernel configuration with `make menuconfig`

As I checked, the minimum required change for Arch Linux to run is to enable “Control Group support” (with pretty much everything inside enabled and compiled in), and “Automatic process group scheduling”. I’ve posted the .config I’ve used online.

After all these changes, ready for compilation. The kernel source zip has a file called “toolchain_setup” to set up the environment, and then run the kernel compilation as

make ubin CROSS_COMPILE=arm_1103_le-

When that command is finished, I had a brand new  “uzImage.bin” file in the kernel directory: the kernel image needed for the further steps.

Installation media

Now I could set up my installation media, based on the original installation instructions at EVK/Update_Package/README.txt in the dev pack. In a nutshell, copy everything from EVK/Update_Package onto a FAT formatted SD card. That includes “scriptcmd” and the “bspinst” directory.

I’ve done the following modifications:
• Replace “bspinst/uzImage.bin” with the newly compiled version from the previous step.
• Remove the tar-gzip compressed root file system image from “bspinst/packages” (the only file there).
• Download the latest Arch Linux ARM armv7 root image, change the extension from .tar.gz to .tgz (peculiarity of the install scripts), and place it in the “bspinst/packages” directory.

That should be all that’s strictly necessary, though I added two added bonus steps. First, if using VGA monitor (via the HDMI to VGA converter), looks like I had to explicitly specify the screen resolution in the configuration file, otherwise the display will be messed up. In my case the monitor is 1280 x 1024px at 75Hz, thus in “bspinst.cfg” in the section “<b>[tpevb]</b>” I had to change

setenv wmt.display.param 4:6:1:1920:1080:60

to

setenv wmt.display.param 4:6:1:1280:1024:75

This should not be needed with HDMI monitors, and wide screens.

The second one is a mere cosmetic change. The “u-boot-logo.data” file turned out to be a BMP image that is shown during the boot. Replace it with another BMP image, and you have your unique splash screen on boot! Design it for black background for best visuals (unlike the photo I used in an earlier post).

After this, I’ve plugged in the SD card, power up Springboard, and in 10-15 seconds or so the new install began in a very obvious way (blue screen, large white lettering). The install took 2-3 minutes in total. When that finished, remove the SD card, the board shut down automatically, and was ready to reboot into my new system.

Some troubleshooting notes:
• If the install hasn’t started after 30 seconds or so, but the splash image is showing, then likely the kernel (uzImage.bin) is not quite right. Can put back the original one onto the install media to debug.
• If the screen is scrambled after the splash image, just leave everything running for 10 minutes or so, remove the SD card, and reboot. The install should be finished correctly regardless of the display during the procedure.

In the new system

If the system boots properly after this, then everything is on track, and ready to make myself at “~/”.

Screenshot of Arch Linux running on Springboard (click to enlarge)

Springboard has 4Gb onboard storage, enough for the Arch Linux base system together with graphical environment and more. I will have to check out how can the home directory be moved onto an SD card for extra storage.

One thing to note. The system thinks that it has one kernel installed (the one comes with Arch Linux), while actually it has another (the one we compiled). The kernel and boot files are stored on /dev/mmcblk1p1, and can be updated through there.

Ready for more?

This is just the first step down the road to get to a properly functioning, optimized, stable, and upgradable Arch Linux system. Hopefully it will be interesting enough for the community to keep exploring and improving on these procedures, and Springboard can be a proper member of the Arch Linux family.

This procedure should be also applicable for other Linux distributions that use a root file system image for installation. I wonder which distribution would be interesting to check out next?

A new Android in the VAB family

Springboard (VAB-600) isn’t the only ARM board in the VAB lineup that supports Android. Its “brother”, the VAB-820, just got it’s own, brand new Android Evaluation Package.

VAB-820

What the VAB boards have in common is the aim to be small, efficient, and powerful when they are built into a project. Hence the shared Pico-ITX form factor and integrated ARM architecture. What they have different, though, is the ARM SoC itself. While Springboard features a VIA ARM Cortex-A9 processor, the VAB-820 has a quad-core Freescale i.MX 6Quad ARM Cortex-A9 SoC.

The VAB-820 is one of the few Freescale boards on the market that can run Android. Such a combination of hardware and software is very interesting, bringing together a good, familiar interface, easier software development (apps), and some serious reliability (including a wide operating temperature range from -20°C ~ 70°C). You can find the detailed specs of the board on the VAB-820 product page.

I’m not surprised that VAB-820 is aimed at in-car systems and industrial applications (among other things). VIA has also contributed CAN bus support within Android, which can be especially useful for cars.

Springboard and the VAB-820 are aimed at a different crowd, but I’m excited about the interaction between them and the rest of the VAB family. I also hope I can get my hands on one of the boards to run an Android benchmark on that too. 🙂

This entry was posted in VIA Embedded and tagged Anrdoid, VAB-820, VAB on April 23, 2014 by Gergely Imreh.← Previous Post

A survey of ARM operating systems

A piece of hardware without the software to run on it does not do much good. I can have the best piece of computing equipment if there’s no operating system to boot it.

With all their advantages, each ARM CPU still requires some effort on the side of operating system maintainers before the hardware and software can work well together. Fortunately there’s a very active community,  lots of accumulated developer knowledge, and many choices.

I collected a non-exhaustive list of operating systems for ARM processors, with a preference towards those that are interesting for VIA Springboard.

Linux

Linux supports an amazing variety of computing hardware, and now often that is the first system available for new development boards. With ARM each new processor needs a new driver too, thus usually there’s only one or two operating system is available at first. Fortunately support for one distribution often find its way into others.

The Springboard development pack is based on Debian, which is a distribution with a long track record of stability. I’m writing this article running that Debian development system. It aims to provide a sense of safety using well tested packages. Other distributions sometimes base their core on Debian too.

On my personal computer I’m running Arch Linux, a distribution that is in some sense the direct opposite of Debian. It is on the bleeding edge: many software package is available on the day of their release, and the system’s development is moving quickly. It has a great community, and the Arch Linux Wiki is one of the best sources for all thing Linux. The Arch Linux ARM version supports many ARM boards, from Raspberry Pi to Beaglebone. I would love to see Springboard among those too – it would be one of the most powerful boards in the list.

Raspbian is the Raspberry Pi + Debian system. The original APC board was running it too. This system has a narrower focus than the previous ones (supporting Raspberry Pi), but turned out to be a good base system for other boards too.

FirefoxOS is an up-and coming candidate. The new APC boards are running it too, and I’m looking forward learning more about it.

Ubuntu is probably the most widely known Linux system. It’s not surprising that there’s an ongoing Ubuntu ARM development as well. Their focus seems to be more on the server side than on the desktop/user side.

Android has to be on this list. It has done an amazing job standardizing operating systems for the embedded world, and I feel that there’s a lot more to come. Besides Debian, the other development system for the Springboard is Android 4.0.3, that I’m having a lot of fun exploring as well.

Among the more purpose-built distributions  there is Open Embedded Linux Entertainment Center (OpenELEC), which does what it says: turns a computer into a media center. With the ubiquity of boards like Springboard and our rampant media consumption, there’s definitely a lot of opportunity in this.

This is absolutely not the complete list of Linux distributions supporting ARM. Hopefully it is still adequate to start exploring the ecosystem.

BSD

Besides Linux, the different BSD flavours are among the most widely used open source operating systems. My first *nix system was FreeBSD back in high school, so I’m really happy to see the FreeBSD ARM project. OpenBSD is focusing on openness and security, qualities that are always welcome in the computing world. NetBSD/evbarm is targeting ARM based evaluation boards.

Other

For certain use cases it is worth looking beyond the above open source and mostly general-use systems.

Windows RT has the disadvantage compared to the previous systems that it’s only available preloaded and only on specific devices. It can however tap into a whole different ecosystem both in software, and apparently in supported peripherals.

QNX Neutrino and FreeRTOS are real-time operating systems with ARM support (and also specifically with Cortex-A9 support for the likes of Springboard). For industrial computers, medical computer,  scientific/laboratory work, possibly for certain media applications these can be interesting choices.

Plan 9 from Bell Labs has probably the quirkiest name and intriguing circumstances. It is primarily a research system, and gave us a lot of interesting technology. It has a Raspberry Pi port, so I guess it should be possible to cover other boards too.

Epilogue

There are really a large number of possible systems, while there are still a plenty of hurdles. A lot more work needs to be put into supporting existing and future systems to unlock all that potential. I feel that the deciding factor between different boards will be the amount of support they get, not necessarily the raw available power or awesomeness of their hardware.

Springboard is still very young, and while as of now it runs Debian and Android, I can see a lot of exciting opportunities for different use cases and different systems.

And with this, we are back at the community. What OS would you like to run on your Springboard or other ARM device? Would love to hear your thoughts in the comments.

Ps: a very happy Easter to you all!

This entry was posted in Springboard Blog and tagged operating system, Linux, Android on April 21, 2014 by Gergely Imreh.← Previous PostNext Post →