Home > On-Demand Archives > Q&A Sessions >

Live Q&A - SOLID Design for Embedded C

James Grenning - Watch Now - EOC 2024 - Duration: 25:24

Live Q&A - SOLID Design for Embedded C
James Grenning
Live Q&A with James Grenning for the talk titled SOLID Design for Embedded C
M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

SimonSmith
Score: 0 | 2 weeks ago | 1 reply

Great talk, I recognise much of my code in your first design where all the headers get included. I presume a good test is temporarily renaming a header file or commenting out all structure members and checking only the corresponding module fails to compile, rather than everything breaking? I like the different PCB backgrounds also :)

jwgrenningSpeaker
Score: 1 | 2 weeks ago | no reply

That sounds like it would work. If that works, move the includes, forward declare structs and put the full declaration in the C file.

Hoche
Score: 0 | 2 weeks ago | 1 reply

Hi James, great presentation. I have a question regarding the multiple instance abstract datatype. In a popup, you mentioned that dynamic memory allocation in the Create function for the circular buffer is not needed. Can you explain how you would use static allocation there? Thanks.

jwgrenningSpeaker
Score: 1 | 2 weeks ago | 1 reply

One approach breaks encapsulation, where the struct is put in the header file and a macro could calculate the size .

Another approach is to write your own malloc that allocates memory from a block you statically define. In production the buffer is never destroyed, free is never called. So there is no fragmentation. During off-target testing you could use the real malloc and free.

There are two that come to mind.

Hoche
Score: 0 | 2 weeks ago | no reply

Thanks for these suggestions.

JohnLowe
Score: 0 | 2 weeks ago | no reply

Nice presentation James (as always). I have found the SOLID principles to be very worthwhile, and very much worth studying and learning. SOLID isn't a "...just write the code this way..." thing. Once the principles are understood then it is clear that there is more than one way to "skin the cat" in terms of implementation, depending on the specifics of the application, resources, constraints, etc. Also, not surprisingly, SOLID and TDD get along great together.

Dflyer
Score: 0 | 2 weeks ago | no reply

Great job as always! Thanks for sharing,

kevinz
Score: 0 | 2 weeks ago | 1 reply

James presentations are so entertaining. I wish all presentations were like this. This is hard to do with software. I will have to watch this several times.

jwgrenningSpeaker
Score: 0 | 2 weeks ago | no reply

Thanks Kevin. It takes a lot of time to make one of these. I needed it for my self-paced training as well. When I have the same thing needed for two reasons, it usually gets done.

mmckaydavies
Score: 0 | 2 weeks ago | 1 reply

Solid presentation! ;)

jwgrenningSpeaker
Score: 0 | 2 weeks ago | no reply

Solid comment!

Nathan3
Score: 0 | 2 weeks ago | 1 reply

Great presentation, thanks! Could you upload the slides of the presentation please ?

jwgrenningSpeaker
Score: 0 | 2 weeks ago | no reply

I added the slides I have used for a live talk on this topic. They are not exactly the slides for this talk. I hope they help.

Thanks

jwgrenningSpeaker
Score: 3 | 2 weeks ago | no reply

In the Q&A I mentioned some resources
Progress Before Hardware paper
TDD Self-paced training
TDD Live-Remote training
SOLID Design for Embedded C paper
SOLID Design for Embedded C ACCU 2014 slides
Other titles
blog

Andrew.C
Score: 0 | 3 weeks ago | 2 replies

Hi James, thank you for this fantastic presentation. Could you provide an example of the linker binding (related to the random minute generator). If we have a.h and 2 implementations a1.c and a2.c would you then provide the split in your Makefile with some conditional logic there e.g. ifeq ($(PROCESSOR_TYPE),X86) ... or would you have any other approach?

kevinz
Score: 0 | 2 weeks ago | 1 reply

My two cents: The conditional has to be somewhere, right? So it could be in the makefile or it could be in a script that calls different makefiles...... And, you wouldn't have a1.c and a2.c. You would keep the file names the same and place them in different namespaces (directories) and have the makefile point to the different directories.

jwgrenningSpeaker
Score: 0 | 2 weeks ago | no reply

