Hands-on with the PocketBeagle: a $25 Linux computer with lots of I/O pins

I haven’t had a chance to try Nerves with the new BeagleBone Pocket yet. There may be an issue with using the EEPROM and the nerves flash utility fwup, though if so I’ll likely work on adding support for it myself as the Octeva SoC is pretty awesome for a lot of applications. Especially since it has support for the onboard PRU’s which come in handy for critical timing.

As for the buildchain, Nerves has a Docker based build image (on OS X) or native Linux builds both based on buildroot which you can easily customize to include the PRU build tool chain. You can include a custome make package in buildroot or Elixir dependencies. Though this route would require writing some amount of Elixir.

So if Nerves is not your cup of tea, you could checkout Yocto or even raw Buildroot or the new Ubuntu core stuff. For buildroot it’s a matter of configuring it and putting it all in a Docker image (or similar) and using `make` and it builds the firmware blobs for you.

https://buildroot.org/

https://github.com/buildroot/buildroot/tree/master/board/bea...

In fact, I highly recommend this route (debootstrap) if you're not interested in compiling everything (the way buildroot and OE do it) and instead rely on Debian's prebuilt ARM packages. You still get to customize exactly what is in your image; adding or removing pre-installed packages is not difficult. Plus you get apt/dpkg, for updates which IMO is superior to ipkg.

I've used both kernel v4.4 with Debian Jessie and 4.9 with stretch, both work well.

I've got a bash script which acts as a pseudo-makefile that does the whole shebang: builds kernel & u-boot with my kconfig/ DTS, calls debootstrap including my preferred list of packages, applies my rootfs customizations and spits out an image ready to burn directly to an SD card. The whole thing runs in a docker container (could also use Vagrant) from my Mac workstation. Tweaking the package list, distro or kernel version is mostly a matter of changing a few constants defined at the top of the script.

Note that BBB is slightly different from the Olimex module hardware-wise, but the process is essentially the same. Also note, the ti linux kernel is close mainline, whereas the bbOrg kernel has tons of patches for their "capes" system. If you're not interested in expanding the BBB with capes I think you can stick with the ti kernel sources.

You could also build a very minimal busybox-based distro. But from there you're pretty much on your own w/r/t additional packages.

[1] https://www.olimex.com/wiki/AM335x

- ARM Cortex-A SoC, preferably one with networking built-in to minimize layout hell like with the newer Raspberry Pis, but an ESP32 module could serve that purpose.

- A nice ARM Cortex-M7 core @~200-400MHz, for realtime functionality and honestly, teaching. MCUs have huge potential for teaching about electronics/code with minimal overhead or required prior knowledge, imo. If your cheap laptop could also use successful educational tools like the Arduino IDE and Adafruit's libraries for things like sensors/I2C-SPI displays/etc out-of-the-box without requiring any boards or dongles...well, that would be absolutely terrific.

- FPGA core with as many LUTs as I could get at a similar ~$20 price point of the Cortex-M, for ultra-realtime tasks like signal processing or video encoding.

Then it would just be a fairly large software problem to make a nice GUI interface to program and debug the peripheral cores from a generic Linux/BSD environment.

Unfortunately I can't even do QFN reliably, so a board like that would really limit my options with parts, and it would be huge with all the QFP-100+ parts. Also, the idea of juggling three large processing platforms' enormous documentation makes me shudder.

But it would be a really cool idea for an open platform dedicated to handheld multimedia :/

It's actually a pretty huge development as far as electronics go.

You don't have to use all of the CPU or RAM capabilities. The use cases appropriate for this board include all potential use cases for an equivalent board with less CPU or RAM. I don't think it's fair to knock it for being too capable.

https://hackaday.com/2015/02/19/turn-your-beagleboneblack-in...

It's nice to be able to do a one-off thing like that with high-level tools.

Dimwit #1: Ah, use a 555 timer.

Dimwit #2: Use an Arduino with the Blink sketch.

Senior Software Developer: I'll use a Linux board with a blink program running on Node.js. The blink program will watch for the alarm condition and blink the LED in response. The program will also provide a web based configuration interface. What if marketing changes the requirements from a simple blink pattern to:

