Details Table Of Contents:

Brief Intro

(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.)

Useful Code!

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:

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 systems/drivers).


Example 2: If you were working on two separate (but numerically-near) versions of the kernel (possibly testing whether your custom driver's code is backwards-compatible?), it's quite likely that the two kernels' source-trees would be largely identical. So why have two separate copies if you're not even working on that stuff? Instead, a shared source-tree could e.g. contain drivers/graphics/someModelGPU/ and under that folder could be 1.00/ and 1.02/...


This is what makes 'commonCode' what it is... I don't do kernel-development, but the 'commonCode' system works great for other types of projects as well...



For AVRs and other limited-memory systems, this bit's also quite handy: 'commonThings' have options that make it a bit like using lib-math without it already being precompiled... E.G. If the sin()/cos() functions aren't used in your project, then don't compile them! You don't use some of the more esoteric <stdio.h> functions? Then why the heck are we compiling them into our program-memory? Etc. Etc. Etc. Again, this is an example. As it stands, this system only works with commonThings, not lib-math or stdio.


A Little History:

commonCode is *NOT* exclusively for AVRs, and is being detached from 'em more and more every-day. (see: #operation: Learn The MIPS (PIC32MX1xx/2xx), wherein commonCode is being abstracted and ported to PIC32)

I've been developing software for AVRs since before Arduino existed and have done literally dozens of projects, many in permanent installations, and many others are being constantly improved...

In the process I've written and reused a bunch of code a bunch of times...

And in *that* process, I've developed this method for keeping this oft-reused code in a central location, handling dependencies, versions, etc.

As I've been developing more with desktop-applications, I too have been modifying the commonCode system to be architecture-independent.

I've found that this system lends itself well to development of new projects...

I'll describe that after the list.

A List of 'commonThings'

The list below contains some of my more well-developed commonThings...

The bold ones are regularly/recently updated. Some non-bold ones may be used-regularly but indirectly (e.g. hfModulation is used by heartbeat).

Some are quite old... (I've tried to eliminate the questionably-functional from this list)


General / Misc.:

Positioning (Not limited to motors):

Motor Control:

Modulation and blinking:

Keyboards/Keypads and other input:

LCDs / Graphics:

Math:

Serial/Protocols:

Timers and such:


Starting a new project:

When I start a new AVR project, I usually start with nothing more than the 'heartbeat' test-code... This gets me running with a fading LED, a timer, and a pushbutton. (I have an LED and pushbutton attached to my SPI-programmer's "dongle", so that I only need to wire-up the AVR, power, and a programming-header). If the LED fades at 8-seconds per cycle, then I know everything's working/configured right.


From there, I move on to the 'polled_uat' test-code, at which point I have serial I/O at 9600bps. (Recently, I've leaned away from using the U[S]ART and USI peripherals, as these are device-specific. The polled_uar and polled_uat are NOT AVR-Specific, and actually have desktop-PC based test-code that allows you to simulate serial I/O with a couple keys on the keyboard. Further, the polled_uar/t can be placed on any pins, so the default is to have them attached to pins on my programmer's "dongle," as well.).

Depending on my needs, I usually steal a few lines of code from other commonThings' test-code (throw their init() and update() functions in main, and copy a few lines from their 'makefile'). Then start modifying code as-necessary.

SEE: System Design/Flow

STATUS:

I started making my commonCode available as a result of posting my 'audioThing' project. (Thanks to the Trinket Everyday-Carry Contest for the motivation!)

As part of that process, I've come up with some new and easier methods for using and distributing commonThings, some new standards as far as test-code, and more. I'm hoping to make the getting-started process more step-by-step, implement test-code in commonThings that don't have them, and more.

A *big* hurdle I've yet to figure-out is *how* to distribute it! You see there's *dozens* of commonThings, and even more I didn't list here... I wouldn't mind using something like git, and even started putting stuff up on gitHub, but that doesn't really seem to lend-itself well to the structure, here... For one thing, it means having dozens of separate repositories. Then, to make things even more confusing; how should I handle *versions*? 'heartbeat' is now at v2.02 and has about 10 *functional* versions leading up to that. For the most-part there's no reason to distribute *all* of these, but some older projects still depend on older versions... changing them over to v2+ is a big change... and there's no guarantee that v1.50 is backwards-compatible with v1.10 (though most-likely v1.19 is). You get the idea. Even if I *only* uploaded the latest versions, what when I've developed 2.50?

Unless I can find (or am directed to?) a system that lends itself to a structure like this, the best I can think is to run a custom web-server... That would be my normal path; (I tend to reinvent the wheel, but usually do-so in a way that works well for my needs while giving me a good learning-experience in the process), but these days I don't have a steady internet-connection to serve from, nor access to a server like that...

So, for now, there's a bit to be done, and a bit to ponder.

Progect Log Table Of Contents (roughly oldest to newest, some from 'the other projects'):


Licensing:

The Vast Majority of 'commonCode' and its 'commonThings' are written by me, in their entirety, and fall under my so-called 'mehPL' (included below).

Exceptions are noted in the corresponding code.

Exceptions include:

See the mehPL for additional gratititude!

'commonCode' was developed to make use of GPLed tools such as gcc, gnu-bash, gnu-make, etc. as well as avr-libc, etc. However, commonCode does not contain their source-code except where explicitly mentioned (again, e.g. variable/register names/dereferencing-methods found in avr/io.h, etc) TODO! Similarly, Microchip's xc32-gcc, associated tools (xc32-objdump, etc.), and header/linker files are used by-default for PIC32 devices, but these files are not included with commonCode, and must be downloaded from Microchip and installed by the user.

mehPL:

My so-called "mehPL" is listed below. There's certainly room for improvement, and I'm willing to flex on a few requirements, in light of better ideas. (Feel free to contact me with 'em!) I haven't yet fully read the GPL nor other de-facto open-source licenses, but I am pretty certain they do not include some aspects I consider essential in my willingness to share my code... Again, I'm open to being enlightened!

Currently the top of each file is noted as follows:

/* mehPL:
 *    This is Open Source, but NOT GPL. I call it mehPL.
 *    I'm not too fond of long licenses at the top of the file
 *    Please see the bottom.
 *    Enjoy!
 */

The bottom of each file is noted with the terms of the mehPL:

/* mehPL:
 *    I would love to believe in a world where licensing shouldn't be
 *    necessary; where people would respect others' work and wishes,
 *    and give credit where it's due.
 *    A world where those who find people's work useful would at least
 *    send positive vibes--if not an email.
 *    A world where we wouldn't have to think about the potential
 *    legal-loopholes that others may take advantage of.
 *
 *    Until that world exists:
 *
 *    This software and associated hardware design is free to use,
 *    modify, and even redistribute, etc. with only a few exceptions
 *    I've thought-up as-yet (this list may be appended-to, hopefully it
 *    doesn't have to be):
 *
 *    1) Please do not change/remove this licensing info.
 *    2) Please do not change/remove others' credit/licensing/copyright
 *         info, where noted.
 *    3) If you find yourself profiting from my work, please send me a
 *         beer, a trinket, or cash is always handy as well.
 *         (Please be considerate. E.G. if you've reposted my work on a
 *          revenue-making (ad-based) website, please think of the
 *          years and years of hard work that went into this!)
 *    4) If you *intend* to profit from my work, you must get my
 *         permission, first.
 *    5) No permission is given for my work to be used in Military, NSA,
 *         pranks, victimizations, 'hacking' of others' computers/networks,
 *         or other creepy-ass purposes. No exceptions. And if there's
 *         any question in your mind as to whether your project qualifies
 *         under this category, you must get my explicit permission.
 *
 *    The open-sourced project this originated from is ~98% the work of
 *    the original author (me), except where otherwise noted.
 *    That includes the "commonCode" and makefiles.
 *    Thanks, of course, should be given to those who worked on the tools
 *    I've used: avr-dude, avr-gcc, gnu-make, vim, usb-tiny, and
 *    I'm certain many others.
 *    And, as well, to the countless coders who've taken time to post
 *    solutions to issues I couldn't solve, all over the internets.
 *
 *
 *    I'd love to hear of how this is being used, suggestions for
 *    improvements, etc!
 *
 *    The creator of the original code and original hardware can be
 *    contacted at:
 *
 *        EricWazHung At Gmail Dotcom
 *
 *    This code's origin (and latest versions) may be found at:
 *
 *        https://github.com/ericwazhung
 *        https://code.google.com/u/ericwazhung/    
 *        https://github.com/esot-eric-test         
 *
 *    The site associated with the original open-sourced project is at:
 *
 *        https://sites.google.com/site/geekattempts/
 *
 *    If any of that ever changes, I will be sure to note it here,
 *    and add a link at the pages above.
 *
 *    (Wow, that's a lot longer than I'd hoped).
 *
 *    Enjoy!
 */