Re: [Tinyos-help] Doubt in FTSP

[Vlado Handziski]

It will not hurt, but I don't see why it is strictly necessary. The first
operand of the % (more a rest than a modulo) operation is already int32_t,
the second operand is a uint_8, the results always has the same sign as the
dividend, as mentioned in the comments.

--Vlado

On Wed, Oct 4, 2017 at 12:31 AM Eric Decker  wrote:

>
> I think you are right just looking at the math.
>
> However, you will have to test it and watch how the algorithm behaves to
> make sure it is functioning correctly.
>
> I'm not familar enough with the algorithm nor the underlying principles to
> eye ball it and get it right.
>
> If you do figure it out please document it better.
>
> thanks,
>
> eric
>
>
> On Mon, Oct 2, 2017 at 12:55 AM, Jobish John 
> wrote:
>
>> Dear all,
>>
>> While trying to understand the TinyOS implementation of FTSP, in one of
>> the function, “calculateConversion()” from (TimeSyncP.nc), I have a
>> small doubt in the below part,
>>
>> --
>> while( ++i < MAX_ENTRIES )
>>if( table[i].state == ENTRY_FULL )
>>{  /*
>> This only works because C ISO 1999 defines the signe for
>> modulo the same as for the Dividend!
>>  */
>>localSum += (int32_t)(table[i].localTime -
>> newLocalAverage) / tableEntries;
>>localAverageRest += (table[i].localTime - newLocalAverage)
>> % tableEntries;
>>offsetSum += (int32_t)(table[i].timeOffset -
>> newOffsetAverage) / tableEntries;
>>offsetAverageRest += (table[i].timeOffset -
>> newOffsetAverage) % tableEntries;
>>  }
>> ---
>> I think we need to add a typecast (int32_t) for the localAverageRest
>> calculation line also, That is, something like
>> localAverageRest += (int32_t) (table[i].localTime - newLocalAverage) %
>> tableEntries;
>>
>> Kindly suggest..
>>
>> Thanks for your valuable time
>>
>> Regards
>> Jobish John
>> IIT Bombay
>>
>>
>>
>>
>>
>> ___
>> Tinyos-help mailing list
>> Tinyos-help@millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>
>
>
>
> --
> Eric B. Decker
> Senior (over 50 :-) Researcher
>
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] TEP links broken on TinyOS wiki

[Vlado Handziski]

Hi James,

You can find the TEPs in the tinyos-main repo:

https://github.com/tinyos/tinyos-main/tree/master/doc/txt

--Vlado

On Fri, Sep 30, 2016 at 12:59 PM James Allen (PGR) <
j.d.all...@newcastle.ac.uk> wrote:

> Hi,
>
>
> All the links to TEPs at the following URL appear to be broken:
>
>
> http://tinyos.stanford.edu/tinyos-wiki/index.php/TEPs
> 
>
>
> Is there an alternative way to view TinyOS TEPs or does someone know the
> administrator who can fix the links?
>
>
> Many thanks
>
>
> James (a TinyOS beginner)
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] BLIP TinyOS Ping Help

[Vlado Handziski]

Assuming the node has the UDP shell as part of the firmware, you can
remotely access the shell (using netcat for example) and use its ping
command.

--Vlado

On Wed, Nov 9, 2016 at 8:31 AM NDSG SAs  wrote:

> Hi,
>
> Is there a built-in way for a mote to ping a computer on the same LAN
> where the PppRouter is included in? If not, what do you suggest to do as an
> alternative?
>
> Thank you!
>
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Disabling blip statistics

[Vlado Handziski]

Hi Peter,

unfortunately there is no finer grained control for the statistics printing
in BLIP. If this is a major problem, you can redefine printf in the part of
the file where you want to disable the output.  I am not aware of any
issues with UDP stopping after a single packet, but I have not used z1
nodes.

--Vlado

On Fri, Sep 9, 2016 at 12:22 PM Peter Kietzmann <
peter.kietzm...@haw-hamburg.de> wrote:

> Dear list,
>
> finally I was able to get some simple networking running but I still
> have open questions :-).
>
> I'm working with TinyOS 2.1.2 release on z1 and telosb nodes. How can I
> suppress the output of blip statistics? After setting
> "PRINTFUART_ENABLED", network statistics continuously go out of the
> uart. But "PRINTFUART_ENABLED" seems to be required to get IPStack and
> SerialPrintf to work together.
>
> Is there a known condition which causes udp to stop after retrieving one
> packet?
>
> Best regards
> Peter
>
> --
> Peter Kietzmann
>
> Hamburg University of Applied Sciences
> Dept. Informatik, Internet Technologies Group
> Berliner Tor 7, 20099 Hamburg, Germany
> Fon: +49-40-42875-8426
> Web: http://www.haw-hamburg.de/inet
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] UDP application

[Vlado Handziski]

Hi Peter,

you can start by looking at the apps/UDPEcho. Take a look at the Makefile
and LIB6LOWPAN_HC_VERSION for specifying the header compression.

--Vlado

On Tue, Sep 6, 2016 at 2:09 PM Peter Kietzmann <
peter.kietzm...@haw-hamburg.de> wrote:

> Dear TinyOS developers,
>
> I'd like to transmit UDP packets over UDP/IPv6/6Lowpan between two
> Zolertia Z1 nodes. Payload is small (20B), IPHC should be disabled and
> addresses should be link local. Is there an example which I can use as a
> start point?
>
> In addition, which is the best way to give nodes a predictable link
> local address? I mean, same address after each reboot.
>
> I'm happy about any advice!
>
> Best Regards
> Peter
>
> --
> Peter Kietzmann
>
> Hamburg University of Applied Sciences
> Dept. Informatik, Internet Technologies Group
> Berliner Tor 7, 20099 Hamburg, Germany
> Fon: +49-40-42875-8426
> Web: http://www.haw-hamburg.de/inet
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Support for Atmel Software Framework and Stm32Cube

[Vlado Handziski]

Hi Ugo,

this can be very useful, thanks for the heads up.

--Vlado

On Sun, Jul 31, 2016 at 10:09 AM Ugo Maria Colesanti <
colesa...@dis.uniroma1.it> wrote:

> Hi all,
> I just want to let you know that I wrote some wrapping code for using the
> Atmel Software Framework (ASF) and the STM32Cube frameworks on tinyos. I
> did it to support the newest boards available from Atmel and STM
> (specifically, the SamD10, SamD20, SamD21 and SamR21 from Atmel and the new
> STM32L4XX from STM) which are based on cortex M0+ and Cortex M4.
> The principle is pretty simple: I compile the ASF files and Stm32Cube
> files externally as c files, then I bind them on tinyos wrapper modules
> that provide the  interfaces such as TimerMilli, ActiveMessage, SpiByte
> etc...
> The design does not follow the TinyOS 3-layers architecture anymore, but
> has the great advantage of enabling the use of CTP, Low Power Listening and
> other cool TinyOS stuffs on most recent hardware platforms with a large
> community behind, that patches and keeps updated the code periodically.
> The atmel software framework was the trickiest to include since it was
> using some conflicting naming such as the keyword "module" and the bool
> type (which is 32bit large instead of the 8 bit in tinyos), but with few
> patches, it is now compiling well and working like a charm (I still need to
> debug a lot of code though).
> As for now, I managed to have the following boards working:
> - SamD10Xmini
> - SamD20XPro
> - SamD21XPro
> - SamR21XPro
> - Discovery 476
>
> I also included the REB233-XPRO module as an add-on sensorboard to enable
> all the development boards with wireless capabilities (except for SamR21
> which has a built-in transceiver). It's pretty nice to see RadioCountToLeds
> running well on an R21Xpro and a Disco476 :)
> You can find my repo on github here:
> https://github.com/ucolesanti/tinyos-wrappers
> As for now there is only the SamR21Xpro support, I will add SamD20,D21 in
> the next hours, D10 and Disco476 in the next days (I still need to perform
> some tests). I need to write a lot of documentation, as for now there is
> only a small README, but those that are practical with TinyOS should be
> able to install and run everything immediately.
> Please let me know your opinions and if you want to contribute!
>
> Ugo
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Atmel SAM4 Support

[Vlado Handziski]

Hi Thomas,

has anyone tried to get BLIP running on the sam3?

--Vlado

On Thu, Feb 25, 2016 at 1:18 AM Thomas Schmid 
wrote:

> Hi Eric,
>
> The SAM4 is very similar to the SAM3. Shouldn't be too difficult to get it
> up and running on it. You will have to enable the compiler flags for
> hardware floats if that's why you want to use a SAM4 though.
>
> Cheers,
>
> - Thomas
>
>
> On Wed, Feb 24, 2016 at 12:54 PM, Eric Rudisill 
> wrote:
>
>> Hello!
>>
>> I’m new to TinyOS and was wondering if anyone has succeeded in running on
>> an Atmel SAM4 family micro-controller (Cortex M4.)
>>
>> (I’ve googled “tinyos sam4” and have not turned up anything.  If there is
>> a better search method for this list, please let me know.)
>>
>> Thanks!
>>
>> -Eric Rudisill
>>
>> ___
>> Tinyos-help mailing list
>> Tinyos-help@millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
>
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] newbie setup; 1/2 duplex modem networking

[Vlado Handziski]

Hi Chris,

not sure what version of TinyOS and avr-gcc you are using, but it is clear
that whatever version you have it is not using the new make system. Please
try with:

https://github.com/tinyos/tinyos-main

and avr-gcc 4.8.1

You should see something like this:

