Products

View as: List  Grid

Show                                                                                                                                                                            per page

Sort By

VIA VAB-600 Springboard Kit

$99.00

add to cart

The VIA VAB-600 Springboard Kit combines an ultra-compact VIA VAB-600 Pico-ITX board with an I/O extender card, A/C adaptor, and COM and USB cables, to provide a comprehensive package for developing and building the next generation of innovative connected hardware devices.

The VIA Technologies is creating a wonderful history in producing springboards which are very useful for software development. The VIA VAB-600 Springboard is one of the stunning productions of VIA technologies which comes with various items.

It even gives a six-month warranty for the users and thus we can blindly purchase one for our software development process. This springboard has long life up to three years and thus we can purchase it blindly and use it effectively for the innovative software product.

If you would like to get more information about it, do make a quick google search and it is sure that we can obtain plenty of information about the recent technological changes in spring board production and every nook corner about it. It is even possible to expand the functionality of this VIA VAB-600 Springboard with the combination of many input and output devices, TTL cards and Low Voltage Digital Signaling(LVDS).

The VIA VAB-600 Springboard Kit comes with the following items:
– VIA VAB-600 board
– VIA VAB-600-A I/O extender card
– A/C adaptor
– 1 x COM cable
– 1 x USB 2.0 cable
– 3 year longevity
– 6 month warrantee

Learn More

  • | Add to Compare

VIA VAB-600 Springboard WiFi Kit

$129.00

add to cart

The VIA VAB-600 Springboard WiFi Kit combines an ultra-compact VIA VAB-600 Pico-ITX board with a USB WiFi module, I/O extender card, A/C adaptor, and COM and USB cables, to provide a comprehensive package for developing and building the next generation of wireless connected hardware devices.

The VIA VAB-600 Springboard WiFi Kit comes with the following items:
– VIA VAB-600 board
– VIA VNT9271 Springboard USB WiFi module
– VIA VAB-600-A I/O extender card
– A/C adaptor
– 1 x COM cable
– 1 x USB 2.0 cable
– 3 year longevity
– 6 month warrantee

*Note:
The VIA VAB-600 board contains only one on-board USB port which can be used to enable the two USB ports on the I/O extender card or the VIA VNT9271 USB WiFi module but not both simultaneously.

 

VIA Launches Springboard Platform

Provides fastest and most stable path to take innovative ideas for Android and Linux smart connected devices from prototype to production  

Taipei, Taiwan, 31st October, 2013 – VIA Technologies, Inc, a leading innovator of power efficient computing platforms, today announced the launch of VIA Springboard, a unique platform developed to provide embedded developers, start-ups, and DIY enthusiasts with the fastest and most stable path for prototyping next-generation ARM-based smart connected devices and taking them to mass-production.

“The growing availability of affordable open hardware platforms is leading to an explosion of exciting new concepts for innovative new connected devices, but taking a great idea from a prototype to mass production remains a major challenge with many such projects,” commented Epan Wu, Head of the VIA Embedded Platform Division, VIA Technologies, Inc. “Our goal with VIA Springboard is to provide  highly stable and scalable development platforms backed up by a comprehensive range of hardware and software support services that will enable them to reduce new system development costs and speed up their time to market.”

In this modern technical world, every one of us wants to make things as easy as possible. Thus, the software developers keep on producing innovative creations which would help the users so much. One of the creative productions is VIA Springboard. It offers a great pathway in the development of Android and other softwares. The reviews from the users are really amazing as it is a trustworthy springboard from the time of production and you can also discover this info here.

VIA Springboard provides a tightly-integrated platform of hardware kits, Android and Linux software development packages, and support services that covers all stages of the development process, including rapid system prototyping, application development, hardware and software customization, and pre-production testing and diagnostics. With a three-year longevity guarantee, customers can also be assured that VIA Springboard platforms will be available throughout the entire product life cycle.

VIA Springboard Kits

VIA Springboard Kits are available for global purchase in two configurations at www.viaspringboard.com. The VIA VAB-600 Springboard Kit features an ultra-compact VIA VAB-600 Pico-ITX board with an I/O extender card, A/C adaptor, and COM and USB cables, and is priced at US$99 plus shipping. The VIA VAB-600 Springboard WiFi Kit also includes a USB WiFi module and is priced at $129 plus shipping.

VIA Springboard Software Development Packages

