June 11 LMS in 4DIAC-IDE

Time to recover the LMS FBs and applications from various work spaces.

FBs:

LMS:   OFF, LED, TOUCH, SOUND, M_BASIC

Utility: GT, AVG, HYSTERESIS 

Applications:  

See blog links for details

• Flip-Flop Blinky
• one system
• distributed so producer / consumer (LED)
• On-Off when over Light-Dark
• Line-Follower
• Segway
  

The 4DIAC-IDE directories/files used are obvious and were never documented anywhere...

template - contains the templates for IEC61449 FB types: 

  basic, composite, service interface, adaptor

  It comes with the IDE hg version.

typelibrary - import initial FBs here. (Can FBs be imported later?)

workspace file - where the system including its applications are.

FBDT\ runtime library with FBDT FBs

More details in local mowes wiki.

[Side note: New netbook has atom processor = slow compiles. 

Old laptop has OpenOCD etc working, BUT it turns itself off often (every 5-15min) to not trust doing real work on it.]

June 9 6PM exclude FBs=unknown device

E_SR on the exclude list is the reason.

Found out that due to something like reflection LMS forte device code needs E_SR, but it still compiles.


Compiles, links, fits in Lego, blinks, clicks like forte is running, BUT there is a catch...

Windows no longer sees the LMS as an eCos USB serial device,  

but as an unknown device under Universal Serial Bus controllers instead of under COM ports.

Note: Before flashing Windows sees the LMS under Ports(COM & LPT) as AT91 USB to Serial Converter (COMx) just like it should.

Windows did see the LMS as an eCos device before:

1. adding in the call to init the avr
2. before excluding anything

Test 1: Comment out the call to init the avr

Result: Windows doesn't see the LMS device at all. 

Scan for HW changes didn't find it either. LMS still blinks and clicks.

Test 2: Test with AVR and no excludes

Expected too big, but wasn't.  Sees the LMS device as an eCos device like it should.

So the exclude list or something in it, makes the LMS into an unknown device.
Really dum error:  duplicated text at the beginning of the Exclude FBS text in the cMake file.
BUT didn't hurt anything.

June Unoffical Open Requests for hg changes

This blog entry is a summary of open "unoffical" requests for forte hg changes, that should not be forgotten because they have a user / developer impact.

Unofficial, because 

• LMS is only partly in hg
• The requests only affect usability. Usability issues are low priority.

June 9

Request: So wstring and iso flags appear together in the Cmake gui,
it would be nice if FORTE_UNICODE_SUPPORT
was renamed to FORTE_USE_UNICODE_SUPPORT

June 7

The following hg updates would be helpful:

