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

Ask HN: What should a systems/low-level software engineer know?

news.ycombinator.com

Post reply on HN
Print view View original

161–170 of 231 posts

Re: Ask HN: What should a systems/low-level software engineer know?

#161

Post by bsder »

mbreedlove wrote: post #152
akiselev wrote: post #135

Earlier quoted context omitted.

> 1. Get a platform you can tinker around with, and recover quickly in case of disaster. Raspberry pi is a good example. I'd recommend something cheaper and simpler like the STM32F4 discovery boards. You won't get linux and will have to program via JTAG but the documentation for the STM32F4 is not as overwhelming as Broadcom's.

Does knowledge of the STM32 family apply to other ARM chips?

Yes and no.

General ARM programming--yes.

Specific peripherals--no.

General peripheral knowledge--yes.

An ARM is an ARM withing certain limits so your knowledge transfers. Sadly, every chip has a different way of programming the periperhals. However, every chip has roughly the same core peripherals (I2C, SPI, UART, etc.), and those electrical specifications and how you use them for protocols doesn't change.

Re: Ask HN: What should a systems/low-level software engineer know?

#162

Post by ninjakeyboard »

jschwartzi wrote: post #138
ninjakeyboard wrote: post #99

I am somewhat of a systems engineer but more in the distributed systems space rather than embedded systems. I guess: - runtime/space complexity and general algorithmic heuristics to know how the system will perform, or to be able to fix scale issues in the code. - network characteristic (eg fallacies of distributed computing) - CAP theorem and applying it to real world designs - A co-ordination tool like zookeeper -…

It's important to realize that algorithms which scale very well on high performance and distributed systems are frequently not the best algorithms to use in an embedded system. For example scanning an array for each lookup instead of using a hash is usually good enough when your array size is relatively small(10 items to several-thousand). And it can mean the difference between spending a week or two coding a hash ma…

For sure I'm not anywhere close to embedded. https://en.wikipedia.org/wiki/Systems_engineering

Re: Ask HN: What should a systems/low-level software engineer know?

#163

Post by Glawen »

hwj wrote: post #45
Glawen wrote: post #20

If by low level you mean embedded systems programming, you will definetly need to be proficient in C. The other knowledge depends on the product that you will make. For example I work in the automotive industry, where you need to be interested in cars and how the different parts work. Knowledge of electrical engineering and control theory is also valuable. There is a good book about it if you wat to learn how cars wo…

The german version is called "Kraftfahrtechnisches Taschenbuch" and is ~15EUR cheaper.

But it is in german, and i believe that a native will not fully understand it if he did not work in the field in germany.

I'm french and studied in the UK. I'm sometimes lost when my colleague use french technical terms, i have to ask the concept behind it to be able to identify the english term which i learnt during my studies.

Re: Ask HN: What should a systems/low-level software engineer know?

#164

Post by AnimalMuppet »

jschwartzi wrote: post #142
pjc50 wrote: post #85

Earlier quoted context omitted.

> 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…

Note that they ban the use of dynamic allocation at run-time except via the stack, but that you are still allowed to allocate from the heap as long as that heap allocation is static for the life of the system. This avoids a whole host of problems related to heap exhaustion that result from allocation timing causing heap fragmentation.

It also eliminates a whole lot of uncertainty in the timing.

If you're running in an automotive environment, you're probably real time; that is, you have to finish your processing before, for example, the next cylinder comes into firing position. You have to hit that, for every cylinder of every rotation of the engine, for any rotation rate that the engine is capable of reaching. You can't be late even once.

Now in the processing you have a malloc call. How long will the call take? Depends on the state of the heap. And what is that state? Depends on the exact sequence of other calls to the heap since boot time. That's really hard to analyze.

Yes, you can get a memory allocator that has a bounded-worst-case response time, but you also need one that absolutely guaranteed always returns you a valid block. And the same on calls to free: there must be a guaranteed hard upper bound on how long it takes, and it must always leave the heap in a state where future allocations are guaranteed to work and guaranteed to have bounded time.