The VAB-600 board can be configured with a choice of Android and Linux Software Development Packages that are available for download from the VIA Springboard website. The Springboard Android Software Development Package features Android version 4.0.3, and includes the kernel and bootloader source codes as well as a Smart ETK comprising a number of APIs, including Watchdog Timer (WDT) for safeguarding against system crashes, GPIO access, COM port access, RTC for auto-power on, and a sample app. The Springboard Linux Software Development Package has a pre-built Debian image, including the kernel and bootloader source codes, and also comes with a Tool Chain to help make adjustments to the kernel and to leverage the onboard pin-headers, GPIO, I2C, and other hardware features.

VIA VAB-600

Based on the ultra-compact Pico-ITX form factor measuring just 10 cm x 7.2 cm, the VIA VAB-600 integrates a low power 800MHz ARM Cortex-A9 SoC and is packed with advanced multimedia features, including a built-in multi-standard decoder for playback support of the most demanding video formats in resolutions of up to 1080p.

The VIA VAB-600 includes a wide array of rear I/O features, including one Mini HDMI port, two Mini-USB 2.0 ports, one 10/100 Ethernet port, and one 12~24V DC-in jack. Other onboard features include 4GB eMMC Flash memory, 1GB DDR3 SDRAM, one DVO connector, two COM ports (one for TX/RX only), SPI, one USB 2.0 connector, one Mini Card slot, touch screen support, front pin headers for line-in/out and MIC-in, I¬2C and GPIO pin headers. Combining a wide operating temperature range of 0°C up to 60°C with extremely low power consumption, the VIA VAB-600 is designed to operate in even the most extreme environments.

VIA VAB-600-A I/O Extender Card

The VIA VAB-600-A I/O extender card adds multiple I/O interfaces, including Line-Out and Mic-In audio jacks and two USB ports. Measuring 100mm x 20mm x 1.6mm (L x W x H), the card also features one suspend LED power indicator and a power on/off button as well as three board-to-board connectors and one USB board-to-board connector.

VIA VNT9271 Springboard USB WiFi Module

The VIA VNT9271 Springboard USB WiFi Module enables the fast and convenient integration of high-speed wireless capabilities into the VIA VAB-600 board. Featuring the Atheros AR9271 controller chip, the module is fully compliant with IEEE 802.11b/g/n standards working from 2.4GHz to 2.5GHz. In addition, the module can provide up to 11Mbps for IEEE 802.11b, 54Mbps for IEEE 802.11g or 150Mbps for IEEE 802.11n to connect the Wi-Fi client to a Local Area Network or the Internet.

For images related to this release, please visit: http://www.viagallery.com/Products/via-vab-600-springboard-kits.aspx

Availability

The VIA VAB-600 Springboard Kit and the VIA VAB-600 Springboard WiFi Kit are available for global purchase at www.viaspringboard.com. The kits are priced at $99 and $129 respectively, plus shipping.

About VIA Technologies, Inc.

VIA Technologies, Inc is the foremost fabless supplier of power efficient x86 processor platforms that are driving system innovation in the PC, client, ultra mobile and embedded markets. Combining energy-saving processors with digital media chipsets and advanced connectivity, multimedia and networking silicon enables a broad spectrum of computing and communication platforms, including its widely acclaimed ultra compact mainboards. Headquartered in Taipei, Taiwan, VIA’s global network links the high tech centers of the US, Europe and Asia, and its customer base includes the world’s top OEMs and system integrators

 

Tag Archives: ProtoSpring

  • 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: Continue reading 

This entry was posted in Springboard Blog and tagged ProtoSpringprototypingelectronicsAndroid on November 7, 2014 by Gergely Imreh.

  • 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×24×2, and 7×2 connectors by 3M.

We would find many of us are speaking about the new generation software development and computer programming system. Among it, ProtoSpring is one of the prototyping beard board which gets connected with a single board computer and we can see this board in every individual electronic good. It can be broken out to 8XGPIO channels, 12C channel, Led, audio connectors and power buttons.

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… Continue reading 

This entry was posted in Springboard Blog and tagged ProtoSpringPCBschematicKiCaddesignelectronics on October 28, 2014by Gergely Imreh.

  • 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. Continue reading 

 

Running Go on VIA ARM devices

Go is a modern and quite popular systems programming language developed at Google. I’ve recently came across a wiki page describing its ARM support, I thought it would be interesting to check how VIA devices can make use of Go. I’ve checked out the VAB-820, VAB-600, and the APC 8750 boards, all a bit different from each other.

VAB-820 with a Gopher

I found that the general documentation does not cover all the things that can (and generally do) go wrong, though a few online searches usually pointed me in the right direction. Installing Go needs two separate steps: bootstrapping first, then compiling from source.

Bootstrap

