harmonic analysis report - power quality specialists | harmonic

Slide: 1 Copyright © 2012 AdaCore

José F. Ruiz

FOSDEM 2012, Brussels

Senior Software Engineer

AdaCore

Programming LEGO MINDSTORMS robots in Ada

4 February 2012


Outline

• The hardware

– Platform

• The software

– Compiler

– Drivers

– Controller

• The concurrency model

• The show


• The brain (NXT brick)

– 32-bit ARM7 main processor

– 48 MHz

– 64 KB RAM

– 256 KB Flash

– 8-bit AVR co-processor

– 4 Input ports (sensors)

– 3 Output ports (actuators)

– USB 2.0

– Bluetooth

– LCD (100 x 64 pixel)

• Sensors

– Rotation

– Ultrasonic sensor

– Gyroscope

• Actuators

– Motors

Hardware platform


And everything together


The compiler

• GNAT GPL for LEGO MINDSTORMS NXT – Ravenscar Edition

– GPL port for the GNAT compilation system

– Support for the Ravenscar profile

– Ada tasking

– Support for Ada 2005 and a preview of Ada 2012

– Support for SPARK and RavenSPARK

– Ada high-level drivers for the NXT brick, sensors and motors

– Getting Started material and examples

• Some universities already using it for teaching

Segway from Telecom Paris Wired controlled vehicle from DIT/UPM


How to use the hardware

• Drivers written in Ada

– Based on the LeJOS Project (Java Virtual Machine)

• NXT firmware removed

• Binary image of Ada application executed in RAM

– Through USB


Getting started with the software

• Write everything in Ada

• Many small examples

– Bluetooth

– Motors

– Sounds

• Remote controller car

• Concurrent archetypes

• Robot soon!


How to balance the robot

• The principle: drive the wheels in the direction that the robot is falling

– Keep wheels under the robot's center of gravity

• Use feedback control

– Get

– Position of the wheels (motor angle)

– Body pitch angular velocity (gyroscope)

– Distance to obstacle

– Compute

– Motor power

Segway

Robot

Sensors

NXT

Processor Motors


C Controller

Freq = 250 Hz Prio = High

Software architecture

C Comm with AVR

Freq = 1 KHz Prio = Highest

C Check stop

Freq = 1 Hz Prio = Low

S Remote (BT)

Freq = Polling Prio = Lowest

•Send required power to the motor

•Get wheel position

•Get pressed buttons

•Read sensors

•Compute commands

•Ask for required motor power

•Check stop request

•Keep and check communication

•Get remote commands

•Move forward

•Turn (left/right)


• The system is obviously unstable

– If you do nothing it falls

• Use PID controller

– There is a reference example

coming from MathWorks

• From Matlab to Ada code

– Gene-Auto code generator

• Task architecture by hand

– Task archetypes and

synchronization

Controller design


What kind of support for concurrency

• Ravenscar tasking

– A subset of Ada tasking

• Everything done by the Ada run time

– No OS underneath


Why Ravenscar

• Use concurrency in embedded real-time systems

– Verifiable

– Simple

– Implemented reliably and efficiently

• Scheduling theory for accurate analysis of real-time behavior

– Preemptive fixed priority scheduling

– Rate Monotonic Analysis (RMA)

– Response Time Analysis (RTA)

– Priority Ceiling Protocol (PCP)

– Avoids unbounded priority inversion and deadlocks

• Tool support

– RMA and RTA

– Static simulation of concurrent real-time programs


What is the Ravenscar profile

• A subset of the Ada tasking model

• Defined to meet safety-critical real-time requirements

– Determinism

– Schedulability analysis

– Memory-boundedness

– Execution efficiency and small footprint

– Suitability for certification

• State-of-the-art concurrency constructs

– Adequate for most types of real-time software


Static model

• Set of tasks / protected objects / interrupts

– Fixed and with static properties

• Tasks, protected objects only at library level

– No dynamic allocation of tasks or protected objects

• Each task is infinite loop

– single “triggering” action (delay or event)

• Fixed priority

– Simple static analysis

– Schedulability analysis

• Tasks cannot be aborted

– No changes to the set of tasks

– Reduces size and complexity of the run time system

• Deterministic memory usage

– Tasks descriptors and stacks are statically created at compile time

– No implicit use of dynamic memory


Simple synchronization and communication model

• No rendezvous

• Synchronize using protected objects and suspension objects

– Bounded priority inversion

– Efficient locking/unlocking by increasing/decreasing priority

– Deterministic


Deterministic execution model (I)

• At most one entry per protected object

– Avoids two or more barriers becoming open simultaneously

– Non-determinism of selecting which entry should be serviced first

• At most one task can be suspended waiting on a closed entry barrier for

each protected object

– Avoids the possibility of queues of tasks on an entry

– Non-determinism depending on the length of the waiting time in the queue

• Simple barriers

– The Boolean variable must be declared immediately within the protected object

– Deterministic execution time

– Absence of side effects for the evaluation of entry barriers

• No requeue

– Deterministic task release from protected entry barriers


Deterministic execution model (II)

• Task cannot be stopped from the outside

– Time deterministic

• Deterministic time handling

– delay until is deterministic and should be used for accurate release of time-triggered

tasks

– Use high precision timing

• Task creation and activation is very simple and deterministic

– Tasks created at initialization, then activated and executed according to their priority


• A single processor

