astronomerroyal
New Member
Hello,
I'd like your advice on matters concerning designing/organising firmware projects using C.
Being a 30 year old novice I've finally realized I'm going to have to take responsibility for my behaviour and rewrite my firmware - complete misuse of header files, too many global variables etc. I'd like to get it right this time, hence this request for advice. For the record I'm using MPLAB, C18 compiler and 18F devices, naturally.
1) Michael Pont (**broken link removed**) in his book 'Embedded C' (Section 5.2) discusses a 'file-based object oriented' style using C. I believe the source file is analogous to the class, and the declarations of static variables and function prototypes in the source file are then the private members of the class, as opposed to things declared in the header file which are visible publicly. He suggests this approach for its maintainability and code reusability.
Any thoughts/experience with this approach? Pros/cons, when to choose it etc...
2) Pont also advocates the use of special-purpose header files e.g. MAIN.H is the project header that contains oscillator freq, #includes the device header, perhaps also statements like
which offer a shorthand, but also, brilliantly, allows one to change from an 8bit system to a 16bit system, for example, with relative ease. Then another header PORT.H containing #defines for pin names etc.
Maximizing the use of headers is probably a no-brainer but it took me weeks to understand this aspect of C. Anything to add here?
3) Jack Ganssle (The Ganssle Group - Home) in 'The art of designing embedded systems' (mostly for large teams of programmers rather than hobbyists) advocates modular hardware design e.g. uC for purpose A and another uC for purpose B, rather than one uC that does both. (Recommended for reducing development times of huge projects = $$$.) Personally, I like putting an LCD+keypad interface on almost all my projects - that's ~20pins used straight away. I was wondering if it made sense to have not just modular code for the user interface but also a dedicated uC that dealt with the keypresses/menu system/LCD and sent any resultant data to the other uC(s) via, say, I2C. Since I'm always pin-limited it would finally allow me to use In-circuit programming and debugging - seems like a huge motivation. Your thoughts?
As always, many thanks.
Here's my project - a motorized dolly for fancy time-lapse photography. Shiny on the outside, rubbish on the inside. And apparently 90 degrees rotated.
I'd like your advice on matters concerning designing/organising firmware projects using C.
Being a 30 year old novice I've finally realized I'm going to have to take responsibility for my behaviour and rewrite my firmware - complete misuse of header files, too many global variables etc. I'd like to get it right this time, hence this request for advice. For the record I'm using MPLAB, C18 compiler and 18F devices, naturally.
1) Michael Pont (**broken link removed**) in his book 'Embedded C' (Section 5.2) discusses a 'file-based object oriented' style using C. I believe the source file is analogous to the class, and the declarations of static variables and function prototypes in the source file are then the private members of the class, as opposed to things declared in the header file which are visible publicly. He suggests this approach for its maintainability and code reusability.
Any thoughts/experience with this approach? Pros/cons, when to choose it etc...
2) Pont also advocates the use of special-purpose header files e.g. MAIN.H is the project header that contains oscillator freq, #includes the device header, perhaps also statements like
Code:
typedef unsigned char tByte;
which offer a shorthand, but also, brilliantly, allows one to change from an 8bit system to a 16bit system, for example, with relative ease. Then another header PORT.H containing #defines for pin names etc.
Maximizing the use of headers is probably a no-brainer but it took me weeks to understand this aspect of C. Anything to add here?
3) Jack Ganssle (The Ganssle Group - Home) in 'The art of designing embedded systems' (mostly for large teams of programmers rather than hobbyists) advocates modular hardware design e.g. uC for purpose A and another uC for purpose B, rather than one uC that does both. (Recommended for reducing development times of huge projects = $$$.) Personally, I like putting an LCD+keypad interface on almost all my projects - that's ~20pins used straight away. I was wondering if it made sense to have not just modular code for the user interface but also a dedicated uC that dealt with the keypresses/menu system/LCD and sent any resultant data to the other uC(s) via, say, I2C. Since I'm always pin-limited it would finally allow me to use In-circuit programming and debugging - seems like a huge motivation. Your thoughts?
As always, many thanks.
Here's my project - a motorized dolly for fancy time-lapse photography. Shiny on the outside, rubbish on the inside. And apparently 90 degrees rotated.
Attachments
Last edited: