2007 TinyOS 3

From Seamonster

(Redirected from TinyOS Programming 3)
Jump to: navigation, search

Motes ("Telos-B")


Related


Contents

Struggling with Syntax

I'll draw up a component to get a start on the syntax. I have dropped into using the module version of a component rather than the configuration version of the component. In my opinion Phil is correct to start with modules since they provide implementations of these functions (among other things) and a programmer like me is accustomed to thinking in terms of implementations: blocks of code that do things.


My pretend application will play some music and: 

module Bongo {
  provides interface StdControl;
  provides interface DrumHead;
  uses     interface Bam;
} 
implementation {
.
  int count_var;
.
  command result_t StdControl.init() {
    return SUCCESS;
  }
  command result_t StdControl.start() {
    return SUCCESS;
  }
  command result_t StdControl.stop() { 
    return SUCCESS;
  } 
.
.
  command result_t DrumHead.setTension(args) {
    // code to set the tension
  }
.
  event void Bam.done() { }
}


With so much built in SUCCESS this module is guaranteed never to crash, cymballically speaking.


My idea is that the Bongo module is going to provide a "Standard Control" interface and a DrumHead interface and it will also use a Bam interface. Bam is some sort of noise generator, so some other process would hit the Bongo and Bongo would defer to Bam to get a sound back out. Kinda weak, and my syntax is still horrible...


Anyway what is the difference between provided versus used interfaces? Imagine that these interfaces are specified elsewhere. Each has a little laundry list of constitutive functions, either commands or events. A command is something the interface is capable of doing. One expects Bongo.StdControl.init() to get called at the top of the program and Bongo.start() and Bongo.stop() to g 1000 et called over the course of the program run (say a musical performance). These calls to Bongo.StdControl member functions will have to come from somewhere else like main()--either implicitly or explicitly--as will calls to the DrumHead interface. A call to one of the commands in this interface might look like 

call Bongo.DrumHead.setTension(7);


