4 ms·

Yes, I'm aware of what is involved in systems programming and what kind of problems I might end up solving. However my knowledge is mostly theoretical or based

Yes, I'm aware of what is involved in systems programming and what kind of problems I might end up solving. However my knowledge is mostly theoretical or based on spare time hacking or university classes practice. The point you are raising is valid though. One should be aware where he is going to stick his nose :) Based on your previous post I see that you are an embedded developer. Would you mind to shortly tell how you started and what you found most difficult or most important in the beginning or even later in your career?

AnimalMuppet 13y ago
How I started: I got hired right out of college (with a math and physics degree, not CS) for an embedded position. From that start, I've been in embedded for almost all of my career. What I've found to be important/different: Debugging can be really hard. You can't always run a debugger; you can't always print something out. Sometimes bugs can come from interaction between different threads, which is something that you don't run into in many kinds of programming. You have to watch for multiple threads accessing the same data, and you have to figure out what you need to do if it happens. You need to remember that any thread can stop running between any two assembly instructions - a C statement is not atomic. I've never done system programming, but in ignorance I think it's harder than what I do. It's got all of my problems, plus a bunch more...
- blobfish 13y ago
  What would be the situation in which you can't run debugger? Is this when the issue can't be reproduced in dev environment?
  - AnimalMuppet 13y ago
    You can't run a debugger when you don't have room on the embedded device for the debugger. You can't run one if you don't have communication with the device (if you're installing code by physically inserting ROM chips in sockets, and don't have a serial port or ethernet connection to it. And you can only run a debugger with great difficulty if your system is handling real time events, and if the debugger hits a breakpoint, you mess up the timing so that the behavior from that point on is completely changed. You might be able to get the information that the breakpoint triggered, and what the variables are at that point in time, but you can't continue from there and see how execution proceeds.

AnimalMuppet 13y ago

How I started: I got hired right out of college (with a math and physics degree, not CS) for an embedded position. From that start, I've been in embedded for almost all of my career. What I've found to be important/different: Debugging can be really hard. You can't always run a debugger; you can't always print something out. Sometimes bugs can come from interaction between different threads, which is something that you don't run into in many kinds of programming. You have to watch for multiple threads accessing the same data, and you have to figure out what you need to do if it happens. You need to remember that any thread can stop running between any two assembly instructions - a C statement is not atomic. I've never done system programming, but in ignorance I think it's harder than what I do. It's got all of my problems, plus a bunch more...

blobfish 13y ago
What would be the situation in which you can't run debugger? Is this when the issue can't be reproduced in dev environment?
- AnimalMuppet 13y ago
  You can't run a debugger when you don't have room on the embedded device for the debugger. You can't run one if you don't have communication with the device (if you're installing code by physically inserting ROM chips in sockets, and don't have a serial port or ethernet connection to it. And you can only run a debugger with great difficulty if your system is handling real time events, and if the debugger hits a breakpoint, you mess up the timing so that the behavior from that point on is completely changed. You might be able to get the information that the breakpoint triggered, and what the variables are at that point in time, but you can't continue from there and see how execution proceeds.