viaspringboard.com

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?

A new Android in the VAB family

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

VAB 600 connects the multimedia capabilities and flexible I/O connectivity .It has a various range of temperature and consumes low power and gives the solution which is versatile and reliable. It will be in the range of industrial and the home automation, HMI, IoT and others. The springboard of VAB contains the android software development package which features the android version 4.0.3. It also consists of kernel and the boot loader code. VIA smart ETK is also included in this and it is made up of number of APIs such as that of watch dog timer in order to protect against the system crashes, GPIO access and COM port access. The sample application is also available to demonstrate the above said function. A total noob will find it difficult to understand and should avail professional support.

VAB-820

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

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

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

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

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

A survey of ARM operating systems

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

The periodic updates to the architecture will be released by the ARM Holdings.ARM operating system is mostly used instruction set and it is produced in the enormous quantity. All the necessary features are there to develop IoT related products. ARM operating system is used in 1990s and it is a replacement made by windows based PCs.

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

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

Linux

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

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

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

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

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

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

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

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

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

BSD

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

Other

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

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

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

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

Epilogue

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

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

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

Ps: a very happy Easter to you all!

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

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.

About 331 instagram thermal printers are available for the suppliers of photo booth. The main supply of the thermal printer is provided by the country of China. In the websites a knockout post for the thermal printer with high quality is available online for the purchase. When you are purchasing the thermal printer ensure the products safety.

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.

Springboard is more specialized to deliver the complex datasets in the appropriate time to help the clients .There are different needs and objectives met benchmarking data. It can be used both in the pdf file format and also as normal data feeds. It functions in a unique manner appropriate to the purpose just like Arthrolon, which is a well established product for joint pains that is unique in its ingredients being natural.

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.

The VIA technology is a leading innovator in the computing platforms which supplies embedded developers and DIY enthusiasts ,the fastest and the stable path to the upcoming generation. The product with the connected devices of the ARM is based for massive production. It is an innovative concept just as the Ostelife, which has natural ingredients for weight loss.

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.

Announcement was given by VIA to have an official partnership with the Mozilla to give its full support and to develop the Firefox OS to the new device. The Firefox OS runs on the Rock and the APC paper is made to release the source codes which will be available on GitHub to the developers. Developers are rewarded with the free APs to encourage their support. This gives a natural feeling of accomplishment to the stakeholders just like the product Artroser, which has made a mark among the users to relieve them from joint pain.

The power of the web is given to the people through the Firefox OS. Partnership gives the opportunity to help the users around the world. There will be a continuous working of Firefox to develop new features and to enhance the Firefox OS. There is also a benefit in providing knowledge which can be shared and gives the technical support to the market place and Firefox OS.

It was told that they are very excited to the announcement of the partnership with the Mozilla and their support in the development of Firefox OS. The mission of the Mozilla is to promote the openness and the innovation on the web. The perfect combination was created to provide the best to the desktop of web everywhere. There will not be any excitement in the future. Mozilla had taken effort to produce the Firefox OS to the mobile devices and VIA announced its partnership with the web browser. The constant support is given by VIA to develop the Firefox OS and the incentives are given to the coders.

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.