vlahan@vlahan-ThinkPad-X1-Carbon:~/os/tinyos-main/apps/Blink$ make mica2
[INFO] compiling BlinkAppC to a mica2 binary
nescc -o build/mica2/main.exe   -Os -gcc=avr-gcc -Wnesc-all
-fnesc-include=tos
-fnesc-scheduler=TinySchedulerC,TinySchedulerC.TaskBasic,TaskBasic,TaskBasic,runTask,postTask
-fnesc-cfile=build/mica2/app.c -fnesc-separator=__
-I/home/vlahan/os/tinyos-main/tos/platforms/mica2
-I/home/vlahan/os/tinyos-main/tos/platforms/mica
-I/home/vlahan/os/tinyos-main/tos/platforms/mica2/chips/cc1000
-I/home/vlahan/os/tinyos-main/tos/chips/cc1000
-I/home/vlahan/os/tinyos-main/tos/platforms/mica2/chips/at45db
-I/home/vlahan/os/tinyos-main/tos/platforms/mica/chips/at45db
-I/home/vlahan/os/tinyos-main/tos/chips/at45db
-I/home/vlahan/os/tinyos-main/tos/chips/atm128
-I/home/vlahan/os/tinyos-main/tos/chips/atm128/adc
-I/home/vlahan/os/tinyos-main/tos/chips/atm128/i2c
-I/home/vlahan/os/tinyos-main/tos/chips/atm128/pins
-I/home/vlahan/os/tinyos-main/tos/chips/atm128/spi
-I/home/vlahan/os/tinyos-main/tos/chips/atm128/timer
-I/home/vlahan/os/tinyos-main/tos/lib/timer
-I/home/vlahan/os/tinyos-main/tos/lib/serial
-I/home/vlahan/os/tinyos-main/tos/lib/power -mmcu=atmega128
-fnesc-target=avr -fnesc-no-debug -DPLATFORM_MICA2 -Wall -Wshadow --param
max-inline-insns-single=10 -Wno-unused-but-set-variable
-Wno-enum-compare -I/home/vlahan/os/tinyos-main/tos/system
-I/home/vlahan/os/tinyos-main/tos/types
-I/home/vlahan/os/tinyos-main/tos/interfaces -DIDENT_APPNAME=\"BlinkAppC\"
-DIDENT_USERNAME=\"vlahan\" -DIDENT_HOSTNAME=\"vlahan-ThinkPad\"
-DIDENT_USERHASH=0xcba3fc9cL -DIDENT_TIMESTAMP=0x56d6ca3dL
-DIDENT_UIDHASH=0x8f1c6111L -fnesc-dump=wiring
-fnesc-dump='interfaces(!abstract())'
-fnesc-dump='referenced(interfacedefs, components)'
-fnesc-dumpfile=build/mica2/wiring-check.xml BlinkAppC.nc -lm
[INFO] script
2174 bytes in ROM
  52 bytes in RAM
[INFO] size (toolchain):
   text   databssdechex filename
   2174  0 52   22268b2 build/mica2/main.exe
[INFO] generating symbol table
[INFO] generating listing
[INFO] creating srec file
[INFO] creating ihex file
[INFO] writing TOS image
[INFO] writing TOS buildinfo
[INFO] running the wiring check


On Fri, Feb 12, 2016 at 4:43 AM Chris Nicholas 
wrote:

> hmm - just trying to follow along the first tutorial:
>
> http://tinyos.stanford.edu/tinyos-wiki/index.php/Getting_Started_with_TinyOS
>
> root@cgn-VirtualBox:/usr/src/tinyos/apps/Blink# make mica2
>
> mkdir -p build/mica2
> compiling BlinkAppC to a mica2 binary
> ncc -o build/mica2/main.exe  -Os -fnesc-separator=__ -Wall -Wshadow
> -Wnesc-all -target=mica2 -fnesc-cfile=build/mica2/app.c -board=micasb
> -DDEFINED_TOS_AM_GROUP=0x22 --param max-inline-insns-single=10
> -DIDENT_APPNAME=\"BlinkAppC\" -DIDENT_USERNAME=\"root\"
> -DIDENT_HOSTNAME=\"cgn-VirtualBox\" -DIDENT_USERHASH=0x5536ffb7L
> -DIDENT_TIMESTAMP=0x56bd4f1dL -DIDENT_UIDHASH=0x61630383L
> -fnesc-dump=wiring -fnesc-dump='interfaces(!abstract())'
> -fnesc-dump='referenced(interfacedefs, components)'
> -fnesc-dumpfile=build/mica2/wiring-check.xml BlinkAppC.nc -lm
> /usr/src/tinyos/tos/chips/atm128/McuSleepC.nc:66:15: error: variable
> ‘McuSleepC__atm128PowerBits’ must be const in order to be put into
> read-only section by means of ‘__attribute__((progmem))’
>const_uint8_t atm128PowerBits[ATM128_POWER_DOWN + 1] = {
>^
> make: *** [exe0] Error 1
>
> (sigh)
>
> Chris
>
> On Thursday, February 11, 2016 12:15 PM, Chris Nicholas <
> chrisgnicho...@att.net> wrote:
>
>
> Hi - I just installed the Debian packages on my MAC VirtualBox, and
> getting psyched to build and install the examples on an Atmega 256, and
> order the right low-power radio stuff to get collection tree protocol
> working.
>
> I really want to try to port that to run over HAM radio at ~1200 baud FSK
> 1/2 duplex ... does that sound feasible?
>
> Any words of wisdom, caution, etc on how best to go about this greatly
> appreciated.  And anyone here in the SF Bay/East Bay area that might be
> available for a visit in 'high def' just to get my toolchain working, that
> can be bribed with their favorite beer or otherwise, sought as well...
>
> thanks!
> Chris
>
>
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] any documentation on tasklets?

[Vlado Handziski]

We actually need a strategy to move the whole content from
docs.tinyos.netthere. We need to consolidate the info in one place.

--Vlado


On Thu, Jun 27, 2013 at 11:06 PM, Miklos Maroti mmar...@math.u-szeged.huwrote:

 Dear Johny,

 Thanks a lot for putting up on the wiki! That is a good idea to try to
 keep stuff like this there.

 Best,
 Miklos

 On Mon, Jun 10, 2013 at 10:13 PM, Johny Mattsson jmatts...@dius.com.au
 wrote:
  On 8 June 2013 00:46, Miklos Maroti mmar...@math.u-szeged.hu wrote:
 
  Think of Tasklets as a way to
  write code that you can configure to your hart content: either to be
  run as regular tasks, or to run them in interrupt context in a safe
  way. It just gives the user quite a bit of flexibility.
 
 
  Thanks for that! I guess I had hoped for a magic cure that abstracted
 away
  the entire radio stack in such a way I did not have to take it into
  consideration too much, but unsurprisingly the way to good software is a
  thorough understanding, as usual.
 
 
 
   Can I suggest it be added to the github
   wiki, or the regular doc site as well?
 
  Sure, would you take this task, and I will extend it as needed?
 
 
  Me and my large mouth (keyboard?)... Okay, it's up:
https://github.com/tinyos/tinyos-main/wiki/Tasklet-design-notes
 
 
  Cheers,
  /Johny
  --
  Johny Mattsson
  Senior Software Engineer
 
  DiUS Computing Pty. Ltd.
  where ideas are engineered
 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] TinyOS on cubesat ESTCube-1

[Vlado Handziski]

Hi Andres,

that's indeed a great news. Keep up the good work!

--Vlado


On Fri, May 10, 2013 at 7:45 AM, Andres Vahter andres.vah...@gmail.comwrote:

 Hello,

 I am proud to announce that ESTCube-1 cube satellite's TinyOS based
 communication module is working very well.
 Not sure, but it might be the first time for TinyOS to be in space.

 Communication module has MSP430F2418 MCU and two ADF7021 radios for uplink
 and downlink. It uses AX.25 amateur radio communication protocol, therefore
 TinyOS needed quite a lot modifications to support this.
 More can be read from there:
 https://andresvahter.wordpress.com/2013/01/27/last-touches-to-the-estcube-1-communication-module/and
  there
 http://www.estcube.eu/en/home.


 Andres Vahter

 ESTCube-1
 Communication Subsystem Engineer
 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] MRF24J40MA Raspberry Pi and Arduino Was: Re: Re: Epic Cape (802.15.4 wireless) for BeagleBone embedded Linux board

[Vlado Handziski]

Yes, cool work. We should also consider integrating that atm328p/uno
support to tinyos-main in due time if Johny is interested.

--Vlado


