Home > On-Demand Archives > Q&A Sessions >
Live Q&A - Strategies for Developing Scalable Embedded Software for Microcontrolllers
Timothy Adu - Watch Now - EOC 2024 - Duration: 24:33
Hi Nathan,
Thanks for the feedback!
Thanks for the excellent presentation. I have a question about the example slide. I am wondering why the notify client went directly out from the telemetry service. I would have expected the telemetry service to send to the connectivity service mailbox instead, and have the ble module send the notification to the client.
Hi mck,
Thanks for the feedback.
It's a design choice. For each service, we define the "boundaries" of operation. In this case, I made the following design choices:
- The connectivity service would only deal with setting up a connection, tearing it down and reporting updates in connection status.
- The telemetry service would collect data from the sensors, analyze them and check with the connectivity service before nofifying the client.
The connectivity service exposes functions that the telemtetry service uses to send notifications.
In the end, there's many ways to do this. It all comes down to design choices. Your proposal works perfectly too. In the example case, I simply decided to let the telemetry service handle the sampling, analysis and transmission of sensor data, while the connectivity service handles the connection itself and keeps the system service updated if anything about the connection changes.
Can you describe more about your logging and CLI? Just browsing your website - looks good!
Hi SimonSmith,
What specifically about the CLI/logging do you want to focus on?
I just watched it again, the logging is straightforward. What was used for the shell and command parser? That was very impressive. I've implemented one that parses commands and uses function pointers, so each performs a specific action and returns a string, but it was very clunky. Do shell commands run in another task, so they don't impact performance?
Also I heard that GitLab has a critical security vulnerability - see recent Ars Technica article.
Thank you for the nice presentation. Interestingly, your microADF architecture is (at the highest level) event-driven and asynchronous (posting messages to mailboxes without blocking and waiting for the processing). Also, you mention state machines that implement the internal event-driven behavior of your "entities". Such architecture seems to be a universal conclusion of experienced developers. The other name of this design pattern is "Active Object" (a.k.a., "Actor"). An "Active Object" typically has a mailbox and a thread of execution. However, your design has two threads: a "parent thread" and a "worker thread". It's unclear how these two interact (synchronously, asynchronously?). Wouldn't the design be cleaner with just one thread per "entity" (Active Object)?
Hi Miro,
Thanks for the feedback.
Yes, in the specific example I provided there were two threads. This doesn't necessarily have to be the case. It depends on the feature being implemented.
The design principle is that there is one (and only one) parent thread (on the service layer). The presence of a worker thread (or absence thereof) is entirely at the designer's discretion. Ideally, the choice of having a worker thread depends almost entirely on how that feature itself is meant to work. Not every feature requires it own thread, hence the FSD matrix, where you have an overview/breakdown of which features use threads and which ones do not.
Very nice presentation. Would love to work in your environment or be able to more effectively convince management that it’s worth setting up the infrastructure you outline. Any tips for that conversation?
Hi BarryR7,
Thanks for the feedback.
In my experience, the battle is convincing management that it is worth the TIME that is to be invested in infrastructure. To be a little blunt, in most cases, management rarely gives a damn about infrastructure. They key is pointing out that the infrastructure is critical to getting your job done.
My advice is to start by defining what infrastructure you deem relevant. Then determine what is critical and nice-to-have.
Then build a timeline for building the critical infrastructure and nice-to-have infrastructure. Find a way to embed the infrastructure development in the "actual work", in such a way that it does not take away significant time from the development work. Also when you're setting up project timelines, remember to account for time that needed to be spent on infrastructure as well.
If you're up for it, let's hop on a call and discuss this at length. You can message me on LinkedIn.
Thanks Timothy. I really enjoyed your talk and it was very clear, with excellent examples. I hadn’t seen your FSD approach with simple spreadsheet used before. I find most projects jump to the scaffolding and all the foundation steps you showed are rarely done, as there is little time. Nice to see RTT and SystemView used as well for observabilty (I’ve been using these too).
Hi SimonSmith,
Thanks for the feedback. Glad you found the presentation enjoyable.
The FSD approach provides a simple yet broad overview/breakdown of the system. I developed the approach to solve challenge of bridging the gap between requirements and code - something that has always frustrated me.
As for RTT and SystemView, I use them whenever I get the chance. I generally love using SEGGER's tools.
If you're interested, tune in to the live Q&A and I can show some code examples.
Excellent lecture, thank you. It would be nice to see some code examples.
Hi Theodor,
Thanks for the feedback. I had considered showing some code examples but it was tricky to fit so much material into a 1 hour presentation. I would be more than happy to give a one-on-one code walkthrough. Otherwise, feel free to join the live Q&A and I can show some code examples there.
15:35:31 From Andrew MacIsaac to Everyone: I was wondering though if there are times that you have needed to "pierce" the layers of abstraction. This could be because the generic interface of the abstraction layers doesn't expose some needed specific hardware feature on a particular MCU, or assumes that a hardware feature will be used in a particular way. It could also be due to specific timing requirements which are not met when going through the multiple layers of abstraction. How do you balance the desire for abstraction with the sometimes restrictive requirements of the product? 15:49:37 From BobF to Everyone: Showing the Acropolis (in Athens) on the Infrastructure slide (No. 9), how appropriate are these strategies to enhancing legacy products? 15:52:31 From BobF to Everyone: Somehow, obsolesence has to be minimise!! 15:55:28 From BobF to Everyone: Thanks Tim, good points !! 15:55:35 From Andrew MacIsaac to Everyone: Thank you! 15:55:40 From Lyden Smith to Everyone: Thank you Timothy! 15:55:50 From Timothy to Everyone: Thank you all :) 15:55:53 From Ingo Beyer to Everyone: great presentation thanks a lot!! 15:55:53 From Stephane to Everyone: Thank you Timothy!
I really enjoyed this talk! Great job, Timothy.