If you're interested in embedded there must be things you want to build with it. So build something you want to build.
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.
All aspects that you mention...I find value in it all...It'd be a shame to be forced to choose only one medium.
I posed the question with a low-level of specificity on purpose...I want as many opinions and ideas as possible in regards to the parameters which I chose intently...
Also I whole-heartedly disagree with an assertion that learning a topic must be top-down or bottom-up. My experience shows me I learn best when trying to apply concepts I may not fully understand, as the aspects where my knowledge is lacking are quickly highlighted.
Well learning methods are a matter of personal style, so whatever works for you. But it's important to come away with thorough understanding at the end, rather than "I tried X and it worked, so X must be the right way to do it".
Anyway your question is so vague as it stands, that I can't make concrete suggestions. How about this: what are some embedded things you have already done, and what parts interested you? Or, why do you want to program embedded in the first place?
Embedded programming is often just a resource-constrained version of programming bigger computers. Unless you're sort of forced into that by end-goal requirements, you might as well program bigger computers so you can solve bigger problems, have more convenient dev tools, etc. If you're pursuing embedded without having an end goal that needs it, it sounds to me like you're just drifting.
(Added:) Hmm ok, here is one idea that I think is cool: get some popular commercial quadcopter and replace the controller code with something that you release as FOSS. That would give more freedom to lots of quadcopter users. There is something like that on an old Adacore page, but I don't think it fits existing popular hardware.
Another: watch some "Stuff Made Here" videos on youtube for inspiration. That guy builds stuff with a lot of code inside.
Also not mentioned: what is your budget? For a pure software project you are allowed to say "zero" since all you need is time and keystrokes. But for embedded, if you do anything interesting, you will end up accreting a workbench full of oscilloscopes, SMT rework tools, and so on. That takes $$$ not just for the gear itself, but for the living space that it will occupy if you are in a high rent location. One reason I don't do this stuff is I don't have the space for it.
I'm not sure if this is what you're looking for (and it might be bit too advanced but you seem to be up for a challenge) but I remember seeing this post on r/arduino and thinking it looking pretty fucking hard. OP also posted a pretty detailed write-up.
Think of a device that doesn't yet exist, but should. This might mean that something similar exists, but has deficiencies, or is too expensive.
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:
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
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!
Have you implemented your own USB devices yet? How about your own BLE based protocol? All with your own code (not using some off the shelf library which imposes its own abstractions on you)?
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.
Figure out how to accurately transmit and reproduce jitter sensitive data over BLE as the transport, while keeping latency bounded. (ok, now I'm blatantly just rehashing problems I've solved before. But it was kinda hard!)
The reason I suggested BLE and USB was because, for both of those transports, I really felt myself "level up" as an engineer after reading the whole >1000 page spec, and use that knowledge to implement my own device.
Knowing how things like that work "behind the scenes" feels gratifying. Tho it may impact your normal life, sometimes seeing how the sausage is made turns you into a vegetarian. ;)
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.
Coincidentally, I also, also, started a project to do soil analysis remotely! :D Tho mine is just a few crude proofs of concept and a lot of dreaming. The eventual goal is an inexpensive automated black box box that provides me with fresh lettuce daily, with no human intervention.
I'm curious, what route are you taking for sensors? Off the shelf moisture? NPK? DIY? I love the idea of logging everything that's possible to log :>
That's cool! Honestly right now mine is too :)
But I'm getting the parts together now to build the first box, the plan is for it to be outside in the garden so it needs to be pretty weather proof.
I went with temperature + moisture sensors . I was seriously considering NPK, but I didn't like most of the sensor options I saw. I can't find the original white paper I was reading, but this is a good one on the subject too . Basically it seems like all the NPK sensors you can easily find are three-pronged and based on electrical-conductivity. These sensors don't have a super long lifespan, and can be pretty inaccurate (when soil moisture changes for example). There may be some good options out there, but I haven't found it yet. I might be overestimating how inaccuract the electrical-conductivity sensors are too, need to do more research.
I also want to log temperature and sun exposure; as well as place a rainfall sensor somewhere. I'm really looking forward to a Grafana dashboard of my garden
As for your "black box that makes lettuce," I'd highly recommend you look into hydroponics (specifically NFT). That's what I'm most interested in, I keep looking at this blog post as inspiration.
And yeah, now that I know the term "NFT hydroponics" that is exactly what I was imagining, just didn't know what it was called. "i want plants that are plugged into the matrix. living in a fake reality, the organic component of a larger machine that nourishes me.".
As for NPK, I (obviously) don't know what I'm talking about, but I'd really want to do something optical. For one, I think you're right, it strikes me as bad to use electrical conductivity to measure both hydration, and relative concentrations of ions, and two, optical just seems ... cooler... to me. In theory, you can "just" use 3 tuned LEDs and a photodiode...
Wow, that last link is... now my standard to strive towards for project writeups.
ha, coincidentally I just started on a similar project this weekend. One thing I've found interesting is the accessibility and accuracy found in such small modern sensors. Hydroponics may not be "microcontroller heavy", but can definitely be applied.
If you want an extra challenge take a cellular module and try again. For example there is a GSM expansion for Raspberry Pi, try to build a "sensor" that can check something every N seconds/minutes/hours and report back to you with a battery lasting months or more (hint- send it to sleep and wake on a timer)