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
rdComment: 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
