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.