search

tinyos / tinyos-main

Main development repository for TinyOS (an OS for embedded, wireless devices).
1.4k stars 516 forks source link

TinyOS 2.2 (formerly 2.1.3), packages and repository #265

Open phil-levis opened 10 years ago

phil-levis commented 10 years ago

So it looks like tinyprod is down and won't be coming back up. I'm going to move TinyOS and its support packages (e.g., msp430-46) back to being hosted at tinyos.stanford.edu. In part, this means I'd like to package up version 2.1.3 of TinyOS.

Also, if anyone would like to help with the packaging and maintenance of the repository, please drop me a line (pal@cs.stanford.edu), I'd of course appreciate help. My plan is to start working on this in May and have a release ready by mid-June. I'm starting this issue so we can come up with a to-do list of what to pull into the main repository (and issues to address) for 2.1.3 under that timeframe.

-Phil

cire831 commented 10 years ago

Do you want 2.1.3 based off the current tip of the development trunk or

are you thinking we should make it a selective maintance release based off of 2.1.2? Ie. selective patches brought over from the development trunk?

On Fri, Apr 18, 2014 at 1:37 AM, phil-levis notifications@github.comwrote:

So it looks like tinyprod is down and won't be coming back up. I'm going to move TinyOS and its support packages (e.g., msp430-46) back to being hosted at tinyos.stanford.edu. In part, this means I'd like to package up version 2.1.3 of TinyOS.

Also, if anyone would like to help with the packaging and maintenance of the repository, please drop me a line (pal@cs.stanford.edu), I'd of course appreciate help. My plan is to start working on this in May and have a release ready by mid-June. I'm starting this issue so we can come up with a to-do list of what to pull into the main repository (and issues to address) for 2.1.3 under that timeframe.

-Phil

— Reply to this email directly or view it on GitHubhttps://github.com/tinyos/tinyos-main/issues/265 .

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

phil-levis commented 10 years ago

I'm thinking off the tip of the development trunk. In all honesty, though, I think 2.1.3 should focus primarily on toolchain and Mac OSX support. Hearing the horror stories from students on how hard it is to get TinyOS running under OSX means we need to figure this out and write documentation on how to do it. Also, a new Linux VM for one-step installation would be good.

phil-levis commented 10 years ago

I think the first question to answer is what platforms will 2.1.3 support? The list for 2.1.2 was (with responsible tester):

Prabal: Epic Janos: IRIS Thanh: mica2 Phil: micaz Laurynas: mulle Steve: shimmer, shimmer2, span Vlado: telosb Pierre: tinynode Miklos: ucmini Antonio: z1

I'm willing to test the micaz. Availability of platforms will basically depend on who is wiling to test. If you'd like to test a platform, let me know, I can add it to the list.

Phil

vlahan commented 10 years ago

We can test the telosb like last time.

--Vlado

alignan commented 10 years ago

I can test like las time too.

--Antonio

cire831 commented 10 years ago

I'm currently actively figuring out Linux VM stuff (currently 14.04 on Parallels 7 (migrating to 9 also). Will probably also need to tackel the Mac OS X stuff too.

On Tue, Jun 10, 2014 at 9:56 AM, Philip Levis notifications@github.com wrote:

I'm thinking off the tip of the development trunk. In all honesty, though, I think 2.1.3 should focus primarily on toolchain and Mac OSX support. Hearing the horror stories from students on how hard it is to get TinyOS running under OSX means we need to figure this out and write documentation on how to do it. Also, a new Linux VM for one-step installation would be good.

— Reply to this email directly or view it on GitHub https://github.com/tinyos/tinyos-main/issues/265#issuecomment-45641221.

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

mikehealy commented 10 years ago

I can test the shimmer, shimmer2, shimmer2r and span platforms

Northshoot commented 10 years ago

Current version of mulle may become obsolete since new 32 bit version is on the way. I will get back with info if we will keep mulle in 2.1.3.

For the OS x it maybe an option to make TinyOS available through brew and automate installiation?

cire831 commented 10 years ago

On Wed, Jun 11, 2014 at 12:26 AM, Northshoot notifications@github.com wrote:

Current version of mulle may become obsolete since new 32 bit version is on the way. I will get back with info if we will keep mulle in 2.1.3.

For the OS x it maybe an option to make TinyOS available through brew and automate installiation?

not sure what you mean. TinyOS is source, grabbing the release sources via git is more natural than using something like brew. Typically what you install is toolchains. Brew already has the msp430 toolchains I beleive. I know macports does.

what we need are reasonable instructions as opposed to the peicemeal way one needs to figure it out.

—

Reply to this email directly or view it on GitHub https://github.com/tinyos/tinyos-main/issues/265#issuecomment-45710028.

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

Northshoot commented 10 years ago

Formula could be created to grab tool chain requared for tinyos, including nesc, msp, etc, platform creators could easily add additional formulas to download and compile needed tools.

