7 ms·
My father still uses assembly language, on 8-bit Motorola (now NXP via Freescale) microprocessors. He's ben doing it since the early 80s, for data monitoring an
by tomhoward 4y ago
My father still uses assembly language, on 8-bit Motorola (now NXP via Freescale) microprocessors. He's ben doing it since the early 80s, for data monitoring and control devices for various applications in agriculture, industry, academia and other sectors.
I've been working with him for the past few years to modernise his products and give them a future beyond his retirement, which is finally happening now (he's 74).
The device we've been working is an agricultural data monitor that reads from sensors in the soil and atmosphere (measuring impedance, voltage, pulse and digital signals), stores it in local flash memory then periodically uploads it via to my web app via a U-Blox cellular/IoT modem.
It's amazing what he's been able to make it do, and how simple/cheap the componentry is and how low the power consumption is. And whilst the coding and debugging is pretty slow and laborious, once it works, it's incredibly reliable and stable.
Now he's retiring, if the business is to continue we'll basically have to find someone who can migrate it to higher level platforms and languages. There aren't many (any?) people around willing/able to work with this kind of assembly code these days.
It feels like a shame. Other players doing this kind of work use higher-level platforms, which may be faster to develop for and debug but are more costly to manufacture, use more power and are less reliable.
I'm hoping we can find a balance between the easier/faster development cycle of newer platforms, whilst retaining at least some of the simplicity and elegance of my father's approach.
- MrYellowP 4y agoMate, how does this "migration" look like (I have no idea how to imagine it) and what platforms are you writing of?
- SnowHill9902 4y agoWhy do you have to “migrate to higher level platforms and languages”? Assembly is perfectly valid for this application.
- tomhoward 4y agoIf we could find developers willing/able to do it, I'd happily stick with it. Such people are hard to find, but anyone reading this who is interested, feel free to get in touch (email address in profile).
- GartzenDeHaes 4y agoI imagine it's a lot easier to find someone to hire with python (picopython) or c# (nano .net framework) skills.
- tomhoward 4y agoThat's what other players in the space do. I'd happily settle for C, in which case we wouldn't need to change the hardware much.
- the_only_law 4y agoSerious question, do these run on stuff outside of “toy MCU’s” almost everytime I hear them mentioned it’s in the realm of education, hobbyist stuff, etc.
- dmonitor 4y agoThe Arduino portenta boards are pretty powerful. I just don't see where you would want to use one instead of a full OS
- ddingus 4y agoThe full OS is what blows the power budget.
- GartzenDeHaes 4y agoThat's not my area of expertise, I was commenting on the hiring side. Maybe OP could use those "toy MCU's" as bait to attract some college interns? They might get lucky.
- alfor 4y agoC is much better for this now, you are not tied to the processor architecture and thus can switch to a better/cheaper cpu easily. The cell modem he is using already has a 32 arm cpu maybe even multi-core. 32bit it the new 8bit. C is the new assembly for 99% of code. You can drop to assembly for the 1% where it matter.
- tomhoward 4y agoYep, that's exactly what we've been talking about.
- StillBored 4y agonot tied to the processor architecture and thus can switch to a better/cheaper cpu easily. The core processor arch yes, but for many (most?) of these small embedded systems, a large part of the code is basically device drivers used to communicate with GPIO, a plethera of serial buses, and any number of other devices which vary from microcontroller to microcontroller. So unless you offload all that to a RTOS of some kind (which your then limited to devices the RTOS supports) switching devices isn't easy. And for many things, the RTOS overhead will be the largest consumer of CPU+RAM. That is sorta the beauty of the ardunio ecosystem were much of this has been abstracted into common libraries across a number of device families.
- alfor 4y agoState machines in C work great when you don’t want a preemptive RTOS. I did a embedded project on 8051 like that, we had the legacy code 100% in asm and we moved to C. In the end I think we had about 10-20 lines of asm and everything else in C. You are right switching cpu and thus all the peripheral is major headache, not something to take lightly.
- deleted 4y ago[deleted]
- Johnythree 4y agoIs relatively trivial. Have done it countless times since the early '80's. In fact I find that learning new high level packages much harder.
- blibble 4y agohis company eventually did mobile ports of some of his games I'd be interested in knowing how they did that as it was all x86..!
- dgb23 4y ago> Other players doing this kind of work use higher-level platforms, which (...) are less reliable Is my assumption right that the reliability of these programs is based on the proficiency and expertise of your father, rather than being a platform/language issue? Or do these platforms come with complexity that makes them more fragile in your opinion?
- tomhoward 4y agoIt's not specifically about my father's proficiency/expertise. (There's a quirky brilliance to the way he builds this stuff, but it's unconventional. He's an electronics engineer, not a computer scientist; he taught himself assembly language when the 6800 micros came out in the 70s, and has never felt the need to learn newer techniques). So yeah, it's more about the newer platforms having more hardware and software abstraction layers, so more things that can break and they have much higher power consumption. In our applications, the weakest links are always the more "modern" communications modules, of which we've used Bluetooth and Cellular/IoT. In both cases, they are high-level SoC devices, with all kinds of capabilities and the ability to run BASIC or Python scripts on them. But they turn out to be much less reliable than our assembly code on the basic micros we use, and are the source of almost all device faults. To illustrate the real-world advantage of the way we do it: our biggest competitor (a significant player that has shipped thousands of devices globally), uses a more modern/high-level platform (I don't know what exactly - it may be Arduino). One of our customers was given one to try out. Like most of our customers, they wanted data uploaded to the web app every 60 or even 30 minutes in order to have precise visibility of their soil moisture throughout the day. Ours can do that, running on just two 3.7V Li-ion cells that last for 1-2 years per charge. For the competitor product, to upload more than twice a day, it needs a solar panel, which needs to be mounted high up on a post above the crop. But that's a deal-breaker for this grower and many others, due to the use of pivot sprinklers and machinery.
- hnthrowaway0328 4y ago> Now he's retiring, if the business is to continue we'll basically have to find someone who can migrate it to higher level platforms and languages. There aren't many (any?) people around willing/able to work with this kind of assembly code these days. I think you can definitely hire someone for training and go from there. I don't see a huge problem about assembly language. Does your father keep notes? Is it possible to share them?
- ddingus 4y agoIf I were in a different place, I would ask for the job. You should ask around. Assembly language itself is not hard. At least not on those smaller 8 bit Moto chips. What needs to happen is your father's notes, hopefully code comments, math, etc. and how that maps to the problem space needs to be recorded. Others can write the code. Frankly, you can likely do that given a little time. 8 bit assembly is both fun and a niche skill. Tons of people write it for fun these days, myself included. There is probably someone near you who knows this stuff from the retro computing scene.