Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Embedded Systems – Shape the World (2014)

users.ece.utexas.edu

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Embedded Systems – Shape the World (2014)

#31

Post by aidenn0 »

kierank wrote: post #20
ChuckNorris89 wrote: post #19

Earlier quoted context omitted.

Binary blobs you say? How about how our entire lives are ruined by having to use garbage apps like Teams every day or any other multitude of garbage websites on a daily baiss ? Did you actually work in the embedded industry, or are you just venting on some bad experiences you had with some boards/phones? You know, embedded is more than r-pi clones and android devices, right? It's auomotive, aerospace, industrial auto…

Unfortunately the industry I am in (multimedia) is slowly getting invaded by all the awful embedded development practices, binary blobs, custom forks, hacks galore. It's ruining an area where there was clean code, no blobs. Also Linus' ARM rant for good measure: https://lkml.org/lkml/2012/7/15/133 And imagine the stuff they didn't upstream...I'm sure that's part of some magic SDK that only works on one version of gli…

I remember people hacking on the binary of the MS mpeg4 encoder to create "DivX" binary blobs are everywhere (though much less so in every industry than they were 30 years ago)

Re: Embedded Systems – Shape the World (2014)

#32

Post by xsecxtanx »

synergy20 wrote: post #9
spyremeown wrote: post #7

Earlier quoted context omitted.

We are slowly getting better at this. Most embedded Linux companies for example have shifted or are in the process of shifting to an upstream-first policy. A lot of the toolchains are open, busybox is used everywhere. A lot of the really good HALs are open source. We're getting there!

which open source HAL do we have these days? thanks.

There is quite a bit of interesting work in the embedded Rust space on this. The embedded-hal project has made some progress on standardizing traits for peripherals and there are some decent HAL crates that have largely adopted those standards. The stm32-hal crates are fantastic.

Re: Embedded Systems – Shape the World (2014)

#33

Post by sgtnoodle »

MrBuddyCasino wrote: post #3
eschneider wrote: post #2

This looks like a good resource. Remember kids, embedded systems is like retro computing that people will pay you to do. :)

pay very little to do

I've always been quite happy with my compensation as an embedded software engineer. There also seems to always be high demand for the skill set.

Re: Embedded Systems – Shape the World (2014)

#34

Post by eschneider »

AnimalMuppet wrote: post #24
fest wrote: post #11

Earlier quoted context omitted.

Yeah, I work in a robotics company in Europe- our embedded people are paid essentially the same as web/enterprise software developers in the same market. Definitely a lot less remote Opportunities (though usually for institutional reasons- most of the work can be done remotely, if company is organized for that- which not a lot are). EEs are IMHO underpaid in both sides of the pond though.

Embedded can be remote, if the hardware is small enough and cheap enough to ship one to each remote developer. I worked on telephones for the hard of hearing, and we had some remote developers. No problem. On the other hand, there are embedded systems that are for 3D printing spaceship hulls. I kind of suspect that remote isn't going to fly for working on those systems...

You can probably do (most) of that remotely. If you're writing embedded systems that can't be 95% tested off the hardware, you're living in unnecessary pain.

I work on devices bigger than a car and sure, occasionally I have to visit the 'office', but almost everything can be debugged and tested remotely.

Re: Embedded Systems – Shape the World (2014)

#35

Post by fest »

eschneider wrote: post #34
AnimalMuppet wrote: post #24

Earlier quoted context omitted.

Embedded can be remote, if the hardware is small enough and cheap enough to ship one to each remote developer. I worked on telephones for the hard of hearing, and we had some remote developers. No problem. On the other hand, there are embedded systems that are for 3D printing spaceship hulls. I kind of suspect that remote isn't going to fly for working on those systems...

You can probably do (most) of that remotely. If you're writing embedded systems that can't be 95% tested off the hardware, you're living in unnecessary pain. I work on devices bigger than a car and sure, occasionally I have to visit the 'office', but almost everything can be debugged and tested remotely.

Yes, remote access to test units (if practical, I.e. more than one instance of system exists) or the real one, simulated h/w for higher level software (i.e. a GUI that connects to simulated device instead of real one).

Obviously there will always be some physical component to embedded development, but in many cases it is possible to do a lot remotely.

Re: Embedded Systems – Shape the World (2014)

#36

Post by synergy20 »

xsecxtanx wrote: post #32
synergy20 wrote: post #9

Earlier quoted context omitted.

which open source HAL do we have these days? thanks.

There is quite a bit of interesting work in the embedded Rust space on this. The embedded-hal project has made some progress on standardizing traits for peripherals and there are some decent HAL crates that have largely adopted those standards. The stm32-hal crates are fantastic.

rust is too hard to use for me, if I need pick up a modern language for low level it will be zig instead of rust. while rust might be fine for MCU low level embedded, it does not work for mid-range embedded linux when you have 64MB storage for example, as rust is by default static linked, a few of rust executable will fill up the storage, unlike c or c++ or zig where they can share some libraries _easily_ to save space.

Re: Embedded Systems – Shape the World (2014)

#37

Post by tonyarkles »

synergy20 wrote: post #16
tonyarkles wrote: post #10

Earlier quoted context omitted.

I've been using Zephyr lately and have been really enjoying it. It still has the vendor HAL libraries available (e.g. Microchip/Atmel ASF), but the devicetree-based HAL has been fabulous to work with. I've tried a number of different embedded frameworks/RTOSes over the years, but it's the first that I actually feel happy using. There's a few sharp edges for sure, but it's at least an order of magnitude better than an…

Great to know, Zephyr is on my to-use list and I need move it up the list more. Heard good things about it. It might become the Linux OS for low resource MCUs as the trend goes, it's also a LF(Linux foundation) project and vendor neutral, very promising. For me my plan is to use Zephyr with RP2040.

> For me my plan is to use Zephyr with RP2040.

I've been using Zephyr on an Atmel/Microchip SAMD21 for $WORK and it's been awesome.

I have an RP2040 sitting on my desk for a personal project and the plan was to use Zephyr for that as well, but it seems the WiFi is based around a binary blob and a weird interface to it that the Arduino BSP has wrappers for... It's been crunch time at work and I haven't gone back yet to see if the RP2040 port is coming along further, but on the Saturday I was looking at it, it seemed like connectivity was potentially going to be an issue for now.

ESP32 support is currently great for some chips and a WIP for other chips. I got unlucky and the one board I planned to use for a different project was pretty much completely unsupported, but I found a different one in my parts bin that only took about 4 hours to get going with the sensors I had planned on using (I2C or SPI, I don't recall), Bluetooth Central for some different sensors, and WiFi to connect it to the local network. It was really smooth!

Post reply on HN