viaspringboard.com

Mini-PCIe microcontroller and make your board too

All VIA’s current ARM boards (VAB-600, 820, 1000) have an online mini-PCIe connector, and I’ve been planning to do something interesting with that for a long time (see this intro post from more than a year ago). Thus I’m very happy to introduce the PCIeDuino – mini-PCIe form-factor Arduino-compatible microcontroller, which can add a whole new set of I/O capabilities to these ARM “carrier boards”.

PCIeDuino under the magnifying glass

I have just recently finished this board, and been able to test it briefly with Springboard and also with the VAB-820. The picture just below shows the shining blue LED, that is tied to D13 – the 13th digital pin, as most Arduinos do.

Sign of life, working with Springboard

Blinking LEDs are good to ascertain life, but electronics like this should do something more useful too!

Hardware

I have written about the PCIeDuino hardware in a lot more detail elsewhere; in a nutshell it is a remixed version of the Sparkfun Arduino Pro Micro 3.3V. It is built around an Atmel ATmega32U4 microcontroller, and breaks out all 13 digital I/O pins, 6 analog input pins, as well as PWM, Serial, I2C, SPI functionality.

PCIeDuino functional diagram

While Arduino boards can already be connected to any system that uses USB, this card has the advantage of being screwed onto the base board, so accidental disconnection is not possible. That should make PCIeDuino more reliable companion for embedded systems, where reliability trumps pretty much any other criteria.

Experience

So far I feel the PCIeDuino is a mixed success. The hardware works quite well, the software needs (a lot) more work, though. Originally I wanted to create an Arduino-compatible board, so the standard Arduino IDE could be used to interface with it. Unfortunately, the IDE is lacking some support on ARM boards, so even if this board is ready, the upstream functionality is not quite there yet. The whole system is usable, but definitely a “developer” setup, requiring manual care – and some patience. 🙂

PCIe is predominantly used for communication purposes between the embedded systems. It contains around 32 lanes between the two devices which are connected for network interaction. A lane contains two signaling wires so that if two systems are connected, then there happen four signaling wires.  PCIes are the best ever options for board integration as it can be plugging in very easily as same as USBs. It can be as strong as an anchor for the entire system.

Now the likely next step is creating some demo use cases with the board; I’m just brewing up some interesting automation and industrial projects. If you have any suggestion what would you use an ARM board with an onboard Arduino, would love to hear!

PCIeDuino is available on Tindie, the indie hardware marketplace. It’s open source hardware, released under the Creative Commons Attribution (CC-BY 3.0) license, just as the original Pro Micro was. The whole design was made with KiCad, and the design files are available on Github.

Make your own mini-PCIe board!

Still, I wanted to take this one step further. My first aim with the whole PCIeDuino project was to show how easy it is to make your own mini-PCIe hardware to extend the functionality of these VIA boards! Now that I see what did it really take to do just that, I have put together a small “base board” kit for mini-PCIe, so everyone could do their own compatible accessory as easily as possible.

miniPCIe baseboard design in KiCad

The base board kit is available on Github as a KiCad project (library, schematic, and PCB outline). I used KiCad because it’s also free and open source, to keep in the spirit of openness – and it’s a pretty good design tool as well in my experience.

If you create any new boards, would be great to hear! If you have any questions, can leave it in the comment section below.

And in the meantime, it’s another weekend coming up, another chance to hack on interesting hardware projects! Have fun, everyone!

Going Real-Time with Xenomai on VAB-820

It has been quite a few years since I’ve last used Xenomai, the real-time application framework for Linux, during the work on my thesis back at the university physics lab. When I’ve found that the VIA VAB-820 board is listed on Xenomai’s compatible hardware page, it brought back a lot of interesting memories and I got excited trying it out again. Now that the new (testing) kernel for the VAB-820 is released recently, I thought it’s a good chance to revisit real-time operating systems.

Setting up

Buildroot is a very handy tool to build a kernel and simple file system for embedded devices, and just recently accepted our submitted patch adding support for VAB-820. Buildroot already has support for Xenomai, so everything’s set up to create a system complete with the required patches & tools.

Running xeno-test on the VAB-820

One outstanding issue was a bit of adaptation. Xenomai (at least the stable 2.6.4 version I targeted) needs a suitable Adeos I-pipe patch applied to the Linux kernel, which enables secondary real-time kernel on the same hardware (see the Xenomai FAQ). The closest kernel version that had an available patch was 3.10.18, and I’ve backported that to the 3.10.17 kernel used in our latest release (can download the patch from Github).

The kernel is nothing but the operating system which plays a vital role in the computer system and its purpose is to boot up the computer system in a proper manner. When Linux got outdated and it was not able to cope up with the requirements of the applications, Xenomai was introduced and it was chained with Cobalt. Cobalt is a real-time infrastructure which can do all the activities without the support of the main kernel. We all should agree with the new development in the technological field and make use of all these things in the right way.

After this comes setting up Buildroot. Besides the base configuration for the VAB-820, I had to add the following changes:

