I'm curious about your experience with learning electrical engineering coming from a software engineering background.
I'm a software engineer, and though I've toyed around with hardware platforms building some basic circuits, I haven't done the deep dive you have.
Do you think anybody doing software engineering for devices needs to know electrical engineering? Or do you think most software engineers will interact with devices via APIs? What negatives or positives do you foresee in a future where devs must know the full stack, or only know a component of it.
If you have some thoughts on that, might be a blog post rather than answering here, but keen to hear your thoughts.
Well, I have a biased view here. I'm a knowledge junkie and I love learning systems. In software, I _actually_ RTFM for every single tool I use even tangentially. (As a side note, reading tech documentation cover to cover is actually awesome). So instinctually my gut reaction is to say "yes of course learn the system".
But as far as a more measured, less biased opinion goes: it depends on how professional you want to be. Most real consumer hardware doesn't really have APIs in the same manner that arduino and other user-friendly platforms do; arduino is basically designed to make programmer hobbyists feel comfortable with hardware.
But real embedded systems are programmed on microcontrollers (generally, sometimes we use FPGAs or other exotic platforms) in assembly or a dialect of C. And there, you're not so much "using an API" as you are manipulating output pins directly. So if you really want to work with high powered, professional platforms, you should certainly learn the stack.
Learning the stack is advantageous even with a friendly platform like the Arduino. At low power, most robotics are pretty easy to work with, very few surprises. But as you try and build bigger and more powerful robots, especially where motors are concerned, you start running into real electrical engineering problems (like back-EMF) that you _can't_ fix with software. So if you aren't comfortable with electrical engineering, the first time you attempt a more ambitious project you'll find yourself at a brick wall that you don't know how to get around.
So, unsatisfyingly, the answer seems to be "it depends" ;)
That is not an unsatisfying answer at all. I believe a hardware abstraction layer may get us to an api like experience (and have been developing one myself), so wanted to get your opinion.
I didn't want to mention my project before as I wanted to get your unbiased opinion. Great answer. thanks.
Nice! It's a cool project, and ambitious, but definitely worth doing. I'll be rooting for you!
Let me try to poke a hole or two in it for you. Not to discourage you, of course, but just to try and get you to think of some of the harder, less technical problems you may run into.
First, there's a fine line between a HAL and a full-fledged operating system, so be careful there! It's also hard to justify adding overhead or third party code to a system in many cases, especially if you're manufacturing for six sigma. You want every system to be in your complete control, because it turns out that making reliable products is _hard_.
I also don't see something like a universally-used HAL becoming mainstream anytime soon; for almost all production purposes (I don't know the number, of course, but perhaps on the order of 99%) a 50kHz chip with a 30-year old design is _exactly_ what you want. In most cases, you want to use a tried-and-true workhorse that you can get for $0.012 each, and not have to use a $2 chip that's powerful enough to run the HAL.
BUT a universal HAL could be great for hobbyists. Port your code easily from arduino to a powerful RISC to some other platform. That'd be great :)
Thanks, I wish I had a better term than HAL, as that does sound like an OS term. I'm doing more of a middleware layer, focused on the hobbyist market first.
I say Hardware Abstraction because technically, that is what it is doing, abstracting away the hardware level.
5 comments
[ 4.8 ms ] story [ 21.7 ms ] threadI'm a software engineer, and though I've toyed around with hardware platforms building some basic circuits, I haven't done the deep dive you have.
Do you think anybody doing software engineering for devices needs to know electrical engineering? Or do you think most software engineers will interact with devices via APIs? What negatives or positives do you foresee in a future where devs must know the full stack, or only know a component of it.
If you have some thoughts on that, might be a blog post rather than answering here, but keen to hear your thoughts.
But as far as a more measured, less biased opinion goes: it depends on how professional you want to be. Most real consumer hardware doesn't really have APIs in the same manner that arduino and other user-friendly platforms do; arduino is basically designed to make programmer hobbyists feel comfortable with hardware.
But real embedded systems are programmed on microcontrollers (generally, sometimes we use FPGAs or other exotic platforms) in assembly or a dialect of C. And there, you're not so much "using an API" as you are manipulating output pins directly. So if you really want to work with high powered, professional platforms, you should certainly learn the stack.
Learning the stack is advantageous even with a friendly platform like the Arduino. At low power, most robotics are pretty easy to work with, very few surprises. But as you try and build bigger and more powerful robots, especially where motors are concerned, you start running into real electrical engineering problems (like back-EMF) that you _can't_ fix with software. So if you aren't comfortable with electrical engineering, the first time you attempt a more ambitious project you'll find yourself at a brick wall that you don't know how to get around.
So, unsatisfyingly, the answer seems to be "it depends" ;)
I didn't want to mention my project before as I wanted to get your unbiased opinion. Great answer. thanks.
Let me try to poke a hole or two in it for you. Not to discourage you, of course, but just to try and get you to think of some of the harder, less technical problems you may run into.
First, there's a fine line between a HAL and a full-fledged operating system, so be careful there! It's also hard to justify adding overhead or third party code to a system in many cases, especially if you're manufacturing for six sigma. You want every system to be in your complete control, because it turns out that making reliable products is _hard_.
I also don't see something like a universally-used HAL becoming mainstream anytime soon; for almost all production purposes (I don't know the number, of course, but perhaps on the order of 99%) a 50kHz chip with a 30-year old design is _exactly_ what you want. In most cases, you want to use a tried-and-true workhorse that you can get for $0.012 each, and not have to use a $2 chip that's powerful enough to run the HAL.
BUT a universal HAL could be great for hobbyists. Port your code easily from arduino to a powerful RISC to some other platform. That'd be great :)
BEST of luck!!
I say Hardware Abstraction because technically, that is what it is doing, abstracting away the hardware level.
My project is at https://github.com/favor/it if you are interested in learning more.