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
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
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?
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.
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.
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!
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 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.
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.
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.
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?
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 :)
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.
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…
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.
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.
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).
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
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.
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.
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?
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.
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.
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
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...
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.
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
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.
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.
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.
"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.
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.
101 comments
[ 3.6 ms ] story [ 152 ms ] threadWhen did 1 GHz cores become "not much" for small embedded systems?
My guess would be that a lot of of embedded things like kitchen appliances tend to run touchscreens with graphical interfaces these days.
http://www.jagregory.com/abrash-zen-of-asm/
https://www.amazon.com/Windows-Assembly-Language-Systems-Pro...
Really though, I don't think the SOC is that bare bones either.
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.
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!
And my A1200 with a 68020@20 have a pretty smooth GUI
By the time you got more than 1 BGA in the BOM however, it's time to seriously consider an assembly service.
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.
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.
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.
Anyone have a drawing? Curious if it NEEDS capacitors to function.
https://github.com/raspberrypi/firmware/blob/master/boot/LIC...
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?
Having a full unix-like OS can actually add "resistance" compared to that :)
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.
Luckily there are alternatives so you can choose the right tool for the job.
Why not? Power budget, simplicity, security.
I also have a light hammer, a medium sized hammer, and a sledgehammer in my basement.
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.
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.
https://www.aliexpress.com/w/wholesale-allwinner-a13.html
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.
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.
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.
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.
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 ..
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.
Not sure this is true. It should be the case, but afaik the salary polls don’t support that.
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.
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.
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
Mine looks almost the same
There's also a pretty good, in some areas even better support from some BSDs.
But I have a CHIP at a location running autossh for a permanent tunnel into that network...
https://en.m.wikipedia.org/wiki/CHIP_(computer)
The catch: memory is still BGA, you will save more if you go for slightly more expensive SiPs
If its non-ball, you can use a magnifying glass to verify.
If its ball, you aren't verifying it. You need xray gear.
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.
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.
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.
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.
"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.
All serious stuff in IOT is WLCSP which has an insanely small footprint __and__ z-height.
https://www.digikey.com/product-detail/en/nxp-usa-inc/MCIMX2...
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)