Embedded development boards have, in the last few years, progressed from being expensive platforms only available to professional or commercial developers, to almost-commodity devices accessible to anybody with an inclination to tinker. In the same time, the processing power available has progressed from cramped 8-bit micros to something resembling a previous-generation desktop, in a board the size of a deck of cards. As a result, there has been an emergence of hobbyist devices, ranging from the intimidating to the inane, of which we'll highlight a few here. Deeply impressive: Autonomous Trans-Atlantic Sailboats [From: http://www.roboat.at/en/technologie/] The Microtransat Challenge is a trans-Atlantic race of fully autonomous sail boats, designed to stimulate development of autonomous sailing boats. There are currently 12 teams registered for the 2009 race, with control systems ranging from commodity PC hardware to a custom FPGA-based system PCB. Resilience, intelligence, a wide range of sensor options and energy efficiency are key to success for these boats – a task to which modern embedded processors are ideally suited. Inevitable, in a way: RFID Cat Doors [From: http://ioanghip.googlepages.com/catdoor – controller laptop not shown] The key to invention is to recognise a need, and address it. In this case, the need is controlling the use of a cat door - whether to prevent other cats entry, or to control what the cat is allowed to bring in with it. In both these cases, the hacked-together prototype is a mishmash of commodity desktop computer hardware and components - a mixture that ideally lends itself to being simplified through the use of a smart embedded controller. While this may seem like an obscure product, commercial variations now exist: RFID Cat Door Pet Porte® Microchip Cat Flaps Just cool: Persistence-of-Vision LED Bike Lights [From: http://www.ladyada.net/make/spokepov/index.html] Persistence-of-vision means that rapidly-moving light sources will appear to be present for longer than they actually are, in this instance allowing a rapidly spinning line of LEDs to appear as a solid surface. Combine this with a small micro-controller, a sensor capable of determining rotational position, and you have the ability to display arbitrary images – or to turn your bicycle into a stunning mobile billboard. Again, this appears to be a fairly niche device – more of a toy than anything – but it has been commercialised by a number of companies: SpokePOV Kit MonkeyLectric Monkey Light Hokey Spokes Pimpstar Dub Custom Wheels The focal point here is that the line between hobbyist and commercial development is blurring: build something interesting, and you might find people lining up to give you money.

Embedded computing is a fast-moving field, with products, components, even whole markets coming and going on a monthly basis. The Open Source world is similar - and you often find that the problems you have at the moment are ones that other people are working on right now. Keeping a close eye on the industry gives you advance warning of up-and-coming issues, a window into the minds of your competitors and consumers, and can be a valuable source of ideas for future trends. In addition to the more traditional vendor-driver news channels, there are numerous Internet-based resources providing notification and discussion of events - ranging from aggregations of company press releases to personal ramblings by personalities driving new development. In this entry we will present a sampling of some of the resources found to be of particular and consistent interest. High-level news aggregates http://slashdot.org/ Extremely popular general news aggregation site for geek-related news, the discussion on topics of interest can offer valuable insight into the mind of the common technically-inclined consumer. http://arstechnica.com/ Well-written news site on technology-related events - could be seen as an editorial counter for Slashdot's discussion model. http://news.cnet.com/nanotech/ Cnet News network's blog focusing on news related to computer hardware. Field-specific news sites http://www.linuxdevices.com/ One of the central resources for news related to Linux and embedded devices. http://www.smallformfactors.com/news/ Low-traffic source for news releases from the small form factor computing industry. http://www.dev-monkey.com/ Occasional articles on development tools and new evaluation kits. http://www.portablemultimedia.blogspot.com/ Well-written articles focusing on news about portable devices. http://kerneltrap.org/ At one point a definitive news site on Open Source kernel development, this site still provides a easier-to-digest window into the various kernel mailing lists. http://www.embedded-computing.com/ http://cr4.globalspec.com/blog/83/Embedded-Now-Blog Embedded Computing Design magazine's blogs Personal and individual journals http://gnumonks.org/~laforge/weblog/linux/ Personal blog of Harold Welte, known for his Linux iptables, GPL enforcement and OpenMoko work. Currently active as open source liaison for VIA Technologies. http://pavelmachek.livejournal.com/ Pavel Machek's personal journal, focusing on experiences with open source projects and the G1 Android phone. http://www.bunniestudios.com/blog/ Andrew Huang's personal blog, notable for first-hand discussions on embedded product development and the Name that Ware challenge. The lighter side of engineering http://www.electronicsweekly.com/blogs/engineering-design-problems/ Some pieces of engineering are not quite up to a standard one can be proud of. This site documents pitfalls of engineers, with examples. http://thedailywtf.com/default.aspx Insider anecdotes of how wrong software can go. There are, of course, innumerable other news sites, blogs and journals out there that are of interest in the Embedded Computing domain. Many of them are very subject-focused: dealing only with one particular product, project or the like. If you can recommend additional resources that are of general interest, however, please comment and do so.

