I mean, I’m a front end web developer, and I get fucked up about how little I know about backend web development.
Embedded programming? Dealing with signals?! God forbid, man.
There’s just so much of everything! Terrifying! But fun!
Embedded programming? Dealing with signals?! God forbid, man.
There’s just so much of everything! Terrifying! But fun!
React? Angular? Node? What happened to Notepad and Apache?
I’ve found that’s easier to build a simple UI by loading chromium + webapp than having to deal with the intricacies of multitarget crosscompiling.
As much as I'm starting to hate Qt, I can still have it up and taking to hardware in a few minutes. And the onscreen touchscreen keyboard is worth the money.
One of the devices I’m working on had to use rust (we were looking for some niche libraries, and we found that the C ones weren’t working, while the Rust ones did).
Building GUIs in rust is still a WIP, and I had to spend 2-3 days fixing libs and tweeking stuff to get to something that compiled but was very buggy.
Instead of losing more time on that I set chromium + apache on the thing, and built the GUI as a web app. The rust executable has a simple API with actix that works flawlessly.
In that case it was the perfect solution because I had to add an API for remote management anyway, but I found the approach quite nice to work with.
I can get a decently functional UI app working in native code with just the SDK for whatever platform it’s on, but try to use React and suddenly I’ve got a web of 200 dependencies, each more shady than the last. And that’s just for “hello, world”
Plus the JavaScript engine is single-threaded and insanely slow.. it’s gross. I’m guessing that one of these days app developers are collectively going to snap out of it and throw Node in the trash
As single-board devices get faster and cheaper by the week there's a flood of developers that have cut their teeth on Node/JS/React and they get something working on a Raspberry Pi and think "Yeah, embedded development is a piece of cake. I can do this."
And maybe they're right, because doing it all by scratch and cobbling together robot parts to make a system work is just really getting to be old.
I used to get annoyed at the RPi newbies but now I welcome it as job security because someone still needs to write the bootloader and drivers. And if you read StackOverflow/Reddit you'll see there's nobody teaching that anymore.
Then again, any company that takes firmware engineering seriously can make devices 5+ years before Moore's Law makes it feasible for others, so maybe there'll always be room for us.
You must be a Broadcom user. My sympathies. =)
But I totally hear you. I'm not as pessimistic because I tend to follow parts that the automotive sector uses (yeah, not great right now) and they typically don't put up with random Chinesium parts and code. And yeah, it seems more and more like everyone is just throwing Linux into the mix and hoping that some OSS developer and/or Otavio Salvador swoops in and fixes things up.
RISC-V may be a way out of this. Maybe. Or it will make things ten times worse.
Why not, out of curiosity?
Nothing wrong with Apache, but syntax highlighting would be nice to have in Notepad.
For self-learning, frontend is orders of magnitude more accessible.
Every single time I touch anything web-related I discover that the entire landscape has shifted, all the tools I used last time are now abandonware, and I have to figure out everything anew. It may be more accessible if you're starting from scratch, but it's a constant treadmill that you instantly fall off of as soon as you do anything else. And when something doesn't work? Good luck finding out what's happening in the countless layers on top of layers on top of layers.
Then got into Arduino programming. There are tutorials for that online. Try communicating with other Chips like a Shift-Register, then something that uses a standard serial protocol (ex. I²C).
When you feel like you have a good grasp of the basics, I recommend getting a development board and doing the same there.
Most Microcontrollers (ARM Cortex Processors at least) are pretty similar: You get a datasheet and a User's Manual. The User's Manual describes a bunch memory addresses, which control the built-in peripherals. There are excellent descriptions of what value will give you what result, but it can be a bit daunting to get your head around it at first.
I recommend a chip that has a so called "Board support Package". I have experience with LPCOPEN. This will make things a bit easier, as you don't have to figure out each register address for each thing and can instead use functions like "Chip_TIMER_Enable(timer_t timer)".
There is a lot more to it, but once you get started, you usually always see the next step.
It's very doable with dedicated study and I'd argue it's one of the best ways to get your design ability to rise to the level of being able to build something from scratch, without reference to other code / searching google for answers.
Embedded has advanced a lot on this front, but for a lot if the industry, good luck finding anything but the original documentation.
Treat MDN as documentation for registers. :)
That’s only the case if you use the small (tiny!) subset of parts that everyone uses.
If instead of using some nice and common stm32FXX MCU, you need to work with some obscure Renesas or Fujitsu for example, prepare for a world of pain.
The good thing with web stuff is that you can swap frameworks until one does what you want nicely, and leave it at that. You can’t really change the IC in your board just because the I2C module is doing something weird.
I think you are exeggarating. Over last few years, there were no hard deprecations, except for AngularJS. Many tools, popular in past, went "maintanence mode" and receive mostly bug fixes, but these tools are still viable.
"How does a USB keyboard work? by Ben Eater:
My strategy has been to get into 80s game consoles where assembly programming was expected but the platform is small and standard enough that I can use emulators with memory views/debuggers & see everything going on.
heck at the end I might even have a game!
I'm starting out on z80 since I have an MSX and I hope to move to Sega Megadrive/Genesis later since I hear nothing but good things about the motorola 68k. The z80 seems pretty easy to understand (though it's not always consistent).
It's worth checking the limitations of the video and sound hardware to see what you like as well. I'm partial to FM synthesis so Sega consoles make sense to me. 8-bit stuff is going to land you with really tough colour restrictions (often about 3 per 8x8 square, tops). You may want to start with the "16-bit" era, which generally used 4-bit colours (16 for the whole screen, easier to create assets for).