Resources for learning intermediate C++ embedded programming concepts

[MajorEE]

What resources are there for learning intermediate embedded programming concepts?

I have a project I have invested a significant amount of time in and have come to a hard stop in progress when it comes time to tie everything together. I realize that I likely missing some concepts, but no longer have any idea where to go to for assistance or education.

In particular, I have written a control system in what I believe is an object oriented manner. It works reasonably well, but now I want to interface it with an LCD menu using an encoder to change parameters of the system.

I have no idea how to tie this together, and I have spent months researching this. Delegators, interfaces, linked lists, design patterns and so forth.

I can get the doubly linked list to work fine, I can scroll through a single level menu, but cannot figure out how to make it modular enough to interact with more than one object, and then modifying the variables becomes an issue.

So I am completely stuck with no idea how to proceed, and this thing has been sitting on my desk for months.

I have looked into TcMenu, different callback menu libraries, I have posted on the various sites StackExchange, Reddit, and so forth but minimal/no response so I am either misunderstanding something, missing a fundamental concept, or googling the wrong thing. Any recommendations?

High level overview of my architecture
Hardware Driver Class -> Software Subclass -> DAQ (Opens multiple instances of hardware for multi-channels) -> Main.cpp

Instance of controlSystem, passed &DAQ to access low level hardware components. There will be three different classes of controlSystem depending on what mode it is in as they are completely different logic.

Then we have main.cpp -> Menu/Display. I need to have the menu talk to DAQ, and controlSystem to adjust parameters. DAQ might be changing units, or hardware tasks, control system would be setpoints/limits/etc.

Any help greatly appreciated. I'm at my wits end!

[james_s]

You might look at the offerings on Udemy, quality of the courses is highly variable but there is some good stuff. Never pay the crazy inflated "regular" prices they list, they have sales every few weeks where most of the courses are $10-$15.

[Lindley]

Would have thought using a SPI TFT touch screen a much better option than the old LCDs ...?

The larger screen allows much better represtention of your data etc.

Have coded and used both but on a simpler level than your needs.

A good TFT example with free code here , its code structure  may also help  with your lcd.

[james_s]

It really depends on what the device is and who is the target market. I hate touchscreens and find an encoder driven menu infinitely preferable, especially if it's equipment that you might need to operate with gloved/dirty/wet hands.

[Zeyneb]

Hi there,

You seem to be knowledgeable in software engineering concepts. But also a bit of a perfectionist. I admit I do too myself. I assume when you think about some approach you immediately think of too many disadvantages in that approach that prevents you from completing some idea in code. Sure some of the disadvantages you come up with are valid. But as there isn’t any code yet that does something useful it is hard to judge what would work well and what is less useful.

So, my concrete suggestion to you is to start of with some basic approach that actually does the right thing from the users perspective. Adhere to the KISS principle. Don’t be tempted to make it too nice and scalable in this stage. Maybe even getting this to run will unfold some useful solutions to you.

If this runs fine you have something concrete to look at and to see how you could or should improve on this. Moreover you can ask for concrete advice on forums like this as you are able to give details about the actual problem you are facing.

I hope this was useful. I responded to my interpretation on what you wrote. I keep the option open that I misinterpreted your situation.

[rstofer]

I'm not sure you're going to find a lot of embedded programming done in C++ or any other object oriented language.  Among other things, dynamic memory allocation doesn't always work out well with limited RAM.

I might consider C and FreeRTOS.  I could have the encoder cause an event (interrupt) that sets a semaphore and the code driving the LCD menu could react and clear the semaphore.  All of this in a separate task.  The task itself would be dormant waiting to be scheduled when the semaphore is set.  No compute cycles are wasted by the task waiting for the semaphore.  No "super loop" interrogating everything.

The fundamental idea of FreeRTOS isn't so much "real time" as it is "divide and conquer".  You build a bunch of tasks, tie them together through semaphores or queues and let the scheduler worry about executing the tasks.  Each task is simple and focused on a single issue.

https://www.freertos.org/Documentation/RTOS_book.html

Using FreeRTOS pretty much requires using a CPU for which a port is available.  Porting from scratch may be a bit ambitious.