A $1, Linux-Capable, Hand-Solderable Processor | Hacker News Reader

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

hackaday.com

225 pointsjohncole99 comments

This makes no sense. (I do electronics)

"Hand-solderable"? Every QFN package is hand-solderable, too, using hot air, and is much smaller than the TQFP. And what is the benefit of "hand-soldering" if you still need to use DDR3 DRAM? It won't come in TQFP, and for good reasons, and good luck connecting it to that Allwinner CPU.

If you want tiny chips that can be hand-soldered, go with microcontrollers (ESP32 or Kinetis), which have everything on-board. You really do not need the overhead, complexity and incidental bugginess of Linux for most things, trust me. Also, choose QFN, not TQFP, use hot-air and have the entire thing soldered in 30 seconds.

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.)

Wirebonding a massive footprint is less yielding. Also the large packages take up more room on JEDEC processing trays in semiconductor manufacturing and leads to higher costs due to low chip/tray throughput. Furthermore, warpage of large packages is of concern and so is inability to ship in Tape & Reel.

All serious stuff in IOT is WLCSP which has an insanely small footprint __and__ z-height.

Maybe they mean it's not BGA?

If you want to hand solder a Linux SoC into a hobbyist project it's generally a whole lot easier and cheaper to stick some headers on and piggyback a $5 Pi Zero or similar board.

Board layout for one of these things and the associated DRAM etc. is not exactly a trivial task either. I really don't think that the sort of person who can't be bothered to set up a toaster oven for reflow soldering is going to be able to make a functioning board using this chip.

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.

You also have to remember, Hackaday is a mixture of true amateurs and semi-pro "hobbyists". People in the latter category would probably be more interested in and capable of designing a fully custom SBC for whatever project they have in mind.

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

Olimex, whose board is mentioned, sells them https://www.olimex.com/Products/Components/IC/A13/ (for 3 EUR, ships from Bulgaria)

For many of these small (cheap) chips that aren't at common distributors, you're probably looking here:

https://www.aliexpress.com/w/wholesale-allwinner-a13.html

I had to deal with theses processors this weekend (Allwinner H3) for a side project (Pandora Box5 Jamma, an arcade system), the documentation is awful, i was unable to find the "real" SDK, the boot0 is a proprietary blob, but i found this awesome project https://linux-sunxi.org if you want to work with these kinds of processors.

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).

Thanks ! i will look into it.

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).

That’s right. I don’t think this is for RTOS.

> The chip in question, the Allwinner A13, is a 1GHz ARM Cortex-A8 processor. While it’s not much

When did 1 GHz cores become "not much" for small embedded systems?

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.

You can run a small touchscreen with an Arduino. You also don’t need a fast processor for a big touchscreen; just enough RAM and a dedicated video chip

Yeah, and that's how you get laggy user interfaces that at least I despise. Spend that 4€ on a better chip.

How did we manage non-laggy user interfaces back in 1995 when 120 MHz single core/single chip, registers slower than modern RAM, and no dedicated graphics processor was top of the line?

By writing lots of optimizations in hand optimized Assembly.

http://www.jagregory.com/abrash-zen-of-asm/

https://www.amazon.com/Windows-Assembly-Language-Systems-Pro...

And by using a highly restricted colour palette, low resolution, no anti-aliasing, etc.

By living without 20 layers of middleware.

With physical buttons instead of touch screens?

“Vive La Resolution!”

It appears for world-class 'small-screen' interface you need a couple of Linux-capable SoC chips and a decent FPGA https://xdevs.com/review/dmm6500/

It's scientifically proven that almost every post-2000 UI has slower response than a DOS input mask.

Displays with relatively simple off-board processing are common, too; you can often run a big display pretty reasonably with a 16MHz Arduino: buydisplay.com

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.

so something it's very wrong, if a CPU at 20mhz can run softly a GUI at 800x600 and a CPU at 1ghz can't

A 1 ghz CPU absolutely can run a smooth touchscreen GUI, I think what OP meant is that it's not gonna be capable of running a snazzy Electron interface or some other trendy framework that makes everything super easy. You can't really afford the overhead that software running on a modern desktop can, so it will require a bit more work.

For reference, the original iPhone CPU was a single ARM11 core clocked at 412 MHz. Obviously it's possible, this Allwinner chip would run circles around that.

> snazzy Electron interface or some other trendy framework that makes everything super easy

Except that Electron is harder to use than pre-.NET Visual Basic, or Delphi, or especially HyperCard. All of the developer convenience of web apps, with all of the great performance of web apps!

I had smooth GUIs made with Visual Basic 3 running on my old 386@40

And my A1200 with a 68020@20 have a pretty smooth GUI

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.

