commonCode (not exclusively for AVRs)

A shit-ton of things that are useful for a shit-ton of projects. (and, Think 'apt-get' for reusable project-code)

Similar projects worth following
commonCode is similar to centralized shared-libraries or DLLs on a desktop-computer, except aimed at (though not exclusively for) microcontrollers, and developed-heavily for the AVR-series.

The idea is to keep the code that's used in several projects in a central-location, so that e.g. bug-fixes to this 'commonCode' will trickle-down to other/older projects.

Especially-handy when developing two projects simultaneously.

Also automatically handles inclusion of dependencies.


'heartbeat' is a fading/error-code LED and pushbutton on a shared pin.
It uses (and automatically-includes):
* 'hfModulation' to fade the LED
* 'bithandling' for basic bit-manipulation, signed-shifts, port/pin directions...
* OPTIONALLY 'tcnter' or 'dmsTimer' for accurate timing (1-second blinks)
'tcnter' and 'dmsTimer' include:
* 'timerCommon' - a standardized interface for most AVRs' timers
* (and bithandling, if heartbeat wasn't already included)

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)
  • Status
  • Project Log Table Of Contents
  • Licensing
  • mehPL (my "meh public license")

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:

  • 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.
  • Distribution-system
    • 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 »


Goertzel Algorithm in integer-math... It's been a *LONG* time since I last worked with this, and I really have no idea of its status. AS I RECALL, it was once floating-point, and this was my ATTEMPT at integerifying it... I don't know whether it works. DO NOT DOWNLOAD THIS. It's a friggin' mess. And in no way representative of most of commonCode. Wow, what a mess this is!.

