ArduCAM Introduces A Third Party Raspberry Pi

There are hundreds of ARM-based Linux development boards out there, with new ones appearing every week. The bulk of these ARM boards are mostly unsupported, and in the worst case they don’t work at all. There’s a reason the Raspberry Pi is the best-selling tiny ARM computer, and it isn’t because it’s the fastest or most capable. The Raspberry Pi got to where it is today because of a huge amount of work from devs around the globe.

Try as they might, the newcomer fabricators of these other ARM boards can’t easily glom onto the popularity of the Pi. Doing so would require a Broadcom chipset. Now that the Broadcom BCM2835-based ODROID-W has gone out of production because Broadcom refused to sell the chips, the Raspberry Pi ecosystem has been completely closed.

Things may be changing. ArduCAM has introduced a tiny Raspberry Pi compatible module based on Broadcom’s BCM2835 chipset, the same chip found in the original Raspberry Pis A, B, B+ and Zero. This module is tiny – just under an inch square – and compatible with all of the supported software that makes the Raspberry Pi so irresistible.

nano-rpi-cmio-backAlthough this Raspberry Pi-compatible board is not finalized, the specs are what you would expect from what is essentially a Raspberry Pi Zero cut down to a square inch board. The CPU is listed as, “Broadcom BCM2835 ARM11 Processor @ 700 MHz (or 1GHz?)” – yes, even the spec sheet doesn’t know how fast the CPU is running – and RAM is either 256 or 512MB of LPDDR2.

There isn’t space on the board for a 2×20 pin header, but a sufficient number of GPIOs are broken out to make this board useful. You will fin a micro-SD card slot, twin micro-USB ports, connectors for power and composite video, as well as the Pi Camera connector. This board is basically the same size as the Pi Camera board, making the idea of a very tiny Linux-backed imaging systems tantalizingly close to being a reality.

It must be noted that this board is not for sale yet, and if Broadcom takes offense to the project, it may never be. That’s exactly what happened with the ODROID-W, and if ArduCAM can’t secure a supply of chips from Broadcom, this project will never see the light of day.

Another Small Linux Computer With Pi In Its Name

Since the introduction of the Raspberry Pi, the embedded Linux scene has been rocked by well supported hardware that is produced in quantity, a company that won’t go out of business in six months, and a huge user base. Yes, there are a few small problems with the Raspberry Pi and its foundation – some stuff is still closed source, the Foundation itself plays things close to their chests, and there are some weird binary blobs somebody will eventually reverse engineer. Viewed against the competition, though, nothing else compares.

Here’s the NanoPi Neo, the latest quad-core Allwinner board from a company in China you’ve never heard of.

The NanoPi Neo is someone’s answer to the Raspberry Pi Zero, the very small and very cheap single board Linux computer whose out-of-stock percentage has led some to claim it’s completely fake and a media conspiracy. The NanoPi Zero features an Allwinner H3 quad-core Cortex-A7 running at 1.2 GHz, 256MB RAM, with a 512MB version being released shortly. Unlike the Raspberry Pi Zero, the NanoPi Neo features a 10/100 Ethernet port. No, it does not have PoE.

As with anything comparing itself to the Raspberry Pi Zero, only two things are important: size and price. The NanoPi Neo is a mere 40mm square, compared to the 65x30mm measurements of the Pi Zero. The NanoPi Neo is available for $7.99, with $5 shipping to the US. Yes, for just three dollars more than a Pi Zero with shipping, you get a poorly supported Linux board. What a time to be alive.

If you’re looking for another wonderful tale of what happens with cheap, powerful ARM chips and contract manufacturers in China, check out my review of the Pine64.

STM32 and FPGAs In A Tiny Package

Slowly, very slowly, the time when we don’t subject embedded beginners to AVRs and PICs is coming. At a glacial pace, FPGA development platforms are becoming ever more capable and less expensive. [Eric Brombaugh] has been playing around with both ARMs and FPGAs for a while now and decided to combine these two loves into a single board that’s capable of a lot.

This board is fittingly called an STM32F303 + ice5 development board, and does exactly what it says on the tin. There’s an STM32F303 on board providing a 32-bit CPU running at 72 MHz, 48 kB of SRAM, a quarter meg of Flash, and enough peripherals to keep anyone happy. The FPGA side of this board is a Lattice iCE5 with about 3k Look Up Tables (LUTs), and one time programmable non-volatile config memory.

The connections between the ARM and FPGA include a dedicated SPI port, and enough GPIOs to implement full-duplex I2S and a USART. Like all good projects, [Eric] has shared all the files, schematics, and BOMs required to make this board your very own reality, and has provided a few links to the development toolchains. While the FPGA is from Lattice’s ice40 family, it’s not supported by the Open Source Project Icestorm toolchain. Still, it’s a very capable board for ARM and FPGA development.