https://linux-sunxi.org/Linux_mainlining_effort#Status_Matri...

What is with the obsession with hand soldering everything? I did all of the pre-production prototyping for a startup several years ago using low temp solder paste, laser cut stencils, and a hotplate.

It was way easier than trying to solder everything by hand. I started out only using the hotplate for the stuff I couldn't get in a through-hole package, but I eventually moved almost everything over to SMD.

> 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.

Also, they may have a soldering iron. They do not have this other stuff.

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.

In my experience, hobbyists always use "hand soldering" to mean using a soldering iron, which is how I was using the term.

From the comments, a complete hand assembly system using a similar chip with onboard RAM (allwinner v3s): https://github.com/petit-miner/Blueberry-PI

Good luck hand soldering the BGA memory which is the only package you're going to find DDR2/3 in.

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.

The problem is QA.

If its non-ball, you can use a magnifying glass to verify.

If its ball, you aren't verifying it. You need xray gear.

I completely agree, I've done a bunch of 100BGAs - it's hard but not impossible, I use a steel mask, solder paste and a cheap reflow oven - alignment just requires a steady hand and good tweezers

We're in an amazing technical availability era. For the nearly same price and form-factor size you can either have a 4 MHz low-power microcontroller working in your custom TV remote controller or a (headless) machine capable of running RetroPie and C-64 games.

And the part that stands out to me is the draw toward the obvious path of least resistance. Why program any of that in assembly, when you can put together a few bash scripts with LIRC?

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 :)

That's pretty much true, but I have to nitpick a bit. Arduino tends to mean an 8-bit AVR chip, say ATmega328. That's actually not very low-power and things get difficult once you need just a tiny bit of performance.

Luckily there are alternatives so you can choose the right tool for the job.

Yeah, the most common boards (cheap Uno/Leonardo clones on eBay/Aliexpress) are AVR, but newer Arduino boards (M0) are based on Cortex-M cores, and there's things like the ESP32 that can be used with Arduino IDE…

Absolutely. I see nothing but benefits from having both options (incidentally was thinking PIC due to power requirements) for a project. But the "hmmm" thought was about complexity of a system as time goes on. Was imagining dozens of unpatched Linux-based devices put on top of other dozens of devices in a system and the maintenance aspect took on a new tone.

It's like you can send an email with a single line of PHP code, which turns into 673 lines of system calls, which turns into thousands of assembly instructions and that's not even counting what happens after it's passed to a mailer - and at some point the complexity of being able to account for every action of a part becomes untenable.

> it should be noted that like all of these random Linux-capable SoCs, the software is a mess

Such nonsense. A13 is almost fully supported in the mainline kernel.

http://linux-sunxi.org/Linux_mainlining_effort

And datasheets are available:

http://linux-sunxi.org/A13

So I'm not sure what the author is missing.

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

The Allwinner SoCs will load U-Boot from a SDcard.

From SPI flash too.

I have a tiny pinout board with a winbond chip hanging off of a bunch of wires from an Orange Pi PC, U-Boot loads from there and network boots FreeBSD. +1 SD card freed! :D

A photo of that wouldn't go astray on here, I don't think.

There's one already on the sunxi wiki: https://linux-sunxi.org/File:Xunlong_Orange_Pi_PC_with_impro...

Mine looks almost the same

Interesting. Wonder why there's someone above complaining about how much of a PITA it is.

They probably haven't upgraded their knowledge about mainline Linux support in the last 4 years or so. It improved a lot!

There's also a pretty good, in some areas even better support from some BSDs.

"There is no HDMI support, you’ll need to add some more chips (that are probably in a BGA package), but, hey, it’s only a dollar."

And a power supply, IO, RAM, ROM, board, etc. The BOM quickly adds up.

I don't know what the price of the RPi CPU is, but my guess is it's not far off $1 in bulk.

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...

Also, you more or less need the binary blob with the license agreement that forbids use on non-Pi boards in order to boot that chip. It runs on an undocumented CPU architecture and initializes a whole bunch of undocumented but essential hardware. There's an open source replacement which is just barely capable of booting Linux and giving a serial console, but the developers basically gave up and recommended people use something like one of the Allwinner chips instead.

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.

It will do, almost every digital IC will require decoupling capacitors for stable operation.

You don't need to wear a seatbelt either. Sometimes thing go slightly less than perfectly though...

That's Allwinner a13

The catch: memory is still BGA, you will save more if you go for slightly more expensive SiPs

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.

I think this is roughly the chip in CHIP, from Nextthing Co; I've got a few floating around my desk. I think the Pi Zero killed their party, haven't looked them up in a while.

