In order to save space for patterns, we set the brightness
independently from pattern. Each brightness has only two levels
for PWMLED 0 and 2, and one for PWMLED 1. Patterns can then use
two-bit values for each PWMLED (one-bit for PWMLED 1), with the
following meaning:
0: off
1: level 1
2: level 2
3: also level 2, with a separate state stored. This can be used for
saving regulation value for a single current level with
and without other outputs running, or with different levels
of other output. This is in order to avoid flicker when one
PWMLED (usually the front one) is steady on, and the others
are blinking.
Include date and git revision in the eeprom variable
... in order to be able to find out which firmware version is this MCU
running. This roughly corresponds to the commit 49420b56b31e113f4c40128c530f2e585a9f8061
of project Tinyboard.
Measure also longer-term running average of ambient light values,
and log instead of minima and maxima of adc readings the diffrence
between this longer-term average and normal avereage (ambient_val).
This is so that we would be able to switch the front light on when
entering a darkish area from the bright sun.
In order to mitigate the problem with watchdog reset, possibly caused
by timer IRQ handling taking too long, we only increment the jiffies
value in the WDT IRQ handler, and then read this value in the main
loop, compare with the previous one, and if those two are different,
we run the timer-induced operations. We can (probably) detect the
timer overrun (the difference in jiffies being greater than 1), and log
it.
The individual timer-induced operations are run in their own atomic
blocks for now, in order to be safe. The finer-grained locking is
in the TODO list :-).
- early HW setup, run once after reset, is moved to the first_boot()
function
- main loop iteration is in a separate function main_loop_iteration()
- both functions (and hw_suspend() as well) are made inline
Apparently, after WDT reset, WDT is still running, and has to be
disabled. Otherwise it will kick in again during the initialization.
We want to indicate the WDT reset contition somehow. We use the GPIO
LED 0 - we set it to on if the reset source was WDT.
Also, we want to read and reset MCUSR as early as possible. We do it
from main(), and we then send the saved value where needed (init_log()
and power_down()).
pwm.c: channels running - visible from the outside
Make the status of T/C1 visible from the outside, in order to
make the on-demand ADC channel selection possible, and also
to allow selecting the sleep modes in the main loop.
A common failure mode is that the magnet slips and does not provide
the signal, so it appears as if constantly braking. Avoid this situation
by allowing continuous braking of at most 16 seconds. After that, report
brake off, and wait for the real "brake off" signall from the Hall sensor.
In order to be able to tune the ambient light sensor better, I made
it to log the minimum and maximum values read for every three minutes
or so. When the log buffer fills, start over only after the next
off/on cycle.
With low-pass filters at the input of PWMLED ADC pins, it is now
relatively stable and noise-free, so we can lower the number of readings
to two. Hopefully this will not cause instability.
The fastest-repeated measurements are needed for PWM LEDs. OTOH,
things like buttons, battery voltage, ambient lights, etc. can be
read less frequently, and should be read in a deterministic time frame.
So we will measure PWMLED current in the free-running mode (as fast
as possible), and the other "slow" ADC inputs with each PATTERN_DIV-th
timer tick.
Run ADC synchronously with timer IRQ. This partially reverts
commit 210916486d18b3dc976c65c7b01b44bca446d856 in order to
prepare for selectively enabling and disabling ADC channels.
When there is a supposed ADC noise problem, it is handful to drop
several first readings, and even discharge the ADC capacitor
by reading the single-ended wire connected to zero. This commit
rewrites the ADC handling to allow exactly this, for each ADC input.
- status LEDs should not blink together
- PWM LEDs should start synchronized, in order to allow for compensation
of battery voltage variations when one output is on
compared to when more outputs are on
I have decided to implement a brake light, which I want to trigger using
Hall-effect sensor mounted in the brake lever. Unfortunately I still
have only three wires for two switches and a Hall-effect sensor, so I
would have to change the digital switch readings (on/off) to ADC
readings (voltages selected using voltage split on resistors).
Here is the schematics for the whole handlebar electronics, and the
symbol file and datasheet for the Honeywell SS341RT Hall-effect sensor.
- low-pass filters added to the ADC pins measuring LED current
- prog_ena jumper changed to disconnect pwm0 only, as this is what makes
problem during in-system programming
- labels for LED and battery connectors moved outside the footprint
- factored out from init_pwm() in order to be able to suspend PLL also
during normal operation
- use _delay_us(100) instead of _delay_ms(1) as recommended by datasheet
- disable PLL in susp_pwm()
firmware: control logic moved to a separate module
- buttons.c now controls status LEDs only when setting parameters
- pattern.c:
can use NULL instead of off_pattern
has number_pattern() than can also set up inverted patterns
contains only number and boot patterns as static variables
can reload all patterns if some state changes
- ambient.c resets all patterns when ambient zone changes
- control.c:
- now contains almost all pattern strings, only those needed by
other modules are exported
- status LED and illumination LED can be controlled by buttons.c
- separate _pattern_select() function for each LED
https://www.fi.muni.cz/~kas/git / bike-lights.git / log