Project Logs

Collapse

• --- STATE ---

  Eric Hertz • 02/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"...
  

  Weee!

  -----------

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

  https://github.com/esot-eric-test/heartbeat-2.00-gitHubbing_-revisions

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

  https://github.com/ericwazhung/sdramThingZero

  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 Hertz • 01/06/2017 at 23:34 • 0 comments

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

  e.g.:

  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
  #-Wstrict-aliasing?
  # 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
  endif
  
  
  # 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 Hertz • 10/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 Hertz • 09/06/2016 at 05:04 • 9 comments

  So the "thing", of the last post, was porting of https://github.com/ericwazhung/grbl-abstracted 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:

  https://xkcd.com/936/... 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 Hertz • 06/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 Hertz • 03/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 Hertz • 09/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 Hertz • 08/17/2015 at 16:12 • 0 comments

  Each commonThing typically has three files: thing.h, thing.c and thing.mk (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)
  {
      heart_init();
  
      while(1)
      {
          heart_update();
      }
  }
  
  

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

  static int blink = 0; //0 = fading in and out, not blinking
  
  if(heart_getButton())
      heart_setBlink(blink++);
  

  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_

  puat_init(0);

  puat_update(0); 

  (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
  

  puar_init(0);
  

  puar_update(0);

  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):

  if(puar_dataWaiting(0))
      puat_sendByte(0, puar_getByte(0));

  Conclusion:

  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 Hertz • 08/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:

  • 'commonCode' (this project)
  • #operation: Learn The MIPS (PIC32MX1xx/2xx)
  • #2.5-3D thing

  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 Hertz • 08/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: https://hackaday.io/project/6450/log/22496-finally and #operation: Learn The MIPS (PIC32MX1xx/2xx)
  

View all 22 project logs