tp-freeforall / prod Goto Github PK

This project forked from tinyprod/prod

TinyOS (less academic, more industrial, rD, less filling), still a floor wax

License: BSD 3-Clause "New" or "Revised" License

Makefile 1.08% nesC 54.76% C 33.50% Java 2.12% Shell 0.65% C++ 3.61% Python 1.34% Perl 0.07% CSS 0.01% XSLT 0.03% Awk 0.01% MATLAB 0.01% Assembly 0.09% HTML 0.09% Batchfile 0.03% M4 2.05% Roff 0.08% C# 0.36% SWIG 0.12%

prod's Introduction

TinyOS

TinyOS is an open source, BSD-licensed operating system designed for low-power wireless devices, such as those used in sensor networks, ubiquitous computing, personal area networks, smart buildings, and smart meters.

TinyProd

The main Tinyos-Main tree has seen less activity over the years. That doesn't mean TinyOS is dead, rather most new work has been concentrated on the tinyprod repository. See tinyprod/prod and its working development repository tp-freeforall/prod

Make 3

The main TinyOS trees have been converted to using the new Make3 build system. See the (Make Version 3) section below.

Where to Begin

doc/00a_Getting_Started_w_Git: Overview of getting started using git, github.
doc/00c_Setting_Up_Debian_Development: Setting up development on Debian based Linux machines. Debian and Ubuntu.
doc/00d_MacOSX_Development: Setting up development on Mac OS X.

TinyOS Wiki

Much information about how to setup and use TinyOS can be found on the wiki. It is also editable by the community if you have information to add or update.

About tinyos-main

Long ago (well not that long ago), in a galaxy not too distant, tinyos development was hosted on Google Code as a subversion repository. This repository was writeable by a select group of core developers.

TinyOS development has moved to a fully distributed model to encourage more participation by switching to the git distributed version control system.

The Github tinyos-main repository will still be writeable by those same core developers. Pull requests are welcome and will be reviewed by the core developer most familiar with the relevant code.

Repo Structure

Currently there is a single mainline, master. gh:tinyos/tinyos-main(master). This is equivalent to the tip of the svn trunk.

Branches are very inexpensive and are encouraged for any significant development. Typically, a feature will be implemented on a topic branch, ie. -int. where stands for integration.

For the immediate future, branching should be done in private user repositories. until the community gets used to how they work.

The general form for a repository/branch reference is: <github_context>/(branch) ie. gh:tinyos/tinyos-main(master) is the master branch in the tinyos/tinyos-main repository. Note that github repositories have a specific default branch controlled by github repository settings. gh:tinyos/tinyos-main refers to the repository but if that repository is pulled it will reference the default branch.

Local repositories are referenced using local(branch).

(Make Version 3)