Either this drumhead could be a physical (hardware) thing (we're building a robot drum player) or it could be software. In the former case the operation of setting the tension might take awhile so the command would return before the operation was done. Later on when the drumhead tension had been set a signal (callback) is sent back to the Bongo module and caught by an event function (event handler) that would also be declared as part of the DrumHead interface. 

signal Bongo.DrumHead.tensionSet();


In this way the split phase model is achieved.

Make Magic

Heavy library usage helps keep nesC source code small, and this shows up in the compile-time include list. Here is this compile command reproduced; while it prints monolithically in practice I added line breaks: 

% make tmote
.
ncc 
-o build/tmote/main.exe 
-O 
-I/opt/moteiv/tinyos-1.x/tos/lib/Oscope 
-DDELUGE_PAGETRANSFER_LEDS 
-Wall 
-Wshadow 
-DDEF_TOS_AM_GROUP=0x7d 
-Wnesc-all 
-target=tmote 
-fnesc-cfile=build/tmote/app.c 
-board= 
-DOSCOPE_MAX_CHANNELS=6 
-I/opt/moteiv/tos/platform/tmote 
-I/opt/moteiv/tos/platform/tmote/util/uartdetect 
-I/opt/moteiv/tos/platform/msp430/adc 
-I/opt/moteiv/tos/platform/msp430/dac 
-I/opt/moteiv/tos/platform/msp430/dma 
-I/opt/moteiv/tos/platform/msp430/resource 
-I/opt/moteiv/tos/platform/msp430/timer 
-I/opt/moteiv/tos/platform/msp430 
-I/opt/moteiv/tos/lib/util/pool 
-I/opt/moteiv/tos/lib/util/button 
-I/opt/moteiv/tos/lib/util/null 
-I/opt/moteiv/tos/lib/util 
-I/opt/moteiv/tos/lib/MultiHopLQI 
-I/opt/moteiv/tos/lib/netsync 
-I/opt/moteiv/tos/lib/sp 
-I/opt/moteiv/tos/lib/sp/cc2420 
-I/opt/moteiv/tos/lib/timer 
-I/opt/moteiv/tos/lib/resource 
-I/opt/moteiv/tos/lib/sched 
-I/opt/moteiv/tos/lib/Deluge 
-I/opt/moteiv/tos/lib/Flash/STM25P 
-I/opt/moteiv/tos/lib/Flash 
-I/opt/moteiv/tos/lib/Spram 
-I/opt/moteiv/tos/interfaces 
-I/opt/moteiv/tos/lib/CC2420Radio 
-I/opt/moteiv/tos/system 
-I/opt/moteiv/tinyos-1.x/tos/lib/CC2420Radio 
-I/opt/moteiv/tinyos-1.x/tos/lib/Drip 
-fnesc-scheduler=TinySchedulerC,TinySchedulerC.TaskBasic,TaskBasic,TaskBasic,runTask,postTask 
-Wl,--section-start=.text=0x4800,--defsym=_reset_vector__=0x4000
-DLIB_DELUGE 
-DDELUGE_NUM_IMAGES=6 
-mdisable-hwmul 
-I%T/lib/Deluge 
-Wl,--section-start=.text=0x4800,--defsym=_reset_vector__=0x4000 
-DIDENT_PROGRAM_NAME=\"Oscilloscope\" 
-DIDENT_USER_ID=\"robfat\" 
-DIDENT_HOSTNAME=\"robfat-m5\" 
-DIDENT_USER_HASH=0x340adc7bL 
-DIDENT_UNIX_TIME=0x45a0909bL 
-DIDENT_UID_HASH=0xbdbd55f5L 
OscilloscopeTmoteSky.nc 
-lm


If you look at the Makefile it doesn't have all these clever include directories in it. The only clue is 'include $MAKERULES' as the last line of the program. Where then does all this careful include structure come from? I think these includes are hardwired into the file /opt/moteiv/tools/make/tmote.target. This is reproduced on this page: Tmote Makefile. On further investigation I find that the environment variable $MAKERULES is in fact /opt/tinyos-1.x/tools/make/Makerules which is reproduced on this page: TinyOS Makerules. I think the Makerules file does all the heavy lifting (perl, conditionals...) and the tmote.target file is used to construct the actual ncc compile command given above.


By looking through this compile command I can see where component software resides for other ADC channels like the temp/humidity sensor and the radiation sensor (Hamamatsu). The place to start would be /opt/moteiv/tos/platform/tmote since it is at the top of the list; see below.

Tmote Sky Mechanical / Package Notes

  • Supply voltage can be 2.1V--3.6V.
  • Temp rated -40C to 85C
  • Max current

1000 consumption Full-Up 23 milliamps

  • Max current consumption MCU ON Radio OFF 2.4 milliamps
  • Max current consumption MCU Standby Radio OFF 21 microamps
  • Dimensions 1.267 x 2.580 x .256 inches (no USB conn, no SMA)
  • Add USB: Length to 3.163; Add SMA: Thickness to 0.513
  • Do not use metal in mounting hole near antenna.
  • PAR sensor is on ADC4
  • TSR sensor is on ADC5
  • This leaves ADC0--3,6--7 available


Tmote Sky Expansion Connector Pinout

First we have a 10-pin connector 'primary', then an adjacent 6-pin 'secondary'. The 10-pin is the further of the two from the USB port. Pin 1 of the 10-pin is inboard closest to the USB side. Likewise Pin 1 of the 6-pin is inboard closest to the USB. Both are 'square-looking' rather than round. Pins are numbered in socket-fashion even-side / odd-side (and so not in part fashion incrementally along one side).

You can assemble a mental picture of where these two pads are in relation to one another by first taking the 10-pin pad and rotating it 90 degrees clockwise, then doing the same to the 6-pin pad, then moving that second pad to the right of the first pad. 

     Analog Vcc  (AVcc)   [1]   (2)   UART Rx   (UART0RX)
.
     Analog In 0 (ADC0)   (3)   (4)   UART Tx   (UART0TX)
.
     Analog In 1 (ADC1)   (5)   (6)   I2C Clock (I2C_SCL)
                                      Shared Digital I/O 4 (GIO4)
     Analog In 2 (ADC2)   (7)   (8)   I2C Data  (I2C_SDA)
Excl. Dig. I/O 1 (GIO1)               Shared Digital I/O 5 (GIO5)
     Analog Gd   (Gnd)    (9)  (10)   Analog Input 3 (ADC3)
                                      Exclusive Digital I/O 0 (GIO0)
. 
. 
     Analog In 6 (ADC6)   [1]   (2)   Analog In 7 (ADC7)
                  DAC0                DAC1/SVS in 
Excl. Dig. I/O 2 (GIO2)   (3)   (4)   Excl. Dig. I/O 3 (GIO3)
  Timer A Capture (TA1)               External DMA Trigger (DMAE0)
 User Interr. (UserInt)   (5)   (6)   Reset

Notes

  • Determine where the onboard jumpers are as alluded to.
  • DAC0 and DAC1 are 12-bit DAC outputs
  • SVS stands for supply voltage sensor (input)
  • "Note: The I2C pins are shared with the radio's data input pin and the radio clock. Care must be taken by application developers to mulitplex operations on the I2C bus and the radio."

Hacking Oscilloscope

README.TmoteSky

  • Contact support@moteiv.com: Sent 4 emails, replies to date: well they finally wrote back when I told them I was going to create a service board to make their devices easier to use.
  • The Oscilloscope app copies 6 sensor streams to a TOSBase application by radio. The down side is that it does not make use of the multihop library as far as I can tell (whereas the Delta app does) so out of the box we don't get that full functionality in a single demo.
  • Sensirion Relative Humidity / Temp, Hamamatsu PAR and TSR light sensors
  • ...(PA = photosynth-active)
  • ...(TS = Total Solar)
  • ...(R = Radiation)
  • Chan 0: Humidity
  • Chan 1: Temp
  • Chan 2: TSR (Pin5--ADC0 after hack)
  • Chan 3: PAR (Pin3--ADC1 after hack)
  • Chan 4: Internal Temp
  • Chan 5: Internal Voltage
  • To burn oscilloscope into a mote
  • ... 0) modify /opt/moteiv/tos/platform/tmote/Hamamatsu.h as described below
  • ... 1) cd /cygdrive/c/cygwin/opt/moteiv/apps/Oscilloscope
  • ... 2) Onto mote 7: % make tmote install,7 (note no space after comma)
  • To build a base station
  • ... 0) plug in another Tmote
  • ... 1) From apps/TOSBase % make tmote install (note no mote number)
  • To visualize data on a PC
  • ... 0) Note the COM port it uses (command is motelist); suppose it is COM9.
  • ... 1) alias go='MOTECOM=serial@COM9:tmote java com.moteiv.oscope.oscilloscope'
  • ... 2) go
  • To obtain voltage: Internal ADC is 12 bits (0-4095); Voltage = value/4096 * (Vref = 1.5V or 2.5V)
  • Confusing: internal voltage reported in millivolts (so no calibration???)
  • See Moteiv datasheet for internal temp conversion.
  • TSR and PAR are also 12-bit ADC with Vref=1.5V; they are current-based devices.
  • --> Obtain Amps -> Voltage as above -> Current using Ohm's law and 100ko