While instruction are good in any case automating installiation is a plus, the same way packages are created for linux we could have formulas for mac.

On Wed, Jun 11, 2014 at 10:29 AM, Eric Decker notifications@github.com wrote:

On Wed, Jun 11, 2014 at 12:26 AM, Northshoot notifications@github.com wrote:

Current version of mulle may become obsolete since new 32 bit version is on the way. I will get back with info if we will keep mulle in 2.1.3.

For the OS x it maybe an option to make TinyOS available through brew and automate installiation?

not sure what you mean. TinyOS is source, grabbing the release sources via git is more natural than using something like brew. Typically what you install is toolchains. Brew already has the msp430 toolchains I beleive. I know macports does.

what we need are reasonable instructions as opposed to the peicemeal way one needs to figure it out.

—

Reply to this email directly or view it on GitHub https://github.com/tinyos/tinyos-main/issues/265#issuecomment-45710028.

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

— Reply to this email directly or view it on GitHub https://github.com/tinyos/tinyos-main/issues/265#issuecomment-45715033.

bradjc commented 10 years ago

I can test epic.

Re mac: it would be nice if

brew install tinyos
   OR
port install tinyos

installed all of the toolchain dependencies. Then the user just downloads and extracts the tarball to get the source files.

phil-levis commented 10 years ago

Eric, the problem with TinyOS has never been installing the source. That's easy. The challenge in releases and packaging has always been the toolchain, especially for multiple platforms.

Many people who want to use TinyOS do not necessarily want to grab from git. Making the code only available through git says that we're only interested in supporting developers, and aren't interested in supporting users.

Phil

On Jun 11, 2014, at 1:29 AM, Eric Decker notifications@github.com wrote:

On Wed, Jun 11, 2014 at 12:26 AM, Northshoot notifications@github.com wrote:

Current version of mulle may become obsolete since new 32 bit version is on the way. I will get back with info if we will keep mulle in 2.1.3.

For the OS x it maybe an option to make TinyOS available through brew and automate installiation?

not sure what you mean. TinyOS is source, grabbing the release sources via git is more natural than using something like brew. Typically what you install is toolchains. Brew already has the msp430 toolchains I beleive. I know macports does.

what we need are reasonable instructions as opposed to the peicemeal way one needs to figure it out.

—

Reply to this email directly or view it on GitHub https://github.com/tinyos/tinyos-main/issues/265#issuecomment-45710028.

Eric B. Decker Senior (over 50 :-) Researcher — Reply to this email directly or view it on GitHub.

vlahan commented 10 years ago

Anyone interested to help me develop and test a Docker based image that includes both the toolchain(s) and the TinyOS source?

cire831 commented 10 years ago

On Wed, Jun 11, 2014 at 3:47 AM, Brad Campbell notifications@github.com wrote:

I can test epic.

Re mac: it would be nice if

brew install tinyos OR port install tinyos

installed all of the toolchain dependencies.

so that would install all the toolchains for all the main supported motes?

Then the user just downloads and extracts the tarball to get the source files.

— Reply to this email directly or view it on GitHub https://github.com/tinyos/tinyos-main/issues/265#issuecomment-45726643.

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

ppannuto commented 10 years ago

Space is cheap. I would say yes.

bradjc commented 10 years ago

so that would install all the toolchains for all the main supported motes?

Absolutely. In my experience people want as few hurdles as possible to getting started.

alignan commented 10 years ago

Agree,

--Antonio

On Thu, Jun 12, 2014 at 11:39 AM, Brad Campbell notifications@github.com wrote:

so that would install all the toolchains for all the main supported motes?

Absolutely. In my experience people want as few hurdles as possible to getting started.

— Reply to this email directly or view it on GitHub https://github.com/tinyos/tinyos-main/issues/265#issuecomment-45848560.

Antonio Liñán Colina R+D Engineer @: alinan@advancare.com

@: alinan@zolertia.com

Advancare Ph.: +34 935 511 403 http://www.advancare.com http://www.zolertia.com http://zolertia.sourceforge.net http://webshop.zolertia.com

Northshoot commented 10 years ago

I can look into into brew and create test formula. However, I will have time first in couple of weeks.

andrasbiro commented 10 years ago

It's a bit late, but we might want to test the new avr toolchain for this release (see #293). I'm using it for a while on iris and various ucmotes without any issue (except some small warnings), so I don't except major problems. Otherwise, we might need to test the avr motes again for the toolchain release, or I don't know what's the procedure for a toolchain release.

phil-levis commented 10 years ago

Great -- I hope to test on micaz (so atm128) this weekend.

Phil

On Jun 20, 2014, at 4:34 AM, András Bíró notifications@github.com wrote:

It's a bit late, but we might want to test the new avr toolchain (see #293). I'm using it for a while on iris and various ucmotes without any issue (except some small warnings), so I don't except major problems. Otherwise, we might need to test the avr motes again for the toolchain release, or I don't know what's the procedure for a toolchain release.

