Mar.29-31Learning building, design and events

For Tutorial 2:  Building the Car Wash

Using parts of a LEGO forklift construction to learn how to make something that goes up and down with LEGOs. Mainly learned how to make a track and how far up & down a track works without tilting to 1 side or the other. Next is learning the ultrasound sensor.

Graphical OO SW design  mapped to real objects:

Still working on using just 1 light sensor for line follower in 4diac. How to use just 1 light sensor FB mapped to the actual 1 light sensor to read the light sensor to 4 steps:

• calibrate on the line color
• calibrate off the line color
• follow the line
• find line. 

then "repeat" for a follow the line application with 3 light sensors. 

Want a clean design - currently still looks like spaghetti.
Current direction: Use E_DEMUX to direct  the read output to the current step.

Whether it can be implemented similar to the behavior programming design used/described in Lejos documentation - is currently still an open question.

Port mapping, so an application can't say there are 2 sensors on the same sensor port.  That should be handled during INITs.

Created an Events palette overview to understand what events are available to use.  Everyone starting out seems to ask the same/similar questions.

But what is the basic FB E_LDU (Event-driven Workpiece Load/Unload Model)? It has    2 algorithms, but no ecc? 

Mar.26& Apr.2 Blinky with LtSensor.led etc

Using LEGO HW:
1. Create and export FB types via normal way:

• 4diac-ide Types
• export to Forte using 0.4 export filter
• edit C++ code for SI FBs 

2.  openocd-FLASH.bat
3.  openocd.bat
     know finished when:

• the LMS boot blinking finished 
• the PC sounds indicate new HW connected

4.  run from eclipse java
5.  4diac-ide deployment (check and download)
     (not launch!)


Tested and working with:

• Alex's blinky unchanged
• Alex's blinky with shorter delay times
• In Alex's System: New Application: Test1LedOff with 1 LMS_LED (discovered 1=turn off) 
• In LegoHW:  OffLed changed new LtSensor.led FB so 0=turn off

Next:

• In LegoHW: in LtSensor.led FB use input PORT # 
• Note: #define macros are used to shorten for hw access. The macros refer to lower level macros. The highest level macro used had port# in its name, so used #define macro 1 level down where the port # appears as a number.

Currently getting:

end Mar.26 
Error: Vref too low. Check Target Power

Even after trying: 

• a different fully charged battery pack  
• leaving charger plugged in 

but after continued tries, it appeared to be get further before failing - so will try again after plugged in a while.

Apr.2 works: 
Suspect problem was the PC was confused if LMS is USB or something else.
Next time problem occurs need to try openocd-flash.bat after each of the following:
(not sure which one cleared the problem):

• Plugged in a USB memory stick and disconnected it.
• Unplugged/plugged in the LMS USB cable and went to control panel to install new HW. When clicked on it - said this id is not autorized.
• Tried openocd-flash.bat and it worked.

The broken pipe problem occurred when Alex was showing me what to do. He also had to try various things to get it to work again. Did we plug in an USB stick at some point to save something? Maybe.

Important Design Problem: Use 1 instantiation when only 1 physical object or when reading or writing you have to be aware of state changes.

Seems obvious, but easy to use  more when "hidden" in a Composite FB
Ex: an application that uses composite FB - for example lineboundary or calibrate before line1 (very simple line follower).

Mar.23-26 Notes from Alex on eCos/LegoHW set-up

note: lms= Lego Mindstorms

when openocd_flash doesn't work.

   under programs Atmel /Sam-ba flash

In C++ Eclipse:
·       setup_lms  creates the makefiles
·       all (see  makefile.am for list of files ) (just normal make all)
        ·       compiles and links to ecos
        ·       the output file is forte. (no ext)

From Desktop:

openocd_flash.bat

·        first creates the forte.bin
·        It outputs size of forte.bin
·        It flashes forte.bin to lms via jtag. (with the available FBs)
 
After flashing, the program does not run, it’s halted.
openocd.bat resets the lms and starts running.

In java Eclipse - run

open 4diac-ide deployment: 
·       check system with application
·       download (FB instantiations that make up the application)
·       application should run


Optional debugging with  gdb
·       start arm-elf-insight from cygwin
in gdb

·       Open forte using default
·       connect via Ethernet – localhost/3333

(where? details notes lost)
        ·        monitor reset
        ·        monitor halt
        ·       (usually did a 2nd reset?)
        ·       see GDB table for more commands
        ·       can only use 1 breakpoint at a time

        ·       openocd.bat (should already be running)

First Tasks:
Check Sensor HW outputs like:
GetButtonState() - buttons are 1,2,4,8 but which button is which
SetOutputPower(…) - from motor
etc.


Cmds from cygwin history:
cd events/
svn commit -m"solved issue in E_RS"

cd /cygdrive/c
whoami
login
 cd /cygdrive_ecos
cd /cygdrive/c
 cd sourceware_ecos
 cd 3/lego/blink_hal

make
make clean
svn
 arm-elf-insight
 arm-elf-size blink_hal
 cd ../d/AA_local/eclipseWork/forte_lms_neu/src/fblib/

Mar.23 Calibrate as Composite FB + FindLine

Calibrate as a composite FB 

(currently exported code has casting problem)

LineBoundary - returns the average boundary between line and off-line light sensor values.

   It uses CALIBRATE1 composite FB

FindLine Application: sweeps left and right looking for line (10 degrees) 

   Currently keeps looking even if never finds line.

Mar.19 LegoHW types and apps

Lego HW types (1st try):

Line1 application: overly simple line follower - if black both motors forward, otherwise just 1 motor. Will only work in 1 direction.

 

Calibrate application: calculates the on-line (Black) and off-line (usually White) boundary.

Mar. 18 LEGO HW and simulator

Light sensor on multiple targets:
HW:
LS in 4DIAC as (SIFB)  export

• for LEGO HW: add HW calls to C++
• for java simulation - use FBDK as described previously in blog
• hide the subscribe (for motor publish) in composite block, then use FBDK for java
• XML trick so stays SIFB in 4DIAC but is composite block for simulation:
• add   use other composite block XML as example

Generalize Sensor Port : in C++

static const state TUINT32[5] = {0,23,28,29,30};



Then current need for JTAG can limit school examples, but simulation may help and show/teach how IEC61499 can be flexible.


Need to ask about trial runs so they actually happen so:

Trial Runs of the IEC61499 Tutorial: 

April 30 - Sprengergasse HTL : Line Follower Tutorial

Wien TGM HTL - in May(?) - some students come to TU ACIN lab Thursdays

?St.Pölten HTL - (update 17Mar.) contact is no longer director. Hopefully he will still answer.

?HTLs of TU Lehramt Informatik Profs (Gangster, )
?in Houston area

Mar.17 JTAG debugging and optimized eCos+forte

(raw) Notizen Erklärung von Alex (to be organized / cleaned-up)


D:/AA_local/Dominik/pfade .txt = beschriebt was ist wo

Configuration downloaded in 4DIAC

Flashes = download O/s=eCos+FORTE+appl in 61499


Bei make all broken pipe – retry

If still doesn’t work in cygwin … see brokenpipe.jpg


Lms= lego mindstorms

lmsmain


Part of Gnuarm toolchain:

Start in cygwin:

arm-elf-insight used for debugging  connects über port 3333

see copied sheet and gdb-intro.pdf

monitor reset

monitor halt

monitor reset

delete – to clear breakpts


winmerge tool

lego_nxt_hw_dev_kit p.27 sensor diagrams