viaspringboard.com

Maker Club: The Thermal Printer Photobooth

The VIA Maker Club has already been featured on this blog, and I had the chance to meet some of the members when they came to visit the Taipei Hackerspace back in December of last year to demo their Smart Garden project. Now that I have joined VIA, I was eager to establish some credibility for myself in this very much technical team. I spent a half-day to come up with a project I could show at the regular Maker Club: meet MonoBooth, the thermal printer photobooth!

MonoBooth

For my quick project I wanted to do something interactive, personal, and which included hardware as well as software. I have worked with the thermal printer on a previous project, and looked like it would be fun to use it for this quick setup. So MonoBooth (monochrome + photobooth) was born.

The ingredients: webcam, thermal printer, and a Springboard

The hardware I have used for the project:

• VIA Springboard with Linux
  • A webcam that works under Linux (e.g UVC-supported ones, like this Logitech I found lying around)
  • ICT GP-58 IVthermal printer (probably other ESC/POS protocol speaking printer will do
  • Keyboard, Mouse, USB Hub, Mini-HDMI-to-VGA converter, screen…

Python is very useful for quick projects, and it has a very large community and software support, so I used it for this setup.

The webcam interaction is done with PyGame, it requires only a handful of lines of code to whip together the “photo” part of the booth: grabbing pictures from the webcam, displaying them, and once a key is pressed on the keyboard, take a shot and send it to post-processing and printing.

The printer was a tougher nut to crack. I’m using python-escpos, that implements the ESC/POS protocol, originating from Epson. The library can connect to printers in many different way (over the network, Serial/RS232 connection, bare USB). The current Springboard kernel doesn’t have all the modules compiled to save some space, so I couldn’t use the Serial (CDC_ACM), but the bare USB did work. I could get the required numbers from `lsusb -v`. The relevant output is saved on Github for future reference.

The important parts are:

• Vendor and Product ID, in this case 0x0483 and 0x5740)
  • Interface number, the printer has two, the printing’s on “bInterfaceNumber 1”
  • The endpoints (bEndpointAddress) for data IN and OUT are 0x81 and 0x03

Using these numbers the escpos library can communicate:

printer.Usb(0x0483, 0x5740, 1, 0x81, 0x03)

Text printing was working okay, but ran into a problem: pictures didn’t come out right most of the time. I had to do quite a bit of testing to figure out what might be causing this problem, and how to work around that for the demo.

Development troubleshooting

After testing different pictures sizes, formats, and colours, I found that up to about 120 pixel square images worked 90% of the time, so I settled for those (down from the maximum of approximately 512×256). Fortunately there’s a protocol setting to print pictures in quadruple size (double width and height), so my 120 x 120 pixel images can be printed as 240 x 240, which looks somewhat better. It is the usual procedure when hacking: problems inevitably come up, and people still find a compromise workaround if they try hard enough. 🙂

As the captured images needed to be modified to fit the printer well: first crop the webcam’s 640×480 image to 480×480, resize to 120×120, then turn into monochrome with the Python Imaging Library (PIL). The escpos library has its own conversion, but PIL looks better according to my tests.

When all the parts were sort-of working separately, the pieces were put together.

A picture of a picture

And ready to print…

A picture of a picture of a picture

It’s a good enough picture to recognize myself, so success is declared. The demo run at the Maker Club, and sparked a good conversation.

Party time

The source code of the project is on Github. I have tried to comment enough to make it usable. Since I modified the escpos library a bit to scale up the image as mentioned above and adding some printing delays for possibly better printer reliability, I added those to the repository as well.

Aftermath

This was a fun half-day project. I still want to figure out how to communicate with the printer better so I can use the total available resolution for the future version of this photobooth. Fortunately, we have a lot of firmware and hardware experts here who also want to play with the printer. I’m sure we’ll figure out where’s the problem (Linux? USB? Printer firmware? Software library?) and update the project.

Do you have any comments how to make the photobooth more fun? Or do you have projects you made with Springboard or another single-board-computer? Would love to hear about it! 🙂

 

Benching the mark, step one

HWBot is a very active overclocking community, based just nearby to the Springboard HQ in Taipei. For years they were promoting desktop performance testing. At their intro event at the Taipei Hackerspace a few months ago they made a very convincing case for the overclocking community driving stability and quality improvements in the desktop computing, forcing companies to come out with better motherboards, more stable and rugged CPUs and so on.

Now they want to apply the same pressure on smartphone manufacturers. Their Android benchmarking app, HWBot Prime, now has a beta version on the Play Store. It’s a good start comparing the performance and stability of the different smartphones, and to start competing in the community for benchmark higher scores to brag about. 😉

