Details Table Of Contents:
- Brief Intro
- Useful Code!
- More than just a bunch of commonly-used code; 'commonCode' is a system
- Examples (if the Linux Kernel used commonCode)
- A Little History
- A List of 'commonThings'
- Starting a new project
- System Design/Flow (in project log)
- Project Log Table Of Contents
- mehPL (my "meh public license")
(Every code-bearing project I've made available contains a _commonCode_localized/ directory! Find out, here, what it does, and help me develop it further! Also, look here for more info.)
I think the name says it, 'commonCode' is a bunch of useful code. But it's more than that.
Similar to a 'library', I refer to each piece of commonCode as a 'commonThing'. CommonThings cover a broad-range of functionality: math functions, graphics, motion-control, I/O, peripheral drivers, protocols, etc.
(A listing of 'commonThings' follows the next explanation. Scroll down, then Please click "Read More")
What is 'commonCode' besides just a bunch of commonly-used code?
'commonCode' is a system, implementing:
- Example/test-code – most commonThings come with dedicated test-code
- Similar to 'hello-world' or 'blinky' (or the ol' AVR 'gcc-tests') getting-started projects
- Great place to start a new project, to learn how to implement a commonThing in your own project, or even get-started with a new architecture/MCU.
- Centralized 'commonThings'
- Make a bug-fix or improvement to one commonThing, and it will be applied to all projects using that commonThing (when they're recompiled).
- Configuration/Optimization-options and Abstraction
- What pin is your LED connected-to? Configure that in your project configuration, rather than modifying the commonThing. (Think about the centralized-bug-fixes, mentioned above. Now think about having five concurrent projects with different pinouts, fixing a bug in one, then having to modify four other files either with the bugfix or to copy the file with the bugfix four times and modify each with the pinout which you'd already had defined in the previous unbugfixed 'library.')
- Don't need certain functionality a commonThing provides? Mark that portion as "unused" and recover some program-space.
- Want to use that fancy commonThing on a different architecture? Many commonThings are completely architecture-independent. Many other once-AVR-specific pieces of code are being abstracted with no speed/program-space penalty. E.G. Your MCU doesn't use PB4/PORTB definitions? Override the default *inline* LED-On/Off functions with your own. Or replace the default LED-On/Off functions with functions containing printf's, and simulate that fading LED-thing in a console window on your desktop-PC.
- Handles dependencies/versions
- Can create a package of your project and all necessary commonCode: 'make localize'
- Can extract commonCode from a downloaded-project, placing it in your central commonCode directory: 'make delocalize'
- ...This bit is hard to explain, see the example below
I don't know exactly how to describe it, but it's a bit more like a distribution-system ala 'apt-get' for reusable project-code; handling dependencies, versions, etc. keeping it all centralized, and allowing for project-specific customization without modifying the centralized code. And all it requires is the standard toolchain (C, preprocessor, make, etc.).
Examples (if the Linux Kernel used commonCode):
Example 1: Say you were compiling two Linux Kernels, side-by-side... one for your desktop and one for your android phone. Normally you'd have two *HUGE* and nearly-identical source-trees containing all the code needed by both kernels, and both also containing code for all the drivers for a bunch of systems you've never even seen before.
If the Linux Kernel used something like 'commonCode', you'd have two folders containing little more than the specific configuration-files necessary for your two targets, and a third containing all the common stuff (and, optionally, wouldn't even need to have the code for unused...Read more »