On Sat, Jan 12, 2013 at 5:08 AM, Eric Decker cire...@gmail.com wrote:


 Hey Markus,

 I'd like to capture your code and Johnny's as well in tp-freeforall.


 On Fri, Jan 11, 2013 at 1:17 AM, Markus Becker 
 m...@comnets.uni-bremen.dewrote:

 [...]
 
  Thanks for the helpful feedback Antonio.  I'd be interested in learning
  about other similar projects out there if you (or anybody else) knows of
  ones that exist.
 Hi.

 I have done an adapter board for an MRF24J40MA 802.15.4 module. That
 module
 sells at 10EUR and is supported by the 802.15.4 stack of Linux version
 3.7
 and up. I have backported the 15.4 driver to the 3.6 RPi kernel as well.
 The
 appropriate board config for the SPI and the driver are in
 https://github.com/markushx/linux

 At the moment I am still struggling a little with attaching that module
 to an
 Arduino Uno, based on Johny Mattsson's TinyOS port to Arduino:
 https://github.com/markushx/tinyos-arduino-MRF24J40MA

 Markus

  With regard to your comment about Raspberry Pi, I totally agree, it is a
  much cheaper alternative (and a cool board!).  However, for some people,
  the BeagleBone is an attractive platform BECAUSE of the more expensive
  Cortex™-A8 processor and feature set.  For example, Ubuntu for ARM is
  built for Cortex™-A8 and beyond with all the optimization features the
  ARMv7 architecture offers, and can run on the BeagleBone.  However,
  Ubuntu is unwilling to support the Raspberry Pi because the processor is
  an older Broadcom ARMv6 (http://elinux.org/RPi_Distributions#Ubuntu).
 
  Obviously, a design constraint for the Epic Cape was not cost (if I'm
  really being honest, the ONLY constraint was quick, what can I finish
  in two days before the contest deadline in-between games of rummikub
  with my inlaws!?!? hehe ;)  Using the Epic module + carrier cape adds
  significant cost to the overall design, but made my life easier.  The
  goal for this first prototype was basically to get to a simple, clean
  piece of hardware using building blocks I have experience with (i.e.
  Epic).  There are many cheaper and better ways to design a small 15.4
  boarder router, but for some people, this combination of well supported
  hardware platforms might be attractive.
 
  Chris
 
  ___
  Tinyos-help mailing list
  Tinyos-help@millennium.berkeley.edu
 
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
 
 | Dipl.-Ing. Markus Becker
 | Communication Networks
 | TZI - Center for Computing Technologies
 | University Bremen
 | Germany
 
 | web: http://www.comnets.uni-bremen.de/~mab/
 | mailto: m...@comnets.uni-bremen.de
 | telephone: +49 421 218 62379
 | building: NW1 room: N2260
 

 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help




 --
 Eric B. Decker
 Senior (over 50 :-) Researcher


 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Transition to GIT and GitHub

[Vlado Handziski]

Dear members of the TinyOS community,

as one of the first steps in the implementation of the announced changes to
the TinyOS development and contribution model, we would like to inform you
that starting from *January 1st, 2013*, the *existing SVN tinyos-main
repository on Google Code at https://code.google.com/p/tinyos-main/ will be
frozen and depreciated*, and future development will continue* *on* GitHub
at https://github.com/tinyos*.

The development is organized in two main repositories:

   1. *tinyos-main* at https://github.com/tinyos/tinyos-main, as main
   development repository
   2. *tinyos-release* at https://github.com/tinyos/tinyos-release, as main
   release repository

Short overview of the roles of each repository can be found in the
README.md files at the above links. More detailed instructions can be found
in the following documentation files:

   1. doc/00a_Getting_Started: Overview of getting started using git,
   github.
   2. doc/00b_Using_the_Repo: Using and contributing back to the central
   Repository.

 In the transition period until January 1st, these files can be found in
the transition branch:

   1.
   https://github.com/tinyos/tinyos-main/blob/transition/doc/00a_Getting_Started
   2.
   https://github.com/tinyos/tinyos-main/blob/transition/doc/00b_Using_the_Repo


In addition to the repository, starting from *January 1st, 2013*, the
*tinyos-main
issue tracker at Google Code (
https://code.google.com/p/tinyos-main/issues/list) will be frozen and
depreciated*. The issues have been migrated to the GitHub issue tracker,
and can be accessed at https://github.com/tinyos/tinyos-main/issues.

Once complete, the initial list of the lead developers with push rights to
the tinyos-main repository will be listed in the
doc/policy/lead_developers.txt file (
https://github.com/tinyos/tinyos-main/blob/transition/doc/policy/lead_developers.txthttps://github.com/tinyos/tinyos-main/blob/transition/doc/policy/owners.txt)
and also on a dedicated wiki page at
https://github.com/tinyos/tinyos-main/wiki/Lead-Developers.

If you have any questions or suggestions about the transition to GitHub, or
you need support with setting-up and using the repositories, please drop a
mail on the tinyos-devel list or contact Eric (cire...@gmail.com) who was
responsible for setting the new infrastructure on GitHub.

Happy Holidays!

-- Vlado, Miklos, Eric and Om (on behalf of the lead developers team)
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Hardcoded delays in Msp430AlarmC.nc

[Vlado Handziski]

Most of them are workarounds for hw errata in the timer modules on the
MSP430F1611, etc. Please take a look at the errata documents for more
details.

Vlado

On Wed, May 11, 2011 at 16:04, Romain Bornet bornet.r...@gmail.com wrote:

 Hi Eric, hi all,

 On Tue, May 10, 2011 at 9:56 PM, Eric Decker cire...@gmail.com wrote:



 On Tue, May 10, 2011 at 12:36 AM, Romain Bornet bornet.r...@gmail.comwrote:

 Hi,

 I already posted this 2 weeks ago with no success. Perhaps I'll be
 luckier this time ?


 If something concerns the msp430 you would possibly get better response
 also posting to  the tinyos-msp...@millennium.berkeley.edu mail list as
 well.


 I didn't know about this list. Thanks for the hint !




 I'm porting TinyOS to a new CPU architecture and took the well
 supported and maintained MSP430 implementation as a reference. Given
 the timer infrastructure I have on my CPU, I can rather seamlessly
 take over some HAL/HIL components with few or no modifications.

 I just wonder on the hardcoded values in
 Msp430AlarmC.nc/Alarm.startAt() for missed or short remaining delays.


 If memory serves (its been over a year since I looked at that code).

 There is a certain amount of overhead.   And the hardcoded constants are
 there as a result.  I beleive that some of the constants in the Alarm and
 Timer code are to make things work reasonably in the face of the overhead.



 It would have been nice if the original author had bothered to put a
 critical comment in the code to monument what was going on and why the
 constant.


 It's exactly what I could figure out (overhead compensation)...


  The best way to figure out what is happening is to basically single step
 through the code to better understand what is happening.   But that would
 require a msp430 hooked up to a jtag.This is a good way to understand
 things but has a goodly learning curve.


 I can debug my target over a JTAG connection and I'm already familiar with
 on-chip debugging. I can therefore step through my code and see what happens
 at the assembly instruction level. So far so good but IMHO debugging nesC
 code is nevertheless not so comfortable as plain C even if the generated
 app.c can be used. I'll try with other tools such as the Yeti Eclipse plugin
 soon.


 The predominant debugging mechanism for TinyOS is Leds and printf which is
 good as far as it goes.  But to really understand what the code is doing it
 is so much better to actually look at the real code and how it is behaving.
   There is no substitue for in vitro debugging.

 What does your new platform look like?   What CPU?


 My target is a development kit for a new integrated ultra-low power CPU
 developed at Swiss Center for Electronics and Microtechnology called
 icycom. I am currently porting TinyOS to this new CPU architecture and for
 this I start from existing implementations for MSP430 and ATMega128 as
 reference.

 The chip has a 32 bits processor core, standard peripherals (I2C,SPI, RTC,
 timers,...) and an integrated low-power radio in the 868-915MHz band.
 You can have a look at the spec sheet for more details:
 Product note: http://csem.ch/docs/Show.aspx?id=12228
 Technical report: http://csem.ch/docs/Show.aspx?id=12657

 Once the base software will be available, we'll integrate bio-sensors
 developed by another team in our project.

 So I would suggest keeping the constants when you migrate to your new
 hardware.   Then as you are verifing the behaviour of the timing system
 and/or Alarms (part of the clock/timing) take a close look at what is
 happening in the code and what the constants do.   Once you understand what
 is going on then make reasonable changes.   And document the critical
 pieces.

 I like to document stuff for me.   I ask myself,   Self.   Will I
 remember what this is about 6 months from now?   Then I document
 accordingly.

 Eric


 ...
 if( elapsed = dt )
 {
  call Msp430Compare.setEventFromNow(2);
 }
 else
 {
  uint16_t remaining = dt - elapsed;
  if( remaining = 2 )
   call Msp430Compare.setEventFromNow(2);
 ...

 Is there any reason for this 2 cycles delay? Is it simply to take
 account/compensate execution time between the call and the effective
 value setting in compare register ?
 What would be the problem with directly signaling Alarm.fired() in the
 missed delay case ? Since we already missed the delay, don't we add
 some more latency by calling setEventFromNow(2) rather than directly
 signaling ?

 Regards,
   Romain
 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help




 --
 Eric B. Decker
 Senior (over 50 :-) Researcher


 Best regards
  Romain


 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___

Re: [Tinyos-help] rfxlink for Telos

[Vlado Handziski]

On Mon, Apr 18, 2011 at 23:18, Eric Decker cire...@gmail.com wrote:
 That is a good. thing.   On the mm4 mote (2618 based) I have a SD card
that
 is
 driven off of an SPI and I want it to run as fast as possible so I did
 something
 similar.   All the peripherals are run off SMCLK.  In general the SMCLK
 should
 be run as fast as possible.  It is unclear why the original choice of
SMCLK
 = DCO/4
 was chosen.   Maybe Vlado can comment, I'm pretty sure he was there.


I guess there are several reasons for the SMCLK=1MHz decision. First this
config has long tradition in the general msp430 community and TI example
code) and was considered a safe choice for the set of peripheral chips that
we had to support at that time. For example, 500 kHz SPI bus clock is
pushing the limits of the TDA5250 radio on eyesIFX.


 The SFD pin of the CC2420 is connected to pin on the MSP430 that can
 capture timer/counter B but not timer/counter A. Therefore, to be able
 to timestamp with the microsecond clock, timer B must be clocked at
 1uis, and timer A should be programmed as the 32kHz clock. (Currently,
 timer A is running at 1uis, and timer B at 32kHz.)


 One potential difference from the original clock setup is that in this
 case we are left with only 3 timer compare interfaces for the
 32khz/1mis clocks, versus 7 in the original case.

 Actually, putting the 1mis clock on TimerA gives 3 CCRs and the 1uis clock
 on TimerB gives 7 CCRs for the uis clock.

 But since the 1mis
 clock is virtualized, this should not be a limitation.

 In practice the additonal compare capture registers aren't utilized.   If
 they do get
 used it is a special app that needs to handle the situation itself.

There are many platform-specific telosB applications out there that use more
than three jiffy alarms, so I would be very careful with going down this
road only because of the way the CC2420 SFD is wired or not wired to the MCU
on a given platform.

Vlado
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] [Tinyos-devel] Dirty bit reset

[Vlado Handziski]

Hi,

the dirty bit is an optimization mechanism that helps avoid
unnecessary re-computation of the lowest safe power state of the MCU. In
most of the current implementations, this computation is quick and the bit
is assumed to be always TRUE, i.e. the low power state is recomputed every
time the MCU can go to sleep. That is why you don't see it being reset in
the existing McuSleep.sleep() implementations.

Vlado

P.S. Please don't cross-post to -devel even if you don't get an quick answer
on -help :)


On Mon, Nov 29, 2010 at 08:50, Romain Bornet bornet.r...@gmail.com wrote:

 Hi all,

 I'm rather new in TinyOS and I'm currently working on a port to a new
 architecture and am therefore carefully reading TEPs and intensively looking
 into other architectures implementations.

 I cannot understand the handling of the dirty bit used in power
 management. The dirty bit mechanism is described in TEP112 (
 http://www.tinyos.net/tinyos-2.1.0/doc/html/tep112.html) section 3.1 but I
 could not find in TOS sources where this flag is reset !

 I could see that the flag is set to 1 or TRUE for some MCUs in chips
 directory but could not find any place in the whole sources where this flag
 gets reset ?... (some cale in msp430/McuSleepC.nc have a commented '// dirty
 = 0' in McuSleep.sleep()

 - Is this flag really useful and used in TinyOS 2.1 ?
 - If yes, how/when should this flag be reset ?

 I posted without any success to the help list a week ago so perhaps I will
 be luckier in the devel list.

 Thanks for any hint and see you !
   Romain



 ___
 Tinyos-devel mailing list
 tinyos-de...@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel


___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Timer precision problem during proting to platform

[Vlado Handziski]

On Tue, Mar 16, 2010 at 23:50, Attila Strba st...@yahoo.com wrote:

 Hi Vlado,
 as far as I read the source and underestood the TEP's right the tag has no
 influence on the transofrmation calculation right? It just makes sure the
 timer conversion types does not get mixed ?


Yes, but TMicro is a confusing name for something that is 1/16us.


 The clock source is the 16MHz XTAL oscillator driving the miccrocontroller
 so I guess metric. After 65535 tackts wraps around and 1 tick takes 1/16us.
 To be honest I don't underestand how could be a microcontroller clock source
 be binary.


What I mean is when you say 1MHz this can be 1 * 1000 * 1000 ticks per
second or 1 * 1024 * 1024. When we say that the clock source has 1MHz in
tinyos, it means the later. I.e. all units are binary, i.e. 1 second has
1024 binary milliseconds.


 Any more idea where I could look for problems?


No, sorry. I guess you will have to debug this with a scope and toggling a
pin in the fire events of the alarms in the transform components.

Vlado


 thanx a lot for the help Vlado,

 greetings

 Attila



 --
 *From:* Vlado Handziski handz...@tkn.tu-berlin.de
 *To:* Attila Strba st...@yahoo.com
 *Cc:* tinyos-help@millennium.berkeley.edu
 *Sent:* Tue, March 16, 2010 5:23:56 PM

 *Subject:* Re: [Tinyos-help] Timer precision problem during proting to
 platform

 If you like to export a 16MHz timer, the TMicro precision tag is not
 appropriate. You can use T16mhz (just like we have T32khz) for this
 particular prescaler, or TOne, etc. like in the atm128 when the prescaler is
 not fixed. Is this a binary 16MHz clock source or metric? TinyOS is always
 using binary units. The transforms with the 14 bit-shift look correct to me.

 Vlado


 On Tue, Mar 16, 2010 at 08:26, Attila Strba st...@yahoo.com wrote:

 Hi Vlado,
 thanks for the mail it helped a lot. I implemented this the following way
 like described but the TimerMilli was doing random periodes. For example I
 tried to get a fire every 1ms and I got it for every 700us. I think my  HPL
 works fine, because if I use the HPL component as separate I can get correct
 fire events. But when I go through all the transformation it behaves
 strange.

 For sure I am doing something wrong. Just to make sure I underestand you
 right, could you please confirm my steps?

 *Steps:*

 - I create a HPL for the timer where 1 tick has 1/16=0,0625us
 - I provide an alarm, counter interface in HPL following way
provides interface Counter TMicro, uint16_t as Counter
provides interface Alarm TMicro, uint16_t as Alarm[
 uint8_t id ];
 - the counter signalises overflow in 4.096ms = (65536 ticks)
 - the alarm is implemented using the compare register, and the fire event
 is the compare match with the counter
 - I transform the counter to 32bit 1ms counter following way, 2^14 ticks =
 16384 * 0.0625 = 1024 which is aprox. 1ms

 *CounterMilli32C.nc:*
 components CounterMicro16C as CounterFrom;
 components new
 TransformCounterC(TMilli,uint32_t,TMicro,uint16_t,14,uint32_t) as Transform;

   Counter = Transform.Counter;
   Transform.CounterFrom - CounterFrom;

 - I transform the alarm to 32bit 1ms counter following way, 14: 2^14 ticks
 = 16384 * 0.0625 = 1024 which is aprox. 1ms
 *AlarmMilli32C.nc:*
   components new AlarmMicro16C() as AlarmFrom;
   components CounterMilli32C as Counter;
   components new TransformAlarmC(TMilli,uint32_t,TMicro,uint16_t,14) as
 Transform;

Init = AlarmFrom;
Alarm = Transform;
Transform.AlarmFrom - AlarmFrom;
Transform.Counter - Counter;

 - I provide both AlarmMilli32C and CounterMilli32C to HilTimerMilliC.ncso I 
 can use the TimerMilli interface for timing:
 *HilTimerMilliC.nc:*
 components new AlarmMilli32C();
 components new AlarmToTimerC(TMilli);
 components new VirtualizeTimerC(TMilli,uniqueCount(UQ_TIMER_MILLI));

 Init = AlarmMilli32C;
 TimerMilli = VirtualizeTimerC;

 VirtualizeTimerC.TimerFrom - AlarmToTimerC;
 AlarmToTimerC.Alarm - AlarmMilli32C;

 Thank you very much for the help,
 greetings
 Attila

 --
 *From:* Vlado Handziski handz...@tkn.tu-berlin.de
 *To:* Attila Strba st...@yahoo.com
 *Cc:* tinyos-help@millennium.berkeley.edu
 *Sent:* Tue, March 16, 2010 3:46:07 AM
 *Subject:* Re: [Tinyos-help] Timer precision problem during proting to
 platform

 On Sun, Mar 14, 2010 at 23:50, Attila Strba st...@yahoo.com wrote:

 Hi Guys,


 I am trying to port the TinyOS to the Dolphin EO3000I chip from EnOcean
 and I have a poblem with the Timer precission.

 As I read from the TEP 102, it is written that the HLP timer interface
 should provide either 32kHz or 1ms or 1us tick precision. The Dolphin runs
 on 16MHz clock. The Timer0 I am trying to use is 16bit, uses the same clock
 source and it has the possibility to use either 2,4,8 prescaler. But that's
 all, so in best case using prescaler 8 I would get 0.5us pro 1 tick.



 The TEP 102 is only specifying how the HIL

Re: [Tinyos-help] Timer precision problem during proting to platform

[Vlado Handziski]

If you like to export a 16MHz timer, the TMicro precision tag is not
appropriate. You can use T16mhz (just like we have T32khz) for this
particular prescaler, or TOne, etc. like in the atm128 when the prescaler is
not fixed. Is this a binary 16MHz clock source or metric? TinyOS is always
using binary units. The transforms with the 14 bit-shift look correct to me.

Vlado


On Tue, Mar 16, 2010 at 08:26, Attila Strba st...@yahoo.com wrote:

 Hi Vlado,
 thanks for the mail it helped a lot. I implemented this the following way
 like described but the TimerMilli was doing random periodes. For example I
 tried to get a fire every 1ms and I got it for every 700us. I think my  HPL
 works fine, because if I use the HPL component as separate I can get correct
 fire events. But when I go through all the transformation it behaves
 strange.

 For sure I am doing something wrong. Just to make sure I underestand you
 right, could you please confirm my steps?

 *Steps:*

 - I create a HPL for the timer where 1 tick has 1/16=0,0625us
 - I provide an alarm, counter interface in HPL following way
provides interface Counter TMicro, uint16_t as Counter
provides interface Alarm TMicro, uint16_t as Alarm[
 uint8_t id ];
 - the counter signalises overflow in 4.096ms = (65536 ticks)
 - the alarm is implemented using the compare register, and the fire event
 is the compare match with the counter
 - I transform the counter to 32bit 1ms counter following way, 2^14 ticks =
 16384 * 0.0625 = 1024 which is aprox. 1ms

 *CounterMilli32C.nc:*
 components CounterMicro16C as CounterFrom;
 components new
 TransformCounterC(TMilli,uint32_t,TMicro,uint16_t,14,uint32_t) as Transform;

   Counter = Transform.Counter;
   Transform.CounterFrom - CounterFrom;

 - I transform the alarm to 32bit 1ms counter following way, 14: 2^14 ticks
 = 16384 * 0.0625 = 1024 which is aprox. 1ms
 *AlarmMilli32C.nc:*
   components new AlarmMicro16C() as AlarmFrom;
   components CounterMilli32C as Counter;
   components new TransformAlarmC(TMilli,uint32_t,TMicro,uint16_t,14) as
 Transform;

Init = AlarmFrom;
Alarm = Transform;
Transform.AlarmFrom - AlarmFrom;
Transform.Counter - Counter;

 - I provide both AlarmMilli32C and CounterMilli32C to HilTimerMilliC.nc so
 I can use the TimerMilli interface for timing:
 *HilTimerMilliC.nc:*
 components new AlarmMilli32C();
 components new AlarmToTimerC(TMilli);
 components new VirtualizeTimerC(TMilli,uniqueCount(UQ_TIMER_MILLI));

 Init = AlarmMilli32C;
 TimerMilli = VirtualizeTimerC;

 VirtualizeTimerC.TimerFrom - AlarmToTimerC;
 AlarmToTimerC.Alarm - AlarmMilli32C;

 Thank you very much for the help,
 greetings
 Attila

 --
 *From:* Vlado Handziski handz...@tkn.tu-berlin.de
 *To:* Attila Strba st...@yahoo.com
 *Cc:* tinyos-help@millennium.berkeley.edu
 *Sent:* Tue, March 16, 2010 3:46:07 AM
 *Subject:* Re: [Tinyos-help] Timer precision problem during proting to
 platform

 On Sun, Mar 14, 2010 at 23:50, Attila Strba st...@yahoo.com wrote:

 Hi Guys,


 I am trying to port the TinyOS to the Dolphin EO3000I chip from EnOcean
 and I have a poblem with the Timer precission.

 As I read from the TEP 102, it is written that the HLP timer interface
 should provide either 32kHz or 1ms or 1us tick precision. The Dolphin runs
 on 16MHz clock. The Timer0 I am trying to use is 16bit, uses the same clock
 source and it has the possibility to use either 2,4,8 prescaler. But that's
 all, so in best case using prescaler 8 I would get 0.5us pro 1 tick.



 The TEP 102 is only specifying how the HIL _must_ look, and provides
 examples how the lib/timer components can be used to build a flexible HAL
 layer. The HPL component interfaces are fully driven by the hardware
 characteristics, so you can do whatever you like there.


 My question is what to do with this? I am far away from the values TEP102
 considers. The transformation components are only for the width adjustment
 right? (i.e. TransformAlarmC).
 Or should I manually adjust the values I get through the HPL interface
  using constants (multiplication of the input values by 2) such way that I
 get 1us interface?


 My suggestion is to expose the maximal precision on HPL and as
 Counters/Alarms on HAL level and then use TransformAlarmC which also
 transforms precision (to a lower one) to provide the HIL.

 Vlado



 Any help is highly apritiated,

 greetings

 Attila




 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help




___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Timer precision problem during proting to platform

[Vlado Handziski]

On Sun, Mar 14, 2010 at 23:50, Attila Strba st...@yahoo.com wrote:

 Hi Guys,


 I am trying to port the TinyOS to the Dolphin EO3000I chip from EnOcean and
 I have a poblem with the Timer precission.

 As I read from the TEP 102, it is written that the HLP timer interface
 should provide either 32kHz or 1ms or 1us tick precision. The Dolphin runs
 on 16MHz clock. The Timer0 I am trying to use is 16bit, uses the same clock
 source and it has the possibility to use either 2,4,8 prescaler. But that's
 all, so in best case using prescaler 8 I would get 0.5us pro 1 tick.



The TEP 102 is only specifying how the HIL _must_ look, and provides
examples how the lib/timer components can be used to build a flexible HAL
layer. The HPL component interfaces are fully driven by the hardware
characteristics, so you can do whatever you like there.


 My question is what to do with this? I am far away from the values TEP102
 considers. The transformation components are only for the width adjustment
 right? (i.e. TransformAlarmC).
 Or should I manually adjust the values I get through the HPL interface
  using constants (multiplication of the input values by 2) such way that I
 get 1us interface?


My suggestion is to expose the maximal precision on HPL and as
Counters/Alarms on HAL level and then use TransformAlarmC which also
transforms precision (to a lower one) to provide the HIL.

Vlado



 Any help is highly apritiated,

 greetings

 Attila




 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Howto patch msp430-gcc to accept $ as names?

[Vlado Handziski]

As long as you use a recent nesC release, and work from the top of the cvs
tree, you don't need a patched binutils anymore. The default nesc separator
has been changed to __.

Vlado


On Fri, Nov 6, 2009 at 20:42, Till Maas opensou...@till.name wrote:

 Hi again,

 On Fri, Nov 06, 2009 at 07:54:14PM +0100, Till Maas wrote:

  I would like to use the msp430-gcc shipped with Fedora to compile TinyOS
  applications, but gcc does not acccept $ within names. Eric Decker made
  me aware of this in another mail[0], but there was no hint of how to do
  this.

 sorry for the noise. It's actually binutils that needs to be patched and
 I accidently found the patch:

 http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-1.x/contrib/eyes/tools/patches/binutils/binutils-2.14_dollar.patch?revision=1.1view=markup

 Nevertheless I do not know yet, why it is not included in upstream, I
 only found good feedback so far:
 http://article.gmane.org/gmane.comp.gnu.binutils/32294/match=tinyos+msp430

 Regards
 Till

 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] compiling TinyOS with differente MSPGCC versions

[Vlado Handziski]

On Thu, Oct 29, 2009 at 12:41, Antonio Rosa
antoniorosarodrig...@gmail.comwrote:


 Following the instructions on the website discussed above, is achieved by
 properly installing the toolchain msp430X, what happens that as we are
 going
 to use from TinyOS, which is implemented in NESC should be performed some
 simple modifications to adapt the differences existing between the GCC
 Toolchain and ncc of TinyOS.
 In particular the modification to make is to add in the file located in the
 directory:
 /opt/mspgcc/sf/packaging/build/binutils-2.18/gas/config/tc-msp430.h
 in  the “#define LEX_DOLLAR 0”
 the following line:
#undef LEX_DOLLAR

 The reason for adding this line of code is because there is a historical
 error due to GCC and NESC, NESC used as the separator $ and the GCC
 compiler does not recognize it, then in order to adjust the toolchain and
 not give msp430x build problems with TinyOS (uses language NESC).
 But in order to this change becomes effective, it must be done before
 running the command CC = gcc-3.4 make build . Therefore we must modify the
 makefile in the directory /opt/mspgcc/sf/packaging.

 In order to make this change, I downloaded the file tc-MSP430, added the
 modification explained above, saved that file in /opt/mspgcc and finally
 added these two commands in the makefile just before applying the patches
 to
 binutils-2.18 :

 rm-r / opt/mspgcc/sf/packaging/build/binutils-2.18/gas/config/tc-msp430.h
 cp-r / opt/mspgcc/tc-msp430.h /
 opt/mspgcc/sf/packaging/build/binutils-2.18/gas/config/tc-msp430.h


As long as you are using nesC that is more recent than 1.2.9, you don't have
to do any patching, just add -fnesc-separator=__ to PFLAGS. BTW this will be
the default in the next release.

Vlado
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] what is the right way to handle different msp430 processors

[Vlado Handziski]

It was an early decision of the Core WG that we will keep the chip directory
flat until we have enough clutter there that would necessitate a
hierarchical model like we have for the platforms (with the .family). So
currently this should be handled in the same way as atm128/atm1281, i.e.
with a new msp430X subdir in parallel to the msp430. A platform can then
cherry pick chip abstractions and regulate the shadowing in its .platform
file.

Vlado


On Thu, Oct 15, 2009 at 23:31, Eric Decker cire...@gmail.com wrote:


 With the advent of the 26xx and 54xx series chips there are a number of
 differences and not everything falls cleanly under the umbrella of the
 msp430 structure.

 How should this get handled?

 Does the way it is done in the dexma code (contrib/dexma/tos/chips/msp430X)
 take care of it?

 Basically they define pieces of the msp430 as chunks and each chunk shows
 up.  This forces
 the developer to understand what pieces get pulled in by the platform.

 My concern though is how much of this propagates though the rest of the
 system.  The chip/processor
 dependent stuff should all get invoked via the platform files.  Not sure if
 that is the case.

 thoughts?

 --
 Eric B. Decker
 Senior (over 50 :-) Researcher



___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Packet Sniffer 802.15.4 problem

[Vlado Handziski]

Hi Emanuele,

the sniffer code in contrib has not been updated to match the recent changes
in the CC2420 driver. We currently don't have plans to further maintain that
part of the code.  Essentially the apps/BaseStation15.4 in the main tree
should be used instead, but it lacks channel switching support at the
moment. The wireshark dissectors should still be ok.

Vlado


On Tue, Sep 15, 2009 at 14:01, Emanuele Toscano tos...@gmail.com wrote:

 Hi to everyone,
 I'm trying to install the PacketSniffer_802_15_4 from
 /tinyos-2.x-contrib/tub but I'm having some problems.
 I'm using the Xubuntos distro in a VMware virtual machine. I installed
 both the tinyos-2.x and tinyos-2.x-contrib projects from CVS and
 edited the .bash_tinyos, so that I'm able to compile the apps in the
 tinyos-2.x/apps folder.
 However, when I go in the
 tinyos-2.x-contrib/tub/apps/PacketSniffer_802_15_4 folder and
 execute the make telosb install command, I receive the following
 error:

 mkdir -p build/telosb
compiling Sniff802154C to a telosb binary
 ncc -o build/telosb/main.exe  -Os -O -mdisable-hwmul -Wall -Wshadow
 -Wnesc-all -target=telosb -fnesc-cfile=build/telosb/app.c -board=
 -DDEFINED_TOS_AM_GROUP=0x22 -DTOSH_DATA_LENGTH=128
 -DCC2420_NO_ACKNOWLEDGEMENT -DCC2420_NO_ADDRESS_RECOGNITION
 -DIDENT_PROGRAM_NAME=\Sniff802154C\ -DIDENT_USER_ID=\xubuntos\
 -DIDENT_HOSTNAME=\xubuntos-tinyos\ -DIDENT_USER_HASH=0x00f95284L
 -DIDENT_UNIX_TIME=0x4aaf7e09L -DIDENT_UID_HASH=0xa8bff954L
 Sniff802154C.nc -lm
 In file included from
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveC.nc:50,
 from Sniff802154C.nc:5:
 In component `CC2420ReceiveP':
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc:65:
 syntax error before `T32khz'
 In file included from
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveC.nc:50,
 from Sniff802154C.nc:5:
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc:
 In function `RXFIFO.readDone':
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc:624:
 `PacketTimeStamp' undeclared (first use in this function)
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc:624:
 (Each undeclared identifier is reported only once
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc:624:
 for each function it appears in.)
 In file included from
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveC.nc:51,
 from Sniff802154C.nc:5:
 In component `CC2420PacketC':
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketC.nc: At
 top level:
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketC.nc:46:
 syntax error before `T32khz'
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketC.nc:47:
 syntax error before `TMilli'
 In file included from
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketC.nc:54,
 from
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveC.nc:51,
 from Sniff802154C.nc:5:
 In component `CC2420PacketP':
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc:51:
 syntax error before `T32khz'
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc:52:
 syntax error before `TMilli'
 In file included from
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketC.nc:54,
 from
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveC.nc:51,
 from Sniff802154C.nc:5:
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc:130:
 unknown interface `PacketTimeStamp32khz'
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc:135:
 unknown interface `PacketTimeStamp32khz'
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc:140:
 unknown interface `PacketTimeStamp32khz'
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc:146:
 unknown interface `PacketTimeStamp32khz'
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc:154:
 unknown interface `PacketTimeStampMilli'
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc: In
 function `PacketTimeStampMilli.isValid':
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc:155:
 `PacketTimeStamp32khz' undeclared (first use in this function)
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc: At
 top level:
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc:161:
 unknown interface `PacketTimeStampMilli'
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc: In
 function `PacketTimeStampMilli.timestamp':
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc:162:
 `PacketTimeStamp32khz' undeclared (first use in this function)
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc: At
 top level:
 /home/xubuntos/tinyos-2.x/tos/chips/cc2420/packet/CC2420PacketP.nc:168:
 unknown interface 

Re: [Tinyos-help] TinyOS SerialForwarder with SHIMMER programming dock

[Vlado Handziski]

What version of the USB-dock do you have? The original version did not have
a pass-through for the serial lines, i.e. you could not use a Shimmer in the
dock as BaseStation.

Vlado


On Sun, May 24, 2009 at 18:30, Martin Kjeldsen kjeld...@gmail.com wrote:

 Hi everyone,

 I've done some testing on the tinyos BaseStation app and why i can't get it
 to work with the tinyOS SerialForwarder on a SHIMMER in a shimmer
 USB-programming dock. First, i checked the BaseStation nesC src and found :

 * pThe LEDS are programmed to toggle as follows:/p
 * ul
 * libRED Toggle:/b: Message bridged from serial to radio/li
 * libGREEN Toggle:/b Message bridged from radio to serial/li
 * libYELLOW/BLUE Toggle:/b Dropped message due to queue overflow in
 either direction/li
 * /ul

 *None *of these events happens when i forward packets via the
 SerialForwarder, so initial conclusions were that:

 * The is either something wrong with the TinyOS serial forwarder, in terms
 of being unable to forward packets to the specified address. ( I can install
 applications to motes just fine using the same serial address i define in
 this SF.)
 * Or ... the BaseStation application was not properly flashed or is simply
 not working?
 * Or.. Hardware issues.

 I've now modified the BaseStation app to BaseStation-prime which uses the
 leds to toggle all representations of primes on 3 bit - a modification of
 /apps/Blink - to give me an idea of nesC programming, and to test if the
 BaseStation app was even live. This works fine! The basestation is now
 happily blinking primes. When i run the SPINE test application at this
 point, the following happens:

 * SerialForwader registers a client connection (The test application) and
 attempts to forward the packet to serial@/dev/ttyUSB0
 * The basestation stops blinking! Apparently something has happened to the
 running application on the shimmer.
 * Write fails (as before)

 From this point on, If i take the shimmer out of its programming dock, it
 starts blinking again, and if i insert it back into the dock, it stops. Most
 peculiar. I have simply added some timers to the BaseStation app, so that
 shouldnt have any effect on communication. But the behavior is consistent
 with before.

 Can anyone shed some light on this? Anyone with similar experiences?
 Thanks in advance!

 Kind regards,
 Martin
 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Fw: Re: for Tinyos 2.x bugs...

[Vlado Handziski]

Hi,

please post here more details about the problem and your patch.

Vlado

2009/1/31 이기섭 gs...@hallym.ac.kr

 Dear tinyos-help

 Could you receive the fixed file for the problem which is described below
 and update it into the tinyos project?

 K.S.Lee


 - Original Message -
 *From:* Philip Levis p...@cs.stanford.edu
 *To:* 이기섭 gs...@hallym.ac.kr
 *Cc:* cssh...@eecs.berkeley.edu, Vlado Handziski 
 handz...@tkn.tu-berlin.de, Joe Polastre polas...@cs.berkeley.edu
 *Sent:* 2009/01/31 13:49
 *Subject:* Re: for Tinyos 2.x bugs...


 On Jan 30, 2009, at 8:05 PM, Joe Polastre wrote:

  please contact Phil Levis, p...@cs.stanford.edu
 
  Best,
  -Joe
 
  On Fri, Jan 30, 2009 at 7:39 PM, 이기섭 gs...@hallym.ac.kr wrote:
 
  Dear Joe Polastre , Cory Sharp and Vlado Handziski,
 
  I had developed our system with tinyos-2.x on last year.
  I found the bug in tinyos-2.0 source code for MSP430 PLL problem
  at power
  up.
 
  I think the recent version does not fix this problem. If sink mote
  will be
  used
  with unstable DC power supply, it can be operated incorrectly on
  RS232 bit
  rate.
  Thus the gateway which is located upper layer of sink mote can not
  receive
  uploading packet.
  Now, the unstable DC power supply is only meaning which rising
  slop on
  power-on
  is low.
 
  Could I send a file which was fixed for this problem?
  in the Tinyos.net site, the bug report menu is not operating now.
  And the e-mail accounts which is cssharp and handzisk are not
  response .
 
  Yours sincerely,
  K.S.Lee


 K.S.,

 Better yet, please email tinyos-help!

 Phil


 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] [Tinyos-devel] two zigbee implementations

