Oct.15 Regression tests

Finally buttons and avr code clean-up is hopefully finished.

Alot of the testing was to be sure nothing broke due to clean-up.

Regression Test 1: Test as many LMS FBs as possible

• Touch turns on LED 2
• Enter turns on Motor and an LED 1
• If LED1 measures enough light then LED3 comes on. 
• If turn LED2 and point at LED1, then LED3 comes on.
• Or if room very light try putting finger over LED1 and LED 3 should go off
• Very sensitive to room's lighting and might flicker if room light close to light boundary
• Left +Enter turns off

Regression Test 2: Test all buttons

• Change numbers to test button combinations

Regression Test 3: Test Port errors are handled correctly

• Order of the inits is important so the errors / LEDs expects turn on or are ignored

Sept.29 Clean-up and Motor ports

Code clean-up time. 

AVR Control class still needs some more clean-up, but otherwise FBs are used now.

1. CL_Button and CL_SensorPortMgr are now in  associated FBs and tested. 

Our good friend blinky is deleted.

Means you have to guess when you can start the eth_serial communication, but even with blinky it was possible to start it too soon.

Using the include define flag didn't work because of the order of compiling.

But handcoding one so if no Button FB , buttons are not polled, which make Button FB not always required 

saves 2536  bytes.  We have enough space at moment, but that's alot isn't?

*2. Should all FBs that don't do port checking (L_LED, L_TOUCH, L_SOUND) be:

- deleted

- go in different pallette

- be kept and go in the same pallette

???

They are slightly smaller since not composite FBs, but would not be considered safe. 

3. Can LMS device wide constants go in LMS_DEV? 

 like max motors and max sensors?  in multiple places at the moment and shouldn't be.

supported sensor list?

After avr ctl is cleaned up, do its methods really belong in the LMS device?

Its not a sub-device, its part of the LMS device.

4. Comments and clean-up 

tabs - have to set for every type editor!!! Hope I got them all.

Made more things private in various classes

Either deleted extra comments or added a TODO or TOFIX to explain why didnt want to lose the info.

Added a few more checks for the motor including extra FBs for port checking

LC_M_PWR with port checking and  L_M_PORT FB 

Sept.27 All (updated) LMS FBs

Here are all the tested LMS FBs with updates:

Sept.27 Button FB and Motor FB updates

Button FB
LMS has little space so to save string space, event names are repeated 
BUT for the button I can never remember which is a "match" a button and "button changed", so changed to: 

• MATCH/CNF - button, b, pressed matches button pressed
• CHG/IND - button pressed changed (including no button to some button pressed)

Full Tests:

Use a e_cycle every 300ms to check the buttons

Test 1 (works, but..): 

Press button and associated led comes on

Test 2 (works, but..)

- Additonally when Enter pressed, then led comes on and motor moves.

- BUT sometimes when Enter released, led and motor stay on

- 9/29 Buttons are sampled at slower rate than thought so debounce time /counter was too long(1.5sec)/ large (25).   Changed so now works.

Motor FB

• Should a STOP event be added or is it ok to use INIT event to stop a motor?
• Removed BR, brake/coast, flag for L_M_PWR FB.
• Currently the motor is turned on and left on until stopped via INIT event or PWR =0.
• Braking when the motor power > 0, could be damaging to the motors.
• BR flag could be used in a future FB that moves a specific angle

Sept.26 Button FB works

Button FB works
Simple test:

Sept.15 -O2 and Button FB v1

(RIE 2011 is also today)


-O2 tests:

• smaller than -O3
• known as eCos device
• application deployment appears ok
• Simple app that just turns LED on works.

Button FB v1

INIT /INITO initialzed variables.
REQ/CNF 

• Q=true if the button # is equal to the button pushed
• RD - raw value
• BO - button #

IND/RSP will send true if button changed.


Button #s:

• 0 nothing 
• 1 ENTER 
• 2 RIGHT
• 4 LEFT 
• 8 ESC 

Time to test (and conference dinner)

Sept.14 -O3 optimization

-Os result - doesn't work

not recognized as an eCos device

-O3 results

• no  - boot blinky - 
• What does the boot blinky not working affect?
• yes -known as ecos device
• yes -deployment / running lego arm test application correctly
• the up/down works better... it doesn't drift down!!!
• 158592 (size)

(next task: Button FB)