• Kernel -> Linux Kernel Extensions -> Adeos/Xenomai Real-time patch(and add path for the downloaded patch file linked above
  • Target packages -> Real-Time -> (add your required Xenomai userspace skins; add test suite optionally)
  • Enable netcat in the busybox configuration (“make busybox-menuconfig”) if want to use network load in testing (optional)
  • Enable Target packages -> Debugging, profiling and benchmark -> ltp-testsuite for load testing  (optional, just need hackbench provided by that package)

This is not an exhaustive list, there are some dependencies (including the toolchain, I used the latest eglibc), but the required choices are quite obvious during the Buildroot setup using “make menuconfig”.

Now I can run make, wait for the compilation to finish (~30 minutes on my laptop), prepare an SD card with the new system, and boot up your VAB-820 or AMOS-820.

Running benchmarks

Of course I want some proof that the system is really running in real-time mode. The Xenomai knowledgebase has a pretty straightforward article on benchmarking with xeno-test, used that as a base to set up my testing environment.

I’ve connected the VAB-820 to the network, and the testing was run xeno-test like this, explained below:

xeno-test -l “dohell -s SERVERIP -p PORT -b PATH-TO-HACKBENCH 7200” -g results

dohell is a script that generates load for the latency benchmarks. If there’s no load, it’s very easy for a computer to do things reliably on time, the whole point of real time systems is delivering regardless of the load.

The dohell script can use a couple of different sources of load. For example, if provided with the “-s SERVERIP -p PORT” parameters (fill in the blank for them), then it generates network load. It needs netcat (nc) to work, and the easiest way I found on the other end to set up a server receiving the load is to run a simple network sink on the server on the port given to the script above:

nc -v -v -n -l -p PORT >/dev/null

Other load include is loading the CPU: that’s what hackbench is used for, “-b PATH-TO-HACKBENCH” tells the script where to find that tool.

Also have to tell the script how long to run, in seconds: “7200” = 2h, it does generate very nice plots, though I think you can have pretty good results in “900”  = 15mins.

Other flags are added to the latency tool running the actual measurements. Here’s “-g result” is telling it to save binned latency measurements ready to be plotted in a file called “result”. Other flags that can be useful is “-t 0|1|2”, which sets the test mode: put 0 there for user mode task timing (this is the default), 1 for kernel mode tasks, or 2 for IRQ timing. For most use cases user mode tasks are the most relevant information.

I’ve run 3 benchmarks: one run, 2h for each test mode (that’s a nice little 6h window to do other things). Below is the result of the benchmarks:

VAB-820 Xenomai results (click to enlarge)

The results are 16.5us mean / 57us max latency for user tasks, 11.6us mean / 43us max latency for kernel tasks, 4.9us mean / 24us max latency for timer IRQ, while being under full load. These are pretty close to the results I could find for other ARM systems out there, so looking good!

Future work

The upcoming Xenomai 3 is a rewritten version of Xenomai that can provide different ways of creating a real-time system, possibly allowing even stricter response time limits. It’s still in it’s 3rd release candidate form and Buildroot has no support for it, so trying it out would mean once again rolling up the sleeves and do the hard work.

Before that, it should be more interesting to find some real use cases for our brand new real-time system that’s running on the board, let it be for example drone control, industrial automation, or scientific research (and gather some inspiration from out there, eg. these slides: Real-Time Linux in Industrial Appliances).

If you have real-time OS requirements, would love to hear your experience too! What’s your use case, what are your tools, and experience with them? Leave us a note in the comments!

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.

The hashlet is used mainly for security and authentication purposes. It is hardware protected key storage which is used for performing the SHA-256 algorithm in the chip.

It adds an authentication key and sends to the other projects. The advice for the other embedded projects is to use the authentication message received from the hashlet to start using the PCB.

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
•  The Prototyping boards are the heart of every electronic good which we are using on our day-to-day lives. The components in the prototyping board are checked in a minute way to avoid some critical problems in the future. The electrical components in this board decide the way of working and how fast it should work and much more. We can know more about PCB and how it tends to address different issues.

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? Nowadays, technology has enhanced so much and we would find many electronic devices which literally reduce the manual works. However, we must be very careful while handling that electronic equipment. Every electronic apparatus contains a prototyping board which is a major thing required for its functioning. A PCB is designed with a copper board with a few non-conductive substances and additional resources.  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.  The experimental project was to create a prototype expansion board for VIA VAB-600 Spring board is known as ProtoSpring. The board was designed in such a way that a bunch of pin headers are found on one edge of the board. The additional reading is included in the schematic of ProtoSpring. It was found to be a very interesting project. 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. It is a great platform to exchange these ideas. Such knowledge sharing experiences can encourage a lot of people in the younger generation. Additional info regarding such developments needs to be discussed so that people participate and get the best knowledge in a good form. Technical ideas get to develop in such platforms.

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

Peripheral Component Interconnect (PCI) is an integral part of the computer network. The function of the PCI is to connect video, sound and the network to the mother board which is powerful and faster one. Know about the additional hints of PCI express. It can replace the AGP slot and add graphics performance potentially.

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.

The smart garden is designed as such that the plant grows in the indoor and from the smart soil, they can obtain the nutrients, water and the oxygen and they are active. The required energy for the plant will be provided by the LED light. In the smart garden you can grow fresh food.

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 Arch Linux repository is essential software which can be easily accessed through the pacman.  They are found to very popular as it will be upgraded constantly to new versions. The instructions regarding installation Arch Linux is given in the CD. It is a great idea which started developing from Judd Vinet. Read about his contribution to know more.

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?