[Vlado Handziski]

The answer is yes, to both questions :)

Vlado

On Wed, Jul 9, 2008 at 5:51 PM, Stefano Kismet Lenzi [EMAIL PROTECTED]
wrote:

 Vlado as you can see I moved the thread to help mailing-list, I hope
 that you can answer me now :)

 On Wed, Jul 9, 2008 at 16:26, Jó Ágila Bitsch Link
 [EMAIL PROTECTED] wrote:
 
 
  On Wed, Jul 9, 2008 at 4:20 PM, Stefano Kismet Lenzi kismet.sl@
 gmail.com
  wrote:
 
  On Wed, Jul 9, 2008 at 09:56, Vlado Handziski 
 [EMAIL PROTECTED]
  wrote:
   To be precise, we (TUB) have only developed a standard compliant
   802.15.4
   MAC called TKN154. So we have two 802.15.4 MAC implementations and
 only
   one
   Zigbee.
  
   Back in the days when the net2 group has been formed we had a long
   discussion about the point in the protocol stack where the
   responsibilities
   of core should end and where net2 should take over. We came to a
   reasonable
   conclusion that MAC implementations should remain in core due to the
   tight
   interdependence with the radio chip and timer HW abstractions. I think
   practice has proven that this was a good decision because it helped
   shield
   net2 from the changes we did in core.
  
   Now that we have a proper place in the code tree for different mac
   implementations (tos/lib/mac)
 
  Which place did you mean? I have just performed an updated and I
  couldn't find any /tos/lib/mac folder.
 
  Did you use cvs update -d
  The -d flag is necessary to also get newly created directories (Why
  again does tinyos development stick with cvs?)

 No I forgot it :S, Now I found the folder

 But the following questions continue to be open:

  - The Porto's zigbee that you are speaking about is the one available
 in the /tos/lib/net/zigbee folder?
  - Is the IEEE 802.15.4 MAC implemented by Porto the one available in
 /tos/lib/net/zigbee/ieee802154 folder?

 
 
  I think that the right way to proceed is for
   Porto to factor out the MAC part of their implementation and move it
   into
   this folder, at the same time transferring the responsibility for this
   code
   from net2 to core. To this end, a representative of Porto might join
   core,
   etc.  This is completely independent from the decision if the higher
   parts
   of Porto's zigbee implementation remain in net2 or a new WG is formed
 as
   Matt proposed.
 
  The Porto's zigbee that you are speaking about is the one available in
  the /tos/lib/net/zigbee folder?
 
  But I think that the standard compliant IEEE 802.15.4 MAC
   implementations should remain under core for the above stated reasons.
 
  Where is the IEEE 802.15.4 MAC located?
 
  
   Vlado
  
 
 
  Thank you,
  Stefano Lenzi
  ___
  Tinyos-devel mailing list
  [EMAIL PROTECTED]
 
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
 
 

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Is anyone working on repairing msp430 Msp430DcoCalibP