Hi Kevin
Take a look at the reply to Andrew. Let me know if you have a follow-up comment/question.
Cheers, James

jwgrenningSpeaker
Score: 0 | 2 weeks ago | no reply

Hi Andrew,
Thanks! I'm glad you enjoyed the presentation. Thanks for the question.

I tend to separate the test build from the production build and avoid conditionals in the makefile. If I use the linker for the random minute generator I'll need three builds: one production build, a test build that uses the real random minute generator (so it can be tested), and a test build that fakes the generator so the scheduler can be tested.

The bad part about using only the linker for substitution is that when there are many functions that need tests and those functions also need to be faked (to test other parts of the system) you can get an explosion of builds.

The random minute generator made a case for using a function pointer to access one of two random minute generators, the real one and a fake one for test. Now we have one less reason to split a test build. You may have other reasons for more than one test build.

HTH

TomD
Score: 0 | 3 weeks ago | no reply

Excellent Presentation - informative and also very entertaining. Thank you!

Vishwa
Score: 0 | 3 weeks ago | no reply

Thank you so much for the great presentation.

SidJPrice
Score: 0 | 3 weeks ago | no reply

Excellent presentation, thank you so much.

15:36:55 From maria to Everyone:
	You didn't mention anything with regard to rtos. Is there anything you would add to your talk when thinking about rtos too?
15:39:01 From BobF to Everyone:
	When, in your career to date, did you begin to focus on TDD techniques ... early on or later and what triggered it? Further, what are your opinions on fitting this topic in tertiary U/G , P/G courses if not prior  ... bearing in mind many technical courses are overloaded already!?
15:39:05 From Caio J. B. V. Guimaraes to Everyone:
	THe Art of Writing Efficient Programs by Fedor G. Pikus, talks alot about optimization in the same sense: you've got to know where it should be optimized, how and why. The most important thing is to measure where it matters to understand where and how far it can be optimized.
15:41:36 From Gonzalo to Everyone:
	Is it easier to develop modularized software in C++ rather than C? Should new engineers keep using C for new designs that are getting more complex and that need more organized modules, layers, interfaces, etc.?
15:42:46 From SuziO to Everyone:
	Your talk reminded me a lot of using factory pattern. Do you suggest patterns as a way to keep SOLID principles?
15:43:34 From tyhw to Everyone:
	Is this as applicable to bare metal? If an application layer knows about the hardware and the hardware changes, then you need to change the application code. If you separate with a middle layer, then you would have to change the middle layer. Where is the time savings?
15:47:56 From BobF to Everyone:
	Thank you for your encompassing, and beyond all, honest and frank answer. Those events in one's experience are the most insightful, to many!
15:53:16 From Keith J to Everyone:
	Reacted to "Thank you for your e..." with 👍
15:53:19 From tyhw to Everyone:
	Yes
15:53:21 From tyhw to Everyone:
	Thanks
15:53:53 From Vishwa to Everyone:
	Do you recommend structuring folders in the project in sensible way for to match the abstraction layers and adapters?
15:56:37 From Caio J. B. V. Guimaraes to Everyone:
	Thank you very much for all the experience sharing!
15:56:38 From Vishwa to Everyone:
	Thank you James
15:56:38 From Andrew MacIsaac to Everyone:
	Thank you!
15:56:39 From Lyden Smith to Everyone:
	Thank you James!
15:56:45 From Jui Yen to Everyone:
	Thank you James!
15:56:59 From Keith J to Everyone:
	Thanks again James.  Always a pleasure.
15:56:59 From Caio J. B. V. Guimaraes to Everyone:
	links from James????
15:57:01 From Andrew Geard to Everyone:
	Thank you for another excellent talk.
15:57:10 From Caio J. B. V. Guimaraes to Everyone:
	I'd love to take a look at those classes and resources
15:57:10 From BobF to Everyone:
	Refer - Kelvin's Dictum (Lord Kelvin) for the importance of measurement
15:57:27 From John Singleton to Everyone:
	Thank you, James!
15:57:29 From Caio J. B. V. Guimaraes to Everyone:
	Thx a lot!

OUR SPONSORS

OUR PARTNERS