Since Springboard can also run Android, I thought it would be interesting to run their benchmark and see where are we now.

Installation

Flashing the Android image was pretty straightforward (especially after doing Linux already).

Flashing Android on the Springboard

The Springboard Android image doesn’t come with many apps, nor does it have a Web Browser or the Play Store app yet. I had to install HWBot Prime by putting the APK file on an SD Card, and manually opening it in the file manager. A bit of trial and error, but got there.

Android installed

Doesn’t need that many apps to get started with my particular plan, and it probably even helps that I don’t have to kill background apps to get a good performance measurement.

Benchmarking

Running HWBot Prime for the first time, the software mentioned that it doesn’t recognize the system, which is not a surprise. The benchmark did run successfully, though.

Benchmark run

The result is 354 primes/s with Springboard’s Android 4.0.3. Looking at the Hardware information, the app didn’t recognize pretty much any of the hardware, just the SoC name. The CPU Core#1 is also shown as “down”. Judging from my experience running HWBot on my phone, that probably means meaning “idling”, and when the app correctly recognizes the CPU, it shows the current frequency too. Thus the reading might mean that this performance measure is a “minimum” benchmark.

First time benchmarking results

So now we have a number, that might or might not mean anything. The interesting thing will be to see how we can improve on this number, with hardware settings, software updates, tuning…

“What gets measured, gets managed.” – Peter Drucker

The first thing I can do with it, though is comparing the results to my phone (an HTC Butterfly). That got 1838 primes/s on full power mode (Quad Core, 4x1512MHz), or 1529 primes/s on power saving (4x1134MHz). Springboard has a single core 800MHz CPU

A quick, non-scientific comparison, so I can relate the numbers:

Springboard:  0.4425 (prime/s) / core / MHz
Butterfly full power: 0.3039 (prime/s) / core / MHz
Butterfly power save: 0.3370 (prime/s) / core / MHz

This doesn’t look too bad, even if the overall power is lower, you get more power out by MHz from the Springboard.

Overclocking

The next step is talking to the HWBot guys, get Springboard into their database, and hear their ideas about improving performance.

Since tuning parameters of the hardware should be easier in Linux, will definitely look into running a similar check on that image as well, and start tweaking things. I’m sure the Springboard hardware team will be delighted. 🙂

Update 2014/04/18:
Springboard now shows up correctly in the HWBot leaderboard with its WM8950 CPU. Let the fine-tuning begin!

 

Hi, I’m new here

 

This entry was posted on April 12, 2014 by Gergely Imreh.

Hi, I’m Greg, and this is my first week here at VIA. While I was waiting for my regular office computer to arrive, spent some time thinking about Springboard, since I will be focusing on that a lot. Instead of just sitting around, decided to set up my own Springboard to get started in the meantime.

Setting up

Picked up one of the boards, and started to scavenge for the rest of the parts needed for a full computer:

• Power supply
• Mini-HDMI to HDMI cable
• HDMI monitor
• Extension board for USB
• USB hub
• USB keyboard and mouse
• Ethernet cable
• MicroSD Card

Fortunately some of them I’ve already had with me (what geek doesn’t have a MicroSD card forgotten in some coat pockets?), other pieces I got on loan from around the office.

Decided to use the Linux version of the operating system this time (will give Android a spin later), and downloaded the image from the resources page. Format the SD Card to FAT32, copy things over, and ready to flash the system anew.

After flashing successfully (a minute or so), just shut down and reboot.

To add a little personal touch, I have modified the boot logo: it’s spring and just got back from Kyoto cherry blossom watching, so let’s see that when my computer starts (spring – Springboard, got it?)

The boot logo is just a BMP file with the name u-boot-logo.data among the update files. Not sure how large file it can be, I kept around the original 240pixel width, though that looks tiny on the large screen.

Now Debian Linux is booting and ready to do some actual computing soon.

Getting the networking up was a bit trickier. I didn’t have wifi for Springboard, nor ethernet yet. Fortunately my laptop had wifi connection and a free ethernet port: let’s set up my laptop (temporarily) to be the router for the Springboard!

All I needed was basically to follow the description of Internet Sharing on the Arch Linux wiki (with some more optional tips from the Revsys blog about Linux NAT). This was the first time I did that, but it was easier than expected. Most of the problems I had were due to typos. Arch Linux (that I’m using for my laptop for years now) has an amazing knowledge base for all things Linux….

Networking now done, run a quick update to bring Debian up to date since the original OS image was published.

