Aug.22 eCos Interrupts and Motor

Lego FW (in c) and Lejos FW (in c+asm) both have a minimum O/S and set-up interrupts themselves. nxtOSEK uses Lejos drivers in c and interrupt calls in asm.

eCos provides interrupt support calls, so an interrupt call is done by the driver code, but eCos creates/releases and attaches/detaches interrupts.

References:

• eCos Reference pp.83-88 especially p.84
• eCos Book -Sec. 3.2.3 pp.64-78  example p.69
• in eCos code:  i2c_at91sam7sxxx.c (i2c driver) and platform_i2c.c (optional lego HW driver

Tacho Counting via Interrupts:
Ver.1: using Timer TC1: 

• Interrupt when the motor goes from low to high.
• Number of interrupts is part of the angle used

Ver. 2: Interrupt when
Topic 2: eCos configuration questions

• Changing System Timer from TC0 to PIT
• Thumb vs ARM commands -  
• Thumb cmds = smaller = more space  
• http://ecos.sourceware.org/docs-1.3.1/tutorials/arm/ecos-tutorial.11.html

Tests:

1. An interrupt occurs

2. Get Tacho count

Open Question:
Should both an option using TCxs and not using in them be available?
What needs to be faster Motor Tacho counting or Ultrasound sensor reading (US)?
Can a mixture be used if the # of sensors and motors is known?

Aug. 12 Motor Turn Tests

How the motor(s) react can help us understand what can be expected from Lego HW.
(Test environments:  Lego Mindstorms (MS) SW; eCos LMS)
(Later?: various Lejos pkgs; RobotC)


Tests:
When multiple motors are told to turn at the same time... 

• Is there a delay so motors really start 1 after the other? (eCos LMS; Lego MS SW)
• When motors are told turn a specific angle - how accurate is it? (Lego MS SW)
• How do motor run when told to use a specific power % 
• once
• repeatly

Power to the motors initialized via the eCos I2C driver works and sending % power works.
Also using Forte basic Motor FB.


For Tacho using Lego FW as a starting example. eCos requires some changes so can't be exactly same, but counting edge changes using TC1 counter for now on just 1 motor.

Tried various turning tests of all 3 motors at same time to see if they really turn at the same rate.


eCos LMS Forte FBs: 
All 3 motors set to same rate, power command sent multiple times
   - motors turn at same rate
All 3 motors set to same rate,  power command sent once
  - motors turn at different rates 
    Possibly motor given command first turns faster, but hard to tell, which one is faster.


Lego Mindstorms SW 1.0 (w/ updates) with Firmware 1.29
3 motors in parallel connection with brake 
 - turn at same rate
3 motors selected in Motor block
- Motor A turns slower; Changed connections - so it was certain.
- Using 360 degrees or 1 Rotation switching motors - Motor A stops short of 1 Rotation.

(To be added motor turning with Lejos)

Now have an idea what to expect.


Success is when counter changes. Until we change eCos setting to use PIT for something else, can't use for all 3 motors.

Acroymns Used in this Blog

• FB       = IEC61499 Function Block
• FW      = firmware
• LMS    = Lego Mindstorms (trademarks of Lego)
• SW     = Software

July 29 Clock Frequency

Lego open source firmware and Lejos both use 48 054 850 for 48Mhz instead of 48 000 000.

The SPI interface uses this value, so I started asking why the difference.

(too curious to just change)

Answer from the nxtasy hardware forum is it must be a multiple of the clock crystal.

The USB will not work if the value is too far off.

In AT91 datasheet p.26 states maximum limits for the crystal are listed for the USB  and debugging to work.

July 19 Started Display

Switched from motor to display while have little time this week

Just a collection of notes:
Started SPI interface to LCD display. There is more specific HW documentation making this easier than motors. However still have open questions at this point.

The SPI initialization for LCD seems straight-forward. (compiled)

Open questions:

Display size - Lego HW specs say 8lines by 100 pixels, but again in Lejos and Lego OS fw their is an option for 128 pixels. So need to test what we have.

Commands:  Where are all commands documented? Device specific?

5A - allow updates - documented.

5E - turn-off updates

other commands?

Questions related to lms eCos implementation:
(eCos implemention is from someone else, so learning code. )

Clock frequency for ARM7 is 48 MHz, which is exactly what is in the eCos include.

But comparing to both Lejos and Lego Open Source firmware includes, they use some slightly larger (48054850L). Need to find out why.

#ifdef includes should be chip related, but for arm7s256 some values needed seem to not be defined. Is this specific to our implementation or eCos?
Just adding what is need currently - but would like to know if left out originally on purpose or assumed not needed?

Background Info:
Serial_Peripheral_Interface_Bus great overview

July 13-14 avr clean-up +

avr code clean-up

Moving hardware related code out of avr_cntl and into their own class / source files.

So far: Buttons, Sensor (ports, led), Motor. The Sensors code will also need sub-class code. Generalized code will stay in Sensors.

Clearing out non-avr related code makes it much easier to see what the eCos thread is doing.  And what hardware is being set  or reset by what.

Buttons 

Besides moving existing button functions now

GetButtonVal function decodes the raw button value from avr.
(note: If speed becomes an issue an inline function or define macro can be used.)
 
Motor
- reset motor
- read tacho counts
options:

• interrupts
• motor thread
• polling in avr thead

Which solution works and  is most accurate= right solution?

**Don't  use timer to generate signal because ecos uses it. ..._TC0 and ..._TC2 
That leaves the TC1 and TWI timers.

Sensors

- Moved sensor  functions and port managment out of avr_cntl 
- Consolidated all Led code in under Sensors.Before the led code was duplicated in at least 3 places:  lms main, avr cntl and led FB.
All led code is now in Sensors.c.  Currently #define macros are used since code in now under eCos, but a class method version is commented out under Forte code.

July 12 Tests

VLOW problem (when battery charged): Isolated the problem to how JTAG plugged into LEGO, so be careful how JTAG plugged into LEGO.
 
Sound sensor 
- high values = low noise
- added Sound FB
- idea is can read sensors be generalized

Comment out parallel communication for sensors 
AT91_PMC_PCER_PIOA); // enable parallel io-controller clock
question: Is this motor only related and not needed in port initialization code
result: leds worked, but motor did not





 
PMC and clocks see p.189 AT91SAM7S 

>> here
motor tests
- reset motor - looking for right place and way to reset motors during start-up and when
- read tacho counts - are interrupts needed?
Looking at interrupt controllers, but may be able to use a eCos thread and polling - but how accurate will it be?.

sensor routine
clean-up - move sensor and port initialization into its own area.