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)

Sept.11-12 Lego Arm application working

Following application does a simple test of the Lego arm

• turning left / right
• up/down  (drifts down - because of weight of motor(?))s
• open/ close

Sept.9 Application Time - Robot Arm

Chose 3 robots, which use few parts, to build and use with test applications,
First Lego arm to test motor FB in applications and for something new and 
because the other 2, (a CarBot, NXTway) use motors.


New motor FB since easiest to change directions in an application via a boolean:

Test 1: Test each motor going back and forth.  Same test was used for all 3 motors.
First simple alternating test with Flip-Flop

Test 2:  Used 2 Touch sensors - 1 turned motor on and 1 reversed the motor direction (both had to be pressed at same time)

Test 3:  Should allow testing of all 3 motors in 1 test.


Lego Arm test reflections / results:
1. Discovered easiest to change motor direction with BOOL input variable, 
so new Motor FB. 
Open: How to switch between on/0/off = tri-state
This is a general problem. Ref: http://www.societyofrobots.com/member_tutorials/node/161

2. Then a good test for changing directions  is using a flip-flop.
Created a F_FLIP FB that is a flip-flop built with 2 delays and 1 SR. 

This design was chosen because it uses 2 rather than 3 types, since each 

downloaded FB type takes more or the limited space.


Using F_FLIP FB there are timing issues. Usually goes back and forth, but sometimes misses one and goes twice in the same direction. Solution is probably to use E_CYCLE even if it an extra FB Type has to be downloaded.


3. Physical results:

• Open/Close - 
• hit on bottom of the other claw
• needs short times and little power
• Up/Down 
• Down is noticably faster than Up due heavy motor on the end of the arm
• Flop-flop with 2 equal delay times allows it to wander down fast.
• Can hit on motor if goes to far over
• Left / Right - works as expected

Sept.8+ Optimizing for size

Using -Os to compile LMS drops the size from 24k to 17k.
But even boot blinky doesn't work...... more to come.

Sept.6 Testing Composite FBs

Composites are working: LC_AD, LC_TOUCH, LC_LED, LC_LT, LC_SOUND
eCos and Forte keep getting smaller.
More interesting was using 1 application, but various combinations of FBs. 
For example testing FBs in the composite network before testing the composite FB.
Another example shown below is the application that was used to test both LC_LT and LC_SOUND. Since both sensors are on port 1, both sensors cannot be mapped to the device during the same test.

Sept. 5 Smaller Forte and ecos

New smaller Forte and eCos packages, so back to 1 version to test.  0904cyg 
Can finish testing all new LMS FBs now...  (current size: edef4)


Test Cases

• Compiles, Links, Boot Blinky: -works
• 4 LED app -works
• FlipFlop app 1 -works
• FlipFlop app Cycle -works
• Touch LED on app  - LC_TOUCH not working
• Reads app - also not working.... backing off to test the FBs that make up the composites
• Motor on app  -works
• 3 Motors on app - uses TOUCH sensor to turn on

Sept. 4 LMS FB clean-up tests

Forte has grown as it has stabilized, not leaving much room in 256K for lms FBs 
LMS FBs C++ /  4diac 0.4 are cleaned up; Now using Composite FBs (see previous post)

Testing one after the other 3 base versions : 

• 0904cyg; With current forte with LMS NXT modification compiled into ecos package 
• BASE is TOO LARGE now. Only L_LED fits
• 0904:   With current forte (1.0)    
• The base forte has grown!
• 727z:      With 0727 forte
• all LMS HW functioned prior to using composite FBs

Tests: black works, grey not yet tested, orange fixing
 note: have to change apps to use most current FBs wtith sensor type.

• all compiles and link
• 727z, 0904, 0904cyg
• Boot Blinky:
• 727z, 0904, 0904cyg
• 4 LED app: (deploy works)
• 727z, 0904, 0904cyg

arm-elf-size forte.elf  size Info

1. with LMS NXT modification compiled into ecos package 

Linked fine,but its too large now, think it should be same size since it should have just changed locations, but

with all LMS FBs  size is 42d9c > 4000  = 256K (max) 

Only small enough with just LED FB : 3fd34

Both Boot Blinky and deploy of an application work.

[Could this be the large eCos version that caused similar space problems in Feb.?]

2. With current forte (1.0) = 0904 forte

when I changed to the most recent forte and it has grown!!!

3f8e8 !!!!  Max is 40000x =256K

3a214 is smallest with only the old Boot Blinky code and no AVR initialization

changing the queue parameters makes no difference to the size 

What caused it to grow so much? Anything else that can be left out?

3. With 0727 forte

0727 forte 3f69c with all LMS FBs in previous post.

Minor side notes:

1. Did some optimization and found the local variables sometimes make it smaller, but in the case of L_LED it was smaller using local variables.

2. Finishing up the lms code I tried to move all the port related code in the FB L_S_PORT, but had problems moving the static constant arrays that were initialized and private methods into the exported code. Not a priority, but if you understand this cryptic description and have hint I will try again... otherwise I will leave the code in a separate class.  

Aug. 30 New LMS Composite FBs design

Below is the new LMS composite FBs design