Hacker News Reader

Comment by aswanson | Hacker News Reader

Could not have said it any better. Embedded development is dominated by hardware engineers who make decisions very often without the software development teams input, placing embedded folk square in the target of management angst as well. Choosing Broadcom chips without drivers, 3rd party experimental hardware who wont release data sheets, choosing USB chips that don't support host mode, miswired memory interfaces that mismap fpga access, FPGAs that cause spurious bugs when consuming more power than necessary in certain modes, all lay squarely on the embedded devs shoulders and can manifest at first looking like pure software problems with the schedule pressing. Not a pretty world.

View on HN

Are you me? Honestly, that all sums it up even better. In an embedded role, you are always a second class citizen. After 6-12 months of planning by the hardware folks: "The hardware is all done. Where's the software? What do you mean it's not finished, you had all year...?" You're a complete afterthought, and it's only amplified when working with a team that doesn't really "get" that without access to the actual, finalized hardware you're extremely limited in capabilities. It only gets better when they decide to go with one-off vendors who have a single product support engineer and its pulling teeth any time something goes wrong. It's often hardware related, but who cares -- you're the guy at the end of pipeline who's tasked with making it work, so yeah, you feel the wrath.

I'm only extra cynical because I'm dealing with that right now. As I have many times before, though. It's part and parcel.

OK, I've worn both hats - chip designer and embedded systems programmer - it makes me better at both - I get to be thye chip guy who understands software and the software guy who understands hardware - it means I get the interrupt setting/clearing logic race free and make sure all the registers can be read, and can make tradeoffs that minimise the amount of hardware we have to build.

The big issue is timing (and latency) - the chip guys are working on long timelines - they're already working on the next chip when the first chip's silicon comes back, their investment and attention is elsewhere, the software guys aren't going to rev up much before real hardware is in their laps, and certainly aren't going to spend any time on that second chip while they're still wrangling the first one - it's not so much a cultural gap between the groups as a gap in time

Isn't hardware emulation common these days? Zebu, palladium, etc. Can emulate a chip and software, which can speed time to market.

yes, but it's not cheap and is essentially a second parallel tapeout path that slows your chip design time - if you're building a CPU you likely build a high-level software model and code to that (with some register-virtualisation layer), then test against that as part of the chip DV (QA) process

In defense of HW engineers, they're often staring at a cost of goods spreadsheet.

Earlier in my career, I had a driver that compiled to about 8500 bytes. I noticed the part was spec'd at 16K and wondered if it could get re-spec'd at 8K if I got it down to 8K. Yep and I got mad props from the HW types.

Understood, but when they stare at that COG sheet they should also have the prescence of mind to look for hidden costs. A toolchain and IDE with a C compiler is going to cost much less in the end to the project than a 8K chip with an assembler and no debug environment/support tools will save it. It's very easy to be penny wise and pound foolish in this area.

Reply on news.ycombinator.com