1000 hm resistor.

  • --> Obtain Lux -> See datasheet.
  • Sensirion Temp: Oscilloscope returns a 14-bit value that can be converted to degC.
  • --> Temp = -39.60 0.01*SOt where SOt is the raw 12-bit number
  • Hum_raw = -4 0.0405*SOrh (-2.8*10^-6)*(SOrh^2) where SOrh is the raw 12-bit number.
  • Hum_comp (compensated) = (Temp - 25) * (0.01 0.00008*SOrh) Hum_raw


Makefile

  • refers to $(TOSDIR)/lib/Oscope
  • MOTEIVDIR ?= ../.. which is /opt/moteiv
  • OSCOPE_MAX_CHANNELS=6 could be used to cut down on the data flow


Hacking OscilloscopeTmoteSky.nc

  • Let's go find the Hamamatsu "support" library.
  • Oh, here it is in /opt/moteiv/tos/platform/tmote, the first directory at the top of the makefile list, including a file called Hamamatsu.h (etc)
  • Hamamatsu.h references A4 twice in referring to the PAR channel. I bet I could change that to A0.
  • It also refers to 1_5 as a reference voltage twice. I bet I could change this to 2_5.
  • I bet I could do a similar number on the TSR channel references, to A1 (ADC1) and 2_5 (2.5V) respectively.
  • My borrowed turbidimeter runs 2.5V and lower so that's ok.
  • My LM19 National Semiconductor analog temp sensor runs 2.5 to 0 volts so that's ok.
  • This turbidimeter is not a nephelometer which measures light reflected off of suspended particles. This turbidimeter measures transmission attenuation. Kirchhoff's Laws in action eh?
  • I criminally copied, changed and commented out the original Hamamatsu PAR and TSR header references as noted. The application Oscilloscope compiled and loaded into a mote.
  • I loaded TOSBase onto a different mote 0 as noted above.
  • I hooked up the turbidimeter to ADC0 and the temp sensor to ADC1.
  • The turbidimeter runs on 12 volts so I attached it to an external 12V supply.
  • The temp sensor requires a cap so I soldered on a 2/10mic cap and covered the leads with some heat shrink so they would be less likely to short.
  • The temp sensor runs on 3 volts so I attached it to the Vcc supply on the Tmote.
  • I got a cup of coffee.
  • I dumped a bunch of milk into it.
  • I heated it to near boiling in the microwave.
  • I hoped that the hot milky coffee would not be highly conductive.
  • I got a cup of water and filled it with ice.
  • I checked all the relevant voltages to make sure everything seemed ok. It seemed ok.


What Happened

  • I ran the java app 'Oscilloscope' as noted above.
  • The PAR and TSR channels were no longer light sensitive.
  • The PAR channel changed value drastically when I removed the turbidimeter from the coffee, returned to its previous value when I re-submerged it.
  • The TSR channel changed value drastically as I moved the temp sensor from the hot coffee to the icy water.
  • I concluded that I seem to have made a cheesy hack that permits me to monitor ADC0 and ADC1 on the Tmote.
  • My coffee is too hot and it has too much milk in it. This closes out the First Objective described here.


Page 4 of these notes

Retrieved from "http://robfatland.net/seamonster/index.php?title=2007_TinyOS_3"
Personal tools