TinyOS development repositories (tinyos/tinyos-main, tinyprod/prod) use the Version 3 make build system (issue #190). (see below).

Releases 2.1.2 and prior uses pre-version 3 tools and requires tinyos-tools-14. The development tree (tinyos-main, tinyprod) requires the new version 3 compatible tools, tinyos-tools-devel.

TinyOS releases after 2.1.2 will use tinyos-tools that are compatabile with the version 3 make system.

Version 3 Make system and tinyos-tools

The TinyOS make system has been upgraded to version 3. This brings many new improvements, see support/make/README.md for details.

The simplest way to obtain the tools is the install from the main tinyprod repository (see doc/00c_Setting_Up_Debian_Development). See the repository Readme at http://tinyprod.net/repos/debian/README.html).

sudo -s
apt update
apt purge tinyos-tools              # remove earlier incompatible version
apt install tinyos-tools-devel

Alternatively, one can build the tools manually:

cd tools
./Bootstrap
./configure
make
sudo make install

prod's People

Contributors

Stargazers

Watchers

prod's Issues

BusyWait does not work

I did a little test with BusyWait and MSP430F2418. Basically platform definition is copied from Z1.
It seems that BusyWait never returns.
I analyzed the output with logic analyzer and it did not toggled within at least 10 seconds.

However similar code worked with Sownet tinyos toolchain with old mspgcc 3.2.3. Unfortunately as far as I know this repository is not public.
Not sure, but perhaps mkonstapel knows inner details.

BusyMicroTestC.nc

#include "printfZ1.h"

module BusyMicroTestC @safe() {
    uses {
        interface Leds;
        interface Boot;
        interface Timer<TMilli>;
        interface BusyWait<TMicro, uint16_t>;
        interface GeneralIO as SCLK;

    }
}
implementation {
    event void Boot.booted() {
        printfz1_init();
        //call Timer.startPeriodic(4096);
        call Leds.led1Toggle();

        printfz1("booted\n");

        call SCLK.makeOutput();
        while (1) {
            call Leds.led2Toggle();
            call SCLK.toggle();
            call BusyWait.wait(1);
        }
    }

    event void Timer.fired() {
    }
}

BusyMicroTestAppC.nc

configuration BusyMicroTestAppC {}
implementation {

    components MainC, BusyMicroTestC as App, LedsC;
    App.Boot -> MainC.Boot;
    App.Leds -> LedsC;

    components new TimerMilliC() as Timer;
    App.Timer -> Timer;

    components BusyWaitMicroC;
    App.BusyWait -> BusyWaitMicroC;

    components HplMsp430GeneralIOC as GeneralIOC;    
    components new Msp430GpioC() as SCLKM;
    SCLKM  -> GeneralIOC.Port26;
    App.SCLK -> SCLKM;

}

surf serial communication garble

Hello,
the TestSerial app and every other serial communication running on my surf boards (Rev.B2) only produces garble bytes:
00000000: ff ef f7 6f ff ef f7 6f ff ef f7 6f ff ef f7 ef
00000010: ff ef f7 ef ff ef f7 ef ff ff ef f7 ef ff ef f7
00000020: ef
(These are 8 serial AM packets from TestSerial received with 115200 baud, note how they are way too short)

RadioCountToLeds works fine, and with the old osian branch my surf boards produce correct output. So suppose its not a hardware or cable fault, but something with the current tinyprod code.
I am using the tinyprod toolchain.

Regards, Tim

x2xx MCUs do not have ADC12ENC in header file

tos/chips/msp430/adc12/HplAdc12P uses ADC12ENC, however for example msp430f2418 has just ENC in header definition.

/* ADC12CTL0 */

define ADC12SC (0x001) /* ADC12 Start Conversion */

define ENC (0x002) /* ADC12 Enable Conversion */

define ADC12TOVIE (0x004) /* ADC12 Timer Overflow interrupt enable */

So this should be somehow universally sorted out.

[MSP430] Can't use USCI A as SPI master

Unfortunately current implementation of Msp430SpiNoDmaP.nc uses HplMsp430UsciB as USCI interface, and it works only for USCI B. If we choose USCI A as SPI channel, it ends up an error since it is incompatible with Msp430SpiA0NoDmaP.nc.

To solve this, we may want to refactor Msp430UsciA and Msp430UsciB interfaces into four, lets say, Msp430Usci, Msp430UsciSpi, Msp430UsciUart, and Msp430UsciI2C.

WDYT?

gnode's cc1101 radio FSTEST is readonly register

I noticed that in gnode's cc1101 driver there is FSTEST register defined and actually value is written into that register, however actually it is read-only register.

Here it is defined: https://github.com/tp-freeforall/prod/blob/msp430-int/tos/platforms/gnode/chips/cc1101/ChipconRegisterValues.h

And here it is used: https://github.com/tp-freeforall/prod/blob/msp430-int/tos/platforms/gnode/chips/ccpacket/hal/HalChipconControlP.nc

/**
 * Load default configuration into registers. 
 */
void configure() {
    uint8_t i;
    for (i = 0; i < NUM_REGISTERS * 2; i += 2) {
        uint8_t reg = chipconRegisterValues[i];
        uint8_t value = chipconRegisterValues[i+1];
        call HplChipconSpi.writeRegister(reg, value);
    }
}

It seems to produce no sideeffects, but it is not correct.

I am not willing to remove it yet, maybe I am missing something. It is better if mkonstapel would comment this issue first.