📄 tep131.txt
字号:
async command void reset();
...
interface HplAtm128Capture<size_type>
{
async command size_type get();
async command void set(size_type t);
async event void captured(size_type t);
async command void reset();
In addition to the timer related interfaces two control interfaces are
provided: 'HplAtm128TimerCtrl16' and 'HplAtm128TimerCtrl8' (below).
::
#include <Atm128Timer.h>
interface HplAtm128TimerCtrl8
{
/// Timer control register: Direct access
async command Atm128TimerControl_t getControl();
async command void setControl( Atm128TimerControl_t control );
/// Interrupt mask register: Direct access
async command Atm128_TIMSK_t getInterruptMask();
async command void setInterruptMask( Atm128_TIMSK_t mask);
/// Interrupt flag register: Direct access
async command Atm128_TIFR_t getInterruptFlag();
async command void setInterruptFlag( Atm128_TIFR_t flags );
}
Each of the hardware timers are exported in one component for example
'HplAtm128Timer1P':
::
#include <Atm128Timer.h>
module HplAtm128Timer1P
{
provides {
// 16-bit Timers
interface HplAtm128Timer<uint16_t> as Timer;
interface HplAtm128TimerCtrl16 as TimerCtrl;
interface HplAtm128Capture<uint16_t> as Capture;
interface HplAtm128Compare<uint16_t> as CompareA;
interface HplAtm128Compare<uint16_t> as CompareB;
interface HplAtm128Compare<uint16_t> as CompareC;
}
uses interface HplAtm128TimerCtrl8 as Timer0Ctrl;
}
implementation
{
//=== Read the current timer value. ===================================
async command uint16_t Timer.get() { return TCNT1; }
//=== Set/clear the current timer value. ==============================
async command void Timer.set(uint16_t t) { TCNT1 = t; }
...
5.4.4 Example: MSP430
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The MSP430 features two very similar (but not identical) timers. Both
timers are provided through the same interfaces in a way similar to
ATMega128l: 'Msp430Timer', 'Msp430Capture' 'Msp430Compare',
'Msp430TimerControl'. All timer interfaces (for both timers) are
accessed through the component Msp430TimerC.
The ``Msp430TimerControl`` is show below. It is slightly different
than the ATMega equivalent - notice that 'setControl' accepts a struct
with configuration parameters instead of setting these with a command
each.
::
#include "Msp430Timer.h"
interface Msp430TimerControl
{
async command msp430_compare_control_t getControl();
async command bool isInterruptPending();
async command void clearPendingInterrupt();
async command void setControl(msp430_compare_control_t control );
async command void setControlAsCompare();
async command void setControlAsCapture(uint8_t cm);
async command void enableEvents();
async command void disableEvents();
async command bool areEventsEnabled();
}
Each timer is implemented through the generic component 'Msp430TimerP'
that is instantiated for each timer in 'Msp430TimerC':
::
configuration Msp430TimerC
{
provides interface Msp430Timer as TimerA;
provides interface Msp430TimerControl as ControlA0;
provides interface Msp430TimerControl as ControlA1;
provides interface Msp430TimerControl as ControlA2;
provides interface Msp430Compare as CompareA0;
provides interface Msp430Compare as CompareA1;
provides interface Msp430Compare as CompareA2;
provides interface Msp430Capture as CaptureA0;
provides interface Msp430Capture as CaptureA1;
provides interface Msp430Capture as CaptureA2;
...
}
implementation
{
components new Msp430TimerP( TAIV_, TAR_, TACTL_, TAIFG, TACLR, TAIE,
TASSEL0, TASSEL1, FALSE ) as Msp430TimerA
, new Msp430TimerP( TBIV_, TBR_, TBCTL_, TBIFG, TBCLR, TBIE,
TBSSEL0, TBSSEL1, TRUE ) as Msp430TimerB
, new Msp430TimerCapComP( TACCTL0_, TACCR0_ ) as Msp430TimerA0
, new Msp430TimerCapComP( TACCTL1_, TACCR1_ ) as Msp430TimerA1
, new Msp430TimerCapComP( TACCTL2_, TACCR2_ ) as Msp430TimerA2
...
5.4.5 Example: PXA27x
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The PXA27x (XScale) platform provides a component for each of the
timers classes on the system. Each component provides a few interfaces
that exposes all features of that unit. Each interface combines timer
and control interface features. For example 'HplPXA27xOSTimerC'
provides 12 instances of the 'HplPXA27xOSTimer' interface and one
instace 'HplPXA27xOSTimerWatchdog'. Similarly for 'HplPXA27xSleep' and
'HplPXA27xWatchdog'.
::
interface HplPXA27xOSTimer
{
async command void setOSCR(uint32_t val);
async command uint32_t getOSCR();
...
async event void fired();
}
All the OS timers are exported through HplPXA27xOSTimerC
::
configuration HplPXA27xOSTimerC {
provides {
interface Init;
interface HplPXA27xOSTimer as OST0;
interface HplPXA27xOSTimer as OST0M1;
interface HplPXA27xOSTimer as OST0M2;
interface HplPXA27xOSTimer as OST0M3;
...
implementation {
components HplPXA27xOSTimerM, HplPXA27xInterruptM;
Init = HplPXA27xOSTimerM;
OST0 = HplPXA27xOSTimerM.PXA27xOST[0];
OST0M1 = HplPXA27xOSTimerM.PXA27xOST[1];
OST0M2 = HplPXA27xOSTimerM.PXA27xOST[2];
OST0M3 = HplPXA27xOSTimerM.PXA27xOST[3];
...
These interfaces are further abstracted through 'HalPXA27xOSTimerMapC'
as a parameterised interface:
::
configuration HalPXA27xOSTimerMapC {
provides {
interface Init;
interface HplPXA27xOSTimer as OSTChnl[uint8_t id];
}
} implementation {
components HplPXA27xOSTimerC;
Init = HplPXA27xOSTimerC;
OSTChnl[0] = HplPXA27xOSTimerC.OST4;
OSTChnl[1] = HplPXA27xOSTimerC.OST5;
OSTChnl[2] = HplPXA27xOSTimerC.OST6;
...
5.4.6 Timer Discussion
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
While the TEP is clear on many points there are few that are left up
to the implementer. The relation between timers and capture events is
unclear and covered in two TEPs. Capture refers to timers[TEP102_] but
the reverse is not clear[TEP102_]. This has a few implications for the
timer/capture relationship:
* Many devices feature multiple timers of the same width and
precision. It is not clear how this is provided. In particular how
this relates to a capture event - e.g. how does a capture event from
timer 2 relate to a time value from timer 1. Presumably TinyOS has
one system time based on a single timer which is used by all timer
capture interfaces and visualized if necessary.
* The interfaces provide a an elegant way to expand a 16 bit timer to
a 32 bit interface. However this is not the case for capture events.
5.5 I/O buses (UART, SPI, I2C)
--------------------------------------------------------------------
Most modern microprocessors provide a selection of standard I/O bus
units such as serial (UART or USART), I2C, SPI, etc. The drivers for
the available buses are usually put in a sub directory for the MCU
(e.g. *chip/atm128/spi* for SPI on ATMega128l).
There are a few TEP that cover different buses in TinyOS, and low
level serial communication:
* TEP113_ Serial Communication: Serial
* TEP117_ Low-Level I/O: Serial, SPI, I2C
On some hardware platforms a single I/O unit is shared among a number
of buses. The MSP430 for example implements SPI, I2C and USART in a
single USART unit that can only operate in one mode at a time. In such
cases the single hardware unit must be shared among the drivers.
5.5.1 Serial Communication
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Serial communication in TinyOS 2.x is implemented as a serial
communications stack with a UART or USART at the bottom. The bottom
layer is covered in [TEP113_] and [TEP117_]. TEP117 states that each
platform must provide access to a serial port through the
'SerialByteComm' interface from the component UartC. However UartC is
not provided by any platforms at the time of writing. There seems to
be a consensus to build the component 'PlatformSerialC' providing the
'UartStream' and 'StdControl' interfaces. Either component will be
placed in the platform directory (e.g. *tos/platforms/mica2* for
mica2). The serial stack is built upon 'PlatformSerialC' and this
component will be required to take advantage of the serial stack.
[TEP117_] defines 'UartStream' and 'UartByte' to access the a UART
multiple bytes at a time and one byte at a time (synchronously), while
[TEP113_] defines 'UartByte' to send and receive one byte at a time
(asynchronously).
5.5.2 I2C, SPI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SPI and I2C buses are provided through straightforward interfaces that
match the functionality of the buses closely.
SpiByte, SpiPacket
******************
::
interface SpiByte {
async command uint8_t write( uint8_t tx );
}
::
interface SpiPacket {
async command error_t send( uint8_t* txBuf, uint8_t* rxBuf, uint16_t len );
async event void sendDone( uint8_t* txBuf, uint8_t* rxBuf, uint16_t len,
error_t error );
}
I2CPacket
*********
::
interface I2CPacket<addr_size> {
async command error_t read(i2c_flags_t flags, uint16_t addr,
uint8_t length, uint8_t* data);
async command error_t write(i2c_flags_t flags, uint16_t addr,
uint8_t length, uint8_t* data);
async event void readDone(error_t error, uint16_t addr,
uint8_t length, uint8_t* data);
async event void writeDone(error_t error, uint16_t addr,
uint8_t length, uint8_t* data);
}
5.5.3 Example
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
..ATMega128
-> does not provide SerialByteComm
..MSP430
-> Uart1C provides SerialByteComm along with Init and StdControl
-> sender det meste videre til Msp430Uart1C (som mangler Init!?!?)
Msp430Uart0C
-> SerialByteComm, Msp430UartControl, Msp430UartConfigure, Resurce
-> Sender videre til Msp430Uart1P & Msp430Usart1C
-> Sender videre til HplMsp430Usart1C->HplMsp430Usart1P
..PXA27
Parametriseret m. HplPXA27xUARTP (Init && HplPXA27xUART)
-> init s鎡ter en masse registre og enabler interrupt
HalPXA27xSerialP: HplPXA27xUART, Init, noget DMA noget
6. Authors
====================================================================
| Martin Leoold
| University of Copenhagen, Dept. of Computer Science
| Universitetsparken 1
| DK-2100 K鴅enhavn
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -