Electronic – Is it worth it to go full stack as an embedded engineer?

embeddedfirmwarehardware

In big companies, they tend to separate embedded engineers by disciplines such as firmware, hardware, interface software, and PCB layout. Still, I think it's more fun to work 'full stack' and build all aspects of the design when possible. Obviously some projects are too large for this approach. All of my experience is with a company that has people separated out. I would like to transition to a full stack role at some point, but I'm not sure if there is a large demand for embedded systems engineers with broad skill sets.

Is there truly a need for engineers that have exposure to all these skill sets?

Best Answer

I have a BS in Electrical Engineering and an MS in Computer Science. I have been doing embedded systems as a consultant/contractor for over 35 years,working for both small companies you've never heard of and large ones like Sony, DirecTv and Apple.

For the smaller companies (typical number of employees: 25, number of other engineers: 0-4), I get involved in everything: hardware design (including choosing parts and creating a BOM), PCB layout, firmware design, hardware/firmware testing of said board, and hardware design/layout/firmware design for production test equipment for high-volume manufacturing in China or wherever. For these smaller companies, I typically get hired just because I have the combination of a BSEE and MSCS (and a track record of successful projects) since they can get by on hiring one engineer instead of two or three.

For the larger companies, I'm typically hired to work in only one area, more likely firmware than hardware (since it seems they always need more firmware engineers). I'll be working with several other engineers, sometimes as lead engineer of a small group even though I'm a contractor. I can't say I like one (large companies vs small companies) a lot more than the other, because they're two completely different environments. But if I had to choose only one, it would be the smaller companies where I can do it all. But you do need the skills to pull it off.

Related Solutions

Electronic – How to check for Stack overflow in an embedded application

A common way to check for memory usage is to prefill memory with a constant value before your program runs. eg a sequence of 0xde 0xad could be written out to your stack area by your startup code. During the program's operation, the stack will grow and write over these sequences. If you then have the ability to examine memory, then you can easily see the untouched 0xde 0xad bytes in memory and so determine how much stack has been used.

It's usually hard to detect an overflow as it occurs since function call return addresses are stored on the stack and any function return will send the program off into the weeds. In this case, if your watchdog is enabled and you can set a breakpoint at the reset vector, you may still be able to examine the memory and look for your prefill bytes to determine if this is what has caused a reset.

Electronic – Use of global variables in Embedded Systems

You can use global variables successfully, as long as you keep in mind @Phil's guidelines. However, here are some nice ways to avoid their issues without making the compiled code less compact.

Use local static variables for persistent state that you only want to access inside one function.

#include <stdint.h>
void skipper()
{
    static uint8_t skip_initial_cycles = 5;
    if (skip_initial_cycles > 0) {
        skip_initial_cycles -= 1;
        return;
    }
    /* ... */
}

Use a struct to keep related variables together, to make it clearer where they should be used and where not.

struct machine_state {
     uint8_t level;
     uint8_t error_code;
} machine_state;

struct led_state {
    uint8_t red;
    uint8_t green;
    uint8_t blue;
} led_state;

void machine_change_state()
{
    machine_state.level += 1;
    /* ... */
    /* We can easily remember not to use led_state in this function. */
}

void machine_set_io()
{
    switch (machine_state.level) {
    case 1:
        PIN_MACHINE_IO_A = 1;
        /* ... */
    }
}

Use global static variables to make the variables visible only within the current C file. This prevents accidental access by code in other files due to naming conflicts.

/* time_machine.c */
static uint8_t current_time;
/* ... */

/* delay.c */
static uint8_t current_time; /* A completely separate variable for this C file only. */
/* ... */

As a final note, if you are modifying a global variable within an interrupt routine and reading it elsewhere:

Mark the variable volatile.
Make sure it is atomic for the CPU (i.e. 8-bit for an 8-bit CPU).

Use a locking mechanism to protect access to the variable.

Best Answer

Related Solutions

Electronic – How to check for Stack overflow in an embedded application

Electronic – Use of global variables in Embedded Systems

Related Topic