> In addition, its processor includes two 200-MHz microcontrollers that allow you to implement low-latency, real-time functions while still having the capabilities of a Linux system.
This is brilliant. Inter-processor communication [1] feels quite like programming GPGPU. I wish there was a way to allow one of RPi's VideoCore unit to access external IO.
It really is a great addition; there have been a few SoCs that packed an ARM Cortex-M core or two alongside the big Application processor, and some FPGAs come with small MCU sister cores. But gee, if I could produce BGA boards, I would be making one tomorrow with:
- 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 :/
(Late edit) Okay, about the small onboard MCUs, I looked a bit more into it, and these 'co-processors' actually look very limited and built into the Cortex-A8 silicon. They only support like, a single UART peripheral and very little else, and appear to be a custom RISC architecture.
Still, it's a promising step. The ESP8266 used a bullshit processor core and still became really popular.
For me, the biggest thing with these small linux boards is the toolchain and major distro support. I prefer making my own custom images for "production" projects.
With Raspberry Pis, you can debootstrap with raspbian, but mainline debian still requires some work [1][2] to make it function 100%.
Does anyone have any information about building custom images for the Beaglebone line of boards? Is it easier or better supported? Are there any boards out there HNers prefer for their toolchain?
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.
Yes, Nerves is an Elixir project. Essentially it’s a wrapper around Buildroot + Elixir based runtime stack + Firmware management. Extremely convenient and could be helpful for the OP as there’s good support for Beaglebone’s, but you do need to know/write some Elixir to use it.
Though it’s entirely possible to have Elixir run say python or any other scripting language via ports. Perhaps one day someone will make a general purpose runtime image from it.
TI maintains a SDK for their Sitara chips/boards, and it has mainline kernel support. There is also the Yocto Project, which TI included a BSP layer for.
I followed Olimex's instructions [1] for their AM352-SOM, which is very similar to the BBB. From those instructions it's not difficult to build a working kernel, u-boot and debian-based rootfs.
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.
Yocto and Buildroot support the BeagleBones out of the box. If you can use menuconfig, you can use Buildroot to get going in half an hour or so. Yocto takes a bit more work, but you have far more flexibility.
What kinds of use-cases do people have in mind for this board? The 1GHz processor and 512MB RAM seem a bit like overkill for everything I can come up with. Although I think I'd still consider hopping on it if it included wireless.
I probably waste way more power at home by keeping the lights on, but I always get a bit frustrated with how much power some of these boards use. It adds up! My college professors probably drilled power management way too hard into my head.
It's basically perfect for building anything in the drone or industrial control space because you can use the same monolithic IC that's on there, on low-quality boards that don't need expensive impedance control or 8 layers.
It's actually a pretty huge development as far as electronics go.
Those benefits are mostly a feature of the Octavo SIP (I think!)
Unfortunately in my case, I want to use it in a product with wired ethernet, so a PocketBeagle limited to a USB or SPI ethernet device because the it doesn't expose the pins for the AM335x's integrated MAC.
Also, buying the Octavo chip alone in small quantities is much more expensive than the whole PocketBeagle :( I wish they made a PocketBeagle-Pro with all signals routed out through high-pitch headers, comparable to Olimex's AM3352-SOM.
This particular board is a subset of the larger boards in the Beaglebone family. Boards like the Green include wifi, and the superset/parent board Black has USB host ports, HDMI output, and Ethernet connectors.
The Black has open-sourced schematics that can easily be edited into your own project. The Beaglebone design philosophy (start with this design and expand on it) is slightly different than the Raspberry Pi one (shoehorn it into whatever you are doing)... which is exciting to embedded developers but confusing to people that have only worked with the RPi.
> What kinds of use-cases do people have in mind for this board? The 1GHz processor and 512MB RAM seem a bit like overkill for everything I can come up with.
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.
But you do have to use the full price, and power/energy requirements of the board, so I think it's a valid question; where is this balance of price/power/capability useful?
Development/prototyping is an obvious one of course.
I agree - this doesn't make sense for many types of mobile-type applications.
But you'd really consider this for really anything that has substantial direct user interface requirements (ie has an actual GUI + full keyboard and maybe even touchscreen interaction).
Or maybe you might use this somewhere where you're not super BOM cost or power constrained, with fuzzy requirements, and limited developer resources. Using this class of hardware opens up using 'standard' Linux tools which can potentially bring great savings in terms of: portability, availability of developer resources, ease of development. There may be applications where a 5-10x increase in BOM cost in exchange for not having to hire an embedded guy might be worth it.
I think the PRUs are the unique selling point of Beagles. So basically when you need both hard(ish) real time and full Linux stack. Neat example what you can do with that:
I use the Beaglebone Black running NodeRED to (gently) teach my kiddos about flow-based programming. All while it provides a HomeKit interface to my ISY/Insteon/Hue home automation accessories.
I have soldered a second USB connector on one and plan to use it as a lazy-person's means of doing some HID (trackball) remapping, though I've not had the time to actually work on that. My current stumbling block was how to keep the included ethernet/serial usb gadget support active while adding a HID usb gadget. I'd rather not have to actually hook up hardware serial to the board if I can avoid it.
It's nice to be able to do a one-off thing like that with high-level tools.
Problem: when a certain alarm condition occurs, an LED on the control panel needs to blink.
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.
Here's my counter-argument in case you were serious.
Dimwit #1: 555's fail when hell freezes over. An engineering intern can make changes and see it work. The PCB will cost more than the electronics. 555 as a component will be available for years.
Dimwit #2: Arduino/ATMEGA are so well documented that the next engineer supporting this should have no problem making appropriate changes even 10 years from now, assuming Microchip sustains the ATMEGA product line.
Senior Software Developer: You've introduced an attack vector [the web interface], increased the BOM cost [the Linux board], programmed it in a language that changes on a yearly basis [node.js]. Not to mention having to provide a Linux image source programmable [preferably eMMC], and ensuring compatibility of the web config for major browsers for the lifetime of the product. All for a blinking LED.
Dimwit #-2: Hey, we already have a microcontroller on this board, and it happens to have plenty of free flash/ram/10mA-sink-gpio. Specify a regular LED and an extra timer in RTOS.
Often the extra horsepower is cheaper than developer time.
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.
You get compression at the low end. It’s not especially cost effective to maintain manufacturing capacity for a bunch of similar designs. If I can make better margins on a $5 part than I can my $4.25 part I’m going to be really tempted to shut down that line and make more of the other or a higher margin chip.
That’s part of the story with Linux on BIOS. Motherboards started shipping with EEPROMs that were 2-4x larger than the BIOS would ever get, as big or bigger than typical rescue disks.
Folks, this is a family of boards with the same CPU but different capabilities. Just because there's no PHY on the smaller board doesn't mean the SoC doesn't support it.
I was just joking. I know about the BB family; what I meant is that such boards support, contrarily to the rpi3, EITHER wlan or ethernet out of the box; not both. I think it's quite a shortcoming for a modern board with such price tag.
And, as I said above, Beaglebone boards should be the means for your project, not the end.
If you're new to embedded and your design philosophy to date has been "squeeze the RPi into whatever I'm making", then Beaglebone (and other embedded EVKs like this) are going to make you grind your teeth and complain about the cost/feature vector instead of figuring out how to use it to help your final design.
I have worked with rpis, BBB, and custom board basted on the latter. I understand what you're saying, customizing a RPI requires working with an external partner. At the same time, I don't agree that such solutions won't work for a final product. There're many untapped opportunities in the embedded/iot space that benefit from a stable, tested, prebuilt solution that you can buy at will even in small batches. In that context, I'd like a full-fledged, highly flexible solution with many features instead of having to choose one or another.
I don't agree that such solutions won't work for a final product.
You would seriously pin your production on the availability of a board from a single vendor and an SoC from a company that won't even talk to you or sell their parts on DigiKey?
We all want a $25 board that does everything. We all also want a pony. The unsubsidized reality is that things cost a bit more than the RPi spectrum in the real world.
> You would seriously pin your production on the availability of a board
If I need >10k pieces, possibly not. If I need 500/1000/5000 pieces... yes, sure. I'll buy a buffer of boards to handle possible upstream production issues, and live happily ever after.
My product is tied to an OS, and my software is got a decent layer of abstraction. If, tomorrow, my supplier stops giving me what I want, I'll switch to a different hardware and I'll retain the same software. Or, I should say: IFF my supplier stops.
Open schematics and kernel source. Publicly available SoC.
If you want a one-off for a little hobby project, then RpiZ is just fine. If you are developing a commercial product and don't want to be at the mercy of RPi or Broadcom for your parts and availability, you go with something like BeagleBone.
Just wish Beaglebone and its variant were as accessible as RPi. I can right now pick up an RPi B3 from any number of regional stores, yet i have to order Beaglebone from abroad (and deal with all the customs and whatsnot that comes with that).
Beaglebone is not nearly as well supported as raspberry pi, but it is second. There are enough interesting things that I think more people should be using it instead of defaulting to raspberry pi. Depending on what you want to do the beaglebone is better supported than the raspberry pi (your are more likely to find kernel support for example)
I wish the day came sooner when we could use linux for power-constrained devices, leaving the classical embedded approach behind. I imagine it for about $20, with BT, lasting for a week on a 500mah battery and running OpenWRT/LEDE.
You can use Linux for this sort of thing, but you have to be very careful with the software stack.
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.
While I love the BeagleBone Black (and have built a number of boards for it), the SIP (Octavo OSD335x-SM) in these is just too expensive. The SIP currently sells for $43.73 on Digikey (it only gets down to around $25 at volumes >1K).
Given the lack of ethernet, Wifi/BT/BLE this really ought to be below or at $10 mark (at most!) to make it cost effective for designs.
Digikey has the AM3358 for $13.51@Q500. I'm sure Octavo gets a much better price with their volumes, but this was never going to be a $10 part, especially considering all the other stuff that goes on the package.
Thanks kens! I had puzzled out some of that but putting it all together was really helpful. I have a mobile robot base that has evolved over the years with a 68HC11 (miniboad) brain, then an AtMega (Arduino) brain, and now a Cortex A-8 (pocketbeagle) brain. The most challenging thing has been how the same functions are different kernel to kernel in Linux (I would expect that from OS to OS but the changes from 3.x to 4.x in Linux were fairly wide ranging (I know, major numbers are for that but still it slows me down to have what I know get invalidated :-)).
I used a couple of opamps to increase the voltage range for the A/D's to 5V to be compatible with the sensors on the robot base. That is pretty straight forward but the 'reverse' of what I normally do with an opamp (trying to go small signal to large vs a 5v swing to small.)
It's nice that it's little and cheap. Since it's useless without things plugged into it, it needs good ways to mount other stuff to it. Please, when you design things like this, think of that. There are boards out there with connectors on all four faces and no mounting holes.
(I wish the free version of QNX was still available. Linux is the wrong tool for the job for embedded.)
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.
I love reading about projects like these, but most of the language and what's happening goes right over my head!
Anybody have any recommendations for how I can finally start get into, I don't even know what to call this - generalized IoT hardware hacking? Hobbyist hardware? Arduino/RasperryPi tooling? No idea, but it's on my list of 2018 goals to build some at least basic projects on these platforms.
(Ironically I do work at an IoT company, but our platform is a little more simplistic - plug in some component to one of the dev boards, then just write squirrel code. I want to learn the juicy stuff!)
A Raspberry Pi is usually just used as a Linux machine, with the addition of some libraries to handle the IO pins. If you're at all familiar with Linux, it's a relatively easy way to start playing.
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.
Knowing the terminology will help you to find resources.
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 r...
Woah, thanks for the detailed response and mini-history!
Out of curiosity, is there something special about pin13 that everyone recommends using it specifically for blinking a light (assuming other pins can do the same thing?) I ask because on the dev boards I've stolen from my company there's only "pin 2" and "pin 5" for uh, "doing stuff" on (like all our example code is based off that, and they got grove connectors stuck on them).
"The PocketBeagle is a tiny but powerful key-fob-sized open source Linux computer for $25. It has 44 digital I/O pins, 8 analog inputs, and supports multiple serial I/O protocols, making it very useful as a controller."
s/open source Linux computer/computer than can run Linux and other open source kernels/
65 comments
[ 4.3 ms ] story [ 128 ms ] threadThis is brilliant. Inter-processor communication [1] feels quite like programming GPGPU. I wish there was a way to allow one of RPi's VideoCore unit to access external IO.
[1] http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_...
- 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 :/
Still, it's a promising step. The ESP8266 used a bullshit processor core and still became really popular.
Mac video driver: https://trmm.net/Mac-SE_video
Led matrix: https://trmm.net/Octoscroller
More, including audio: http://bela.io
With Raspberry Pis, you can debootstrap with raspbian, but mainline debian still requires some work [1][2] to make it function 100%.
1: https://github.com/drtyhlpr/rpi23-gen-image 2: https://wiki.debian.org/RaspberryPi
Does anyone have any information about building custom images for the Beaglebone line of boards? Is it easier or better supported? Are there any boards out there HNers prefer for their toolchain?
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.
Though it’s entirely possible to have Elixir run say python or any other scripting language via ports. Perhaps one day someone will make a general purpose runtime image from it.
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
I probably waste way more power at home by keeping the lights on, but I always get a bit frustrated with how much power some of these boards use. It adds up! My college professors probably drilled power management way too hard into my head.
It's actually a pretty huge development as far as electronics go.
Unfortunately in my case, I want to use it in a product with wired ethernet, so a PocketBeagle limited to a USB or SPI ethernet device because the it doesn't expose the pins for the AM335x's integrated MAC.
Also, buying the Octavo chip alone in small quantities is much more expensive than the whole PocketBeagle :( I wish they made a PocketBeagle-Pro with all signals routed out through high-pitch headers, comparable to Olimex's AM3352-SOM.
The Black has open-sourced schematics that can easily be edited into your own project. The Beaglebone design philosophy (start with this design and expand on it) is slightly different than the Raspberry Pi one (shoehorn it into whatever you are doing)... which is exciting to embedded developers but confusing to people that have only worked with the RPi.
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.
Development/prototyping is an obvious one of course.
But you'd really consider this for really anything that has substantial direct user interface requirements (ie has an actual GUI + full keyboard and maybe even touchscreen interaction).
Or maybe you might use this somewhere where you're not super BOM cost or power constrained, with fuzzy requirements, and limited developer resources. Using this class of hardware opens up using 'standard' Linux tools which can potentially bring great savings in terms of: portability, availability of developer resources, ease of development. There may be applications where a 5-10x increase in BOM cost in exchange for not having to hire an embedded guy might be worth it.
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?
Here's my counter-argument in case you were serious.
Dimwit #1: 555's fail when hell freezes over. An engineering intern can make changes and see it work. The PCB will cost more than the electronics. 555 as a component will be available for years.
Dimwit #2: Arduino/ATMEGA are so well documented that the next engineer supporting this should have no problem making appropriate changes even 10 years from now, assuming Microchip sustains the ATMEGA product line.
Senior Software Developer: You've introduced an attack vector [the web interface], increased the BOM cost [the Linux board], programmed it in a language that changes on a yearly basis [node.js]. Not to mention having to provide a Linux image source programmable [preferably eMMC], and ensuring compatibility of the web config for major browsers for the lifetime of the product. All for a blinking LED.
Although I'd use a tiny micro or a blinking diode by now.
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.
That’s part of the story with Linux on BIOS. Motherboards started shipping with EEPROMs that were 2-4x larger than the BIOS would ever get, as big or bigger than typical rescue disks.
https://beagleboard.org/green-wireless
https://beagleboard.org/black
Folks, this is a family of boards with the same CPU but different capabilities. Just because there's no PHY on the smaller board doesn't mean the SoC doesn't support it.
If you're new to embedded and your design philosophy to date has been "squeeze the RPi into whatever I'm making", then Beaglebone (and other embedded EVKs like this) are going to make you grind your teeth and complain about the cost/feature vector instead of figuring out how to use it to help your final design.
You would seriously pin your production on the availability of a board from a single vendor and an SoC from a company that won't even talk to you or sell their parts on DigiKey?
We all want a $25 board that does everything. We all also want a pony. The unsubsidized reality is that things cost a bit more than the RPi spectrum in the real world.
If I need >10k pieces, possibly not. If I need 500/1000/5000 pieces... yes, sure. I'll buy a buffer of boards to handle possible upstream production issues, and live happily ever after.
My product is tied to an OS, and my software is got a decent layer of abstraction. If, tomorrow, my supplier stops giving me what I want, I'll switch to a different hardware and I'll retain the same software. Or, I should say: IFF my supplier stops.
BTW, custom RPIs are possible https://www.element14.com/community/docs/DOC-76955/l/raspber... and element14 will even talk to you! (yes, I've received quick response emails from them! really!)
If you want a one-off for a little hobby project, then RpiZ is just fine. If you are developing a commercial product and don't want to be at the mercy of RPi or Broadcom for your parts and availability, you go with something like BeagleBone.
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.
Given the lack of ethernet, Wifi/BT/BLE this really ought to be below or at $10 mark (at most!) to make it cost effective for designs.
I used a couple of opamps to increase the voltage range for the A/D's to 5V to be compatible with the sensors on the robot base. That is pretty straight forward but the 'reverse' of what I normally do with an opamp (trying to go small signal to large vs a 5v swing to small.)
(I wish the free version of QNX was still available. Linux is the wrong tool for the job for embedded.)
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!
Also, OpenBSD is another potential option (assuming the BBB and the Pocket are similar enough): https://www.openbsd.org/armv7.html
This has always made the BeagleBone systems relatively attractive to me... my litmus test for "open" includes running more than just Linux.
Anybody have any recommendations for how I can finally start get into, I don't even know what to call this - generalized IoT hardware hacking? Hobbyist hardware? Arduino/RasperryPi tooling? No idea, but it's on my list of 2018 goals to build some at least basic projects on these platforms.
(Ironically I do work at an IoT company, but our platform is a little more simplistic - plug in some component to one of the dev boards, then just write squirrel code. I want to learn the juicy stuff!)
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 r...
Out of curiosity, is there something special about pin13 that everyone recommends using it specifically for blinking a light (assuming other pins can do the same thing?) I ask because on the dev boards I've stolen from my company there's only "pin 2" and "pin 5" for uh, "doing stuff" on (like all our example code is based off that, and they got grove connectors stuck on them).
s/open source Linux computer/computer than can run Linux and other open source kernels/
https://mail-index.netbsd.org/port-arm/2017/10/23/msg004423....