Hey, not sure where to post this but I’ll give it a try.

I’ve changed jobs many times due to the economics of the construction sector in Sweden going to shit. So now I’m all but ready to change my career.

Would it be wise to get a 2 yr degree and start over as an embedded dev? Other programming jobs have been scarce and I wonder if that applies even for embedded.

Thanks :)

  • Valmond@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    2
    ·
    5 hours ago

    As a senior c/c++ expert that has dabbled with the small cpus (8266, z80, nintendo, atmega, esp32 …) how long time would it take for me to up my skills in an embedded job?

    There are loads of them (embedded jobs) at the moment so I’m wondering.

    • litchralee@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      4 hours ago

      I would say that the crucial pillars of embedded work are: mastery of C, computer architecture, and data transfer. I say this because most embedded challenges can be framed in (and often are written in) the C language. The same problem-solving approach for C is very similar to solving problems in a microcontroller. I put specific focus on pointer arithmetic and alignment, because although higher level languages take care of these things automatically, it has to be handled eventually at the lower levels, usually by the embedded engineer.

      For everything that isn’t C, the next set of challenges are in integration: rarely does a microcontroller run on its own. It might coexist with a host computer, have its own serial interfaces or other peripherals, access memories or sensors through complex buses, and some even have a quantity of DDR (with all its required supports). I don’t think it’s absolutely necessary to enter the field knowing the ins-and-outs of ARM’s AXI bus or how PCI/PCIe transactions propagate through a tree. But knowing the inspirations for commonplace things like Virtual Memory, IOMMU, DMAs, and memory bus width, those are foundational.

      Finally, there’s always data transfer. Some data here needs to go over there. This can include actual networking protocols (eg TCP/IP, WiFi, ZigBee) but can also be point to point (I2C, RS232). This is probably the part where people entering the field have to be generalists: there are just so many different ways to transfer data that it’s basically impossible to study them all in advance. Instead, some things are common to all transfers: a specification of the start and end of the payload, why headers or sync patterns are used, error correction, medium arbitration, reliability guarantees (if any), and API considerations (eg conformity to BSD sockets).

      To be abundantly clear, embedded is very hardware oriented. In my time, I’ve seen a lot of Electrical Engineers and even Mechanical Engineers successfully make the leap over to embedded software, because they already have the ability to efficiently absorb knowledge from data sheets and specification documents, and will work within the absolute limits given. If there is the aptitude to dive very deep into the details, to find truth where everyone else sees “magic”, then embedded will not be too difficult.