book/resources on advenced SW design in C - Page 1
Forum section: electronics / general

author: poorchava
author_rank: Super Contributor
timestamp: January 16, 2015, 07:21:02 am
content: Hi,I'm generally pretty proficient with C, using it to program microcontrollers. Targets are mainly STM32 uC, much less often AVR and MSP430. The problem is that how I write the software is entirely self taught, based ony my experience and what appears to make sense. Since more and more of my work is in software, I figured I need to educate myself a bit more on this topic.What I'm looking for is a book about software design in microcontrollers. Not software writing/coding, syntax, how pointers work and so on, but design and planning. I mean stuff like designing program flow, data structures, state machines and so on. I'm also interested in scalable software design, such that adding one feature doesn't require me to change all the software layers. There are books out there, but they are all devoted to PCs rather than microcontrollers. Do you happen to know any good resources (books, internet, YT videos) on that topic.The effect I'm trying to achieve is being able to write software that more closely resembles something that a professional software engineer would write, rather than something a self-taught hobbyist would write.

author: ivaylo
author_rank: Frequent Contributor
timestamp: January 16, 2015, 08:25:08 am
content: Good observation (those books you like may be devoted for PCs for a reason). Not saying that you can't think grand when coding for a uC but as long as it is in C, a single thread of execution, no real OS, and your code is naturally limited in size the world is kinda flat. You can still write crazy efficient libraries behind nice and clean header files but in terms of design that may be pretty much it (if you follow the uC's user manual, use the interrupts and all that). I stand to be corrected of course, I come from the other side and have programmed more PCs than uCs...

author: AndyC_772
author_rank: Super Contributor
timestamp: January 16, 2015, 08:42:06 am
content: I'm interested in this too, especially since I'm now outgrowing PICs and starting to write much more complex firmware running on ARM devices.For example: a simple processor might set up some hardware, then sit in an endless loop monitoring inputs and then doing something interesting when they change. But what happens if, say, the same device also needs to bring up and maintain a network connection, and can receive remote configuration changes or commands at arbitrary times? Straight away you're into the realm of multi-tasking, but how?Does it justify using a multi-threaded OS?Or a complex ISR?Or a system of queues and state machines?Or something else I haven't thought of?

author: nowlan
author_rank: Frequent Contributor
timestamp: January 16, 2015, 09:14:20 am
content: I think you have 2 ways to go.Find a proper embedded C book.How to tell the compiler to shift strings into ROM/Flash etc.Have the compiler make better use of limited stack/ram.There are books out there. Try books.google.comHowever, I think the Internet Of things that everyone malignswill become an interesting area to explore.I would like to have an ARM device with tcp stack, sdcard, lcd interface, embedded webserver.My options at the moment:1. Code python interface on a raspberry pi for prototype.2. Learn Android, and repurpose dirt cheap tablets etc.3. Look into ucLinux.

author: miceuz
author_rank: Frequent Contributor
timestamp: January 16, 2015, 11:39:13 am
content: Making Embedded Systems by Elecia Whilehttp://www.amazon.com/Making-Embedded-Systems-Patterns-Software/dp/1449302149might do the trick. It has an overview of software programming patterns suitable for restricted environments. Frankly, this is the only book I've stumbled on that addresses developing software that does not suck on small systems.

author: dannyf
author_rank: Super Contributor
timestamp: January 16, 2015, 12:02:04 pm
content: QuoteC is C, whether on a mcu or on a large machine. I don't think this "Learn C on ARM/PIC/xxx" ever works.There are many ways to learn to code in a prudent way. The one that has worked for me is to think about coding as an investment that you can rip its benefits over and over in the future.So whenever you write a piece of code, think about how you can write it in a way that you can use it easily in the future.This typically means to write to a logic layer of the device.For example, setting a pin can be done on a PIC like this:Code:RA0 = 1; //set porta.0Next time if you want to move that pin to PORTB.4, you have to find out all the RA0 and replace them. Worse yet, if you were to move the code to a platform that doesn't offer bit-addressable pins, you have to rewrite it.So something like this would be better:Code:#define LED_PORT PORTA#define LED (1<<0)#define PIN_SET(port, pins) port |= (pins)PIN_SET(LED_PORT, LED); //set led on led_portIf you move the pin, you can simply change LED_PORT / LED and recompile.If you change the platform, you can simply change PIN_SET() and recompile, with the confidence that it would work.It is small things like that that makes coding robust. The focus on portability or readability isn't actually about porting the code. It is about building code that works under many circumstances.

author: tggzzz
author_rank: Super Contributor
timestamp: January 16, 2015, 04:34:00 pm
content: Quote from: poorchava on January 16, 2015, 07:21:02 amI suggest that you are in need of understanding the "design patterns" that are used in embedded systems. "Design patterns" are, by definition, language independent and are at a higher level than language statements. They are a codification of "ways of structuring implementation" that have been found to workin practicein alargenumber ofdifferentcases.Once you understand those patterns, you will be easily capable of translating them into C - or whatever other language is used on your next project.So, google for 'embedded "design pattern" ' and you will find things to help you. Even the top result looks like a good starting point!http://www.eventhelix.com/realtimemantra/patterns/Take the trouble to learn the reason for "thinking in design patterns", and then read and understand as many as you can. Your designs will improve - and also be more understandable by other people.