The Dual-Core, ARM-Powered Commodore 64

There is no CPU that is better understood than the 6502 and its cousins the 6510, 6507, 6509, and whatever we’re calling the CPU in the NES. With this vast amount of documentation, just about anything can be done. Want a discrete and un-discreet 6502? Sure thing. It’s the NMOS version, though. Want an emulated version. Sure. With libraries porting the 6502 to every platform ever, there’s only one place left to go: putting a 6502 in a Commodore 64. Make it dual-core, too, so we can run CP/M.

This build is based on one of [telmomoya]’s earlier builds – a soft-core 6510 running on an ARM Cortex M3. The inspiration for this build came from a 6502 emulator running on an Arduino, which got [telmomoya] wondering what would happen if he attached some external RAM, CIA or a SID. Doing this on an Arduino is hard, but there are a few 5 Volt tolerant ARM chips out there, and with a few banks of SRAM, [tel] quickly had an emulated 6502 running EhBasic.

Running an emulated 6502 on an ARM chip is nothing new. What makes this build spectacular is the adaptation to the C64 motherboard. Since [telmomoya] was already breaking out the data and address lines to go to the SRAMs, it didn’t take much extra work to simply build an adapter for the DIP40 CPU socket on a C64. A few 74-series logic chips made the interface easy, and after a bit of soldering, [telmomoya] had a Commodore 64 powered by an ARM chip.

If you’re emulating one chip, you can emulate two, and with the Commodore 64, this leads to a few interesting possibilities. The C64 had a CP/M cartridge — a cartridge that contained a Z80 CPU, sharing the data and address bus with the 6510. This cartridge allowed the ‘toy computer’ C64 to run the ‘business’ CP/M operating system (and the Z80 made the Commodore 128 much cooler).  Since [telmomoya] was already emulating a CPU, emulating a second CPU wasn’t really that hard.

It’s a phenomenal build, and great if you’ve ever wanted to speed up VisiCalc.

An Improved WiFi Connected E-Ink Display

[David] created a great looking e-ink WiFi display project that works a little like a network-connected picture frame with a few improvements over other similar projects. With the help of an ESP8266 it boots up, grabs an 800×600 image over the network, updates the screen, then goes back to sleep. Thanks to some reverse engineering, he was able to make his own firmware for the onboard controller to handle the low-level driving of the display. Since e-ink displays require no power to hold an image and the rest of the unit spends most of the time either asleep or off, power use is extremely low. [David] hopes to go months without needing to recharge the internal lithium-polymer battery.

eink_back
Lithium-polymer charger (top left); Single-cell lithium-polymer battery (center); pullups and power cutoff for nonessential electronics (green board, lower right); ESP866 (lower left).

We previously featured another WiFi-connected e-ink display project that was in fact also the inspiration for this version. [David] uses a 4.3″ 800×600 GDE043A e-ink display and wrote his own firmware for the STM32F103ZE ARM CortexM3 SoC used as a display controller, a process that required some reverse engineering but was aided by the manufacturer providing a closed-source driver for him to use. [David] writes that some reverse-engineering work for this display had already been done, but he had such a hard time getting a clear understanding from it that he reverse engineered the firmware anyway and used the documents mainly for validation and guidance.

As a result, [David] was able to make use of the low-level driver electronics already present on the board instead of having to make and interface his own. E-ink displays have some unusual driving requirements which include generating relatively high positive and negative voltages, and rapidly switching them when updating the display. Taking advantage of the board’s existing low-level driver electronics was a big benefit.

eink_apThe ESP8266 rounds out the project by taking care of periodically booting things up, connecting to the wireless network and downloading an image, feeding the image data to the STM32 to update the display, then disconnecting power from all non-essential electronics and going back to sleep. We especially like how the unit automatically creates a WiFi access point to allow easy (re)configuring.

There’s one more nice touch. [David] goes the extra mile with server software (in the form of PHP scripts) to design screens for the display with data like weather forecasts, stock prices, and exchange rates. Check it out in the project’s github repository.

gcc: Some Assembly Required

There was a time when you pretty much had to be an assembly language programmer to work with embedded systems. Yes, there have always been high-level languages available, but it took improvements in tools and processors for that to make sense for anything but the simplest projects. Today, though, high-quality compilers are readily available for a lot of languages and even an inexpensive CPU is likely to outperform even desktop computers that many of us have used.