During development of our new Snapper 9260 module, one of the requirements was for boot times (power -> prompt) of less than 6s. Since the (rather feature-rich) development system boot time was in the order of 45s, there was quite a bit of scope for improvement: - Enable MMU and data cache in U-Boot: by default, U-Boot does fairly minimal initialisation of hardware. We extended main board support and network driver code to support making full use of the instruction cache (easy) and data cache (a bit more interesting). Time saving: ~3s. - Use on-board storage for kernel and root filesystem, instead of NFS. Time saving: ~2s. - Rationalise U-Boot environment: remove the boot delay, flatten out dynamically-generated bootup scripts, use uncompressed image (or gzip-compressed image if space is a constraint) instead of self-decompressing image, disable redundant image verification. Time saving: ~2s. - Strip unneeded drivers out of Linux kernel: by removing unneeded systems (eg. networking, unneeded filesystems, debugging facilities, splash logo), we reduced the Linux kernel size from 3.6Mb to 1.8Mb. Time saving: ~1.5s, plus reduced kernel boot times. - Add 'quiet' to Linux boot arguments, suppressing synchronous printk output. Unlike removing printk support entirely, the bootup messages are still available via dmesg, supporting field debugging. Time saving: ~2s. - Preset loops-per-jiffy setting for Linux kernel. Time saving: ~0.25s. - Strip filesystem to avoid unneeded subsystems, slow init() scripts, minimise footprint. Time saving: ~30s. Overall, these changes allowed us to reduce the boot times for the unit to 5.2s - well within the 6s target - without sacrificing support for interactive access and field upgrades. We hope to gain another 1.2s back between power-on and start of execution by using a new revision of the AT91SAM9260 chip (an erratum on the 'A' revision silicon), which should bring overall time below 5s - not bad for a full-featured Linux device!

Bluetooth and Wifi (802.11b/g in particular) have two things in common: they're both increasingly ubiquitous in embedded devices, and they both use the 2.4 GHz frequency band. Although resident in the same part of the frequency spectrum, Bluetooth and Wifi use markedly different approaches to transmission management and collision avoidance. As a result, devices (or event localised areas) with both Bluetooth and Wifi active are prone to conflict and service degradation - in extreme cases, leading to wireless networking being completely unusable. The basic issue is that Wifi breaks down the frequency range into 14 channels, and transmits on a fixed channel. Bluetooth, on the other hand, hops between 79 channels at a rate of up to 1600 hops per second. When a Bluetooth transmission happens to coincide (in time and frequency) with a Wifi packet transmission, both transmissions may be lost. Due to the longer packet sizes, this has a far greater impact on Wifi transmissions, at worst leading to a cycle of packet loss, Wifi transmission rate dropping (thus increasing the risk of collision), and further packet loss - terminating in complete loss of Wifi connectivity. To address this problem there are a few basic approaches: 1. Limit inter-device interference via distance or shielding. By providing 25dB or greater isolation between antennas, the issue may be avoided entirely, but this is often not practical for small devices. 2. Activity signaling and time sharing. Many Wifi and Bluetooth modules provide signals indicating that transmission is currently in progress, or to defer non-critical transmissions. This avoids interference, since only one device is transmitting at any given point in time, but can adversely impact performance. 3. Channel signaling. Interference only occurs when both Bluetooth and Wifi attempt to transmit on the same frequency range, so notifying the Bluetooth module of what frequency slots to avoid during its hopping sequence can avoid interference with no loss of Wifi bandwidth, and minimal impact on Bluetooth. 4. Adaptive Frequency Hopping. The Bluetooth v1.2 standard outlines a mechanism for Bluetooth devices to automatically mark and avoid frequency slots that exhibit interference from other devices, this preventing interference for both Bluetooth and Wifi. Unlike the other solutions listed, this does not require special board-level support, but is only available where all devices in a network support it. These schemes typically rely on module extensions and require board-level support, and vary in terms of the types of interference they can address effectively. In particular, these solutions may be limited where there is broad-base interference or where communication between interference sources is impossible. A simple general solution is therefore not achievable, so care must be taken when doing board design and module selection to take these issues into consideration, and to address the specific coexistence needs of the product.

We've recently come across a fantastic article in Keil's latest newsletter that we'd like to share.  This article discusses the benefits of Cortex-M3 for real-time applications, the modifications done to RTX to support Cortex-M3 and how this results in twice the performance over RTX running on ARM7TDMI. Have a read and let us know what you think! RTX Article