author: westfw
author_rank: Super Contributor
timestamp: January 17, 2015, 01:34:22 am
content: QuoteYes, but it's more than that... The biggest lack that tends to hit "self-taught" programmers is in the area of algorithms and data structures, which aren't even specific to particular programming languages.I can highly recommend this online Algorithms class (and its followup part2)https://www.coursera.org/course/algs4partI(starting about now BTW.) Yeah, they use Java. But it's all at such a high level that if you do nothing but watch the lectures, you'll learn a lot. If you do the quizzes (easy) and assignments (involved), you'll probably have knowledge equivalent to many university classes. If you translate the assignments into embedded C...Also recommended:https://www.edx.org/course/embedded-systems-shape-world-utaustinx-ut-6-02x#.VLm6XWTF8hs(also starting now.) This may be a bit elementary for people who already have experience, but it covers some interesting ground. If you "know it all", follow along anyway as your "into to ARM", and help out others in the forums. I did this last time, and found it rewarding; it can be particularly useful to understand the areas where classic programmers DON'T understand "embedded programming."Also recommended: classes, books, or examples in compilers, operating systems, hardware design, and networking. These are all instances of "low level" programming concepts that are important in embedded systems. (I don't have any particular recommendations here, but can say that material I learned in my (30y ago) compiler class was particularly useful for a lot of things.Assembly language classes. Knowing one assembly language is good for your resume, but knowing two or three starts to give you enlightenment about the internal workings of computers. Useful enlightenment!Here's a scathing comment AGAINST "design patterns":http://www.quora.com/What-are-the-most-important-design-patterns-that-software-engineers-should-know-to-work-at-Google-Amazon-and-Facebook/answer/Steven-Grimm?srid=hx&share=1All that said, there is an awful lot of embedded programming that doesn't really touch on "advanced" concepts, and instead is more like "how do I interpret this bad translation of a poorly written datasheet of the device I'm trying to talk to?" or "Where do I put my context switches so that I get the advantages of multitasking without sending my actual performance to hell?" or "How do I work around this bug in the hw/compiler/os?" I don't think there are many ways of getting better at that sort of thing other than just doing more of it.

author: Mechatrommer
author_rank: Super Contributor
timestamp: January 17, 2015, 02:37:12 am
content: Find book for processors/pc several decades ago you'll find good practices for mcu alike. As cpu progresses in complexity,so does sw and the good practices. Get a book for pc, you should find subset thats aplicable for mcu. And better,you have broader view of what is "good practice". Get a book on mcu,then you are stuck there. Every books on engineering are based on self taught and bold people of our ancestors.formalized and laid properly in writing so kids dont reinvent the wheel . Its a good thing but The complication is, most kids got the idea backward.

author: tggzzz
author_rank: Super Contributor
timestamp: January 17, 2015, 02:43:16 am
content: Quote from: westfw on January 17, 2015, 01:34:22 amThat article is poorly reasoned. There is a valid observation w.r.t bloatware and bloated layered frameworks, but to claim those are the result of (mis)using design patterns is simply silly.

author: Mechatrommer
author_rank: Super Contributor
timestamp: January 17, 2015, 02:46:13 am
content: Quotewell it seems i'm among the rarest clan.i was a self taught and still is,but the first thing i learnt in the beginning was that... language independent and the core'st data structure, algorithm and tips and tricks on how to run something that seems impossible on limited resources mcu.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: January 17, 2015, 02:53:51 am
content: Go to Amazon.com and search on "Jack Ganssle"

author: krish2487
author_rank: Frequent Contributor
timestamp: January 17, 2015, 07:06:26 am
content: Quote from: Sal Ammoniac onTodayat 01:53:51 PM

author: dmills
author_rank: Super Contributor
timestamp: January 17, 2015, 01:02:43 pm
content: I would suggest taking a bit of a step back,"The Pragmatic Programmer" by Hunt & Thomas,"Algorithms" by Sedgewick,"Code Complete" by Microsoft press (The first edition was more directly relevant to C on small cores IMHO)."Beautiful Code" by Wilson & Oram.Maybe also, "Structure and interpretation of computer programs" by Ableson & Sussman, and of course the classic "The Art Of Computer Programming" by Knuth for when you have a hard problem to solve.Regards, Dan.