A quick install of XFCE for lightweight graphical environment took another 5-10 minutes or so. In the meantime I started a bit of system administration (e.g. setting up a non-root user for myself).

Once in the graphical environment, had to install a web browser. Looks like using ARM processor does limit the package choices a bit. At first glance I couldn’t install regular choice, Chromium. Instead went with Midori, which was also on the list of XFCE recommended applications.

And now ready to toast to my new computer. Cheers!

Ps: Toasting with a Vitamin C drink, looks like there’s flu going around over here in Taipei, everyone keep safe!

PPs: Thanks Max and Mike for lending me some of the parts to put this system together (though Mike does not know that yet:)

This entry was posted in Springboard Blog and tagged user, office, desktop on April 12, 2014 by Gergely Imreh.

 

VIA Partners with Mozilla

VIA Partners with Mozilla on the development of Firefox OS

 

If you’re interested in developing new connected devices using Firefox OS, you might want to check out our APC.

As we announced yesterday, Firefox OS running on APC Paper and Rock has been released with complete, buildable source codes available to developers on GitHub. In order to continue to encourage community support, we will be awarding free APCs to developers that fix a known issue. For more information, please read the press release here.

This article on CNet has an excellent overview of overall Mozilla’s plans for Firefox OS. We’re very excited to be partnering with them on the development of new device form factors based on the platform.

This entry was posted in Press Releases on January 7, 2014 by viaspringboard.

 

VIA Springboard Blog

• 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.
Continue reading →
This entry was posted in Springboard Blog and tagged APC 8750, golang, VAB-600, tutorial, VAB-820 on November 18, 2015 by Gergely Imreh.
• 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.
Continue reading →
This entry was posted in Springboard Blog and tagged VAB-600, mini-PCIe, open source hardware, KiCad, VAB-820 on September 18, 2015 by Gergely Imreh.
• Grove comes to embedded
Hardware interoperability is hard.
While software is usually easy to adjust to your different needs, hardware pieces tend to be quite finished by the time they are being used. If they require changes, it’s usually not a trivial thing to make it happen. You want to use a different IC, you need more sensors, or want to change your output device? All of these might be custom work instead of plug-and-play solutions.
There are some examples of projects to make such hardware interoperable between devices, so they can benefit a larger user base. The most successful is probably the shields for Arduino. They have now spread beyond Arduino boards as you can start seeing shield connectors in a lot more places. However they are still not the ultimate solution. Some of their drawbacks include their large size for many common accessories as well as difficulty in using more than a handful at a time as stacking can become troublesome very quickly. Fortunately there’s a new system that complements these existing solutions very well and improves usability tremendously!
Enter Grove
The Grove system was designed by Seeed Studio and seems to be taking maker computing platforms by a storm. It is designed to have a standardized physical connector, predictable pinouts, and common board sizes.
Continue reading →
This entry was posted in Springboard Blog and tagged Grove, open source hardware, prototyping, VAB-820 on September 3, 2015by Gergely Imreh.
• 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).
Continue reading →
This entry was posted in Springboard Blog and tagged real-time, Xenomai, buildroot, VAB-820, benchmark on May 13, 2015 by Gergely Imreh.
• Ready-to-go file system for the VAB-820
It’s been a while since we have announced on this blog another member of the VAB family, the VAB-820. At that time the highlight was Android support for this quad-core Freescale SoC based system, but our board support package (BSP) also had a Linux version. Over the Christmas holidays I found a bit of time to make a simplified Linux OS image for the VAB-820, and want to share with you, so you can make the most of your boards too.
Running Debian Wheezy on the VAB-820
That original, official Linux BSP version was is based in turn on the Freescale BSP, and had a lengthy user manual how to arrive to a working system. It is perfectly fine for our embedded customers. For the wider community this clearly does not cut it, the large number of quality ARM boards raised the bar for everyone, and we do want to work harder and smarter too.
Continue reading →
This entry was posted in VIA Embedded and tagged tutorial, Debian, buildroot, kernel, VAB-820, Linux on December 31, 2014 by Gergely Imreh.
• 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
Continue reading →
This entry was posted in Springboard Blog and tagged i2c, cryptotronix, atmel, open source hardware, cryptography, prototyping, open source on December 20, 2014 by Gergely Imreh.
• 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 ProtoSpring, prototyping, electronics, Android 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×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… Continue reading →
This entry was posted in Springboard Blog and tagged ProtoSpring, PCB, schematic, KiCad, design, electronics 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 →
This entry was posted in Springboard Blog and tagged ProtoSpring, schematic, KiCad, design, electronics on October 14, 2014 by Gergely Imreh.
• 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.