For me, low-level is assembly, not C.
Ask HN: What should a systems/low-level software engineer know?
121–130 of 231 posts
Re: Ask HN: What should a systems/low-level software engineer know?
#122The word "system" is used a lot to describe many different collections. For example, the molecules that act on glucose to create ATP is considered a "system," as in something like an RF chip that has Tx/Rx on the same piece of silica. Can someone help provide a definition for what a system means in the Hacker News context? What is "low-level" as well. For me, low-level is assembly, not C.
Re: Ask HN: What should a systems/low-level software engineer know?
#123Re: Ask HN: What should a systems/low-level software engineer know?
#1241. Get a platform you can tinker around with, and recover quickly in case of disaster. Raspberry pi is a good example.
2. Learn how to find and read detailed register-level manuals of the underlying chip you're working on.
3. Learn what a programmer's memory-model is.
4. Learn what peripherals are, and what they do. You may have to dig a bit into basic electronics.
5. Learn what user-space vs kernel-space is.
6. Learn what device trees are, and how to prevent kernel from taking over a peripheral.
7. Based on above information, write a user-space driver for a simple peripheral (e.g. GPIO or UART) in C (don't try to learn assembly, yet). You will not be able to use the peripheral interrupts in user-space.
8. Learn how to verify hardware functionality, and see your driver in action. (Warning: high dopamine levels are reported at this point).
9. Repeat steps 7 and 8 for all peripherals, and see how far you can go.
Re: Ask HN: What should a systems/low-level software engineer know?
#125From 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…
Re: Ask HN: What should a systems/low-level software engineer know?
#126The word "system" is used a lot to describe many different collections. For example, the molecules that act on glucose to create ATP is considered a "system," as in something like an RF chip that has Tx/Rx on the same piece of silica. Can someone help provide a definition for what a system means in the Hacker News context? What is "low-level" as well. For me, low-level is assembly, not C.
Does anyone beside compiler writer write in assembly? For what systems? Why wouldn't they use a compiled language?
Re: Ask HN: What should a systems/low-level software engineer know?
#127I'm an embedded software engineer. Here's my $0.02 on how to get started: 1. Get a platform you can tinker around with, and recover quickly in case of disaster. Raspberry pi is a good example. 2. Learn how to find and read detailed register-level manuals of the underlying chip you're working on. 3. Learn what a programmer's memory-model is. 4. Learn what peripherals are, and what they do. You may have to dig a bit in…
Re: Ask HN: What should a systems/low-level software engineer know?
#128Re: Ask HN: What should a systems/low-level software engineer know?
#129From 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…
Maybe it is just me, but I've seen this issue multiple times where a programmer used a regular expression thinking they were clever, only to have it backfire later when there was some corner case not covered by their regex (which likely would have obviously been caught if they had just taken the time to write out each case as an if statement). You're usually just gaining complexity in exchange for fewer lines of code…
This takes in the definition of a regular language as a set of regular expressions, and generates C code for finite state machine to parse the language. You can visualise the state machine in Graphviz to manually verify all paths, making it much easier to spot hidden corner cases, while being a lot quicker to code than a big pile of if statements.
Re: Ask HN: What should a systems/low-level software engineer know?
#130I'm an embedded software engineer. Here's my $0.02 on how to get started: 1. Get a platform you can tinker around with, and recover quickly in case of disaster. Raspberry pi is a good example. 2. Learn how to find and read detailed register-level manuals of the underlying chip you're working on. 3. Learn what a programmer's memory-model is. 4. Learn what peripherals are, and what they do. You may have to dig a bit in…
Oddly there is a Raspberry Pi 3 sitting on my desk today. I find myself a little reluctant to setup the BTD loop for it (BTD = build test debug), because at the end of the day I'm going to have a (physically small) linux box. Which is fine because I plan on installing a network proxy on it that only needs wifi. But how is the Pi a gateway to embedded programming? It has pinouts you can attach an oscilloscope to?