1. setup_lms.sh - change the default eCos path to LMSecosDir from """

Reason: If setup_lms.sh is accidently run without changing the path then system lib directory will be copied into bin/lms and must be deleted. Better error is just that the directory doesn't exist.

2.  .cproject with finish_lms make entry- Under the make menu finish_lms needs to added (setup_lms.sh as example). 
3. Add buildsupport/toolchain.txt to hg.
Reason: Have to copy it in each time from somewhere.

June 9 Space for AVR

Last step to complete lms_main is adding a call to init the avr interface.

This requires more lms code be included, which in turn made lms overflow the available memory.

To fit in the LMS:

#1. More in the Exclude FBs list: Added FBs  and forte types that were excluded with working lms forte ver.0.3

Except for WSTRING this was easy looking at the old makefile.am 

Arrays were also turned off.

**This alone saved enough space to fit in the Lego.

Observation:

In the working lms forte v.0.3  with autoconf, the makefiles used flags to turn off the major options it didn't need. BUT used a kind of include FBs list.

Currently forte v0.4 with cmake now uses an exclude FBs list.

#2. Alios added a cMake flag to turn off use of iso values and wstring as a new option for Strings
Request: So wstring and iso flags appear together in the Cmake gui,
it would be nice if FORTE_UNICODE_SUPPORT
was renamed to FORTE_USE_UNICODE_SUPPORT

**This (also) alone saved enough space to fit in the Lego.

Loader list change: forte_wstring and unicode_utils are now excluded.
Looking at the size of the object files (.o) for forte data types wstring is one of the largest.

Bottom Line: Went from using more than 15 sectors down to 14 sectors !

Next tests: Verify working with OpenOCD

Next steps: Finish enviroment installs of:

  * eCos driver

  * OpenOCD under Eclipse (needs Yagarto)

LMS CPP code left to add & test:  FBs

Current list of forte types and FBs excluded:

forte_sint forte_dint forte_udint forte_usint forte_dword forte_forte_word forte_byte  forte_struct 

E_D_FF E_R_TRIG E_MERGE E_DEMUX E_SPLIT E_SR

Yagarto documentation solved the "unused" libusb driver mystery.

• This driver is a generic driver for the JLink.
• Related there are cygwin issues with more recent JLink firmware versions, making using Yagarto, which is not cygwin dependent more interesting.
  

June 7 hg Blinky and environment

C++ cleaned up version is there, but initially didn't work so adding it to the hg code increments.

Non-workingTests:

with avr:  compiles, links, but flash gives memory overflow
Next: See if more FBs can be added to the exclude FB list.
Concern: Can exclude unneeded FBs but will need space for LMS FBs / application!

Working Tests:

1. hg compiles and see LMS as an eCos device

2. "blinky" : LED blinks,.but no avr communication

A. no LMS_DEV started

B. LMS_DEV started

status: needed a FB exclude list to be small enough to link with 15 sectors
3. with clean C++ code lms_main.cpp

Open question:

Why did the May 28 hg version only need 10 sectors and June hg needs 15 +sectors?
Still not clear what caused it not to blink before.

The following hg updates would be helpful:

1. setup_lms.sh - change the default eCos path to LMSecosDir from """

Reason: If setup_lms.sh is accidently run without changing the path then system lib directory will be copied into bin/lms and must be deleted. Better error is just that the directory doesn't exist.

2.  .cproject with finish_lms make entry- Under the make menu finish_lms needs to added (setup_lms.sh as example). 
3. Add buildsupport/toolchain.txt to hg.
Reason: Have to copy it in each time from somewhere.

(for thought)

4. finish_lms.sh and .openOCD cfg files may not really belong directly under forte directory, but should also not be lost (since they are in the hg) when a distclean (currently manual) is done by deleting bin/lms/src or as in the past deleting bin/lms. 

June 1 Blinky

The blog is being neglected in favor of:

• a local wiki for an organized how-to
• dropbox for sharing
• more concentration the diditacs

Main ideas, test results and status will still be published here.

My Netbook is back, but laptop died completely. Thankfully due to Dropbox no files have been lost. So setting up and redoing tests with current hg.

Made the mistake of agreeing to get my own id, when the original id owner came back. The copying of files means much of the  lab PC enviroment has to be reinstalled.

Current hg lms does not compile.  Minimum updates were passed on in early May, but not put in hg yet.

Feb.16 version still blinks nicely, but the same lms_main.c used with the current forte hg, does not. It is recognized as an eCos device by windows after being flashed.

It has been strongly suggested that making certain cMake variables smaller would fix this, but this quick pat answer can't true (even if it did get some to laugh).

Because:

• If the compiled source is too large then an .elf  file is not created
• All the forte files are smaller in the May version

Making all cMake parameters smaller to save space will be a help with applications:

Keeping them initially the same repeated the Feb. test case.

Feb.16 forte blinks with the following:

FORTE_CommunicationInterruptQueueSize  = 1

FORTE_EventChainEventListSize = 16

FORTE_EventChainExteranlEvenListSize = 5

FORTE_IPlayerRecvBufferSize = 256

FORTE_STRINGDICTINITIALMAXNROFSTRINGS = 120

FORTE_STRINGDICTINITIAL = 1000