Bootstrap is needed because Go’s now written in Go, so you need to already have Go to get Go. That makes sense, right? There are two ways go about this (pun intended). Either use another system (e.g. an x86 computer) that can create a bootstrap package for ARM, or use the Go package from the ARM board’s distro. My VIA boards are running Debian, and there the available Go version is pretty old. So instead I opted to an x86 bootstrap. These next steps are based on information at the Install Go from Source page.

Due to the extended software development, there are a number of programming languages developed which would ease the manual power. Go is a very simple and reliable programming language which is introduced by Google and it helps the software engineers to produce new and efficient software in a very easy manner. If you are zealous to learn more about Go software, then Read Full Article online and it aids you a lot.

First downloaded Go 1.4 from their binary distribution page, and put it into the ~/go1.4/ directory as that’s where Go looks for the binaries by default.

Next cloned the latest Go source from Github, and used it to create a bootstrap package

$ git clone https://github.com/golang/go.git

$ cd go/src/

$ GOOS=linux GOARCH=arm GOARM=7 ./bootstrap.bash

[lots of stuff]

Bootstrap toolchain for linux/arm installed in /home/user/go-linux-arm-bootstrap.

Building tbz.

-rw-r–r– 1 user user 48983241 Nov 18 16:55 /home/user/go-linux-arm-bootstrap.tbz

In the settings above the GOOS environmental variable selects Linux, GOARCH selects ARM support in general, and GOARM selects ARMv7 support. Working with these settings, since both VAB-820 and VAB-600 are ARMv7 devices, Other values are listed in the installation guide.

To make it easy, I’ve made our current precompiled bootstrap files available for download for ARMv7ARMv6, and ARMv5.

Compilation

The rest of the steps take place on the board itself. Boot up, and set up networking. Copy the “go-linux-arm-bootstrap-X.tgz onto the board and extract it, for example into the user directory. Clone the Go source as well, and then things are almost ready.

Almost, because ARM devices are generally underpowered compared to x86, or at least their CPU/memory/stack balance is very different than an x86 machine. Because of this, some of the settings need to be modified to successfully build Go. Based on a blogpost, the stack size needs to be  reduced (e.g. from 8MB to 1MB) with “ulimit -s 1024”, and the Go tests scaling factors need to be modified through an environmental variable.

And one more trick before starting: the compilation makes heavy use of “/tmp” and it is better to make sure it’s in the memory, not trashing the SD Card or eMMC storage. The wiki recommends these settings in “/etc/fstrab”

tmpfs /tmp tmpfs nodev,nosuid,mode=1777 0 0

The final process is something like this:

$ tar xjvf go-linux-arm-bootstrap-armv7-.tbz

$ git clone https://github.com/golang/go.git

$ cd go/src

$ ulimit -s 1024

$ GO_TEST_TIMEOUT_SCALE=10 GOOS=linux GOARCH=arm GOARM=7 GOROOT_BOOTSTRAP=~/go-linux-arm-bootstrap ./all.bash

[now wait for a long time]

ALL TESTS PASSED

 

Installed Go for linux/arm in /home/user/go

Installed commands in /home/user/go/bin

*** You need to add /home/user/go/bin to your PATH.

In the process first Go is compiled, then all the tests are run that are included in the source repository. That’s the part that takes the longest time. If all the tests passed, then the new go binary will be installed in the “bin” directory of the git repository – and now ready to use!

VAB-820

On VAB-820 I’ve managed to successfully install Go through these steps, and using the ARMv7 bootstrap kit. Its quad core performance is pretty good, and can’t wait to try it for some practical projects! (Might need to permanently set the stack size to 1MB like above.)

There’s also a simpler way to possibly get to use Go: turns out that Resin.io, which has (alpha) support for VAB-820, has some Go base Docker images, so deploying an application onto the board can be as easy as a “git push”. This is still very experimental at the moment, so things will likely to change.

VAB-600

The process is quite similar on VAB-600 as well, though it takes longer time, because it’s a single core ARMv7 device. Nevertheless it works, and provides some interesting options for projects! (Might need to permanently set the stack size to 1MB like above.)

APC 8750

The APC 8750 is an ARMv6 device, and should be okay to bootstrap with a ARMv6 kit, but it turns out that it also depends on the OS version run. The board I had at hand was running soft-float Raspbian, and there the compilation failed with some floating point errors. Looks like that in this case, using a ARMv5 (“GOARM=5”) bootstrap kit might do the trick. The compilation takes quite a long time, though, naturally.

Future

As the next step, you can look around at the tutorial section, and at Awesome Go for great project examples and recommended libraries.

Have you tried Go with any VIA boards, or any other ARM devices? Have any interesting Go project that you want to show off? Would love to hear your experience in the comments!

 

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×24×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 panelGPIO, 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!