Zip Archive - 35.71 kB - 10/23/2016 at 04:17


  • 1 × Atmel AVR Many MANY devices are supported
  • 1 × PIC32MX Currently the MX170 and MX230 are being implemented
  • 1 × Desktop PC Many of the commonThings/libraries can run on a desktop PC
  • 1 × typical toolchain for the selected architecture gcc, make, etc
  • 1 × programmer for the selected device FT2232H JTAGger and OpenOCD for the PIC32, avr-dude and USB-Tiny-ISP for AVRs. (No programmer required for desktop-PC apps l(

  • --- STATE ---

    Eric Hertz02/25/2017 at 16:31 0 comments

    To be honest, I ran out

    of steam on making this project "public-ready." But most of my projects

    rely on it, so it's "out there." At least, in parts.


    I doubt

    that commonCode would offer much, library-wise, that you couldn't

    find elsewhere.

    So, I guess, upon re-looking at commonCode from an outside-level (vs. just using it for my own projects), it might be less about the libraries themselves, and more something along the lines of an *environment* like Arduino; plausibly a bit more customizable and more optimizable, but significantly (nearly infinitely) less-documented and less-supported... nevermind more fine-tuned for my own needs/habits/style... more esoteric ;)

    There'd definitely be a learning-curve to use this system or any of the code within it, probably starting with 'blinky' (or 'heartBeat') and slowly moving up from there. And, again, since I've put public-readiness on the back-burner, the examples stop pretty early-on, pretty much immediately after the [bitbanged] UART 'echo' example. From there, (nearly everything else) user-level documentation is sparse, and user-level consistency even more-so.

    Oh, and... I went through several different iterations of "public-readying" those early-examples, especially as I started making it even more architecture-independent, so the actual user-level interface/examples probably vary between each "step"...



    So, again, *I* use this 'system' for nearly every code-based project I do... and improve it as I go along... But it's not really "public-ready," and making it so, in its entirety, would be a tremendous undertaking.

    But if you're *really* interested in trying out the [a bit outdated] blinky example...

    And here's a project which uses 'the system':

    Browse into the _commonCode_localized directory to see what's used in that project... Usually I start a project with nothing more than 'heartBeat', then move on to 'polled_uat', and then 'polled_uar'. These *should* have test-code in a subdirectory... e.g. _commonCode_localized/heartbeat/2.06/<test>/ wherein you should be able to type 'make' and try it out... But no promises. ;)


    Thanks @David H Haffner Sr for inspiring this status-update!

  • extra warnings/errors

    Eric Hertz01/06/2017 at 23:34 0 comments

    It's handy to have gcc output errors for certain things...


    uint16_t a = 512;
    uint8_t b = a;


    In my code, I prefer to have it explicitly stated that I want to "downsize", so I don't mistakenly do that.

    So, as I recall, there's a gcc-warning option for that, and further a means to convert that warning into an error.


    Here's a listing from my makefile.

    The remaining are CFLAGS for -W... arguments
    # Warnings that I would rather be considered errors...
    # THESE ARE gcc-version specific! (Apple's GCC 4.01 doesn't like 'em)
    #WTF, seriously... this should *not* be a warning, but should be an error:
    #warning: integer overflow in expression [-Werror=overflow]
    #       (((uint32_t)(TOGGLETIME * 8))<<(highNibble)),
    #from heartbeat1.50
    CFLAGS += -Werror=overflow
    # Stupid Mistake: strcmp(0==instruction,"test")
    #  should have been 0==strcmp...
    # Gave a warning, but wanted to convert that to error-material, nogo.
    # Apparently only works when int is of the wrong size for pointer...
    #CFLAGS += -Werror=int-to-pointer-cast
    # Specifically missing return value
    # This is handled with -Wreturn-type "falling out of a function is considered returning void"
    CFLAGS += -Werror=return-type
    # Watch for use of uninitialized variables...
    # This does not handle volatiles! Does (attempt to) look for uninitialized array elements.
    # This apparently isn't very smart and is optional because of that. See the manpage
    # I'd like to think it's possible to code things so it can be detectable, we'll see.
    # Problems? "Some spurious warnings can be avoided if you declare all the
    #            functions you use that never return as 'noreturn'."
    CFLAGS += -Werror=uninitialized
    #THIS IFNDEF is a hack... the old avr-gcc doesn't have this option
    # Would be better to test these options in GCC before compiling... TODO
    ifndef CC
    # That's basically useless in all but the simplest cases, as is:
    CFLAGS += -Werror=maybe-uninitialized
    # Neither detect:
    #int main(void)
    #   int result;
    #   if(rand())        //may be 0
    #      result = 1;
    #   printf("%d\n", result);
    #   return 0;
    # And haven't for over a decade. Except, apparently, Apple's GCC4.0
    # This case is just BAD and should not be allowed ever.
    # int i = i;
    CFLAGS += -Werror=init-self
    # The next two could be handled together with "implicit"
    # Implicit declarations (no type specified: e.g. "static i;")
    CFLAGS += -Werror=implicit-int
    CFLAGS += -Werror=implicit-function-declaration
    # Detect global functions that aren't in headers...
    # This one's kinda annoying... useful, but annoying
    #CFLAGS += -Werror=missing-prototypes
    #CFLAGS += -Werror=missing-declarations
    # Might want to look into -Wignored-qualifiers
    # also -Wmissing-braces (just to be paranoid about array-initialization)
    CFLAGS += -Werror=missing-field-initializers
    # Watch parentheses and nesting... mainly:
    #   if (a)
    #     if (b)
    #       foo ();
    #   else
    #     bar ();
    CFLAGS += -Werror=parentheses
    # Watch out for undefined stuff like a = a++;
    #  do not fall into these habits as "more complicated cases are not diagnosed"
    CFLAGS += -Werror=sequence-point
    # Watch out for switches without default cases... I consider this bad practice
    # Who knows what'll happen if an integer's bit is affected by protons?
    CFLAGS += -Werror=switch-default
    # Do not allow float comparisons that are ==
    CFLAGS += -Werror=float-equal
    # Don't allow bad address comparisons (if(func) instead of if(func()))
    CFLAGS += -Werror=address
    # Might also want to look into int-to-pointer-cast and pointer-to-int-cast
    # Watch for pointer argument passing and assignment with different signedness
    CFLAGS += -Werror=pointer-sign
    # Stop on the first error
    #CFLAGS += -Wfatal-errors
    # Warn for variables that might be changed by longjmp or vfork.
    CFLAGS += -Wclobbered
    # Warn about implicit conversions that may alter a value
    # Annoying... especially when using a uint8_t as an array position uint8_t i; noteList[i];
    #CFLAGS += -Wconversion
    CFLAGS += -Wsign-compare
    # -Wstrict-overflow looks worthwhile for many reasons... watch out for optimization...
    Read more »

  • To Revisit:

    Eric Hertz10/31/2016 at 08:01 0 comments

    This looks useful, but I'm unfamiliar with all the tools: #REM

    Check out the "Comments Section" on the main-page of this project for an overview from the expert, himself.

  • weee! 'bithandling' and now 'gpio_port'

    Eric Hertz09/06/2016 at 05:04 9 comments

    So the "thing", of the last post, was porting of such that grbl can now be more-easily ported to a variety of architectures.

    Now (actually, months-ago) functioning and configurable for either a PIC32 or the original AVR (while remaining Byte-For-Byte identical to the original!). If you're curious, check out the "diff" at that page.


    Today, as a move toward porting #sdramThingZero - 133MS/s 32-bit Logic Analyzer to its next architecture (originally AVR, now PIC32, and, again, with all intention of making it completely "architecture-agnostic" (where did I get that phrase stuck in my head...? It doesn't seem quite right...)... as a means to that end, I've begun the first completely new version of my first go-to 'commonThing,' 'bithandling,' since its origins about a decade ago.


    I've jumped from v0.99 to v1.99, because, frankly, it's darn-near entirely different, and darn-near a complete rewrite, with new function/macro-names and more standardization...

    E.G. a big one that should make it a million times more intuitive:

    all argument-lists are now arranged such that the variable to be modified is listed *first*.

    Apparently, I was pretty much completely arbitrary about that in the previous versions... and, despite having made *TONS* of use of it over the years, that was always a big trip-up...

    e.g. writeMasked2(variable, mask, value) rather'n... oh jeeze, what was that order again?

    E.G.2. a big one that might make it a million times less intuitive:

    'bithandling' has been stripped of most of its GPIO-related stuff, that stuff has now been moved to 'gpio_port' (that's a "more intuitive")... but in-so-doing I also changed quite a few macro-names... e.g. whereas previously all the port-related macro-names were *very closely* related to the associated 'bithandling' names (e.g. setpinPORT() ~ setbit()) now they're NOT AT ALL similar. E.G. setpinPORT -> gpioPORT_ohJeezeI'veAlreadyForgotten.

    gpioPORT_makeOutputPinHigh(), or, rather, gpioPORT_outputOneToPin(), I think.

    So, where *reading* the code is downright self-explanatory, *writing* the code seems to result in lots of reference to gpio_port.h

    That, maybe, is more a result of just not yet being familiar with it...

    It was pretty bad, before, as well... e.g. there was setinPORT() and setPORTin()... one would set a pin on a port to an input, the other would set the entire port to inputs (all bits).

    These *ideas* came about mostly as a result of prepping these macros for grbl-abstracted, and, to a much lesser-extent, much of it was implemented there... and I'm pretty content with most of the changes, but there's reason I went to 1.99, rather than 2.00, as I'm obviously not 100% on a few things. (But, surely, it was *WAY* too large a change to go from merely 0.99 -> 1.00)

    So, having written the whole blasted thing with those crazy-long function-names ala how you're supposed to choose a difficult-to-crack, but allegedly-easy-to-remember password: well, anyways, you're *supposed* to be able to remember those things... but these things are a bit more wonky... Did I choose "correct" or "right", "One" or "High" this time 'round...? Yahknow?

    ...I find I might just write a whole new set of wrapper-macros or otherwise rename 'em back to the old names I've somewhat arbitrarily-memorized, but with a "2" at the end so I know that the version-2 macro-names *always* have the arguments listed with the *variable first* (or *PORT*).

    We'll see.

    Maybe I'll write a shell-script to automatically change e.g. setinPORT2() to gpioPORT_configurePinAsInput() for whenever I might decide to distribute something, just so it's easier for me to write/remember, while also being easier for newbs to digest. It's a thought.


    Other additions:

    Because bithandling is pretty much the first thing to go into any of my projects, regardless of the architecture, it handles a few architecture-related-things, like making it possible to easily add architecture-specific...

    Read more »

  • new... thing...(?)

    Eric Hertz06/18/2016 at 18:11 0 comments

    So I'm working on porting someone else's thing to another thing...

    That "someone else" happened to use some pretty specific things to access their thing, and I'm working on abstracting those specific-accesses to work with my thing... (I'll call it my thing, merely in expression of differing it from the other person's thing which doesn't yet work with the thing I'm trying to make it work with, for my own purposes, which in-so-doing might just make it work with many others' things, with much less effort than currently necessary to make that person's thing work with other people's things).

    hmm, sounds a heck of a lot like what I've been doing here... Abstracting things...? And, low-and-behold, in-so-doing, I've been kinda converting that thing to make use of this thing in order to make it work with mything. Hmm...

    But, I don't particularly want to release "this thing" (nor most of my things) in its entirety via the typical licensing-thing that these things are typically licensed-under--despite the fact that that licensing-thing is exactly what enables things like this to become so common-place in the first place--because, frankly, there're a few side-things in that licensing-thing that I don't particularly agree with subjecting my efforts toward.

    So, rather'n forcing this thing upon that thing, and either sacrificing my preferred-licensing-thing over their licensing-thing or forcing my licensing-thing upon their-thing, I'm thinking, instead, to release *portions* of this thing under that/their-licensing-thing as a means to (hopefully) better their thing and maybe even finally see this thing begin to enter into the usefulness-playing-field, to boot.

    Who knows, it could be all hogwash, but it's a new concept I hadn't considered before...

    I'll be less abstract when I actually get that thing working on my thing. But, as it stands, it looks like this thing is merging into that thing quite a bit more smoothly than I first-expected. Fun things!

    Oh, for a tally, the new thing, so far, takes 6 bytes more program-space than the original thing, out of nearly 32KB, that ain't bad. And, I think, actually, that 6 bytes may be largely due to a mutex-bug I found/fixed in "that thing." So, in fact, it could be that all this abstraction and the benefits it may gain that thing might, in effect, have no noticeable *functionality*-consequences whatsoever... Which, admittedly, was kinda a big part of the goal, but a really nice surprise to see verified.

  • commonCode, commonCode, I haven't forgotten ye...

    Eric Hertz03/06/2016 at 11:38 0 comments

    commonCode is one of those things I (generally) work on as a side-aspect of other projects...

    So, lately, I've been working on my #Big Ol' Modular CNC and various aspects thereof... mostly the motor-control and position-sensing aspects, these days...

    The latest is #anaQuad!, which will *definitely* be added as a new 'commonThing' soon. This guy... well, take a really low resolution analog-output optical encoder (like that from a computer's ball-mouse) and bump that resolution *way* up using an ADC. Currently I'm working with a 72-slot encoder-disk and anaQuad's able to resolve a resolution of 1152 positions per revolution, without adding a whole lot more processing-time than a regular-ol' quadrature-decoding algorithm (e.g. 'encoderDirect'). This guy also has the benefit of... if it somehow falls behind the actual motion, as long as it's less than half a slot, it'll eventually "catch up"... so no "invalid quadrature states".

    I dig it.


    I've been working with PIC32's for a bit, now... The *vast majority* of commonCode was developed on AVRs, so I'm coming up with new ways to make the system more 'architecture agnostic', and including those new discoveries in my progress with commonCode.

    The latest, I guess, is that there seems to be a sort of "core" bit of code that remains almost completely unchanged, regardless of the architecture. Then there are certain architecture-(and project!)-specific aspects that that 'core' relies on...

    E.G. for the 'heartBeat', there's the bit that handles the fading/blinking of the LED, knowing when to switch the pin to an input, waiting for pull-up resistors to overcome capacitances, then reading whether the button is pressed... That's the "core" of the heartBeat code.

    Whereas, there's a tiny bit that's architecture/project-specific... E.G. *which* pin is used for the heartbeat...? How is that pin accessed...? (how do you make it an output, set it high or low, for the LED, and then switch it to an input for the pushbutton...?).

    I went to a bit of effort to keep some sort of standardization, there, based not only on the switching of pinouts/projects, but also for the switching of architectures *while* keeping it backwards-compatible with old projects... I think I went about that wrong.

    Rather'n telling the 'heartBeat' commonThing which *pin* to use, (which gets a bit complicated when switching between MCU's), instead, maybe, tell it *how to access* the pin...

    So... heartBeat, now, has a few functions which must be defined specific to the project, something like "heart_setLED(on/off)", "heart_switchToInput()", "heart_readInput()". These guys are *REALLY* simple. heart_setLED(on/off) is basically nothing more than something like if(on) setBit(pinNum, PORT); else clearBit(pinNum, PORT). And, frankly, for the most-part, they can be the same for the vast-majority of projects, especially those on the same architecture.

    So... where am I going with this...?

    It gets a bit more complicated, e.g. with anaQuad, which makes use of ADCs... Each architecture's ADCs will have a different interface, different registers... so those will have to be set-up prior... So, anaQuad is supplied with a project-specific function for getting the values from the ADC...

    OK, so this is where it gets interesting... There's no reason heartBeat's "heart_setLED()" function has to access a *pin*... It could do *anything*... It could, just as well, contain a 'printf()' call, that prints a '.' on a terminal-window when the LED should be off, or a '*' when it's on...

    Or, for anaQuad, the "anaQuad_getChannelVal(A/B)" function could just as easily grab a value from a ... webpage... for all it cares.

    This makes *testing* really easy... anaQuad's desktop-based test-application just fills the getChannelVal() functions with values from C's built-in sin() function (and a little math). But the *core* of anaQuad is usable on any architecture, from any sinusoidal (or maybe even triangular) source, with a tiny bit of configuration....

    Read more »

  • 'hfModulation' and motors

    Eric Hertz09/09/2015 at 16:32 0 comments

    I never really figured I'd find a use for 'hfModulation' for motors, as generally PWM works well, and generally you want to minimize the number of level-transitions so the MOSFETs don't sit in the resistor/heat-producing state for too long/often... But I finally found a purpose for using it with motors, and there's a bunch of other info here about hfM and power-supplies. (TODO: put a bunch of this info as comments in the code!) And another blog-mention. Too Cool!

    Oh, also, I think we determined with some amount of certainty that 'hfModulation' is actually "first-order delta-sigma modulation".

    And, if you don't know, 'hfModulation' is used for several purposes including LED fading in 'heartbeat', pixel-stretching in 'lcdStuff', bit-stretching in 'polled_uar' and 'polled_uat', is used to increase the resolution on my 'racer' game's track, and several other things. It works well for purposes where division would otherwise be used within iterative loops.

  • System Design

    Eric Hertz08/17/2015 at 16:12 0 comments

    Each commonThing typically has three files: thing.h, thing.c and (represented as a whole by the green boxes in the following diagrams).

    The commonCode system handles automatic inclusion of nearly all aspects of each commonThing. E.G. for a simple test program for the 'heartbeat' commonThing, many other commonThings are included: hfModulation (which handles modulating/fading the LED), tcnter (which handles timing and is useful for many other purposes), and timerCommon (which handles the interface with the AVR's timer peripherals).

    When using defaults, main.c can be as simple as:

    #include _HEARTBEAT_HEADER
    int main(void)

    Optionally, the following can be added to the while() loop:

    static int blink = 0; //0 = fading in and out, not blinking

    Since heartbeat is a good starting-point for (and useful in) most projects, its “test” code is a great place to start any project. Its 'makefile' contains all the necessary defaults and detailed explanations for each configuration option.

    Note that heartbeat.h contains a usage-example, as shown above.

    In the following examples, each of the additions are shown assuming you've started with the heartbeat test application.

    Addition of polled_uat (the bit-banged universal-asynchronous-transmitter) is as simple as adding the following lines to the original 'heartbeatTest' makefile:

    VER_POLLED_UAT = 0.40
    POLLED_UAT_LIB = $(COMDIR)/polled_uat/$(VER_POLLED_UAT)/polled_uat
    include $(POLLED_UAT_LIB).mk

    And this optional line defines the baud-rate:

    CFLAGS += -D'BIT_TCNT=((TCNTER_SEC/9600))'

    This process may seem ugly/complicated, but it is thoroughly standardized throughout the commonCode system, so that adding another commonThing, regardless of its dependencies, is as simple as adding the first three lines, as appropriate. Doing-so includes several pieces of each commonThing, including: a makefile snippet which adds the commonThing to SRC for compilation, creates a macro for the #include statement which contains the proper version, (and, again, handles inclusion of dependencies, if not already included).

    Then in the previous heartbeatTest's main.c add the following three lines in their respective locations (note the argument: 0. There can be multiple puats!):

    #include _POLLED_UAT_HEADER_

    (and optionally: puat_sendByte(0, byte);, etc. as-desired).

    Again, polled_uat.h contains a basic usage-example showing these lines and where they belong.

    That's it!

    To make it a little bit more sophisticated, the following adds transmission of a Period '.' once every second (in the while() loop):

    static tcnter_t lastTime = 0;
    if(tcnter_isItTime(&lastTime, TCNTER_SEC)
        puat_sendByte(0, '.');

    Note that tcnter_update() isn't called in the while() loop, because tcnter and heartbeat are both so commonly-used, tcnter_update() is by default automatically included in heart_update(). (This like many such defaults, can be changed and/or disabled by options in the makefile).

    Now, let's add the polled_uar (the bit-banged universal-asynchronous-receiver):

    polled_uar is another commonThing, so it's added in the same way as polled_uat (and, indeed heartbeat). Add these lines to the makefile:

    VER_POLLED_UAR = 0.40
    POLLED_UAR_LIB = $(COMDIR)/polled_uar/$(VER_POLLED_UAR)/polled_uar
    include $(POLLED_UAR_LIB).mk 

    (BIT_TCNT, defined earlier, also applies to polled_uar)

    And add these lines, in their appropriate locations, to main.c:

    #include _POLLED_UAR_HEADER

    The polled-uar, of course, has the ability to receive data, so something needs to be done with the data it receives, so to implement 'echo' you can add the following to the while() loop, after puar_update(0):

        puat_sendByte(0, puar_getByte(0));


    As you can see, this standardized methodology is used throughout the commonCode system to include commonThings assuring only those necessary pieces get...

    Read more »

  • This is getting confusing... + video!

    Eric Hertz08/17/2015 at 07:33 0 comments

    While, technically, these three projects are three *separate* projects (as in, they have different end-goals), they all feed into each other. I'm talking about:

    A description of these three projects, and how they feed into each other, follows the video, so be sure to click the "Read More" link!

    Click "Read More!"

    Read more »

  • the main-three now on PIC32

    Eric Hertz08/11/2015 at 14:34 0 comments

    The 'main three' are now running on PIC32: 'heartbeat', 'polled-uat' and 'polled-uar'...

    so we have I/O, timers, and a bitbanged UART. Now on to motion-control: #2.5-3D thing

    See more about the PIC32 porting-process at: and #operation: Learn The MIPS (PIC32MX1xx/2xx)

View all 22 project logs

  • 1
    Step 1

    From the file '_GettingStartedMega328P.txt'

    (Developed alongside submission of 'audioThing' to the contest)


    Try to Resize your window-width (counter-intuitively: *smaller* may look better, as HaD apparently lays-out the page differently depending on your window's width).

    Unless otherwise mentioned: commonThing tests are usually located in 
    If working with another MCU:
     Look into the makefile, change the line "MCU="
     Look at pinouts (choose different pins, as necessary)
     Most AVRs are set up to run off the internal RC-Oscillator, by default...
      Though this can be checked by looking into 
      and changed by typing your own FUSEH/FUSEL values into *your* makefile.
    The default chip-programmer is avrdude with a usb-tiny... check out:
    Run 'make fuse'
        'make clean'
        'make run'
    In order of increasing complexity, ish... This order is a good way to start
       heartBeat fades an LED in then out, ala the good ol' Mac "sleep"
       indicator. With DMS the fade-cycle takes 8 seconds.
       If you press the button, the heart will begin blinking the number of
       times the button was pressed. (Until 4, when it returns to fading)
       polled_uat is a polled/bitbanged UART (serial port) without the
       receiver.  The test program runs at 9600 baud and transmits "Boot:" upon
       power-up, and counts from 0-9, one step per second.
       polled_uar is a polled/bitbanged UART (serial port) without the
       transmitter. The test program runs at 9600 baud. Send characters '1'-'9'
       and the heartBeat indicator will blink the specified number of times
       ('0' returns it to fading)
       This is a Tx/Rx program which is nearly identical to polled_uar's with
       the addition of: it transmits a message on boot, sends '.' periodically,
       and echos received characters.
       Please see the file NOTE.TXT regarding sync-errors related to
       heartbeat's spending too much time updating, and how it can be easily
    AT THIS POINT: You have an LED, and Tx/Rx, so anything new can be tested
    from here...
    I need to implement SPI via the USART... Haven't done this before... 
    Did SPI before via USI on another device, but that's different. Enter:
       After implementing SPI via the USART in this commonThing's code, 
       the actual Test-Code is nearly identical to that of 
       polled_uat/testTxRxMega328p+syncError (a/o 0.10ncf)
       This tests the Nokia LCD, it expands on usart_spi's test.
       This tests "anaButtons" -- a method for interfacing an array of buttons
       via resistors and a capacitor to a single (typically *digital*) input.
       This samples the ADC in "free-running" mode, in which the ADC samples
       immediately after the previous conversion, continuously. The
       test-program reports the minimum and maximum values measured, as well as
       the number of measurements, once per second. This is based off of

View all instructions

Enjoy this project?



David H Haffner Sr wrote 02/21/2017 at 12:52 point

Hey Eric, this is very interesting code project you have here (and I've checked out any updates on it at your website also,) I'm somewhat working with Dave Allmon on my TCD1304 CCD driver for my spectrometer and I am wondering if any part of this library can be utilized in the code that we are using to drive the AD7667 and ATmega1284P?

  Are you sure? yes | no

Eric Hertz wrote 02/25/2017 at 16:08 point

Howdy David, Thanks for your interest!

To be honest, I ran out of steam on making this project "public-ready." But most of my projects rely on it, so it's "out there." At least, in parts.

As far as your specific project, I doubt that commonCode would offer anything library-wise that you couldn't find elsewhere. E.G. your ADC uses SPI, which is certainly supported by most environments (e.g. Arduino), or could be implemented at a lower (register) level without too much difficulty. And, in fact, commonCode doesn't implement SPI except on a couple very specific architectures; '1284 not included. (How can that be...? #audioThing - ephemeralEventRecorder used SPI... Maybe I never 'commonFiled' it?).

I'll have to think about this prospect a  bit more... Thanks for the prompting, I'll post a new log in a bit.

  Are you sure? yes | no

Franz wrote 11/02/2016 at 15:38 point

Hello Eric! I think, that your common code could be well integrated into the #REM buildsystem. I've developed this buildsystem to help maintaining such common software packages. The idea of the REM buildsystem is to reuse existing libs and other software packages and to be able to build the same microcontroller project for different architectures by only changing a so called "mach" file. 

  Are you sure? yes | no

Eric Hertz wrote 11/02/2016 at 17:09 point

Hey Franz! From your description, #REM - A Yocto like µC Buildsystem's functionality sounds exactly like what I hoped to eventually accomplish when making commonCode public. 

I'll definitely be looking into REM. It does, however, seem like there's quite a bit of overlap in our two projects, and, of course, I'm a bit stubborn and partial to not amputating even the pinky-toe off "my baby," no matter how disfunctional it may be. ;) 

It's the automatic downloading part in your project that's really caught my attention. Nevermind the fact that your system appears to be *already functional.* (big plus!)

  Are you sure? yes | no

Cristian Dobre wrote 06/09/2015 at 09:26 point

Hi Eric, 

I developed this code for fast reading of multiple analog channels on the ATMega328p, as I needed it in one of my robotics projects. Maybe it can be help you out in yours too.

I know it's not 100% reusable, because it was built with speed in mind(poor AVR was running out of processing time), but it is well commented and easy to understand.

Have a great day!

  Are you sure? yes | no

Eric Hertz wrote 06/09/2015 at 12:36 point

Hi Cristian,

Thanks for sharing that. 

Currently this system is a long ways away from being made-public, but I like the idea of others' being able to contribute 'commonThings' in the future.

Until then, it looks like your code would be well-suited for an arduino library, and probably get more visibility/downloads. :)

Thanks again!

  Are you sure? yes | no

davedarko wrote 01/14/2015 at 12:25 point

A tip for your PR department - write logs about projects you did with and if it is already a project hosted here, link the commonCode in those as well. Not every one will be hooked by this project alone, but if you make projects like the jars, make sure to drop "made with #commCode" often ;) And place the link on the stack page, every view counts.

  Are you sure? yes | no

Eric Hertz wrote 01/14/2015 at 16:33 point

Interesting point! Thanks Dave!

I'll have to check out the stack page, too...

  Are you sure? yes | no

Eric Hertz wrote 01/15/2015 at 13:52 point

Looked into the stack page, I'm not sure I understand what it's for... There doesn't seem to be a whole lot of activity, so it doesn't seem right to use it for shameless self-promotion...?

  Are you sure? yes | no

davedarko wrote 01/15/2015 at 14:04 point

I think it's only used for that :D I didn't want to say out too loudly that I don't think it's visited that often, so I said "every view counts" ;)

  Are you sure? yes | no

Eric Hertz wrote 01/13/2015 at 15:55 point

< Belligerent Woe-Is-Me rant removed, to protect the innocent >

I honestly don't know whether this project c/would appeal to enough people, HaD or otherwise, to bring in the kind of dough it'd take for me *to be able to* make it available to the public. Nor--experience shows--do I know how to go-about drawing the attention of the people to whom it might appeal and/or might be able to help.

(Cash is a definite absolute necessity, at this point, unfortunately. But among other things that could be useful: access to a reliable server on-which I can run server-side scripts for code/directory-browsing/downloading... unfortunately, GIT, etc. don't seem to do what I need)...


A more internet-friendly Summary of the removed-rant:

I'm really struggling financially (no, I mean REALLY), and have this crazy idea that maybe this project could bring in some dough if I could just figure out how to go about it. Unfortunately, there's a pretty strong time-crunch; an impending doom the likes of which most people see in the distance but never really encounter (thankfully). I have, however, encountered that, previously, and don't really want to again.

If I use this time to promote this project and it doesn't work out, I'll be facing that "doom" again.

The alternative would be to use what little time I have remaining in the more de-facto way that people do when faced with these sorts of challenges. A method which has, unfortunately, eluded me for years, and might-well continue to do-so even if I dedicated this time toward that... leading to the same "doom" either way.

  Are you sure? yes | no

Mike Szczys wrote 01/13/2015 at 18:15 point

Hi Eric,

I just sent you a private message. Let's talk about this.

  Are you sure? yes | no

Eric Hertz wrote 01/14/2015 at 01:23 point

Thank you, Mike, and thanks for being cool about the rant-aspect.

  Are you sure? yes | no

Eric Hertz wrote 03/14/2015 at 18:20 point

The "deadline" for the "impending doom" is, technically, at the end of this month.

THANKFULLY: The feared-requirements for that deadline have been scaled-back a little, *just* enough, actually. Doom-no-more, this go-round, but still broker'n'ever.

"Thank yous" abound, for many who have done so much to bring attention to this project. I know updates have been sparse, of late, but be certain that this project is still churning in the ol' gears. It's a "side-project" that quite literally makes *all* my code-projects possible, so is always under consideration for improvements.

The concepts behind the improvements made during (and shortly-after) "The Contest," I think, are totally sound. Further, I consider them necessities in making this project public. I'm not quite content with their implementation, however. I'm definitely mulling it over, but forgive the slow progress!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates