At this point in time not a single user of LUFA is known and
here is reported how usb_serial apparently works more reliable:
http://forums.reprap.org/read.php?147,33082,160724#msg-160724
So it's likely we can move from lufa_serial to usb_serial entirely.
This is not only handy for debugging non-PWM mode, it may also
help those who run a heated bed attached to a solid state relay.
This way it was found out connecting heaters to non-PWM pins
works just fine and did so for a loooong time.
Not yet distributed to all the config.h templates.
This enhances encapsulation.
An attempt to initialise only the timers in use was abandoned.
This isn't only unneccessary, as pins are still in normal
operation mode unless their bits in TCCR0A/TCCR2A/... are set,
even with the timer behind the pins running, it's also at least
tricky to sort pins and their timer bits at compile time. Doing
the sorting at runtime would cause additional binary size.
- ATmega32U timer 4 register handling differs from other AVRs:
Change heater.c and mendel.c.
- LUFA USB recognition expanded in Makefile.
- Add section for __AVR_ATmega32U4__ in arduino.h.
The atmega32u4 timer 4 registers differ from other AVRs, requiring
changes in heater.c and mendel.c The teensy/atmega32u4 uses LUFA USB,
but does not have 'usb' in the name, requiring changes in the
makefile PID values read from a blank EEPROM are set to default
rather than using zeros.
Saves 10 bytes RAM and 16 bytes binary size on an 1284P (8 ADC
channels) running two sensors. Should also be a bit faster, as one
loop runs fewer iterations.
Also, checking for NUM_TEMP_SENSORS was a mistake, as temp sensors
_not_ using an analog pin exist. Extreme case is, temp sensors
exist, but zero ADC channels are used.
Wow! It took something like two years to expose (and get
developer attention of) such a bug: the checksum was calculated
based on the uppercased characters parsed, not the ones actually
received over the line.
The idea was to clear all flags with one variable, but actually,
this raises the binary size instead of lowering it. So, the code
in gcode_parse.c, line 354, is probably as fast as it can get.
Remove the assumption there's always an extruder temperature
sensor and make reading on single sensors (e.g. M105 P2) more usable.
Apparently works very well, but *sigh* yet another 100 bytes of binary size.
There were a whole bunch of cases where P and/or S were used without
checking for the validity of the value. This led to all sorts of
confusion, for obvious reasons.
Markus Hitter
David Forrest
Mikko Sivulainen
Ben Gamari