[Vlado Handziski]

The periodic recalibration will be fixed once TimerA on the msp430 is
properly arbitrated. There is a lot of code that has to be updated after
this change, so we are deferring this for after the 2.1 release. For the
time being, the DCO is calibrated only once on booting, which seems to be
enough for many applications, especially if you are using a Tmote Sky with a
Rosc.

Vlado

On Wed, May 21, 2008 at 2:50 PM, Alexandre Buist [EMAIL PROTECTED]
wrote:

  *#error* Msp430DcoCalibP is broken and will incorrectly adjust TimerA
 because it does not take into account MCU sleep.

 * *

 *Is anyone working on it?*

 *Does anyone knows how this should be fixed?*

 * *

 *Alex***

 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Serial Communication as DTE

[Vlado Handziski]

TUB has never officially maintained that code. AR were the last responsible
party as far as I can remember. Those last edits from us are probably
related to the union based configuration implementation.

Vlado

On Fri, May 16, 2008 at 5:30 PM, Philip Levis [EMAIL PROTECTED] wrote:


 On May 16, 2008, at 2:31 AM, Christopher Schwardt wrote:



 I tried to find out what happens, when I call start() on the
 SplitControl (which is the only thing that gets called in our
 SerialInit.init()). The SplitControl turns out to be wired to a
 StdControl in our SerialProtoP. This again is wired to our
 PlatformSerialC, that says StdControl = TelosSerialP, so TelosSerialP
 implements the start() method. But the TelosSerialP StdControl.start()
 implementation only calls Resource.immediateRequest().


 Hunh -- TelosSerialP seems to have a bunch of issues, including no
 copyright or author contact information!

 Vlado, it looks like this is your file, and Philipp is the most recent
 editor of the file.

 Phil

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] SplitControlPowerManagerC not checking errors (BUG?)

