What kind of project do you mean, anyway? Embedded is partly about software and partly about hardware. I'm a programmer who dabbles in hardware. For many of the embedded ideas I think about, the software challenges are not too bad, but the hardware issues are above my pay grade. Do you want to build interesting hardware, or only write code? Do you want to only develop programming chops, or also domain skills that will require a fair amount of study, such as DSP algorithms? Do you only want to program microprocessors, or also FPGA's?
It would be nice if you could say more about your interests and goals. That would make it easier to suggest projects.
I'm not that big on the concept of trying to learn a topic by doing a project anyway. Better to have the low level pieces together first, and put them together into a project afterwards.
[1]https://www.reddit.com/r/arduino/comments/g9293k/for_the_pas...
Build it. You may find that learning with concrete goals in a real problem is more effective that with something you're disinterested in.
The trick with this skillset is it's a combination of many related skills. The specifics will depend on the project. Some examples:
Soldering
Low-level language proficiency; generally C, C++, or Rust. Also includes interrupts, concurrency, DMA, atomics etc
Embedded tooling (Pick your poison!)
Part selection and BOM/cost management
EDA software, including PCB layout, designing footprints, schematics etc
Communications protocols
Reading datasheets and manuals
Familiarity with your MCUs peripherals of interest for the specific proj
How you get the PCB ordered etc
Mechanical skills, eg designing and building enclosures
CAD software like Solidworks, Inventor, Fusion etc
You'll probably need some combo of all of these, unless you're in/starting a company that has a division of duties. Good luck!
I've done a moderate amount of firmware programming, and while some of it seems "easy" or "obvious" in retrospect, taking a new chip, implementing a crude task sharing "operating system", writing drivers for peripherals, then writing a host facing interface (like USB, or bluetooth) and then writing the host driver for it, and making it all happy... Eh, actually that might be more tedious than hard.
The last thing I worked on that evoked "wow that was fucking hard", required minimizing the power draw without sacrificing features, so you have to deal with creating state machines to track all the various standby and power states of your peripherals and radios and mcu, and transitioning between them in the right way (and with the right timing!)
Doing cool sound/music stuff used to be hard, but it's eas(ier) now that your microcontroller is frequently 32bit.
Make a live update mechanism for your project that is provably un-brickable. That was difficult 10 years ago. Might still be difficult.
I'm currently working on a project to do soil analysis in realtime via a LoraWan network (kinda like https://youtu.be/iN6j1AbUbYo). Also looking at doing hydroponics, but that isn't very microcontroller heavy.
https://m.youtube.com/c/LucasVRTech/
If you have access to a vr headset I think this would be a difficult but possible project that would result in a really cool device.
The project is also currently small enough that there is plenty of room / need for contribution.
Take a system and try and eliminate as much power draw as possible, and then make it resilient to power failure (both program state and safe result).
A lot of modern wifi projects can be completely turned on their heads under these conditions. Turn a 1 mo. battery into 10years.
fourier transform/synthesis
LCD television set
software programmable oscilloscope; logic analyser/injector
JTAG hardware
microcontroller programming hardware
ST sure as hell won't do it. You'd be a hero.
The very idea seems like Sci-Fi to me and i am quite mystified why this is not more widespread.
Would love to know the Experts take on this !
ST sure as hell won't do it.