— Reply to this email directly or view it on GitHub.

phil-levis commented 10 years ago

In addition to msp430-gcc and avr-gcc, I think we should include an arm-gcc. Cortex based platforms are finally becoming truly feasible, and we should be ahead of that, not trail it. Is anyone interested in taking lead on picking a version of arm-gcc and setting up the packages?

ppannuto commented 10 years ago

I have a fair bit of experience with embedded ARM work. I’d be willing to do this.

Ubuntu and OS X both have full ARM toolchains available in standard package managers that are stable / reliable. Fedora (and RHEL, and other rpm-based distros) have a compile toolchain, but no std lib / libc available (though I’m not sure that matters for TinyOS). I’ve also managed to get crosstool-ng to work pretty well to get a full toolchain up on Fedora.

There are also the CodeSourcery archives that we could point people to, but I’d rather avoid the binary blob if possible.

ppannuto commented 10 years ago

As an aside, we already use ARM for a number of apps. In particular, our "Linux" / rpi platform targets the Raspberry Pi where TinyOS runs as a process. We use this for a few apps on a couple dozen Pi's at this point -- it's a pretty convenient development paradigm for things like border routers.

andrasbiro commented 10 years ago

Last time, Thomas Schmid (I'm not sure what's his github account) recommended this toolchain build: https://launchpad.net/gcc-arm-embedded

bradjc commented 10 years ago

Last time, Thomas Schmid (I'm not sure what's his github account) recommended this toolchain build: https://launchpad.net/gcc-arm-embedded

Yes, this is what I use for the CC2538 (arm based). It seems to be preferred toolchain for arm based platforms. Also, we use the http://packages.ubuntu.com/trusty/gcc-arm-linux-gnueabi for running on the RPi on top of Linux.

phil-levis commented 10 years ago

That's great. Do you have some time to talk on the phone soon? I'd like to pick your brain a little about the toolchain and making it usable for current and future ARM-based TinyOS platforms. Send me private email, we can coordinate.

Phil

On Jun 25, 2014, at 9:43 AM, Pat Pannuto notifications@github.com wrote:

I have a fair bit of experience with embedded ARM work. I’d be willing to do this.

Ubuntu and OS X both have full ARM toolchains available in standard package managers that are stable / reliable. Fedora (and RHEL, and other rpm-based distros) have a compile toolchain, but no std lib / libc available (though I’m not sure that matters for TinyOS). I’ve also managed to get crosstool-ng to work pretty well to get a full toolchain up on Fedora.

There are also the CodeSourcery archives that we could point people to, but I’d rather avoid the binary blob if possible. On June 25, 2014 at 12:19:56, Philip Levis (notifications@github.com) wrote:

In addition to msp430-gcc and avr-gcc, I think we should include an arm-gcc. Cortex based platforms are finally becoming truly feasible, and we should be ahead of that, not trail it. Is anyone interested in taking lead on picking a version of arm-gcc and setting up the packages?

— Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.

phil-levis commented 10 years ago

Eric, can you describe the tradeoffs between msp-46 and msp-47? I'm wondering which should be the standard version for the next release. It looks like avr will be 4.8.1, as will arm.

cire831 commented 10 years ago

msp430-47 has the 20 bit support but it is poorly supported and very experimental.

we should stick with msp430-46.

The new RH/TI toolchain is maturing but isn't ready yet.

On Tue, Jul 1, 2014 at 9:01 AM, Philip Levis notifications@github.com wrote:

Eric, can you describe the tradeoffs between msp-46 and msp-47? I'm wondering which should be the standard version for the next release. It looks like avr will be 4.8.1, as will arm.

— Reply to this email directly or view it on GitHub https://github.com/tinyos/tinyos-main/issues/265#issuecomment-47675056.

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

alignan commented 10 years ago

I think having the option to use msp430-47 is highly desirable, if not the default one, at least having the option to select it would be a nice-to-have feature, is complicated to have this?

We normally distribute pre-compiled tarballs supporting all toolchain versions, so if the above cannot be implemented, we are OK to keep providing this.

cire831 commented 10 years ago

There are no plans to remove the msp430-47 packages.

Phil was asking about what the default msp430 toolchain should be for 2.1.3. It should be msp430-46.

Eventually, we will move to the 4.9 based RH/TI toolchain but its not ready for prime time yet.

On Wed, Jul 2, 2014 at 2:20 AM, Antonio Lignan notifications@github.com wrote:

I think having the option to use msp430-47 is highly desirable, if not the default one, at least having the option to select it would be a nice-to-have feature, is complicated to have this?

We normally distribute pre-compiled tarballs supporting all toolchain versions, so if the above cannot be implemented, we are OK to keep providing this.

— Reply to this email directly or view it on GitHub https://github.com/tinyos/tinyos-main/issues/265#issuecomment-47754113.

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

cire831 commented 10 years ago

Release numbering is now definitely 2.2.0