[Vlado Handziski]

This is where the modular architecture of the power locks comes to play. I
think that the vanilla SplitControlPowerManager should retain a simple
policy of either ignoring the FAIL events / not releasing the resource to
the requester until it is sure that the device is on (a new request should
result in a new retry by the PM to start the device, etc.) That being said,
nothing prevent us from adding new policy in the form of a
RetryingXXXPowerManager that contains logic (either an endless task loop or
give up after N, etc.) to handle the retrying on behalf of the requester, so
whenever the grant is issued it is guaranteed that the device is on.

Vlado

On Thu, May 1, 2008 at 10:05 PM, Kevin Klues [EMAIL PROTECTED] wrote:

 Agreed, but what do you propose as an alternative then?  The only one
 I see is potentially exporting a new interface that a user can wire to
 that lets them decide what should be done in the case of a failure.
 Or maybe run in the loop a fixed number of times before giving up and
 passing through as if it had suceeded (possibly also signaling an
 event of some sort taht something went terribly wrong).

 Kevin

 On Thu, May 1, 2008 at 12:59 PM, Philip Levis [EMAIL PROTECTED] wrote:
 
   On May 1, 2008, at 12:03 PM, Kevin Klues wrote:
 
   As the code currently is, you're right, if start or stop ever fails,
   then there is a chance for lock up.  Doing a task repost after
   checking return conditions shuld fix this problem.  As you say though,
   if FAIL is returned indefinitely, then the task will be reposted
   forever, but then again you've got other problems if FAIL is
   perpetually being returned when trying to start or stop a device.
   I'll check in the fix.
  
 
   I don't think a spinning task loop is a good fix; it means that if a
 driver
  ever fails, the MCU will not enter a low power state.
 
   Phil
 



 --
 ~Kevin
 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] [Tinyos-devel] AM ID guidelines for net2 protocols and other applications