And, after all of that, you still have a bunch of embedded engineers scratching their heads, and asking "explain to me again how allocating memory at all is making my life easier?"

So embedded systems that care about meeting their timings often allocate the buffers they need at startup, and never after startup. Instead, the just re-use their buffers.

Re: Ask HN: What should a systems/low-level software engineer know?

#165

Post by pdpi »

Nursie wrote: post #84
mttyng wrote: post #62

Earlier quoted context omitted.

What if -and I'm sorry to hijack- by low-level OP means a position as a C/C++ developer (asking for ~a friend~ me)? I've always been insanely attracted to the C variants and messed around with them to minor extents, but what might someone _need_ to know to be competitive if they're trying to make a move to that area of SE?

Memory management is the major difference between them and most of the higher level stuff. You need a good grasp of who owns what in a program so you can free and close things when they aren't needed (and not before). Less so in C++ these days of course, but definitely in C. It's worth picking up some basic gdb skills. Use of ddd can help with this. On windows you can use VS for most of this of course. Picking up the…

> You need a good grasp of who owns what in a program so you can free and close things when they aren't needed (and not before). Less so in C++ these days of course, but definitely in C

You absolutely need to know in C++ too. Modern C++ just gives you tools to express ownership in code. Rust goes way further and gives you compile time correctness of your lifetime handling

Re: Ask HN: What should a systems/low-level software engineer know?

#166

Post by AnimalMuppet »

jamesadevine wrote: post #133
roland35 wrote: post #112

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).

What do you want? Do you want a system to play with for your own learning? Or do you want to build a shipping product?

If for your own learning, do you want a full-powered environment? Or do you want a simple system that you can learn all of, even if it's more of a toy?

If it's a shipping product, do you care more about ease of development, or about total parts cost? (The difference is often quantity that you expect to ship - 10 cents in part costs matters if you expect to make 100 million of them.)

Re: Ask HN: What should a systems/low-level software engineer know?

#168

Post by senorsmile »

antirez wrote: post #38

There are good general rules in a few comments here, but I think it's ok to say that in 2018 the specialization arrived to a point where system/low-level is too large to reply in a good way? One thing is to write games engines, another is to write networking code, yet another embedded systems, device drivers and so forth. There are certain common aspects, but the details of what you need to know change significantly.

This 1000x. The field is huge. Get the common basics down, then pick a specialization that seems interesting or useful.

Re: Ask HN: What should a systems/low-level software engineer know?

#169

Post by icedchai »

samfisher83 wrote: post #149
icedchai wrote: post #103

Earlier quoted context omitted.

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.

I feel there is the BS there too. You need to get board support packages. Sometimes the memory map is wrong. If you can get board up it might be a timing issue and you have to solder onto the Trace etc.

It also feels more like "real" programming. A lot of web development is dealing with BS problems resulting from building apps on a platform that was never meant for applications in the first place.

Re: Ask HN: What should a systems/low-level software engineer know?

#170

Post by roland35 »

mbreedlove wrote: post #152
akiselev wrote: post #135

Earlier quoted context omitted.

> 1. Get a platform you can tinker around with, and recover quickly in case of disaster. Raspberry pi is a good example. I'd recommend something cheaper and simpler like the STM32F4 discovery boards. You won't get linux and will have to program via JTAG but the documentation for the STM32F4 is not as overwhelming as Broadcom's.

Does knowledge of the STM32 family apply to other ARM chips?

I would say absolutely yes. I started with the STM32 parts and have then used ARM Cortex devices from TI, Freescale, and Atmel. They all have different peripherals and of course different peripheral libraries from the vendor but overall they are conceptually similar. It can certainly be a pain in the neck to switch a project from one device to another (lots of gotchas with pin layout, peripheral minutiae etc etc) but starting a new project with a different device should not be too hard!

Except for the Kinetis DMA, I never understood that one!!

Post reply on HN