author: legacy
author_rank: Super Contributor
timestamp: January 17, 2015, 01:46:07 pm
content: Quote from: dannyf on January 16, 2015, 12:02:04 pmit could depends … i mean if you have do deal with embedded targets & critical things, it may be your C will look like safe-C (aka MISRA C) instead of the ugly-no-styled C of the UNIX systemsbtw, i think you are mostly right

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: January 17, 2015, 06:36:52 pm
content: Here's a book that I'm reading now that I'm finding to be quite good:http://www.amazon.com/Better-Embedded-System-Software/dp/0984449000/ref=sr_1_fkmr0_1?s=books&ie=UTF8&qid=1421519703&sr=1-1-fkmr0&keywords=phil+koopmanIt's more about the process of writing good embedded code rather than how to write code.

author: tggzzz
author_rank: Super Contributor
timestamp: January 17, 2015, 07:33:18 pm
content: Quote from: Sal Ammoniac on January 17, 2015, 06:36:52 pmAnd, of course, writing good embedded code is only a very small part of designing a good embedded device/system.I shudder to think how poor system design will cause immense problems with IoT devices. Watch the newspapers over the next decade to find out

author: daybyter
author_rank: Frequent Contributor
timestamp: January 21, 2015, 11:26:50 pm
content: Maybe some UML book, like 'UML distilled' by Martin Fowler?http://martinfowler.com/books/uml.html

author: tggzzz
author_rank: Super Contributor
timestamp: January 22, 2015, 12:20:40 am
content: Quote from: daybyter on January 21, 2015, 11:26:50 pmUML helps you describesome aspectsof a design in a relatively standard way, so that other people can sort-of understand what you are saying. It doesn't, of itself, help create a good design.Structuring a design appropriately has to be done at a higher level than UML, e.g. sync vs async communications, whether to use FSMs or predicate logic, high availability and failovers.The best documetation for that is in the form of "design patterns", seehttp://en.wikipedia.org/wiki/Design_Patterns.The "Gang of Four" book kickstarted the concept, and is worth reading - but many other people have contributed domain-specific design patterns. Seehttp://www.amazon.co.uk/Design-patterns-elements-reusable-object-oriented/dp/0201633612

author: nctnico
author_rank: Super Contributor
timestamp: January 22, 2015, 01:45:23 am
content: It is not bad to go back a step and look at the big picture first. From what I have read 'design patterns' are solutions to / recipies for solving common problems. IMHO that is already a step too close towards an implementation. It is better to look at the big picture and divide a problem into smaller blocks in a such a way the software solution is simple. Ofcourse it could help to go through an iterative process to see what combination of design patterns fits a certain solution.Many years ago I bought a book by Hatley & Pirbhai (http://en.wikipedia.org/wiki/Hatley-Pirbhai_modeling). The book is hard to read so a waste of money. However their method basically comes down to describing a project in a process flow (interaction), a data flow (processing) and keeping both flows matched. This method has been superseded by UML long ago but for systems with medium complexity it still holds.

author: vvanders
author_rank: Regular Contributor
timestamp: January 22, 2015, 04:14:43 am
content: Quote from: westfw on January 17, 2015, 01:34:22 amAlgorithms classes are all well and good, but I wouldn't place nearly as much importance on them in an embedded space compared to a traditional CS track. Plus most algorithm classes I've found tend to miss the fastest sorting algorithm for < 1-5k items(radix sort based on 32bit key). They like to hand-wave away the constant terms and just look at O(n) when you could see 50-100x improvement by using sorting algorithms that are cache friendly on DRAM based architectures.You generally don't see the datasets where their theoretical performance holds out and in the case of some structures(binary trees, hash maps, and other non-contiguous structures) can wreak absolute havok on your memory allocations unless they are bounded or block allocated.

author: coppice
author_rank: Super Contributor
timestamp: January 22, 2015, 04:41:41 am
content: Quote from: vvanders on January 22, 2015, 04:14:43 amI guess you haven't looked at a lot of people's MCU code. Especially MCU code from people who started on tiny MCUs and are working their way up to more complex applications. The average MCU developer needs a much better appreciation of the power of good algorithmic and data structure design to make everyone's life easier.

author: tggzzz
author_rank: Super Contributor
timestamp: January 22, 2015, 09:58:00 am
content: Quote from: nctnico on January 22, 2015, 01:45:23 amI wouldn't argue with any of that. However IMNSHO in the context of the statements in this thread, understanding design patterns would be a step in the right direction.QuoteBack in the late 80s I was on a course taught by Pirbhai where he used the Hatley-Pirbhai book as the course reference. I came to a number of conclusions:it was a good sound integrated methodology (cf UML which is unified in the sense that cars can be unified with trucks or motorbikes at 30mph)they automated only the important and difficult part of the process: the database keeping track of where the requirements were implemented. In contrast, their belief was thatunimportantparts were done by hand,e.g. the drawingsit was very close to maching an interest of mine: executable specificationsit was heavyweight, and suited to their task: building the Boeing 777. Too heavyweight for my workplace, where fast turnaround was more appropriateI liked itif you need such a thing, it is much better than UML - which is amateur by comparisonI am still slightly regretful that I've never had the opportunity to use their methods.