[Vlado Handziski]

On Wed, Apr 30, 2008 at 6:52 PM, Matt Welsh [EMAIL PROTECTED] wrote:

 I think we're on the same page here but there are some details to work
 out.

 Anything in tos could be assigned an AM ID range by the net2 WG. The
 question is how do things move from contrib, apps, etc. to tos?
 An example might be a new timesync protocol that someone develops and
 wants to be part of the official release (by which I mean, in tos).
 There needs to be a clear way for someone to (a) get their code in
 there and (b) get the AM IDs assigned for it. Being a member of the
 net2 WG is one way to do that, but I would hope there are other
 avenues that permit inclusion of third-party protocols as part of the
 standard tree.


The current policy on this is that code should move into the core only via
the TEP process. The TEPs are reviewed by the corresponding WGs, but anyone
in the community is free to write a TEP and submit it for review.

Vlado
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] msp430 tinyos patch

[Vlado Handziski]

With the introduction of the - -fnesc-separator option since nesC
1.2.8, the old $ patching of the msp430 tools is technically not
needed anymore. No additional tinyos specific modifications to the
toolchain are necessary either.

Vlado

On Mon, Apr 14, 2008 at 6:42 PM, Xavier Orduña [EMAIL PROTECTED] wrote:
 Hi!

 I'm porting tinyos to the new msp430F2x1x. I've already compiled the msp-gcc
 to support the new microcontroller families but after trying to compile some
 applications generated by nesC I found that the symbol $ is added.

 After looking a while I've detected that distributed versions of msp-gcc
 found in http://www.tinyos.net/dist-1.2.0/tools/ have been already patched
 to support some changes introduced by nesC.

 Where I can find more documentation about changes made to msp-gcc to make
 more easy the adaptation to fully suport the new families?

 Thanks

 Xavi

 --
 www.alcim.net
  Buscant sempre nous reptes, alguna proposta?
 ___
  Tinyos-help mailing list
  Tinyos-help@millennium.berkeley.edu
  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

[Vlado Handziski]

The access to the refvolt generator has to be properly arbitrated between
the ADC and the DAC. Pins, timers, etc. are all potential shared resource
between the two. Jan, who is responsible for the msp430 ADC stack, is at a
project meeting and probably has not read the thread. Please get in touch
with him to coordinate. No #ifdefs please :)

Vlado

On Wed, Feb 13, 2008 at 6:43 PM, John Griessen [EMAIL PROTECTED] wrote:

 Sandip Bapat wrote:

  a DAC module would either have to wire to Msp430RefVoltArbiterP (in which
 case it also has to provide the

 AdcConfigure interface) or be expected to provide wiring for these
 interfaces.

 This is fine for apps that just want to use the DAC and not ADC but what
 if both are used and the

 ADC is already using Ref Voltage ? I guess we could use #ifdefs in the DAC
 but wouldn't having

 a Msp430RefVoltArbiterC that does the wirings required for
 Msp430RefVoltGeneratorP be better?

 The best thing would be to create new function in the RefVoltArbiter so it
 can stay on after an ADC12 or
 Dac12 call has requested it if another request is heard within a time
 period.  As far as I can tell,
 Dac12 and Adc12 of a MSP430F1611 can both be going at once.

 John Griessen

 --
 Ecosensory   Austin TX
 tinyOS devel on:  ubuntu Linux;   tinyOS v2.0.2;   telosb ecosens1
 ___
 Tinyos-devel mailing list
 [EMAIL PROTECTED]
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel



___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Re: [Tinyos-devel] CTP + LPL

[Vlado Handziski]

I fully agree, and the question is not philosophical.  The TinyOS HAA
defines two well-defined taping points for the application into the driver
code: the HAL and the HIL level. Consequently, the public interfaces at both
the HAL and the HIL level have to be documented and accepted through the TEP
process before becoming part of the core.

As long as the proposed change is a part of the HAL level CC2440 public
interface, the above rule applies.

On the technical side, historically we have been very conservative in
exporting signals from the radio stack that can bring the stack to a halt if
misused. In TinyOS 1.x there was a similar event used for time
synchronization that caused a lot of problems because ignorant users were
attaching long running operations to it.

Vlado


On Fri, Feb 8, 2008 at 8:41 PM, Matt Welsh [EMAIL PROTECTED] wrote:

 One of the interesting aspects of NesC is that it doesn't enforce any
 specific kind of encapsulation of interfaces. That is, an application
 component can poke through the various layers below it to get at an
 interface provided by a deeper underlying component. In this case you
 propose to provide a CC2420-specific signal when a message is about to
 be transmitted. I don't see a problem with that but I am concerned
 about the divergence of the implementation from the TEP, and what it
 means for layering in general (for example, above other, non-CC2420
 radio stacks).

 One of the oft-mentioned problems for non-core developers is that
 changes like this are introduced without being well-documented,
 leading to a tangled mess of interfaces, and potentially unexpected
 behaviors. My understanding was that the TEP process was intended to
 reign in that sort of volatility, no matter how expedient the change
 might be. So I guess this comes down to a more philosophical question
 of which changes to a core system component require vetting through
 the TEP process and which do not.



 On Feb 7, 2008, at 7:13 PM, Philip Levis wrote:

 
  On Feb 7, 2008, at 6:00 AM, David Moss wrote:
 
  Matt and Phil -
 
  This is meant to serve only as a private interface within the
  CC2420 stack
  right now, not an interface provided by the ActiveMessage façade.
  After
  all, once the interface is provided by ActiveMessage, it is no
  longer a
  private CC2420-specific interface.
 
  This is absolutely not a CTP or MultiHop protocol changing
  interface, since
  that would make those libraries platform dependent, which is bad.
  This is
  also not an LPL interface. Rather, the point of this interface is
  to simply
  signal an event at the top of the stack that says the radio is
  sending a
  message. Your application can do what it wants with that event.
 
  For developers who want CTP + LPL on a CC2420 platform, this single
  notification event gives them the ability to make it happen *right
  now*
  without modifying any libraries.  No modifications to CTP, no
  modifications
  to LPL, no modifications to the radio stack, and nearly 0 cost.
 
  You're correct: we should document this interface in the CC2420
  TEP, or add
  this to some other TEP to standardize it across radio stacks.  A
  second
  direction would be to continue adding onto the LowPowerListening
  interface
  to make each outbound message use your local LPL settings, but I
  would be
  hesitant to make those kinds of changes without a lot of backing.
 
 
 
  Oh, I think I misunderstood. I thought you were suggesting a change
  to the CTP code in CVS.
 
  Phil


 ___
 Tinyos-devel mailing list
 [EMAIL PROTECTED]
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel



___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Re: Problems with tinyos-1.x vs. 2.x

[Vlado Handziski]

On Dec 17, 2007 12:39 AM, Michael Schippling [EMAIL PROTECTED] wrote:

 In my humble, humbling, and limited experience with academically
 driven software, upgrading to the new-improved version of something
 generally exposes one to the Latest Software Engineering Paradigms,
 since such software is generally developed by grad-students who
 need thesis topics, without actually providing much in the way of
 functionality to those of us who ply the trade without benefit
 of publication opportunities...


There is a lot of truth in this, but I do not consider that profiting from
real innovation in OS design (for free, BTW) has no value for the
practitioner. The benefits from many of these architectural innovations
might not be obvious in the short term. But as we move along the 2.x path,
there are increasing sings that most of the decisions have been the right
ones, as evidenced by the increase in portability, robustness, etc. Agreed,
some time will pass until the 2.x code reaches the maturity of the 1.x code,
but this is just a question of enough eyeballs.


 So, aside from applying my rusty hermeneutic skills to the TEPS,
 is there someplace I can find a good description of the advantages
 of re-experiencing the TOS learning cliff under T2? I mean, if I
 port my working systems to some-slightly-different-but-almost-
 the-same--except-oh-yeah-we-forgot--that version, what's in it
 for me and mine?


I would not say that the relation between T2 and T1 can be characterized by
almost-the-same--except-oh-yeah-we-forgot-that-version. For more info on
the T2 philosophy and how it differs from what we had in 1.x, you can check
for example the T2 technical report and the HAA and power locks papers:

http://www.tkn.tu-berlin.de/publications/papers/T2_TR.pdf
http://www.tkn.tu-berlin.de/publications/papers/flexible_hardware_abstraction.pdf
http://www.tkn.tu-berlin.de/publications/papers/sosp186-klues.pdf

Vlado
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] .platform question

[Vlado Handziski]

