A $1, Linux-Capable, Hand-Solderable Processor

I don't think manufacturers offer QFN packages in this high a pin count. Not sure why. Presumably there's some kind of manufacturability issue that TQFP doesn't suffer from. (The much smaller PMIC that's designed to be partnered with this is QFN though.)

Maybe they mean it's not BGA?

despite being unable to disagree with you there still might be a few hardcore hobbyist hackers outside who still want to get such a task done just for the sake of it. As long as it makes fun, right? You don't always have to achieve useful stuff. Also getting something like this done might not even be useless. It trains a lot of skills nevertheless.

PS: Don't take hackaday articles too serious, there are some really really talented people among that community and it is always great to see if someone gets some really great (over)engineering done.

Also, none of these webpages mention where to get it and it's not on the really common distributor websites (Digikey, Mouser).

You don't need an "SDK" for a general purpose computer. Always check mainline U-Boot and mainline OS (Linux, BSD) first. (For Linux, check distributions like Armbian and ArchLinuxARM.)

I don't think there's generally much reason to use Allwinner's boot0 on H3 or older, since mainline U-Boot has supported those chips for a couple of years now. In principle you can even just run Debian on them (though I don't think they build installer images for anything that new right now, and most people use Armbian for its better user experience).

The Armbian guys have done a ton of excellent work in this area as well (they start with sunxi and take it the rest of the way)

This is intended to run Linux, its not a microcontroller-level device. The project you point to is the basis of what is in mainline (I believe now).

It barely even manages to run node.js in a docker! /s

My guess would be that a lot of of embedded things like kitchen appliances tend to run touchscreens with graphical interfaces these days.

The microarchitecture matters. Even ARM's out of order reference cores are very slow compared to intel CPUs. Now take an obsolete decade old core at mediocre 1 GHz and you suddenly have something that is cheap but also extremely slow compared to even a raspberry pi 3 which is also slow as hell.

I think they are referring to the features of the SOC there. They follow it up with a mention that it doesn't have an HDMI controller on chip, I don't think it has an Ethernet controller either.

Really though, I don't think the SOC is that bare bones either.

Since quad-core Cortex-A53 chips kinda became the norm.

> What is with the obsession with hand soldering everything?

My guess it is because it's the only thing a lot of people who are not used to doing hardware (like me) has dabbled with, and so it looks simpler/easier on the surface.

Isn't what you did hand-soldering? Sure, you didn't pick up an iron and wire solder, but still.

You can see how that's a lot more hand-soldered than a board which is pasted by machine, then fed into a pick and place machine, then fed into an oven.

Wait, the memory isn't in that huge package? Jeez.

Yeah there is a reason they have BGA and other packages, and part of it is just the huge lead inductance of those old (T/L/...)QFP packages. Routing DDR3 is no fun no matter what but this is just making your life extra difficult for no good reason.

DRAM packages don't look TOO terrible, you could probably do it by hand with a mask, solder paste, a heat gun and a fair amount of patience. Alignment is the big issue, but your standard DDR3 package is 96 balls with a high enough pitch that you could eyeball it.

Why Linux? Sometimes it's nice to have an OS to take care of all the BS for you.

Why not? Power budget, simplicity, security.

I also have a light hammer, a medium sized hammer, and a sledgehammer in my basement.

It always depends on your goal. If you want a quick prototype and are good with javascript, get a board that you can program easily with javascript. But maybe you want to learn how things really work on a low level. Or maybe you prefer to run on batteries for a long, long time. Or perhaps you need the system to have a constant low latency.

It's like, why use other programming languages when $lang is so good. But there's always a possible reason. In the end everything is a compromise.

That, by the way, is what's great about Arduino. Super low power microcontrollers, native C/C++ code, and a "least resistance" experience — well documented, popular, easy to use libraries for all peripherals.

Having a full unix-like OS can actually add "resistance" compared to that :)

How do you bootstrap the thing? Kernel support is rarely the primary issue with SOCs.

Broadcom has a very high minimum order quantity. There's also an onerous license that won't allow you to use the Rpi software if you build your own broadcom board.

https://github.com/raspberrypi/firmware/blob/master/boot/LIC...

This was my thought, its cool, but you will still need to buy things for power management at a minimum.

Anyone have a drawing? Curious if it NEEDS capacitors to function.

The V3s is much better for this goofy use case because it has onboard RAM so you can bring up a truly hand soldered machine with it.

Ah, went bust:

https://en.m.wikipedia.org/wiki/CHIP_(computer)

I am working on industrial level sorting machine. That machine use Linux device to control other subsystems (cameras, conveyor belt controller, various servos and what not). As number of components in systems grow you want to have single place for all the logging, handling user inputs (both local and remote), calibration and even system upgrades.

Not everything is written in C. On a project I recently worked on we opted for Linux on the embedded platform to support some 3rd party tools and allow ourselves to work in easier-to-prototype languages.

Additionally, the management of the device is now “just Linux”, which is fairly Elmore well known.

——

In retroperspective, I don’t know if I would do it in the future. There are definite advantage in using Linux, but there is also a lot of work involved in understanding Linux and keeping track of the platform. That is true for a simpler OS, but I feel it might be more manageable.

For me? I can have a solid, partitioned filesystem like ext4 running on NOR or NAND flash. I don't have a decade to write my own and make it as stable as what's already out there.

I can also have the system live-mounting USB flash drives (useful for logging and field upgrades) and reading/writing FAT16/FAT32/NTFS out of the box. If I wanted to tack a SATA drive on there, I can do that too.

Oh yeah, and I get a bash shell to manipulate it all on the target device. That's another couple of years saved.

Getting a lot of drivers, a functioning network stack and all those other neat things in one package is really comfortable. And if it is connected to the internet (and an actual product) it might need an update, which should be easier to do with a full-fledged system underneath it then writing everything yourself. Sure it is overkill for a lot of stuff, but as IoT grows by the second there are more than enough use cases for embedded linux

Fantastic platform on which to base a synthesiser, music effects module, or some other such creative device.

The synths from Modal Electronics are some good examples of what you can do with an embedded Linux system .. they're using a $25 part as the prime host for their OS, for example ..

Developer time is expensive. Embedded guys aren't as cheap as python/javascript programmers. If you can grab an off-the-shelf solution that, say, already runs android, you can pay a high-school graduate to whip up an android app and have your embedded product on the market for less time and money.

That said, as an embedded developer, I think there are a lot of bad products thanks to this mentality. But it is the future and it's one reason I try to keep my skill set up to date.

Can't speak to this particular processor, but as far as why use Linux? Yes, it's about working at a higher level of abstraction.

I'm right now finishing up a freelance job: a pump controller that could easily be done in C on an Arduino.

I chose to use an RPi programmed in Python because I could eliminate a bunch of pushbuttons, the associated wiring and a complex menuing system by using a touch screen and a Tk GUI. In this case it's about getting the job done with minimum development effort; the BOM cost is pretty much irrelevant.

Remember, the term "embedded system" encompasses a huge amount of variation in project complexity.