blink blink (pause) blink blink (pause) etc...

The simple 555 timer approach would be too inflexible.

The arduino approach would require altering, recompiling and re-flashing the firmware.

The senior software developer approach would be sufficiently flexible that you could connect a web browser and reconfigure the blink pattern.

Each blink pattern can be given a name and saved. Such as the slow-blink, fast-blink, double-blink, etc. Each pattern consists of a list of on/off states associated with a duration in milliseconds. Anyone can point their browser to this and reconfigure new blink patterns that become popular.

What could possibly go wrong?

A few months ago, I started on a project that needed to read an input signal, do some trigonometry on it and update some I/O at a 30kHz update rate. The kind of thing a DSP could handle in its sleep, but I don't have DSP tools and it wasn't worth the investment.

Since a standard Arduino Uno wasn't fast enough to do the math, I built a table of precomputed sines & cosines, scaled to the output signal.

But then we needed 12 bit analog input. Since the Cortex M0 on newer Arduinos (Due?) has a 12 bit A/D and is much faster, I could now drop my precalculated table and do the math on the fly.

But the ADC in the M0 turned out to be crappy, so I ditched it for an off-board 12-bit ADC and went back to the Uno and the sin/cos tables.

Had I not been concerned about latency and startup times, I'd have used a Raspberry Pi with an external ADC or a Beaglebone right out the gate and probably finished the project inside a week. I'm selling the hardware with enough margin that the extra cost doesn't matter to me and it matters even less to my customer.

Blink the onboard LED.

Read the onboard ADC channels (touch pins with your fingers to vary voltage).

Feed serial text from the terminal app and have the onboard LED on pin 13 blink the text out in Morse Code.

If you have the bug by this point, get more advanced. If not, put it back on the shelf and you haven't wasted much :-)

An Arduino isn't a self-hosting environment (you'd do your actual development on a PC and deploy it to the Arduino), but the hardware's simpler and cheaper. I haven't done as much with it, but there are tons of tutorials to get started with it, and the default development environment will be comfortable if you've done anything in C before.

Devices like this "Pocket Beagle" (and the BeagleBone, Raspberry Pi, and others) all use something called an "SoC" - otherwise known as "System on Chip".

This is where all the essential components of an entire computer are put on a single chip - cpu, ram, peripheral controllers, etc; generally, the cpu and ram are large enough to implement a full OS on (like Linux). Smartphones and tablets use similar (if not the same in many cases) SoC devices; by putting everything on one chip, size is shrunk dramatically (at the cost of upgradability and other things).

The Arduino (Uno, Mega) is something different - it is what's known as a "carrier" or "development" board; what it serves is an easy way to gain access to the pins and functionality of a device known as a "microcontroller". Microcontrollers are somewhat different than an SoC - although there can be and is overlap (particularly as you move into the 32 bit microcontrollers - some have enough functionality to almost be an SoC in all but name).

The biggest difference tends to be in CPU power and amount of memory; usually you have much, much less CPU available (sub-100 MHz and 8/16 bit is common), and much less RAM (some microcontrollers have under 1K of memory!). They also tend to be very inexpensive compared to SoC devices, and in many cases come in thru-hole versions as well as 5V TTL compatibility (though both of these are rapidly becoming less of an option).

The Arduino Uno and the Arduino Mega use two different, but compatible (in the same family) of microcontroller chips. For the Uno it uses the venerable ATMega328, while the Mega uses the ATMega2560. The difference between the two is great - 32K vs 256K of flash RAM, 2K vs 8K of SRAM, number of pins, number of hardware serial ports, number of PWM pins available, etc. Don't worry about all this now, just know there are differences. Which you select will of course depend on the needs of your project.

The ATMega family of microcontrollers is made by a company named Atmel; which is now a subsidiary (I may be wrong here) of what used to be their competitor, Microchip Technology Inc, which also manufacturers their own line of microcontrollers known as PIC microcontrollers (they are not compatible with each other, but who knows what the future holds now that they are owned by the same company).

