Dec.30 Stacksize

This post documents information from studying stacksizes, because the choice of the AVR thread stacksize (2048) was not clear.  
Summary:

used AVR stacksize =2048 is:
    min  < avr < typical 

  1120 < 2048 < 2400

So 2048 is probably ok.  
2048/size(int) = 2048/32 = 75 int variables would be allowed.
Since minimum is 1120, then 2048-1120=928 ==>  928/32= 29 automatic variables could be used by receiveThread function.  

.
Background: AVR control code was written in C. Updating it from C to C++, it  needed the most care due to its direct HW communication between the ARM and AVR.  There may still be improvements, but changes need to be made carefully to not break working code.
.
Studying the code during the code review update.
1. Why the stack size of 2048 was chosen?
Answer: Value used in sample code in eCos Book:: Embedded SW Dev  with eCos p.111 Code Listing 6.1: Thread Initialization Example 
.
2. Is it really the best stacksize for the avr communication thread?
Still unknown, but the min stacksize and typical stacksize suggested via the eCos include comments and other references are:
.
p.117 ecos reference explains the constants used for CYGNUM_HAL_STACK_SIZE_MINIMUM and CYGNUM_HAL_STACK_SIZE_TYPICAL stacksizes and were found in  hal_arch.h. The caclulated values are:

CYGNUM_HAL_STACK_FRAME_SIZE = (4 * 20) = 80
.

CYGNUM_HAL_STACK_INTERRUPT_SIZE=

((4 * 20) + 2 * CYGNUM_HAL_STACK_FRAME_SIZE) =

