4 ms·
For me it was working with vendors. Coming from web dev, that was the biggest change, that you can't just open an account with Heroku/AWS/whatever and go about
by daxfohl 10y ago
For me it was working with vendors. Coming from web dev, that was the biggest change, that you can't just open an account with Heroku/AWS/whatever and go about your business like you would if you were hacking for yourself.
You've first got to figure out what kind of SOC you want, and no it's likely not Arduino/RPi or whatever is popular for hacking projects. And no it's not the EE responsibility to choose these things; they just route them. You have to work with vendors to figure out what performance characteristics, lifespan, etc you'll need for your system along with preferences such as OS support (first class, 2nd class, community/experimental, etc, because no, you don't typically just download and install the latest Ubuntu and call it a day; drivers etc are often custom and proprietary, so unless you want to write your own driver stack...). It all doesn't "just work out of the box" like a SAAS service. You've got to put a lot of thought into "other stuff" and make some big decisions before you even write a line of code.
- zbrozek 10y agoI'm one of those EEs, and I think you're short-selling your colleagues. Or maybe your organization hasn't found great hardware people. Where I've worked, the hardware folks are (on average) just as responsible for architecture as the embedded software folks. Anything less than equal-and-honest cooperation tends to lead to lopsided or quirky designs.
- notalaser 10y agoI'll chime in with a confirmation that, in my experience, too, an EE who "just routes them" is either not very good, or working in a dysfunctional organization. Performance isn't something that exists in its own bubble, it comes with clock and power requirements and the devices that offer "more" of it than other devices have to compromise on other things. If a company insists on enforcing a strict hardware/software team separation, both teams have to be involved in these decisions, otherwise the results are borderline catastrophic -- boards that can barely be programmed and debugged, or sub-optimal component choice, bad analog chains, difficult clock distribution etc., depending on who is more involved in the decisions. Just like, past a certain point, it's impossible to do good embedded development on the software side without at least some basic knowledge of EE, there's no way you can come up with a good hardware design if you're completely ignorant about software development. It's no coincidence that the best engineers are the ones who can do both.
- daxfohl 10y agoSure, you're both correct. I totally understated the EE's role. My intended point was that you can't expect the EE to just "design the board and give it to you". Coming from web / PC app dev this was a big shock. It's a team effort to figure out what hardware is necessary and form relationships with vendors, and the SWE's are by no means absolved from that process. After a few years of embedded dev now, it now seems odd that I'd have been surprised by that, but nonetheless I was.
- notalaser 10y agoOops :-). Sorry if I seemed overly pedantic. I was bit by the EEs who literally "just route them" a long time ago and I'm not very sympathetic towards them. I'm one of the weirdoes who are programmers by profession but have an EE degree (not that I'm a good electrical engineer -- I just know enough to troubleshoot my way around hardware bringups and talk to the real EEs), so I find the whole "just tell me what connections you need" attitude particularly infuriating and conducive to terrible designs.
- pjc50 10y agoHitting upvote as hard as I can here. Sadly this seems to be a common problem; either the teams are siloed, or one of them is in fact outsiders. There's not enough of the tight iterative refinement loop work to put features in the right place. This seems to be why so many companies put out hardware which is handicapped by terrible drivers.