TODO

FLASH SPACE LIMITATIONS:
Static tables for bitbanging are space expensive, flash reads are 1/2 ram speed
as well, though that hasn't been too much of a problem yet...

Need new ways to define patterns:

ISSUE:  We want to have up to N patterns at once (lets say 4?) for complex
setups that use multiple rings on cam wheels or multiple cam sensors (VVT?)

ISSUE: Wheels style classifications:
 1. N even tooth wheels (no missing teeth) (i.e. distributor)
	- Need to the know number of teeth and dutycycle
 2. N-M Even tooth spacing wiht one or more missing teeth (don't need to be 
    sequentiually missing)
 3. Angular defined wheels, Nissan 360 CAS, LT1, LS1, others

 Shortcuts?  Should we allow chars to define repeats?  i.e "*N" where N is 
 an integer?

 
Each wheel (set) is defined by a PATTERN GROUP which contains one or more
patterns that are "linked together", meaning they run in lock-step for a
full engine cycle then repeat.

Sets are defined with the following syntax: all fields are comma separated
 PARAM 1: an integer defining the output pin used (1-4)
 PARAM 2: C or c (crank or cam, meaning does the pattern repeat every 
		  360 or 720 deg)
 PARAM 3: A, S or M, ("A"ngular, "S"ymmetric, or "M"issing tooth)
 PARAM 4: for "S" and "M" types ONLY: NN/MM where NN and MM are integers 
		  defining the tooth duty cycle. i.e. "1/2" (50%) or "5/13" (38.4%)
 For "A" (angular) type wheels the remaining sequence is the HIGH and LOW
 times in degrees separated by commas, The total needs to add up to "360" for
 "C" (crank) wheels and "720" for "c" (cam) wheels.

 For "S" (symmetric) the final parameter is the number of teeth per cycle
 for the wheel type (i.e. number of teeth in 360 deg for "C" (crank) wheels 
 and then number of teeth in 720 degrees for "c" (cam) wheels.)

 For "M" (missing teeth) the remaining sequence consists of the wheels total
 of missing and present teeth, followed by the number of present teeth with a 
 "t" suffix and the number of missing teeth with an "m" suffix repeating until
 all teeth are accounted for., i.e. 36,35t,1m (36-1)
   NOTE: in theory we could get rid of the "t"/"m" suffixes to save flash
   space, but they add an addition layer of checking/verification.

Multiple wheels definitions for a PATTERN GROUP are separated by a colon
(from crank+cam patterns)

The patterns can be defined from any starting position in the wheel's rotation
and it is up to the user to pick a suitable location, it doesn't matter since
the pattern is cyclic and repetitive with each "virtual rotation" of the 
crank/cam.


Parsing:
Thoughts:
Walk the string pointer utilizing a state machine
Need to know the FULL DETAILS of the patterns to determine the amount of 
memory to allocate to fill out the array.

For simple (single wheel) pattern groups.
RAM needed:
	Assume 1 byte per edge (not optimal but easiest, and simpler ISR)
  For Missing and symmetric wheels:
	RAM requirement is number_teeth * duty cycle denominator,
	50% 36*2 = 72 bytes, 33% 36*3 108 bytes, 25%, 36*4 = 144 bytes
	How many bytes is each tooth is high is equal to the tooth dutycycle 
	numerator.
	For a really odd 5/13 dutycycle, for a 36 tooth wheel the ram requirement
	would be: 468 bytes, and each full tooth would have 5 bytes high, and 
	8 bytes	low, each full missing tooth would be 13 bytes wide...

  For ANGULAR wheels
	Options: 
	1. make it simple and make it 360 bytes for crank and 720 for cam
	2. Find the smallest factor between all the angles of the wheel and divide
	down. (may not work in every case, may be impossible to reconcile with
	another pattern)

RECOMMEND option 1 even though it uses more RAM and limits max virtual wheel
RPM.

RAM requirements for PATTERN GROUPS
Needto find least common factor for all of them.
First, If AT LEAST ONE pattern is cam, take crank pattern mem requirement and
double it., find least common factor among all patterns and multiply through
as needed.