There is another company I should mention here, called Parallax. They are really the ones that got this whole "maker thing" ball rolling, when they introduced what could arguably be called the first hobbyist-level microcontroller, called the BASIC Stamp. It was based on a particular PIC microcontroller (from Microchip), with a small amount of extra EEPROM flash memory tacked on, which would load in an interpreter for BASIC, and could be loaded with compiled (tokenized) BASIC code to run. It essentially made the PIC line easier to program for hobbyists (that isn't to say there weren't hobbyists hacking on PICs - it was a big thing back in the early 90s). Introducing the BASIC Stamp, though, opened up a new world for a lot of people, and made microcontrollers for electronics interfacing much easier. Before, you either had to hack in assembler on a PIC, or you had to have access to some form of the 8051 microcontroller/processor line plus toolchain ($$), which was the other big hobbyist platform at the time.

Anyhow - back to Parallax: While they continued with the BASIC Stamp lineup (and IIRC, they still offer it, but it isn't as popular any longer) - they eventually went on to develop their own microcontroller in-house, called the Propeller. It is actually an interesting device, and works in a way unlike virtually every other microcontroller; it can almost be thought of as 7 individual small microcontrollers, each with access to a common memory area, working in a "round robin" fashion (in essence, multi-processing in a manner of speaking). At any rate, it's another option.

Finally, one of the other options you are likely to run into in the wild is known as the ESP8266 (which itself comes in a variety of configurations). This device is closer to an SoC than it is to a microcontroller - but there is a lot of overlap. It was originally developed, IIRC, somewhere in China (probably Shenzhen) and has been cloned out the wazoo all over (hence the vast number of configs available). Originally it was meant as a very simple means to give 802.11 WiFi capability to microcontrollers and other similar devices using a serial port and a modified AT command set. You essentially interacted with it over its serial port, and could send/receive data via WiFi - very simply.

Initially, it was very undocumented, and the little documentation that did exist was in Chinese. Eventually, much of this was translated, and almost overnight it became a hardware hacker's sensation. It was cheap ($5.00 USD or less in even small quantities - still is very inexpensive), it did it's stated job very well, and it was small - it kinda boosted the whole IoT buzz. But there was a ton of power lurking under the hood, and people sought to exploit that.

...and they did! One of the first things to come out of it was something called the "NodeMCU", which was essentially an ESP8266 running Python (hence why it seems to have an overlap between a microcontroller and an SoC) - which made working with it much easier.

Ok - so this is getting kinda long, but hopefully my explanations will help you out. For googling this stuff, use keywords of "microcontrollers", "embedded development", "system on chip", etc. Be sure to check out the official forums for the Arduino and for the Raspberry Pi (and check out the various sub-Reddits and blogs).

For starting out, you've already been given some good advice; just start with an Uno (I would caution about going with a Chinese clone on first time out - please, purchase one of the official boards, to help support the Arduino community and company, then look into the clones - and learn the difference between what a clone is and what a counterfeit is - and go from there). Starting small may seem boring, but it is very easy to be overwhelmed in the embedded and microcontroller space. With only the board, there's only so much you can do with it, so after get your first LED blinking (on pin 13), look into getting a cheap parts and sensors kit (so you can get a breadboard, LEDs, resistors, and other parts to play and learn with).

Good luck!

You just nailed one of my pet peeves. This is what I like about Adafruit's Arduino interfaces and I'm willing to pay a bit extra for: MOUNTING HOLES! Some of us build stuff that moves or vibrates and needs to be held down.

Connectors are not mechanical restraints!

This is identical to a modern laptop where you can hit, say, 10 hours battery life, but the software must be asleep practically all of the time. Anything misbehaving (e.g. Flash, mds) will keep the CPU switched on and waste power.

Smaller micros are less efficient per unit of work but they just aren't capable of running as fast and chewing up a lot of power. You can also compensate for sloppy code by turning down the clock rate.

If you're running a BLE device (not Bluetooth Classic), 500mAh for a week of runtime sounds doable. An iPhone battery is 2-3Ah, and so long as cell modem and screen are switched off, I believe that it would hit a week of runtime.

https://beagleboard.org/green-wireless