So assembly language is dead, right? Not exactly. There are several reasons people still want to use assembly. First, sometimes you need to get every clock cycle of performance out of a chip. It can be the case that a smart compiler will often produce better code than a person will write off the cuff. However, a smart person who is looking at performance can usually find a way to beat a compiler’s generated code. Besides, people can make value trades of speed versus space, for example, or pick entirely different algorithms. All a compiler can do is convert your code over as cleverly as possible.

Besides that, some people just like to program in assembly. Morse code, bows and arrows, and steam engines are all archaic, but there are still people who enjoy mastering them anyway. If you fall into that category, you might just want to write everything in assembly (and that’s fine). Most people, though, would prefer to work with something at a higher level and then slip into assembly just for that critical pieces. For example, a program might spend 5% of its time reading data, 5% of its time writing data, and 90% of the time crunching data. You probably don’t need to recreate the reading and writing parts. They won’t go to zero, after all, and so even if you could cut them in half (and you probably can’t) you get a 2.5% boost for each one. That 90% section is the big target.

The Profiler

Sometimes it is obvious what’s taking time in your programs. When it isn’t, you can actually turn on profiling. If you are running GCC under Linux, for example, you can use the -pg option to have GCC add profiling instrumentation to your code automatically. When you compile the code with -pg, it doesn’t appear to do anything different. You run your program as usual. However, the program will now silently write a file named gmon.out during execution. This file contains execution statistics you can display using gprof (see partial output below). The function b_fact takes up 65.9% of CPU time.

screenshot_232

If you don’t have a profiling option for your environment, you might have to resort to toggling I/O pins or writing to a serial port to get an idea of how long your code spends doing different functions. However you do it, though, it is important to figure it out so you don’t waste time optimizing code that doesn’t really affect overall performance (this is good advice, by the way, for any kind of optimization).

Assembly

If you start with a C or C++ program, one thing you can do is ask the compiler to output assembly language for you. With GCC, use a file name like test.s with the -o option and then use -S to force assembly language output. The output isn’t great, but it is readable. You can also use the -ahl option to get assembly code mixed with source code in comments, which is useful.

You can use this trick with most, if not all, versions of GCC. Of course, the output will be a lot different, depending. A 32-bit Linux compiler, a 64-bit Linux compiler, a Raspberry Pi compiler, and an Arduino compiler are all going to have very different output. Also, you can’t always figure out how the compiler mangles your code, so that is another problem.

If you find a function or section of code you want to rewrite, you can still use GCC and just stick the assembly language inline. Exactly how that works depends on what platform you use, but in general, GCC will send a string inside asm() or __asm__() to the system assembler. There are rules about how to interact with the rest of the C program, too. Here’s a simple example from the a GCC HOWTO document (from a PC program):

__asm__ ("movl %eax, %ebx\n\t"
"movl $56, %esi\n\t"
"movl %ecx, $label(%edx,%ebx,$4)\n\t"
"movb %ah, (%ebx)");

You can also use extended assembly that lets you use placeholders for parts of the C code. You can read more about that in the HOWTO document. If you prefer Arduino, there’s a document for that, too. If you are on ARM (like a Raspberry Pi) you might prefer to start with this document.

So?

You may never need to mix assembly language with C code. But if you do, it is good to know it is possible and maybe not even too difficult. You do need to find what parts of your program can benefit from the effort. Even if you aren’t using GCC, there is probably a way to mix assembly and your language, you just have to learn how. You also have to learn the particulars of your platform.

On the other hand, what if you want to write an entire program in assembly? That’s even more platform-specific, but we’ll look at that next time.

Learning ARM Without Dev Board

There’s a tremendous amount of value in using pre-built, known-good development environments. It saves you hours of potential headaches when things aren’t working. Is the bug in the hardware or the software? If you bought a dev kit, you can be pretty sure it’s your software. But sometimes using a dev kit also feels like there’s a black box in the system. [Kevin] wanted to peer inside the black box, so he ordered a tray of cheap STM32F103 chips on eBay, and did the rest himself.

“The rest” isn’t all that much, but figuring that out is half the battle. [Kevin] soldered the TQFP chip onto a breakout board, added some decoupling capacitors, and connected four pins up to a dirt-cheap ST-Link programmer clone. The rest of the article describes the toolchain he used to compile for and program the chip. The end result is, natch, a blinking LED.

If you’re a bit experienced with microcontrollers and want to dive head-first into an ARM chip, [Kevin]’s writeup is just the ticket. In a single (long) blog post, he walks you through all the steps. If this is your first rodeo, you might be tempted to cheese out and buy a pre-built board on eBay (search “STM32F103” and you’ll find many options to choose from) and we don’t think that’s a bad idea either. Still, there’s just something to be said for the confidence that you’ll have once you’ve built the whole system from scratch.