((4 * 20) + 2 * (4*20) = 240
.

CYGNUM_HAL_MAX_INTERRUPT_NESTING = 4

.

CYGNUM_HAL_STACK_SIZE_MINIMUM =

        (CYGNUM_HAL_MAX_INTERRUPT_NESTING * CYGNUM_HAL_STACK_INTERRUPT_SIZE 

         4     *     240

         + 2 * CYGNUM_HAL_STACK_FRAME_SIZE) + 2 * 80

         = 4* 240 + 2*80 = 1120

.

CYGNUM_HAL_STACK_SIZE_TYPICAL = (CYGNUM_HAL_STACK_SIZE_MINIMUM 

         + 16 * CYGNUM_HAL_STACK_FRAME_SIZE)

= 1120 +16*(4*20) =2400

.

Info from comments;

// ...Idle thread stack should be this big.

.

//    THESE ARE NOT INTENDED TO BE MICROMETRICALLY ACCURATE FIGURES.

//           THEY ARE HOWEVER ENOUGH TO START PROGRAMMING.

// YOU MUST MAKE YOUR STACKS LARGER IF YOU HAVE LARGE "AUTO" VARIABLES!

.

// This is not a config option because it should not be adjusted except

// under "enough rope" sort of disclaimers.

.
This leads to the Summary at the top of this post.

Dec.29 + Jan. 6.AVR Firmware version FB

For complete access to all information in the Battery word, a Function Block to access AVR firmware major and minor version has been created. It will not be automatically compiled by LMS cmake, but commented out by default.

Curious what versions of the AVR firmware version of various LMS will be. (will post test here)


Jan. 6 AVR firmware version # is all zeros.
Jan. 23 AVR FB abandoned because we do not need the information and it would never be used.

Dec.26 Battery FB start

Lego original Battery info documentation:
Battery info is part of the data recieved from the AVR as explained on  p.20 in  Lego Mindstorms NXT (TM)  Hardware Developers Kit 
Battery word contains the 

• voltage (mV) = bits 0-9 * 13.848
• not supporting float so multiply by 1024 * 13.848=  14180 then divide by 1024
• alternative: would be to just use relative power of 0-1023
• accu pack inserted bit (bool)  bit 15
• The accu pack has peg-like tab that pushes battery setting, when its inserted.
• avr firmware major.minor version (xx.yyy) bits 13-14 major; bits 10-12 minor
• AVR firmware version will be given its own FB if its ever needed.

Interesting lms Battery links:

Battery discussion in thenxtstep blog

Interesting study of NXT battery power levels:

Dec.26's Nov.29 Code Review update

General updates:

• in tests put constant first so never accidental assignment (if (0==x)... )
• use simple types (int, unsigned int, bool, etc) instead of forte or cyg types
• Changing cyg_bool to bool caused motors to stop working since cyg_bool=int
• static variables  in .cpp should be private member variables in h file
• when static variable address is passed to thread it must be in .cpp file 
• still looking for more eloquent way to do this
• if return will never be checked, then return changed to void
• delete extra comments with background information only

Not yet implemented:

• rename L_AD (analog digital sensor) to L_AI (analog sensor input)
• rename L_LED (sensor led output) to L_DO (digital sensor output)
• change from F_GT_UNIT to ../IEC61131-3/Functions/SelectionComparison/Comparison/F_GT 
• Using Forte-IDE 1.0 due bugs in dev IDE which cause types to disapper

Partly implemented:

• use { }s for all if and else causes, so to prevent possible errors from  debug prints 

Additional updates: 

• Changed motor max to 3 from 4 and padded the AVR buffer by 1.

Dec.20+ LMS Nov.29 Code Review status

This post is needed because LMS motors do not work with Nov.29 Code review changes.
Dec.24: Motor Problem cause: changing cyg_bool to bool, which is really int.
Specifically:
  cyg_bool is:   typedef  cyg_halbool            cyg_bool 
  cyg_halbool is:    # define cyg_halbool int
Code that translated cyg_bool=int from int to simple bool was deleted as unnecessary during code review. This broke the motor code.
Oct.28 LMS FBs fully tested
Nov.29 LMS code review Change Summary:
* more naming convention changes
* change from eCos ARM and Forte types to simple types like int where possible
* no return function value if it will never be checked
* one return. set a variable rather than return. This helps the optimizer
* AVR changes to be completed
Nov.30 LMS -O0 and current LMS too large
Dec. 1  prelim LMS with current FORTE tests and current FORTE IDE 
...but current Forte grew and caused forte.bin with -O0 to be too large for LMS and dev Forte IDE had problems

LMS after code review: 
* LED works

* TOUCH doesn't - needs F_GT - bug report written ... can regress to UINT_GT, but....

* BUTTON works

* MOTOR is not consistent... seems to need the power to be large enough to move, if too little power, might not turn at all.   motor  code changes were in AVR.

* LT sensor read needs F_GT to work, too.

* (OFF untested with new code, but assume works - no changes)

Dec. 2  Tested individual Nov.29 FBs with current Forte
* Changed to ../IEC61131-3/Functions/SelectionComparison/Comparison/F_GT from F_GT_UINT for LC_TOUCH
* Motor FB not working with lower power
Dec.14 Finished testing builds of various smaller eCos versions
Dec.20+ with current Forte, IDE 1.0 (and F_GT_UINT)
* -O2 with Oct.28  LMS code unchanged - full regression test works (sensors,motor (10%),buttons, off)
* -O2 with Nov.29 LMS code - Sensor FBs and Off work.  Motor FB does below 40% power and then slow.
* Currently adding the Nov.29 Code Review code to the working Oct.28 code a little at a time - All  FBs work with additions. Last is adding the CL_AVR_ctl changes, because there were so many adding in related changes and testing.

Dec.14 eCos Build+thumb

Around Dec.1 it was found the current forte.bin was now too large for the LMS.
The past way to make forte.bin smaller was to make eCos smaller by pruning features consided unnecessary. The LMS eCos build(s) came before me and this is my first eCos build.
    However it has never been built using Thumb instructions, which could almost half the size since Thumb instructions are 16 bits rather than 32 bits. But forte can't be compiled for thumb instructions if eCos isn't also configured for thumb instructions.
    My first own eCos configuration:  change to  -mthumb and -mthumb-interwork.  Then compile and test forte with these same options.
.
First thumb test LMS regression test results:
(LMS regession test: touch, light+led, motors, buttons)
1.works!  LMS forte (-O0) with IDE 1.0 
2. no!  LMS forte (-O2) with IDE 1.0 
** doesn't even register with device manager as an eCos device
.
eCos Build Process:
0. Follow instructions in ..\src\modules\lms\lms_ecos\readme_lms_ecos.txt
.
Using ecos centric configtool:
1. open repository
** 1st time:  Tool asks for eCos source file directory
** 2nd time: build --> repository.. --> enter eCos source file directory
2. open the .ecc file from forte hg
** file --> open  (select file with .ecc)
3. generate build tree
** build--> generate build tree
4. build lib
** build --> library
.
Via eCos Hal --> ARM architecture: checked Thumb options
.
Useful Links:
Config Tool: http://www.ecoscentric.com/devzone/configtool.shtml
Source: ftp://ecos.sourceware.org/pub/ecos/releases/ecos-3.0/ecos-3.0.cygwin.tar.bz2
or  ftp://mirrors.kernel.org/sources.redhat.com/ecos/releases/ecos-3.0/ecos-3.0.cygwin.tar.bz2

eCos Docs page: http://ecos.sourceware.org/docs.html

How to build: Configuring and Building eCos from Source