Anonymous

User talk:Daveb: Difference between revisions

From London Hackspace Wiki
m
m (→‎firmware design: new section)
Line 134: Line 134:


  Plans for cooling of LEDs are still vaugue.
  Plans for cooling of LEDs are still vaugue.
== firmware design ==
isr(int0)
{
freq++ ;
}
isr(counter_2_overflow)
{
// copy current freq to main line, reset freq.
}
isr(adc_complete)
{
copy adc value to mainline;
}
isr(counter1_...)
{
// implement the lighting policy
?flip the current MOSFETs bit..
?change the current MOSFET
?change the counter target
}
main()
{
setup() ; // set the ports, direction etc.
for(;;)
{
if (newFreq)
  {
    {
    DISABLE_ISR ;
    copy new freq ;
    }
  if new freq != old freq
      adjust policy;
  }
if (newLumons)
  {
    {
    DISABLE_ISR;
    copy new lumons;
    }
  if new lumons != old lumons
      adjust policy ;
  }
}
policy ideas.
1) if it is dark provide light ASAP.
2) if it be comes light, wait for a bit to confim it stays light, and thn start flashing the lights to provide visiblity
3) as the speed increases, spend more time with tight focussed lights illuminated
4) as the speed decreases, spend more time with flood lights illuminated.
5) match the power available to the power cunsumed by the LED strings
policy mechanism
four intervals of variable length, for variable strings
off, string-a on, off, string-b on
defined as char counter[4], value[4];
will allow the fading from spots to floods gradually:).
will allow the spots to be flashed at 10% duty cycle at a low speed during the day, intermingled with a 20% flash from the lower power medium floods...
policy config.
night vs day lumonosity value.
samples of day light required for flashing to start.
freq exponential smoothing factor (power of 2)
night freq bounds[4] between {floods | mix | medium | mix | spots}
day freq bounds[4]
153

edits