Apr.22 Light Sensor Clean-up

Open 4/29 
clean-up: right place for led initialization + no unnecessary duplicate code
Options: 

• during eCos/Forte boot *(now led 1 only)
• avr initialization *(now turn all 4 off)
• led function block initialization *(now reinitialize)

led

Hiding the following in  inline functions and static const s

• led initialization, 
• port 4 initialization 
• led on/off -  now 0 is off and 1 is on. Inverted logic was used before.

rd

Testing:

read correctly from all light ports
Port 3 Funnines was caused by design funny:

• for led used 1 for index of first port into an array with HW pins to match standard port #s
• for rd light sensor used this index for port #, but it was +1

Design change: led to HW array to starts with 0 and use (PORT-1) now for led and rd

Comment: led and rd are in same sensor, but different Fn Blocks in FORTE

    SW-wise first thoughts are 1 Object so 1 function block

    but HW-experts prefer separate, since functions are different.

    Different fn blocks allow differences, but easier to understand if same

    Led was hard-coded to 1 port and then later generalized - (how this really happened)

(debugging port 3 funnies described in  Apr.8- 16+ Checking out LMS HW from FORTE)

1020+ indicated nothing is plugged into a port

initialization - Both Lego & Lejos initialize all leds to off


By default  when lms is turned on leds 1-3 is on and led 4 is off.
Changed so RS485 port is initialized and all 4 leds are turned off during avr state e_INITIALIZED:
* This still may not yet be the best place /cleanest code solution. In default mode leds 1-3 had to be in the applications to turn them off even if they were not used. Extra unnecessary FBs to initialized changed the logical INIT event flow and cluttered how the application looked (was annoying and now fixed).

4/26
Trace notes:
 rd.cpp FORTE_rd::executeEvent (REQ)
             ltVal= GetSensorState(PORT);
avr_ctl.c GetSensorState(cyg_uint32 pa_nInputPort)
watch variable:  io_from_avr->adc_value