• A fixed number of tasks

• Task interaction using shared data

– Mutual exclusive access

• Remove constructions difficult to analyse

– No asynchronous control, no abort,

...

• Scheduling policy

– Preemptive fixed-priorities

• Locking policy

– Ceiling priority for bounding priority

inversion

• Single invocation event per task

– Time-triggered or event-triggered

The Ravenscar tasking model

Most violations detected at compile time


Tasks

• Fixed set of tasks

– Only at library level

– No dynamic allocation

– No nested declaration of tasks

– Statically created

– Task descriptors, stacks, …

• Each task is infinite loop

– Single “triggering” action (delay or event)

• Task creation and activation is very simple and deterministic

– All tasks are created at initialization

– Then all activated and executed according to their priority


How tasks look like in Ravenscar

task body Cyclic is

Period : constant Time_Span := Milliseconds (10);

Activation : Time := Clock;

begin

loop

delay until Activation;

-- Do something

Something;

-- Compute next activation time

Activation := Activation + Period;

end loop;

end Cyclic;

Time-triggered task

task body Sporadic is

begin

loop

Monitor.Wait_Event; -- Protected entry

-- Do something

Something;

end loop;

end Sporadic;

Event-triggered task


Protected objects and interrupt handling

• Simple protected operations

– No queuing

– Ceiling locking on monoprocessor

– Bounded priority inversion

– Efficient locking/unlocking by increasing/decreasing priority

– “Proxy model” for protected entries

– Avoid unneeded context switches

• Interrupt handling

– Simple and efficient

– Protected procedures as low level interrupt handlers

– Masking hardware interrupts according to active priority


Synchronization in Ravenscar

Pr Buffer

Put

C Producer

S Consumer

Get

task body Consumer is

Element : Item;

begin

loop

Buffer.Get (Element);

Consume (Element);

end loop;

end Consumer;

task body Producer is

Period : constant Time_Span := Milliseconds (10);

Activation : Time := Clock;

Element : Item;

begin

loop

delay until Activation;

Element := Produce_It;

Buffer.Put (Element);

Activation := Activation + Period;

end loop;

end Producer;

protected Buffer is

procedure Put (Element : Item);

entry Get (Element : out Item);

private

Container : Item;

Received : Boolean := False;

end Buffer;

protected body Buffer is

procedure Put (Element : Item) is

begin

Container := Element;

Received := True;

end Put;

entry Get (Element : out Item)

when Received is

begin

Element := Container;

Received := False;

end Get;

end Buffer;


Interrupt support in Ravenscar

Pr Monitor

Handler

S Interrupt_Task

Wait

External Interrupt

task body Interrupt_Task is

begin

loop

Monitor.Wait;

Handle_Interrupt;

end loop;

end Interrupt_Task;

protected Monitor is

pragma Priority (Interrupt_Priority’Last);

procedure Handler;

pragma Attach_Handler (Handler, Interrupt_ID);

entry Wait;

private

Signaled : Boolean := False;

end Monitor;

protected body Monitor is

procedure Handler is

begin

Signaled := True;

end Put;

entry Wait when Signaled is

begin

Signaled := False;

end Wait;

end Monitor;


• Use a safe Ada subset

• Complete run time

– Layered architecture

– Including multitasking core

– No underlying kernel or operating system

• Isolate target dependencies

– Allow easy retargeting

• Configuration support

– Hardware and run-time parameters

Ada run time

Ravenscar Ada Application

Restricted GNARL

(GNU Ada Run-time Library)

Restricted GNULL

(GNU Low-Level Library)

Multitasking core

Hardware (NXT ARM7)

BSP

drivers


Multitasking core

ARM 7

Restricted GNARL

Restricted GNULL

Multitasking Core

Task

manage-

ment

Synchro-

nisation Time

Ada

interrupt

support


Ravenscar Small FootPrint

• Ravenscar Ada tasking

– Superset of the Zero FootPrint run time

– No other sequential Ada feature added

• Simple

– Footprint for simple tasking program is 10KB

• Static tasking model

– Tasks descriptors and stacks are statically created at compile time

– Task creation and activation is very simple

– All tasks are created at initialization

– Then all activated and executed according to their priority

• Simple protected operations

– No queuing

– Locking/unlocking by increasing/decreasing priority

• Complex features removed

– Such as exception handling and propagation


• Linux kernel 2.6.28

– 10 millions lines of code

– Average cyclomatic complexity: 6

Some metrics

Ravenscar Small FootPrint

• Line metrics summed over 90 units

• code lines : 4186

• Element metrics summed over 90 units

• all statements : 737

• all declarations : 2036

• logical SLOC : 2773

• 134 public types in 30 units including

• 16 private types

• 166 type declarations in 38 units

• 246 public subprograms in 41 units

• 181 subprogram bodies in 32 units

• Average cyclomatic complexity: 1.98


Conclusion

• LEGO Mindstorm NXT

– A low-cost, education-oriented platform for embedded systems

– All required support for Ada

– And in Ada

• Ada 2005 Ravenscar Profile allows for safe tasking

– High-level abstractions

– Deterministic

– Time analyzable

• It can be implemented with a compact and efficient run-time system

– Simple

– Portable

– Mostly written in Ada

• Future

– Keep working on automatic code generation from models

– Work on better debugging

– Load applications in Flash

harmonic analysis report - power quality specialists | harmonic

Documents