One important thing for an embedded engineer (just like any software engineer!) to know is how to select an appropriate solution for a given problem. This includes both hardware and software, and do it yourself vs off the shelf. I think it can be summed up with some questions to ask at different points in a project: - Should I use a microcontroller or a processor? If a microcontroller should I use a simple 8 bit or m…
In your opinion is 8-bit even a realistic choice anymore? Many ARM CPUs offer way more bang for your buck nowadays (unless i'm looking in the wrong place).
Ask HN: What should a systems/low-level software engineer know?
141–150 of 231 posts
Re: Ask HN: What should a systems/low-level software engineer know?
#142Earlier quoted context omitted.
What. What good programs are written in C that don't have well-structured memory management the way C++ does it with RAII? Edit: "But in reality, why C is still the best programming language for large projects (IMO) is exactly that the programmer is allowed to choose a suitable structure, such that the program can fulfill the technical requirements. Other languages force the project into a structure that somehow neve…
> What good programs are written in C that don't have well-structured memory management the way C++ does it with RAII? MISRA C standards, popular in embedded projects especially automotive, ban the use of memory management altogether. The whole point of RAII is that the compiler manages it for you as far as it can. This is impossible in C because you have to do it manually. You might end up writing malloc() at the to…
Re: Ask HN: What should a systems/low-level software engineer know?
#143A bit on the more unusual side, one thing my son and I found very instructive on "lower level" concepts is the fact that within PICO-8, which is already a very user friendly high-level environment, you can use peek(), poke(), memset(), memcpy and similar functions on any memory address that PICO-8 uses. Literally all the capabilities that PICO-8 gives you, it exposes memory for it and explains the conventions it uses…
Surprised that this hasn't been exploited to build a C compiler targeting the platform. (Unless I needed to Google something other than "pico-8 C compiler"...)
Re: Ask HN: What should a systems/low-level software engineer know?
#144Re: Ask HN: What should a systems/low-level software engineer know?
#145A bit on the more unusual side, one thing my son and I found very instructive on "lower level" concepts is the fact that within PICO-8, which is already a very user friendly high-level environment, you can use peek(), poke(), memset(), memcpy and similar functions on any memory address that PICO-8 uses. Literally all the capabilities that PICO-8 gives you, it exposes memory for it and explains the conventions it uses…
> peek(), poke(), memset(), memcpy and similar functions on any memory address that PICO-8 uses Surprised that this hasn't been exploited to build a C compiler targeting the platform. (Unless I needed to Google something other than "pico-8 C compiler"...)
Re: Ask HN: What should a systems/low-level software engineer know?
#146From the top of my head, these are some areas I often would like other system programmers to know better: - Understanding how to write purely event-based programs using e.g. epoll since that will avoid lots of complexity and potential problems compared to throwing threads at everything. - Floating point representation and gotchas ("What Every Computer Scientist Should Know About Floating-Point"). - Unit-testing as pa…
And I would also add fuzz-testing to your list.
Re: Ask HN: What should a systems/low-level software engineer know?
#147- on memory access/caches/memory hierarchy: https://www.akkadia.org/drepper/cpumemory.pdf
- on DSO: https://www.akkadia.org/drepper/dsohowto.pdf
- Agner Fog on CPU optimization, latencies, vectors etc: https://www.agner.org/optimize/
Re: Ask HN: What should a systems/low-level software engineer know?
#148One important thing for an embedded engineer (just like any software engineer!) to know is how to select an appropriate solution for a given problem. This includes both hardware and software, and do it yourself vs off the shelf. I think it can be summed up with some questions to ask at different points in a project: - Should I use a microcontroller or a processor? If a microcontroller should I use a simple 8 bit or m…
In your opinion is 8-bit even a realistic choice anymore? Many ARM CPUs offer way more bang for your buck nowadays (unless i'm looking in the wrong place).
Also sometimes you may have existing expertise, tooling, or firmware already for a processor such as a PIC, AVR, or STM8, so why reinvent?
Some examples may be things like a custom serial to input/output expander, small motor controller, power controller, data logger, or other small and simple machines.
Re: Ask HN: What should a systems/low-level software engineer know?
#149Embedded programing pay sucks compared to the web. I wouldn't do it. Just look at the number of web jobs vs system programmer jobs.
I've done embedded a few times in my career (usually higher level, embedded Linux) though I also did some stuff with PIC microcontrollers for a bit. The pay sucks, but it is much more enjoyable work than web development. There's a lot less BS to deal with.