But I have a CHIP at a location running autossh for a permanent tunnel into that network...

Ah, went bust:

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

Can anyone explain a real world use?(even a DIY use)

What would you use Linux for when embedded systems usually are written in mostly C.

Easier libraries and access to web? I cant quite understand how this can be used.

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.

Yep, write all of your lower level components in C to run on PICs (or HDL on FPGAs, either way you get high reliability) and have those interface with larger systems that run higher level software to display sensor data and offer a control panel to command the actuators in the system. Just like in a car, the collision detector runs fast low level C but it feeds data over CANbus back to the ECU which is probably running an RTOS and sends that sensor data to the head unit which probably runs some sort of Linux-flavor to blink an icon on the reverse camera video feed.

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 ..

Yeah, that's one of the main things I'm looking at this for. I'm working on some new synthesizer code (written in Rust). If someone else is looking to make an inexpensive audio board with this part, we should talk.

Hey - just to ping you on this, your project sounds pretty interesting - any chance you're interested in some feedback/collaboration from another synthesist? I've been in the game for some time now and your project sounds very interesting - will you put out some info on it some time soon?

I'm in that business and am currently actively working on the same sort of project. Maybe we should talk... (Email is in my profile..)

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.

> Embedded guys aren't as cheap as python/javascript programmers

Not sure this is true. It should be the case, but afaik the salary polls don’t support that.

Depends on the area and lots of factors. I only know that in San Diego I had to take a job for low 140's as an embedded guy and I could have leveraged by Django experience to make over 10k more if I wanted to pigeonhole myself as a Django guy. I'm regularly tempted to go into devops because the job is generally easy and the pay seems to be pushing 200k around here.

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.

It isn't anywhere close in perf but the i.MX23 is also in a 128 pin LQFP package.

https://www.digikey.com/product-detail/en/nxp-usa-inc/MCIMX2...

I think this was actually the SoC that launched the original OLinuXino project from Olimex: https://www.olimex.com/Products/OLinuXino/iMX233/open-source...

OLinuXino project started with iMX233 from Freescale for several reasons: this is ARM9 processor running at 454Mhz with enough power to run linux and still in handsolder friendly TQFP package, which allow hobby DIY approach. iMX233-OLinuXino-MICRO is even on 2 layer PCB and running at full speed. The maximum memory of 64MB though limited the applications with it, so we were looking around for something more powerful when A13 from Allwinner came along.

(https://github.com/OLIMEX/OLINUXINO)

"Hand solderable" is a relative term. BGAs are often easier than soldering TQFPs.

I haven't soldered in a while, but back when I did it for a living, I could've soldered that package entirely by hand in under a minute.

Just flux, tack the corners, and then run a blob of solder down the leads. Super easy once you get the hang of it. It's amazing how good you get at tasks when you do them 8 hours a day.

Really!? For me it is trivial to solder a TQFP chip (quite quickly with flux, but it is doable even without flux). On the other hand I do not trust myself to do BGA by hand placement (presumably with solder paste from a stencil and whether with heat gun or a reflow oven). Am I missing something?

You're not. BGA is a pain in the ass, and unless you have an X-ray device to check solder integrity you're going to always be wondering if that last heat cycle took successfully or not.

BGA with a sane pitch size and not too many balls is feasible with a basic reflow setup if you have boundary scan and functional testing. The guy who created tinyFPGA did it-- https://theamphour.com/395-an-interview-with-luke-valenty/

By the time you got more than 1 BGA in the BOM however, it's time to seriously consider an assembly service.

Question for you: how much flexiblity is there in the connection points on these surface mount components? Unlike DIPs seems any heat expansion or mechanical flexing would break the connections.

I don't think it's a matter of flexibility but rather rigidity. One of the products I work on has a BGA with over 1400 balls at a very fine pitch (smt done at contract manufacturer with serious machines, of course).

The really high ball-count devices always go on thick multilayer PCB's (ours has 32 layers). Mechanical flexing certainly can break connections but that requires a significant force that "should never" been seen in the field.

BTW, one way to troubleshoot for already existing poor connections on a BGA (other than using boundary scan) is to blast it with cold spray or push down on it while running a test. If it stops working or suddenly starts working, you know you have a problem. The cold-spray/heat-gun/press-down troubleshooting techniques won't hurt good connections.

These things can be a pain in the ass, but a properly soldered BGA on an appropriate board with appropriate heat sinks and fixturing is very reliable-- they're everywhere.

I'd rather throw a board in a reflow toaster oven than try to hand-solder that monstrosity.

Yes, the Allwinner A13, inside many low-end tablets. Tablets around $50 from two years ago probably had an A13 inside.

Reply on news.ycombinator.com