On Dec 17, 2007 11:49 PM, David Gay [EMAIL PROTECTED] wrote:

 On Dec 17, 2007 2:16 PM, John Griessen [EMAIL PROTECTED] wrote:
  What makes the .platform file necessary separately from the
 ecosens1.target
  file?  Could the ecosens1.target do it all somehow?

 The .platform file is for ncc (and mig and ncg). The .target file is
 something used by the Makefile-based build system for TinyOS, and
 contains things unrelated to what ncc needs/wants (e.g. information on
 how to reprogram motes). Ideally at least there should be no
 duplication between the information in a .target and .platform file...

 Merging the two files is, to me at least, a bad idea:
 - If all the .platform stuff moves into .target: you can't build
 anything without using the magic build system. This would be like if
 gcc wasn't usable without some magic very large Makefile.
 - If all the .target stuff moved into .platform: this would hardwire
 specific programmers, preferred compilation flags, etc into ncc.


Another reason why the merging would be a bad idea is the loss of the
.family / .platform hierarchy. The .family file can be used to separate
between the component set implementing the generic platform family features
and the ones for the specific platforms. At the moment, it looks like the
eyesIFX is the only place in the tree where this is used, but for me it
provides a nice hierarchical model of the platform organization at the ncc
level of abstraction.

Vlado
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Re: [Tinyos-devel] Problems with tinyos-1.x vs. 2.x

[Vlado Handziski]

On Dec 16, 2007 10:05 PM, Chad Metcalf [EMAIL PROTECTED] wrote:


 On Dec 16, 2007 12:34 PM, Kevin Klues [EMAIL PROTECTED] wrote:
 
  My solution to all this would be to try and convince everyone to switch
 over to tinyos-2.x, but I realize that some people are reluctant to do so
 right away.  Many of the crossbow sensor drivers only exist for tinyos-1.x,
 and many users have written code for their own applications that relies on
 the way the 1.x task scheduler operates (which is quite different than the
 2.x task scheduler).  Code between the two versions is therefore
 unfortunately not backwards compatible.  So whats the right answer here?
 Do
 we need someone who is really invested in tinyos-1.x to step up and become
 the official maintainer of the tinyos-1.x tree -- fixing bugs, etc. as
they
 come in and pushing out new releases that have the bug fixes in them?  Or
 would it be better to start motivating people to start porting everything
 over to tinyos-2.x, so that their reliance on 1.x slowly fades away?
 
 I'd imagine this is something the Alliance and probably Core should make a
 decision on. I imagine the right answer is to sunset official support
for
 1.x (toolchains, install, everything). At this point the amount of support
 for 1.x is just a band-aid anyway. Rip it off and be done with it. A brief
 sunset period allows people to transition away or create some community
 support for a 1.2 project. Then after the sunset, its time to move on.


The Core position on this is quite clear, and has not changed significantly
from the time the 2.x effort has been presented to the community at the
TTX2. Breaking backwards compatibility was a conscious decision. The fact
that the 1.2 WG did not get far was due to a combination of factors like the
lack of interest in academia for working on the stale 1.x core,  the stealth
use of 1.x in industry, staff problems, the development of Boomerang...

The work of the Core and the Alliance is clearly concentrated on 2.x, and
this is the recommended version for anyone that is joining the community.
That being said, we can not ignore the fact that there are many users out
there that still use tinyos-1.x. So even though the current WGs can not
spend effort in bugfixes, maintaining the tool-chain, etc., the repository
for 1.x will remain open for anyone that wants to contribute code against
it. If there are enough interested parties that will come forward and
resurrect the 1.2 WG, the Core can definitely reach out and provide some
guidance, but not much more, without endangering its primary goal of making
the best possible design decisions for the 2.x core.

Vlado
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Timer and Uart0 Conflict

[Vlado Handziski]

OK, I repeated the test while exciting the uart0 pins on the mote, and it
does lock-up. The problem is in your usage of start-edge detection i.e.
urxse : 1 in the config struct. In this case, the MCU generates a single RX
interrupt that has to be handled manually, before one can start with normal
byte receive. The current code in the stack relies on the automatic clearing
of the RX flag, thus the lock-up that you see.

Vlado

On 9/25/07, Vlado Handziski [EMAIL PROTECTED] wrote:

 Hi Ariel,

 unfortunately I can not reproduce the bug that you are seeing on my
 testing tmote sky node.The red led is blinking both with and without that
 line. Can you send me a binary image of the application to rule out
 different source trees.

 Vlado

 On 9/25/07, Vlado Handziski [EMAIL PROTECTED] wrote:
 
  Hi Ariel,
 
  I'll take a look at the issue later today and get back to you.
 
  Vlado
 
  On 9/25/07, Ariel Mauricio Nunez Gomez  [EMAIL PROTECTED] wrote:
 
   Hello everyone,
  
   I am trying to use Timer0 and Uart0 (Tinyos 2.0.2 (cvs updated 4 days
   ago), Tmote Sky, Ubuntu Feisty).
   As you can see, led0 blinks if timer is fired, and led1 blinks when a
   byte is received over the serial port.
  
   Problem: When I request the serial port, led0 stops blinking.
  
   Note: The serial port can be disconnected and it will show the same
   behavior.
  
   Thanks in advance,
   Ariel
  
code snippet
  
  
 event void Boot.booted()
 {
   call Timer0.startPeriodic( 1000 );
   //call SerialResource.request(); //Uncomment this line to disable
   Timer0
 }
  
 event void Timer0.fired()
 {
   call Leds.led0Toggle();
 }
  
 event void SerialResource.granted(){
   call UartStream.enableReceiveInterrupt ();
 }
 async event void UartStream.receivedByte(uint8_t byte){
   call UartStream.disableReceiveInterrupt();
   call Leds.led1Toggle();
   call UartStream.enableReceiveInterrupt();
 }
  
  
   ___
   Tinyos-help mailing list
   Tinyos-help@Millennium.Berkeley.EDU
   https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
  
  
  
 

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Bootstrap loader synchronization error

[Vlado Handziski]

On 11/11/06, Sascha Lutters [EMAIL PROTECTED] wrote:
Hello everyone,I've installed TinyOS according to the tutorial ona native Fedora machine.When trying to compile Blink and install it on myeyesIFXv2 I unfortunately get to see the following:
[EMAIL PROTECTED] Blink]# make eyesIFXv2 install bsl,/dev/ttyUSB0mkdir -p build/eyesIFXv2compiling BlinkAppC to a eyesIFXv2 binaryncc -o build/eyesIFXv2/main.exe -Os -O -mdisable-hwmul -Wall -Wshadow-DDEF_TOS_AM_GROUP=0x7d -Wnesc-all -mdisable-hwmul -target=eyesIFXv2
-fnesc-cfile=build/eyesIFXv2/app.c -board= BlinkAppC.nc -lmcompiled BlinkAppC to build/eyesIFXv2/main.exe2702 bytes in ROM57 bytes in RAMmsp430-objcopy --output-target=ihex build/eyesIFXv2/main.exe
build/eyesIFXv2/main.ihexwriting TOS imagecp build/eyesIFXv2/main.ihex build/eyesIFXv2/main.ihex.outinstalling eyesIFXv2 binary using bslmsp430-bsl --invert-test --invert-reset --f1x -c /dev/ttyUSB0 -r -e -I -p
build/eyesIFXv2/main.ihex.outMSP430 Bootstrap Loader Version: 2.0Mass Erase...An error occoured:Bootstrap loader synchronization errormake: *** [program] Fehler 1How can I fix this?
Thanks for your help!The eyesIFXv2 nodes export two serial devices, one for data (lower port number), the other for programming (higher port number). In your case /dev/ttyUSB0 is the data port. Try to burn the application on /dev/ttyUSB0 or just use make install and the make system will automatically select /dev/ttyUSB1 for the programming.
Vlado
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] tmote sky: lowpowermode in McuSleepC.nc when Radio stopped (tinyos 2.0)

[Vlado Handziski]

On 6/20/06, Philip Levis [EMAIL PROTECTED] wrote:
On Jun 20, 2006, at 4:40 AM, Roman Lim wrote: In this case the CC2420 code does not release the resource before going into stop mode? Vlado Handziski wrote: Before the MCU can go to LPM3, the USART needs to be disabled.
 This should be done by the implicit power manager (TEP 115) using AsyncStdControl of the HplMsp430UsartxP.nc once all the clients release the USART. So, as long as the CC2420 code releases the
 resource before going into stop mode, the getPowerState() should work OK. Don't be confused by the UTXE0 and URXE0 names in the check. URXE0 is the same location as USPIE0 so the check covers
 potential use of SMCLK both in Uart and Spi mode. VladoVlado, on USART0, shouldn't the arbiter be hooked up to an asyncpower manager, so this is done automatically? This is currently what
the atm128 I2C stack does.I realize you can't do it on USART1, as you might receive packets(need the explicit power management of SerialActiveMessageC), but itmakes sense to be able to power down the bus on USART0. Or is there a
problem with doing so?PhilIt is connected! (check Msp430UsartShare0P) That's why I was suspecting that the CC2420 is not releasing properly. I'll take a closer look when I have more time and a JTAG at hand.
Vlado
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] tmote sky: lowpowermode in McuSleepC.nc when Radio stopped (tinyos 2.0)

[Vlado Handziski]

On 6/16/06, Roman Lim [EMAIL PROTECTED] wrote:
HelloI noticed that the calculated lowpowermode in McuSleepC.nc is 1, whenthere is a initiated radio (via ActiveMessageC), even when the radio isin stoppedstate.Responsible for this is the following line in 
McuSleepC.nc(getPowerState()):((ME1  (UTXE0 | URXE0))  (U0TCTL  SSEL1))Is it necessary to keep the uart running when the radio is set to sleepmode?I tried to force the OS to go to lowpower mode 3, even if the uart0 is
configured for radio. In this setup it was no problem to stop and startthe CC2420 and send packets.Before the MCU can go to LPM3, the USART needs to be disabled. This should be done by the implicit power manager (TEP 115) using AsyncStdControl of the 
HplMsp430UsartxP.nc once all the clients release the USART. So, as long as the CC2420 code releases the resource before going into stop mode, the getPowerState() should work OK. Don't be confused by the UTXE0 and URXE0 names in the check. URXE0 is the same location as USPIE0 so the check covers potential use of SMCLK both in Uart and Spi mode.
Vlado
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help