Re: [riot-devel] Mailserver issues

[Adam Hunt]

What sort of hardware would RIOT need for CI? Would a machine with,
for example, a pair of E5-2670 (eight cores @ 2.60 GHz), Xeons between
64 and 128 GB of DDR3 ECC RAM, an SSD or two, and maybe some spinning
storage suffice or are we talking about something like a highly
available cluster consisting of half-dozen or more HP ProLiant DL380
Gen10 machines each with a pair Xeon 8100s (28 cores @ 3.60 GHz), a
terabyte of DDR4 RAM, and a pile of blazing fast NVMe drives?

I'm just thinking that if a machine or two with specs closer to the
first example would suffice than I imagine the RIOT community might be
able to find a way to make it happen.

A word of warning… While I'm absolutely serious about trying to help
out in this area (and other) please know I'm currently trying get the
ball rolling and determine what type of resources the project could
most use; it'll take a bit of time to turn these early thoughts into
something real. Personally, I may not have piles of cash laying around
but I do have something else of value, time.

Adam


On Fri, Aug 11, 2017 at 7:16 AM, Koen Zandberg <k...@bergzand.net> wrote:
> Hello,
>
>
> On 08/11/2017 03:49 PM, Stefan Schmidt wrote:
>> Hello.
>>
>> On 08/11/2017 02:03 PM, Oleg Hahm wrote:
>>> Hey Adam!
>>>
>>> Thanks for the pointer. That's definitely something we should consider.
>>>
>>> Cheers,
>>> Oleg
>>>
>>> On Fri, Aug 11, 2017 at 04:52:05AM -0700, Adam Hunt wrote:
>>>> I was going to suggest that you might talk to the Oregon State
>>>> University Open Source Lab (http://osuosl.org). OSUOSL offers free
>>>> hosting, email, VMs, colocation, FTP, backup, etc. (both managed and
>>>> unmanaged) to open source projects. I can't speak to what type of
>>>> computing power they offer but I know they've been working to stand up
>>>> an OpenStack cluster they may be able to help out with CI or in other
>>>> ways.
>>
>> They also offer to host a server of your own. We do that for the
>> Enlightenment project for several years now. Their connectivity and
>> general admin service has worked very well for us.
>>
>> We have a beefy server there hosting our own tons of git repos, web
>> services, downloads, CI, etc. I don't think there is any bandwidth
>> limitation or such. All in all a really nice service from them to the
>> open source communities.
>>
>> If it is something interesting for RIOT I have no idea but if you are
>> looking for something in that regard it is surely worth talking to them.
>>
>> regards
>> Stefan Schmidt
>
> To offer an alternative, I can offer the services of Studenten Net
> Twente[1]. Studenten Net Twente is a student associations of the
> University of Twente aimed at providing IT services. We have a history
> of supporting open source projects by offering FTP space and/or
> colocation services for free.
>
> As we use RIOT-os for an internal project, we'd love to return something
> to the project. If a host for CI or other services is needed, I can see
> if I can get a virtual machine or some real hardware available for
> RIOT-os infrastructure.
>
> Regards,
> Koen Zandberg
>
> 1. http://www.snt.utwente.nl/en/index.php
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Mailserver issues

[Adam Hunt]

I was going to suggest that you might talk to the Oregon State
University Open Source Lab (http://osuosl.org). OSUOSL offers free
hosting, email, VMs, colocation, FTP, backup, etc. (both managed and
unmanaged) to open source projects. I can't speak to what type of
computing power they offer but I know they've been working to stand up
an OpenStack cluster they may be able to help out with CI or in other
ways.

I'm not affiliated with OSUOSL, I just live in their area.

--adam

On Fri, Aug 11, 2017 at 4:16 AM, Oleg Hahm <o...@riot-os.org> wrote:
> Hi Adam!
>
> On Fri, Aug 11, 2017 at 04:04:05AM -0700, Adam Hunt wrote:
>> Just out of curiosity, was this due to a lack of machine resources?
>
> Actually not. In fact, the maximum number of MTA and content filter processes
> were configured too low.
>
>> How is RIOT's infrastructure (e.g. web and mail hosting) handled; is
>> the hosting donated by one or more of the supporters listed at the
>> bottom of the project's homepage? Would additional hosting resources
>> be helpful?
>
> Currently, some of the services (e.g., web and mail) are hosted privately by
> community members, other services are sponsored by supporting institutions
> such as FU Berlin, HAW Hamburg, and Inria. In general, additional resources
> are always helpful, particular for the CI system, I guess. Do you have
> something particular in mind?
>
> Cheers,
> Oleg
> --
> /* Ugly, ugly fucker. */
> linux-2.6.6/include/linux/netfilter_ipv4/ipt_limit.h
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Mailserver issues

[Adam Hunt]

Just out of curiosity, was this due to a lack of machine resources?
How is RIOT's infrastructure (e.g. web and mail hosting) handled; is
the hosting donated by one or more of the supporters listed at the
bottom of the project's homepage? Would additional hosting resources
be helpful?

--adam

On Tue, Aug 8, 2017 at 10:00 AM, Thomas Eichinger  wrote:
> Oleg,
>
> Thank you for handling this!
>
> Best, Thomas
>
> On 8 Aug 2017, at 7:53 PDT(-0700), Oleg Hahm wrote:
>
>> Dear RIOTers,
>>
>> due to an immense load of requests on the mailing lists, ten thousands of
>> mails got queued over the last days. This lead to a delay for mail delivery 
>> up
>> to several days. After some throttling and performance tuning on the mail
>> server everything should be back to normal and most of the mails should have
>> been delivered by now.
>>
>> Sorry for the inconvenience and please let me know if you encounter further
>> problems.
>>
>> Cheers,
>> Oleg
>> --
>> The best thing about script jokes is that they start with a bang.
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Porting to the ARTIK 030 module

[Adam Hunt]

Has anyone taken a look at the ARTIK 030 module from Samsung? It's a
Cortex-M4 based (SiLabs EFR32MG1 SoC) module with 256 kB flash and 32
kB SRAM, a cryto processor, and 802.15.4 radio.

In the US they're available from Digikey and Mouser for $7.30 in
single unit quantities; I'm not sure who distributes them in the UK.

webpage: https://www.artik.io/modules/artik-030/
datasheet: 
https://developer.artik.io/downloads/1101cbd8-2ddf-404f-ac79-26488417c8cb/download




MCU Features

* ARM Cortex-M4 @ 40 MHz
* Silicon Labs EFR32MG1 SoC
* Low Active Mode Current: 63 μA/MHz
* 256 kB flash, 32 kB SRAM
* Hardware cryptography engine with support for AES-128/256, ECC,
SHA-1, SHA-256, and a Random Number Generator
* 8 Channel DMA Controller


Digital Peripherals

* 2 × USART (UART, SPI, IrDA, I²S)
* Low Energy UART • I²C peripheral interface (address recognition down to EM3)
* Timers: RTCC, Low Energy Timer, Pulse Counter
* 12-channel Peripheral Reflex System (PRS)
* Up to 25 GPIO with interrupts


Analog Peripherals

* ADC (12-bit, 1 Msps, 326 μA)
* Current-mode Digital to Analog Converter (IDAC)
* 2 × Analog Comparator (ACMP)


Low Power Modes

* Energy Mode 2 (Deep Sleep) Current: 2.5 μA (Full RAM retention and
RTCC running from LXFO)
* Ultra-fast wake up: 3 μS down to EM3
* Wide Supply Voltage range of 1.85 to 3.8 V Radio Features
* 2.4 GHz with integrated balun
* IEEE 802.15.4
* Data Rate / Modulation: 250 kbps DSSS-OQPSK
* +10 dBm Programmable TX Power
* -99 dBm RX Sensitivity
* 9.8 mA RX current
* 8.2 mA TX current (at +0 dBm)
* Support for wireless mesh networking (ZigBee/Thread)
* Integrated PA (up to +10 dBm TX power)
* Packet Trace Interface (PTI) for non-intrusive packet trace with
Simplicity Studio development tools
* Antenna interface: integrated high-performance chip antennaor u.FL
variant for external antenna


Misc. Features

* Support for SoC and Network Co-Processor (NCP) architectures with
SPI/UART host support
* Serial and Over-The-Air (OTA) bootloaders
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Helping out with the CI situation

[Adam Hunt]

With all the chatter about the CI situation lately I got to wondering if
there might be some way I could help out. It sound like Kaspar has things
under control with the new CI system but what about builders; are there
enough CPU cycles available for the current rate of RIOT development, what
about future development?

Would it be possible for me and/or other members of the community to donate
CPU time for use as builders? I currently have two perfectly good machines
each with a 3.4 GHz quad i5, 16 and 32 GB of memory respectively, fast
SSDs, and plenty of rotational storage; both machines sit idle for much of
the day. If CI builders could be deployed as VMs, or better yet, Docker
images (lighter weight) would it be possible for people like me to help out?

--adam
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] 5 Open Source IoT Projects to Watch in 2016

[Adam Hunt]

I'm not sure if anyone saw this. Check slide #3.

https://blog.benjamin-cabe.com/2016/02/08/5-open-source-iot-projects-to-watch-in-2016
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] TI CC1310 and CC2650

[Adam Hunt]

Jonas,

I was wondering, can you comment on the possibility of loading custom
images for the M0 RF core? While I don't doubt that the TI firmware would
be sufficient for most uses the idea of loading an open source, RIOT based,
MAC onto the M0 is interesting to me.

Thanks,

Adam

On Wed, Nov 18, 2015 at 5:32 AM Jonas Remmert <j.remm...@phytec.de> wrote:

> Hi Adam,
>
> the CC2650 based board has not yet been released officially. It will
> appear online in a few days. Nevertheless, you can order it right now.
>
> There are two options to purchase:
> 1. Art-No.:(PN-00101-A-001.A1) - Only the CC2650 based evaluation board
> for 39€ + VAT.
> 2. Art-No.:(KPW-IOT-002) - An IoT-Kit bundle for 69€ + VAT that comes
> with:
> - CC2650 based evaluation board
> - TI XDS110 Debug Adapter
> - BLE USB Stick
>
> If you are interested in samples for development, just contact me direclty.
>
> We will be in Nuremberg at the SPS IPC Drives by next week (24.11.-26.11;
> Hall 6, Booth 449), so if you are nearby visit us there.
>
> Best
> Jonas
>
> -"devel" <devel-boun...@riot-os.org> schrieb: -
> An: RIOT OS kernel developers <devel@riot-os.org>
> Von: Adam Hunt
> Gesendet von: "devel"
> Datum: 18.11.2015 13:41
>
> Betreff: Re: [riot-devel] TI CC1310 and CC2650
>
> I searched Phytec's site but was unable to find a CC2650 based board.
>
> On Mon, Nov 16, 2015 at 5:54 AM Jonas Remmert <j.remm...@phytec.de> wrote:
>
>> Hi RIOTers,
>>
>> we at Phytec offer the Evaluation board, described in the Wiki at [1],
>> also with a CC2650 module. The yellow Board is the same as described in the
>> Wiki, just the green PCB module differs by containing an TI CC2650 SoC
>> instead of the Freescale KW2x SiP.
>>
>> The board is currently available for 39€ + VAT. Just write the Phytec
>> sales team at: cont...@phytec.de
>>
>> We don`t support RIOT on the CC2650 right now, but we are very interested
>> in any effort to make RIOT available on the CC2650. Currently, we ship the
>> board with an adapted version of the TI's SensorTag BLE example.
>>
>> If someone needs CC2650 hardware samples for porting or testing feel free
>> to contact us.
>> We would be happy to support your efforts.
>>
>> Best Jonas
>>
>> [1] - https://github.com/RIOT-OS/RIOT/wiki/Board%3A-Phytec-phyWAVE-KW22
>>
>>
>>
>> -"devel" <devel-boun...@riot-os.org> schrieb: -
>> An: RIOT OS kernel developers <devel@riot-os.org>
>> Von: "b...@vpt-systems.co.za"
>> Gesendet von: "devel"
>> Datum: 16.11.2015 10:23
>> Betreff: Re: [riot-devel] TI CC1310 and CC2650
>>
>>
>> Hi Adam
>>
>> I'm looking at the CC13xx and as far as I remember is has a Coretex-M3
>> running.  I have 2 CC1350's on my desk and will most likely start to run
>> them in the next 2 weeks, If all is goes well with my current projects.
>>
>> We are running Contiki on our MSP430 with CC1120 and CC1190 (PA) for our
>> OpenWSN mesh network implementation.  Debugging is a major issue on Contiki
>> so I will be loading RIOT and see what is required in terms of porting
>>
>> TI suggested that I wait for version 2 of the silicon of the CC1350 It
>> should have been release end of Q3 of this year, I'm still waiting..
>> The TI rep will be here today  I hope ..
>>
>> Any suggestions on the porting process?
>>
>> Kind regards
>> Ben
>>
>> On 2015-11-14 04:33 PM, Adam Hunt wrote:
>>
>> Has anyone taken a look at TI's CC2560 or  C1310 processors? They're both
>> based on an a Cortex-M3 processor clocked up to 48 MHz and work in the 2.4
>> GHz and sub-1 GHz bands respectively. I haven't had a chance to read all
>> the documentation yet but they appear similar to the CC2538, aside from one
>> part, they both have a Cortex-M0 based "RF Core" softMAC supporting
>> 802.15.4, 6lowpan, BLE, and ZigBee stacks..
>>
>> Unfortunately, the datasheets state "The ARM Cortex-M0 processor is not
>> programmable by customers." While this may mean that it's not possible to
>> write a custom MAC or port RIOT's to the M0 these could still prove to be
>> useful chips. The documentation states that an image for the softMAC is
>> stored in an chip ROM but it does seem to be field upgradeable but I'm not
>> clear if this is only possible by patching the image stored in ROM each
>> boot or if the patch is permanent opening a potential avenue for custom M0
>> firmware. The documentation doesn't include complete register documentat

Re: [riot-devel] TI CC1310 and CC2650

[Adam Hunt]

I searched Phytec's site but was unable to find a CC2650 based board.

On Mon, Nov 16, 2015 at 5:54 AM Jonas Remmert <j.remm...@phytec.de> wrote:

> Hi RIOTers,
>
> we at Phytec offer the Evaluation board, described in the Wiki at [1],
> also with a CC2650 module. The yellow Board is the same as described in the
> Wiki, just the green PCB module differs by containing an TI CC2650 SoC
> instead of the Freescale KW2x SiP.
>
> The board is currently available for 39€ + VAT. Just write the Phytec
> sales team at: cont...@phytec.de
>
> We don`t support RIOT on the CC2650 right now, but we are very interested
> in any effort to make RIOT available on the CC2650. Currently, we ship the
> board with an adapted version of the TI's SensorTag BLE example.
>
> If someone needs CC2650 hardware samples for porting or testing feel free
> to contact us.
> We would be happy to support your efforts.
>
> Best Jonas
>
> [1] - https://github.com/RIOT-OS/RIOT/wiki/Board%3A-Phytec-phyWAVE-KW22
>
>
>
> -"devel" <devel-boun...@riot-os.org> schrieb: -
> An: RIOT OS kernel developers <devel@riot-os.org>
> Von: "b...@vpt-systems.co.za"
> Gesendet von: "devel"
> Datum: 16.11.2015 10:23
> Betreff: Re: [riot-devel] TI CC1310 and CC2650
>
>
> Hi Adam
>
> I'm looking at the CC13xx and as far as I remember is has a Coretex-M3
> running.  I have 2 CC1350's on my desk and will most likely start to run
> them in the next 2 weeks, If all is goes well with my current projects.
>
> We are running Contiki on our MSP430 with CC1120 and CC1190 (PA) for our
> OpenWSN mesh network implementation.  Debugging is a major issue on Contiki
> so I will be loading RIOT and see what is required in terms of porting
>
> TI suggested that I wait for version 2 of the silicon of the CC1350 It
> should have been release end of Q3 of this year, I'm still waiting..
> The TI rep will be here today  I hope ..
>
> Any suggestions on the porting process?
>
> Kind regards
> Ben
>
> On 2015-11-14 04:33 PM, Adam Hunt wrote:
>
> Has anyone taken a look at TI's CC2560 or  C1310 processors? They're both
> based on an a Cortex-M3 processor clocked up to 48 MHz and work in the 2.4
> GHz and sub-1 GHz bands respectively. I haven't had a chance to read all
> the documentation yet but they appear similar to the CC2538, aside from one
> part, they both have a Cortex-M0 based "RF Core" softMAC supporting
> 802.15.4, 6lowpan, BLE, and ZigBee stacks..
>
> Unfortunately, the datasheets state "The ARM Cortex-M0 processor is not
> programmable by customers." While this may mean that it's not possible to
> write a custom MAC or port RIOT's to the M0 these could still prove to be
> useful chips. The documentation states that an image for the softMAC is
> stored in an chip ROM but it does seem to be field upgradeable but I'm not
> clear if this is only possible by patching the image stored in ROM each
> boot or if the patch is permanent opening a potential avenue for custom M0
> firmware. The documentation doesn't include complete register documentation
> for the M0 but it at least includes the names of the registers. I'm not
> sure if debug access is enabled on the M0 but I would be fairly surprised
> if it were.
>
> Both chips also contain a "sensor controller" CPU that can be configured
> to monitor various peripherals even while the main processor is in standby
> mode which sounds like a nice way to further reduce power consumption. I
> haven't had time to investigate how this processor is configured and
> programmed.
>
> Anyways, even if the embedded softMAC isn't user programmable these look
> like interesting chips. Seeing as they only cost US$29 I'll probably buy
> TI's CC2650 based "SensorTag"[1] dev platform and if I'm feeling especially
> adventurous give porting RIOT to it a try.
>
> --adam
>
> [1]   <http://www.ti.com/sensortag>www.ti.com/sensortag
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] TI CC1310 and CC2650

[Adam Hunt]

Has anyone taken a look at TI's CC2560 or  C1310 processors? They're both
based on an a Cortex-M3 processor clocked up to 48 MHz and work in the 2.4
GHz and sub-1 GHz bands respectively. I haven't had a chance to read all
the documentation yet but they appear similar to the CC2538, aside from one
part, they both have a Cortex-M0 based "RF Core" softMAC supporting
802.15.4, 6lowpan, BLE, and ZigBee stacks..

Unfortunately, the datasheets state "The ARM Cortex-M0 processor is not
programmable by customers." While this may mean that it's not possible to
write a custom MAC or port RIOT's to the M0 these could still prove to be
useful chips. The documentation states that an image for the softMAC is
stored in an chip ROM but it does seem to be field upgradeable but I'm not
clear if this is only possible by patching the image stored in ROM each
boot or if the patch is permanent opening a potential avenue for custom M0
firmware. The documentation doesn't include complete register documentation
for the M0 but it at least includes the names of the registers. I'm not
sure if debug access is enabled on the M0 but I would be fairly surprised
if it were.

Both chips also contain a "sensor controller" CPU that can be configured to
monitor various peripherals even while the main processor is in standby
mode which sounds like a nice way to further reduce power consumption. I
haven't had time to investigate how this processor is configured and
programmed.

Anyways, even if the embedded softMAC isn't user programmable these look
like interesting chips. Seeing as they only cost US$29 I'll probably buy
TI's CC2650 based "SensorTag"[1] dev platform and if I'm feeling especially
adventurous give porting RIOT to it a try.

--adam

[1]  www.ti.com/sensortag
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT Release 2015.09

[Adam Hunt]

Great work!

On Mon, Oct 5, 2015 at 2:50 PM Matthias Waehlisch 
wrote:

> +1
>
> and spread the word that RIOT improves, step by step by the community.
>
>
> Cheers
>   matthias
>
> On Mon, 5 Oct 2015, Emmanuel Baccelli wrote:
>
> > And thank you Oleg for driving "the last mile" for the release!
> >
> > On Mon, Oct 5, 2015 at 11:35 PM, rakendra thapa 
> wrote:
> >   Congratulations team !!
> >
> > Cheers,
> > Rakendra
> >
> > On Tue, Oct 6, 2015 at 3:00 AM,  wrote:
> >   wohoooah!
> >
> >   -Original Message-
> >   From: Emmanuel Baccelli 
> >   To: RIOT OS kernel developers 
> >   Sent: Mo., 05 Okt. 2015 23:11
> >   Subject: Re: [riot-devel] RIOT Release 2015.09
> >
> > YAY!
> >
> > On Mon, Oct 5, 2015 at 10:55 PM, Martine Lenders 
> wrote:
> >
> >   \o/ finally!
> >
> >   /goes to bed
> >
> >   Am 05.10.2015 22:17 schrieb "Oleg Hahm" :
> >   Dear RIOT developers and users,
> >
> >   it has been a long and rocky road, but thanks to the marvellous
> >   community, we
> >   managed to finalize the fifth official release of the RIOT
> operating
> >   system:
> >   ---
> >   * RIOT 2015.09*
> >   ---
> >
> >   The highlights of this release are three major parts:
> >   * gnrc network stack
> >   * xtimer
> >   * cleanup of CPU and board specific code
> >
> >   The new generic ("gnrc") network stack is a highly modular and
> >   configurable
> >   IPv6/6LoWPAN network stack. It implements a large number of IETF
> >   RFCs, such as
> >   RFC 2473, RFC 4861, RFC 4944, RFC 6550, or RFC 6775. Furthermore,
> it
> >   provides
> >   a unified API between the different layers and a generic network
> >   device
> >   interface. The provided 6LoWPAN border router (6LBR) can be run on
> >   any
> >   hardware, providing an IPv6 capable network interface or a UART for
> >   using SLIP
> >   (RFC 1055).
> >
> >   A new timer subsystem is introduced by xtimer, replacing hwtimer
> and
> >   vtimer
> >   modules. xtimer offers very precise timer operations as well as
> >   support for
> >   long-term timers running over days and weeks. Along with well-known
> >   timer
> >   operations in RIOT, it also provides a function for accurate
> >   periodic timers.
> >   In order to ease porting of your existing RIOT code, a vtimer
> >   compatibility
> >   layer can be used on top.
> >
> >   Refactoring and cleaning up the peripheral drivers as well as other
> >   CPU and
> >   board specific code, helped to reduce the number of Makefile
> >   duplication lines
> >   by about 50% and provide a much cleaner and easier to use interface
> >   for
> >   porting new platforms to RIOT.
> >
> >   Of course this release also comes along with a variety of newly
> >   supported
> >   boards, CPUs, and device drivers. RIOT 2015.09 has been ported to
> >   the Eistec
> >   Mulle, Phytec phyWAVE, Zolertia ReMote, Atmel SAML21, various ST
> >   Nucleo
> >   boards, Freescale Freedom, TI Stellaris Launchpad, the LimiFrog,
> and
> >   Silab's
> >   Wonder Gecko. It supports a LC display, new light, motion, and
> >   temperature
> >   sensors, and more accelerometers and magnetometers.
> >
> >   Just to give you a rough estimation about the tremendous amount of
> >   work that
> >   has been put into this release, here are some impressive numbers:
> >   About 580 pull requests with about 2,500 commits have been merged
> >   since the
> >   last release and 120 additional issues have been solved. 62 people
> >   contributed
> >   code in 277 days. 2578 files have been touched with ~320,000
> >   insertions and
> >   ~134,000 deletions.
> >
> >   As a major change to our development procedures, the RIOT community
> >   will offer
> >   long-term bug fixes for this release in a API-stable branch.
> >
> >   You can download the RIOT release from Github, either by cloning
> the
> >   repository or using the tarball:
> >   https://github.com/RIOT-OS/RIOT/archive/2015.09.tar.gz
> >
> >   Happy RIOT,
> >   Oleg
> >   --
> >   printk(CARDNAME": Bad Craziness - sent packet while busy.\n" );
> >   linux-2.6.6/drivers/net/smc9194.c
> >
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
> >
> >
> > ___
> > devel mailing list
> > devel@riot-os.org
> > 

Re: [riot-devel] is the msp430 still supported?

[Adam Hunt]

When you say MSP430 does that include the CC430 that has the
integrated CC1101? How similar is the CC430 compared to a MSP430
and CC1101? Are they 100% compatible?

On Sat, Sep 5, 2015 at 1:42 AM Kaspar Schleiser  wrote:

> Hey,
>
> On 09/05/15 09:16, Eric Decker wrote:
> > or did it get pulled?
> >
> > if so why did it get pulled?
> >
> > and what is needed for support?
>
> msp430 is still supported. Actually, we still consider it as a very
> important platform, also because it is the only 16bit architecture we
> support.
>
> We're just now updating the architecture to use our current peripheral
> API, you'll see severel PR's for uart, timers and GPIO.
>
> Not pulling msp430 support but still consolidating hardware abstraction
> was one of our key release goals. ;)
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] HotSpot JVM on RIOT-OS?

[Adam Hunt]

While I applaud the idea of getting something as heavyweight as a JVM to
run on the type of devices that most of us on this list are targeting have
you thought about non-JVM languages? I've often wondered how small of a
system Erlang could be persuaded to running on.

On Wed, Aug 12, 2015 at 4:47 AM Kaspar Schleiser kas...@schleiser.de
wrote:

 Hey,

 On 08/12/2015 01:36 PM, Zac Harvey wrote:
  still planning on using RIOT-OS if it all possible.

 When you're evaluating embedded JVMs, take a look at the VM used by
 leJOS. It seems like it could rather easily be cut out of the OS, and it
 is apparently very capable even on the lego NXTs (64kb RAM, 256kB
 flash), and seems like more than a research proof-of-concept.

 Kaspar
 ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] OTA update

[Adam Hunt]

A BSDish license with the addition of a poison pill. Too bad.

Though, while I'm certainly not a lawyer of any type I wonder about the
possibility/legality of basing future works off the code without violating
the license.

Another option would be to simply ask the powers that be at Atmel to
relicense the code under a more open model, BSD or MIT.

--adam


On Thu, Jun 18, 2015 at 1:35 AM Kaspar Schleiser kas...@schleiser.de
wrote:

 Hi,

 On 06/17/15 23:34, Baptiste Clenet wrote:
  * 4. This software may only be redistributed and used in connection with
 an
   *Atmel microcontroller product.
   *

 too bad.

 Kaspar
 ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] OTA update

[Adam Hunt]

What license have they released their code under? I'd look myself but I'm
away from my desk.

Adam

On Tue, Jun 16, 2015, 7:41 AM Baptiste Clenet bapcle...@gmail.com wrote:

 Those example are provided with the last version of Atmel Studio (which is
 free). See here [1], the two examples:

 - 6LoWPAN OTA Client Application SAMR21  atsamr21g18a
 - 6LoWPAN OTA Server Application SAMR21 atsamr21g18a

 You will need Atmel Studio to get the source. (Download at [2])

 [1]
 http://194.19.124.62/docs/latest/search.html?board=SAM%20R21%20Xplained%20Pro
 [2] http://www.atmel.com/tools/atmelstudio.aspx

 Baptiste


 2015-06-16 14:45 GMT+02:00 Emmanuel Baccelli emmanuel.bacce...@inria.fr:

 Hi Baptiste,
 do you have an URL to share pointing to the Atmel OTA you're mentioning?
 Thanks,
 Emmanuel

 On Tue, Jun 16, 2015 at 10:34 AM, Baptiste Clenet bapcle...@gmail.com
 wrote:

 By the way, ATMEL has just released an app with OTA on its last Atmel
 Studio version. I think iit could be a good start to develop RIOT's
 OTA.

 Baptiste

 2015-06-09 15:16 GMT+02:00 Kaspar Schleiser kas...@schleiser.de:
  Hey,
 
  On 06/09/2015 01:37 PM, Baptiste Clenet wrote:
 
  - Take into account GSOC project about dynamic linking (Could someone
  provide the name of the guy who is going to work on?)
 
 
  He's called Kushal, I'm his mentor.
 
 
  Kaspar
  ___
  devel mailing list
  devel@riot-os.org
  https://lists.riot-os.org/mailman/listinfo/devel
 ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel



 ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel

  ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT - mac80211

[Adam Hunt]

I forgot to mention, these days most wifi devices are softmac based.
Examples of fullmac drivers are Atheros' AR600x (ath6kl), and Marvel's
libertas USB and SDIO devices.

On Wed, May 27, 2015, 1:21 PM Adam Hunt voxa...@gmail.com wrote:

 Unfortunately, I haven't been able to keep up on all the recent network
 stack work but while working on a WSN project that's currently Linux based
 project I got to wondering about the feasibility of 802.11 support in RIOT.
 I know it's been talked about in the past. Driver and MAC SUPPORT are
 obviously big hurdles. What are the chances that Linux's mac80211 and
 related pieces could be adapted to run on the new network stack?

 I'm not all that familiar with Linux's wireless subsystem; softmac may be
 a bit of a memory hog but devices, even WSN devices are becoming and will
 continue to be more and more capable in the future. If softmac is beyond
 the scope of sanity in a RIOT context maybe fullmac devices and their
 drivers could be used.

 Thanks,

 Adam

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Association time in mobile RPL/6lowpan networks

[Adam Hunt]

I like the idea of sending periodic DIS messages but I absolutely believe
that it should not only be optional but  that it be configurable at
runtime.

Honestly, I am a firm believe in the idea that virtually anything like this
should be runtime configurable as long as such configurability doesn't
adversely effect battery life, code complexity/readability, etcetera in a
massive way. This is something that Linus has absolutely right with Linux;
policy don't shouldn't be written in kernel space stone; everyone had
different requirements and altering the way an OS behaves from the
(sensible) defaults shouldn't require altering mainline code and
maintaining a private branch if at all possible. Ideally everything should
be runtime configurable, if that's not possible it should be configurable
at boot, if that for some reason isn't possible it should be compile time
configurable.

On Wed, May 20, 2015, 11:53 PM Joakim Gebart joakim.geb...@eistec.se
wrote:


 On May 21, 2015 8:37 AM, Cenk Gündogan cenk.guendo...@fu-berlin.de
 wrote:
 
  Hey Adam,
 
  I am currently adopting RPL to our new network stack and while doing so,
  I also added sane functionalities which were plainly missing in the old
 implementation.
  This also includes sending a DIS when initializing RPL for the first
 time.
  However,  I am just now realizing that such a DIS can get lost in our
 typical LLN case - it may make sense to send a DIS periodically until a DIO
 is received?
  Does anyone has an opinion on this?

 Good idea, as long as the periodic interval is large enough to not waste
 power or cause interruptions in normal traffic if there is no other rpl
 node on the network.

 
  Forcing a DIS from userspace sounds like a good feature. It may help in
 testing/debuging the dodag tree interactively.
  I also thought about reseting the trickle timer from userspace to
 enforce DIOs.

 +1 for this. It would be nice to have some shell commands to call these
 functions too.

 Best regards,
 /Joakim

 
  Cheers,
  Cenk
 
 
  On 21.05.2015 04:36, Adam Hunt wrote:
 
  That's great. Is there any way to force a node to send a DIS message
 from userspace?
 
 
  On Wed, May 20, 2015, 5:34 PM Oleg Hahm oliver.h...@inria.fr wrote:
 
  Hi Adam!
 
   Has anyone tested the amount of time it takes for a node (full or
 reduced
   function) to join an RPL routed 6lowpan network? I realize that it's
 very
   likely to vary quite a bit depending on the network, I'm just
 curious if
   anyone has an approximate range.
 
  As you said: it depends quite a bit on the network and the parameters.
 Since
  nodes on the current RPL implementation won't send proactively DIS
 messages
  and the interval of sending DIOs increases, it will usually take just
 a couple
  of seconds if you try to join the network right after bootup, but can
 take
  more than one minute in a later phase.
 
  Cheers,
  Oleg
  --
  printk (KERN_ERR %s: Oops - your private data area is hosed!\n, ...)
  linux-2.6.6/drivers/net/ewrk3.c
  ___
  devel mailing list
  devel@riot-os.org
  https://lists.riot-os.org/mailman/listinfo/devel
 
 
 
  ___
  devel mailing list
  devel@riot-os.org
  https://lists.riot-os.org/mailman/listinfo/devel
 
 
 
  ___
  devel mailing list
  devel@riot-os.org
  https://lists.riot-os.org/mailman/listinfo/devel
 
  ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Switch to BSD?

[Adam Hunt]

I'd be willing to bet that GNU Classpath is one of the oldest projects
licensed under the GPL with a linking exception.

Classpath is distributed under the terms of the GNU General Public License
 with the following clarification and special exception.



Linking this library statically or dynamically with other modules is making
 a combined work based on this library. Thus, the terms and conditions of
 the GNU General Public License cover the whole combination.
 ​​




As a special exception, the copyright holders of this library give you
 permission to link this library with independent modules to produce an
 executable, regardless of the license terms of these independent modules,
 and to copy and distribute the resulting executable under terms of your
 choice, provided that you also meet, for each linked independent module,
 the terms and conditions of the license of that module. An independent
 module is a module which is not derived from or based on this library. If
 you modify this library, you may extend this exception to your version of
 the library, but you are not obliged to do so. If you do not wish to do so,
 delete this exception statement from your version.
 ​[1 https://www.gnu.org/software/classpath/license.html]​


​--adam​


​[1] https://www.gnu.org/software/classpath/license.html​


On Tue Feb 24 2015 at 5:08:12 PM Oleg Hahm oliver.h...@inria.fr wrote:

 Hi Matthias!

but the name (or license branding). We had this discussion before.
  Rather unknown licenses need to be explained. Using eCos license is
  similar to use a RIOT license.

 Yes, I agree, but at least it's listed (approved?) by FSF. Another option
 (see
 citation from the OSI list from my previous mail) we could just state GPL
 as a
 license and point to the exception for commercial users. I think the text
 on
 the eCos page is pretty comprehensible.

 The Wikipedia is even claiming that the perception that without applying
 the
 linking exception, code linked with GPL code may only be done using a
 GPL-compatible license is unsupported by any legal precedent or
 citation.

I'm just wondering if eCos is the first license with the introduced
  exception -- I will not research on this ;).

 I don't think so, but it's the only listed license from FSF that specifies
 the
 linking exception.

I never said it's impossible. In this type of discussion you will
  always find counterexamples. I just wanted to point out that I see it as
  an advantage to use an OSI approved license.

 I agree, but if the choice is between a FSF approved license (as I
 understand
 eCos License is) that matches our needs and a less matching OSI approved
 license, I'm willing to bite this bullet.

   At least eCos, ERIKA and ChibiOS are very similar to RIOT from a
   software architecture point of view (OS for embedded hardware).
  
No comment ;).

 For clarification: I was referring to the fact that these systems have a
 similar use case as RIOT, not that there concept or feature set is similar
 to
 RIOT.

   Long story short: I see your concerns, but for me GPL + Linking
   Exception is a common license model that works well for many
   well-known and mature projects. Personally, I would think that GPL +
   Linking Exception matches our needs far better than LGPL.
  
Can you explain in one our two sentences why? Because it's more
  inclusive?

 Again taken from the Wikipedia article: the LGPL formulates more
 requirements
 to the linking exception: you must allow modification of the portions of
 the
 library you use and reverse engineering (of your program and the library)
 for
 debugging such modifications.

   As I see it now, we won't come to any conclusion for or against
   switching to a non-copyleft license that satisfies everyone, because
   the goals and visions where to go with RIOT are too different.
  
At least we don't get new basic insights with this thread.

 Which is too bad.

 Cheers,
 Oleg
 --
 The problem with TCPIP jokes is that when I tell them, all I want is an
 ACK but
 usually get FINs and RSTs
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Nordic's 6LoWPAN over Bluetooth Low Energy

[Adam Hunt]

While I can think of a few good uses for this chip I'm still not sold on
BLE being a good thing for the Internet of Things. Historically, the
Bluetooth SIG has been less than open. Does anyone remember the SIG having
BlueZ's site (maybe it was just a mailing list) taken down back in about
2004-2005?

The IETF and by extension 15.4 may not be perfect but I'll take open
standards over ZigBee-esque quasi-proprietary protocols like Bluetooth any
day. Not to mention that BT or BLE were never intended to be used in
dynamic, self-healing, multihop, mesh configurations. Sure, it might be
possible but such a setup wasn't accounted for in the original design.

Okay, I think I'm done ranting about my distrust and dislike of the
Bluetooth SIG and its associated spec. Suffice to say, v6 over 15.4 is the
way forward, not Bluetooth, ZigBee, Ant(+), Z-Wave, or any other NDA
encumbered psudostandar.

--adam


On Sun Jan 18 2015 at 11:44:42 AM Christian Mehlis christ...@m3hlis.de
wrote:

 Am 18.01.2015 um 19:28 schrieb Arvid E. Picciani:
  In case you missed it: Nordic demonstrated 6LoWPAN including UDP, TCP,
  CoAP and MQTT, over... yes.. Bluetooth Low Energy. The gateway side
  6lowpan_control is _upstream_ in linux since a while.
 
  http://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluet
 ooth-low-energy/nRF51-IoT-SDK

 The data sheet sounds pretty familiar to RIOTs software stack:

 6lowpan, UDP, coap/mqtt
 http://www.nordicsemi.com/eng/nordic/download_resource/41599/5/50185684

 I'm expecting a huge amount of kickstarter/indigogo projects with *real*
 internet of things in some weeks.

 Forecast: The chip nrf51 will get more fans:)
 I hope Intel as a fan of bt smart will also join the 6low over ble club!

 Best
 Christian
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] MIPS platform (PIC32)

[Adam Hunt]

There are a few papers out there that provide a decent 10,000 foot view (or
3,048 meters, if you prefer).

   - RIOT OS: Towards an OS for the Internet of Things
   http://www.riot-os.org/docs/riot-infocom2013-abstract.pdf
   - RIOT: One OS to Rule Them All in the IoT
   https://hal.inria.fr/file/index/docid/776920/filename/RR-8176.pdf
   - A real-time kernel for wireless sensor networks employed in rescue
   scenarios
   http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5355049
(paywalled
   unfortunately)
   - Simply RIOT: Teaching and Experimental Research in the Internet of
   Things https://hal.inria.fr/hal-01058634/document

Aside from those you should take a look at the Porting Guide
https://github.com/RIOT-OS/RIOT/wiki/Porting-Guide on the wiki if you
haven't already. You might also find the API documentation
http://riot-os.org/api/ useful. Beyond that, someone correct me if I'm
wrong, the canonical documentation can be found in the code itself
https://github.com/RIOT-OS/RIOT.

--adam

On Tue Jan 13 2015 at 1:24:26 PM gnu...@dds.nl wrote:

 Hi Adam,

 Does RIOT use any memory protected (do not think so since MSP430 and
 PIC do not have any) is it using any hardware specific things ?. I am
 new to RIOT that is why I ask. Is there a good ducument about the
 inner workings of RIOY OS so I can see if there are possible issues
 with MIPS.

 Paul.

 Adam Hunt voxa...@gmail.com schreef:

  Is there anything special about the MIPS march that would make porting
 RIOT
  an issue? Seeing as RIOT runs on 32-bit ARMs, 16-bit MSP430s, x86, and
 now
  even 8-bit Atmels I don't imagine there is much standing in the way of
  another incredibly well documented architecture. Though, I've been wrong
  before.
 
  On Tue Jan 13 2015 at 5:16:44 AM gnu...@dds.nl wrote:
 
  Hi Oleg,
 
  I do know the MIPS code very good, I am looking for a good e-book or
  normal book about the ARM core. The MIPS code is more powerfull per
  MHz and also has a better architecture. Its only a pitty that the chip
  technology used is less power optimized than most ARM vendors use that
  is why the sleep and powerdown are higher.
 
  I think this will change since microchip is busy with XLP for PIC32.
 
  regards, Paul.
 
  Oleg o...@hobbykeller.org schreef:
 
   Hi Paul!
  
  
   Does anyone know if people are porting RIOT-OS to the MIPS platform
   and what is the status ?.
  
   As far as I know noone ever tried porting RIOT to MIPS and I know
   too little about this platform to give any estimate about the
   feasibility/difficulty of this task.
  
   Cheers,
   Oleg
   ___
   devel mailing list
   devel@riot-os.org
   http://lists.riot-os.org/mailman/listinfo/devel
 
 
 
  ___
  devel mailing list
  devel@riot-os.org
  http://lists.riot-os.org/mailman/listinfo/devel
 



 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] MIPS platform (PIC32)

[Adam Hunt]

Though, if you ask me, RIOT's code is far cleaner and more approachable
than that of some other projects.

On Tue Jan 13 2015 at 3:15:56 PM Martine Lenders authmille...@gmail.com
wrote:

 Hi,

 2015-01-14 0:10 GMT+01:00 Adam Hunt voxa...@gmail.com:

 […]

 Aside from those you should take a look at the Porting Guide
 https://github.com/RIOT-OS/RIOT/wiki/Porting-Guide on the wiki if you
 haven't already. You might also find the API documentation
 http://riot-os.org/api/ useful. Beyond that, someone correct me if I'm
 wrong, the canonical documentation can be found in the code itself
 https://github.com/RIOT-OS/RIOT.


 At least in most cases the API documentation is auto-generated (daily
 iirc) from the canonical documentation these days. For everything else the
 law of code is still a vicious and cruel ruler ;-).

 Cheers,
 Martine
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] new iot hardware from intel: curie

[Adam Hunt]

Interesting, I'd love a little more information on the open source RTOS.
I'd also like to a see hardware with a 15.4 capable radio. BLE *may* have
its place but as it stands now, without CSR mesh solutions being embraced
it's not as an appropriate a solution as 6lowpan over 15.4 for many
applications. Even with CSR it may not be the the right direction.

On Wed Jan 07 2015 at 8:21:53 AM Christian Mehlis christ...@m3hlis.de
wrote:

 hi *,

 first IoT hardware from intel:

 http://www.heise.de/newsticker/meldung/CES-Intel-
 stellt-Entwicklermodul-Curie-fuer-Wearables-vor-2512593.html

 [...32-Bit-Prozessor aus Intels Quark-Schiene, welchem 80 KByte SRAM und
 384 KByte Flash-Speicher zur Seite stehen, auch noch einen
 6-Achsen-Sensor (Beschleunigung und Gyroskop), einen DSP-Sensorhub samt
 Auswertungs-Engine, eine Bluetooth-LE-Einheit sowie einen
 Lade-Controller für Akkus]

 Best
 Christian
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Searchable devel@riot-os.org archive

[Adam Hunt]

I've been meaning to let everyone know that RIOT's development list is now
archived on Gmane http://gmane.org. The group name is gmane.os.riot.devel
http://news.gmane.org/gmane.os.riot.devel/ and it includes every message
sent since the list was created. The archive is fully searchable and also
available via the NNTP for those that prefer it (or even remember it).

I've also requested that the user list be archived there and for the older
messages be added to the archive but the request hasn't yet been completed
(likely because no messages have been posted since 2014.12.18).

Adam Hunt
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Switch to BSD?

[Adam Hunt]

 At risk of further confusing things maybe there's a happy medium between a
strong copyleft/(L)GPL and a the BSD license. While I'm most certainly not
a lawyer, copyright or otherwise, a quick look at the Eclipse Public License
https://eclipse.org/org/documents/epl-v10.php (EPL) and the related EPL
FAQ https://eclipse.org/legal/eplfaq.php# makes me wonder if it might be
another possibility. The way I read it the EPL would keep RIOT itself free
and open, along with any changes a person or company makes to the core OS,
in-tree drivers, etc... but would also allow for extensions to be made
and distributed under whatever license the creator sees fit (open or not).
It seems to me that this would end up in a similar situation to what Ludwig
suggested in his license craziness post but in a slightly more sane way.

Point 27 in the EPL FAQ seems to be very applicable to what we're all
talking about here.

   -
   - I‘m a programmer not a lawyer, can you give me a clear cut example of
   when something is or is not a derivative work?

   If you have made a copy of existing Eclipse code and made a few minor
   revisions to it, that is a derivative work. If youve written your own
   Eclipse plug-in with 100% your own code to implement functionality not
   currently in Eclipse, then it is not a derivative work. Scenarios between
   those two extremes will require you to seek the advice of your own legal
   counsel in deciding whether your program constitutes a derivative work.

   For clarity, merely interfacing or interoperating with Eclipse plug-in
   APIs (without modification) does not make an Eclipse plug-in a derivative
   work.

One potential issue with the EPL is GPL (in)compatibility. The FSF has
stated that GPL code can not be linked or otherwise incorporated into an
EPL licensed codebase. While the EPL isn't GPL compatible I'm reasonably
certain that it *is *compatible with the LGPL. A fairly informative post on
the topic of EPL/(L)GPL compatibility can be found on Stack Overflow here
https://stackoverflow.com/questions/5393873/epl-eclipse-public-license-gpl-gnu-public-license-lgpl-lesser-gpl-and-lic
.

Another issue with using the EPL is the choice of law clause which states
that This Agreement is governed by the laws of the State of New York and
the intellectual property laws of the United States of America. That would
most certainly need to be altered.

Anyway, I just figured I'd mention this as another potential license.


On Mon Dec 15 2014 at 12:03:19 PM Emmanuel Baccelli 
emmanuel.bacce...@inria.fr wrote:

 Hi Oleg,

 On Mon, Dec 15, 2014 at 6:39 PM, Oleg Hahm oliver.h...@inria.fr wrote:

 Hey Hauke!

  To my experience the typical situation in
  (larger) companies is, that technical people actually would like to work
  with LGPL products an give code back but that they are not allowed to
 from
  their management due to their lawyers not allowing LGPL. For MIT I see a
  different picture: from my experience there are mostly strong rules in
  industry about choosing a certain license, but not so many about giving
 back
  changes to the community.

 Actually, the person from FSFE we've contacted told us that the attitude
 of
 several executives towards open source software is: Oh, it's free, but
 you
 have to contribute back? Okay, then we have to live with that. or Oh,
 it's
 free and we don't have to give anything back? Great, why the hell should
 you
 publish our code. Don't do it!

 (Of, course there might be many more executives just saying: Oh, it's
 free,
 but you to contribute back? Don't even think about touching it!)



 It's not entirely surprising that FSF is advocating (L)GPL ;)
 The crux here is: are there constraints specific to IoT software, that
 make LGPL too often problematic, technically?
 I think that's what Hauke (among others) was hinting at.



  (iii) Last I think the community is not influenced very much by
 changing to
  MIT. It's not like a company can take the code and forbid anyone to
 continue
  working on RIOT. If the is a company taking the code, developing it
 further
  internally and selling the results without sharing it can happen. But
 in the
  mean time RIOT will move on (and that fast to the current point) and
 that
  means the motivation for paying for a closed-down RIOT clone instead of
  using the open Original is not very high.

 I second this thought! As Kaspar has written, too: It's all about the
 community and the fun time spending with this awesome tool. It's gonna be
 always free and open source, no matter what stupid companies try to do
 with it
 behind closed doors. We are RIOT, the rest is just code!


 +1


 Emmanuel
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Switch to BSD?

[Adam Hunt]

I entirely understand where Johann is coming from. My view are very
similar; companies all over the world beat up on Linux in the early days
because of the GPL but all these years later things have died down and
multibillion dollar transnational corporations are not only still
contributing to the Linux kernel but are increasing their involvement. If
you had asked me fifteen years ago if I thought Microsoft would be
contributing I would have likely laughed in your face. The Linux kernel is
proof that the GPL *is* a real option for open projects.

That being said... I still wonder if even a quite permissive copyleft
license like the LGPL is truly suitable for an embedded operating system.
We all know how even little changes to an embedded system can require deep
changes to the core of the OS. More than anything I'd like to see RIOT
succeed and take its place as one of the core components in the IOT world
but I think the choice of license that covers the core OS is going to play
an incredibly important part in deciding whether or not that is going to
happen. In my ever so humble opinion RIOT is in an unbelievably strong
position from a technical standpoint but unfortunately we don't necessarily
live in a world run by meritocrats.

In my opinion there are *at least* two things that need to be figured out
for an open project like RIOT to succeed and they're inexorably
intertwined. Those things are license and community structure/governance. A
project's core license and its community structure each have a huge impact
on the other and the project as a whole.

I suppose I'm a little more on the fence than I originally thought. Or,
maybe I just want to make sure that all potential outcomes are evaluated
and the decisions that are made are well thought out. A license change is a
fairly large undertaking and is fraught with potential peril. A change from
a copyleft license to a more permissive license, be it BSD, MIT, X11 or
something similar can never be undone; once the code has be released it can
never entirely be brought back under a copyleft license. Of course it can,
but doing so doesn't eliminate the liberally licensed version from the
universe and the project can be easily forked from using that code.

Emmanuel made a great point when he said that we should distinguish between
the two aspects of the change, the idea, and the effects in practice. In an
more ideal world *I* would like to see the LGPL win out but in terms of
practicality I wonder if companies and even research groups are going to be
willing to take on the additional workload that the LGPL demands in the
form of making each and every one of their changes available to their end
users and in turn to the wider community.

There's another option on the table that would allow a potential license
change to be put off for some time while still being able to do it with
minimal headache down the road. Any license change is obviously going to
require all the past contributors to agree to it so what about keeping the
LGPL license for now and asking those contributors and future contributors
to sign an SLA. One of the downsides to an SLA is that a legal entity (e.g.
RIOT e.v.) would have to be created and managed.

Okay, that's enough from me for the moment.There are other things in my
life that I must attend to and Monday is near a close.

Adam Hunt


On Mon Dec 08 2014 at 1:49:32 PM Johann Fischer johann_fisc...@posteo.de
wrote:

 Hello RIOTers,

 Emmanuel Baccelli emmanuel.bacce...@inria.fr wrote:
  we have been receiving an increasing amount of negative feedback from
  various companies concerning the practical usability of our LGPL license
 in
  their context, being a show-stopper.

 They always do that. We have seen it in other successful projects such as
 linux
 kernel. I see RIOT as a part of a free an open infrastructure.
 And for the IoT we need an open infrastructure. There are
 companies that use (public) infrastructure but want to give anything back
 and
 BSD license favored this behavior. RIOT should not be another Contiki.

  But in the first place, we would like to debate this topic. In
 particular:
  is anyone violently opposing the idea of migrating to a less restrictive
  license, such as BSD? If so, why? On the other hand, if you explicitly
  support the license change, feel free to indicate this as well. Please
 send
  your opinion to the list before Dec. 10th.

 I am absolutely against the BSD license and I see no necessity for it. RIOT
 will be successful without this change.

 That is my personal opinion, not the company where I work.

 Best regards
 Johann Fischer
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Refectoring the network stack

[Adam Hunt]

Will this refactoring effort allow for multiple interfaces on a single RIOT
device?

What about bringing the border router support back into a state where a
real, well designed RIOT based border router? Or, is the role of a border
router better filled by Linux and the associated 15.4 driver work that's
being done.

On Thu Nov 06 2014 at 10:24:24 AM Martine Lenders authmille...@gmail.com
wrote:


 Am 06.11.2014 18:56 schrieb Adam Hunt voxa...@gmail.com:


 
  I'm sorry, somehow I missed the point where you mentioned 802.15.4e.
 Feel free to ignore me. After last night I shouldn't be allowed to post in
 public forums full of people smarter than I.

 No need to be sorry. I'm guilty of this falacy, too! xD

 
  --adam
 
  On Nov 6, 2014 9:46 AM, Martine Lenders authmille...@gmail.com
 wrote:
 
  Hi Adam,
 
  Am 06.11.2014 18:38 schrieb Adam Hunt voxa...@gmail.com:
  
   Is support for TSCH in there somewhere? While I'm not entirely read
 up on the spec it would seem to be fairly important these days.
  
   What is the current state of TSCH support in RIOT these days? I'm
 stuck on my phone at the moment or I'd take a look for myself (really, it
 probably has a bit more to do with my being hungover and slightly lazy this
 morning).
 
  Currently use the already existing TSCH implentation OpenWSN. So that's
 where it is hiding ;)
 
  Cheers,
  Martine
 
  
   --adam
  
   On Nov 5, 2014 9:15 AM, Martine Lenders mlend...@inf.fu-berlin.de
 wrote:
  
   Hi,
   as discussed on the virtual meeting we aim to have the new network
 stack running with the next release (end of November or before christmas).
 Currently, I'm the only one directly involved into the development (appart
 from several radio driver implementations), and while parts of the model
 come from me, Hauke is currently refining it. As for development it is
 clear, that I can't be the only one working on it.
  
   I'm currently in the testing stage of 6LoWPAN but it is mostly done,
 but I still need some kind of way to communicate with the transceiver
 module for older boards (alternative would be to remove it, but for this we
 need #1772 and #1733 merged and all boards moved to the low-level driver
 model). I hope I have this done at the end of next week.
  
   All in all it's still a long way to the transport layer and to speed
 things up, I thought some of you guys may want to help me. I tried to split
 down the tasks at hand and assigned preliminary some people who might be
 able to do it. If you do not want/can not do this task, please notify this.
 Also if you want to take over a task do tell so too, please. Every
 assignment with a question mark is not fixed yet.
  
   * Model (Martine? and Hauke)
   * 6LoWPAN
 - backwards compatibility with transceiver module (Martine)
 - bug-hunting (Martine)
 - ND according to https://tools.ietf.org/html/rfc6775 (Martine?,
 depends on a running ND for IPv6)
 - optional: Next header compression (Oleg?)
   * IPv6
 - port to netapi and pktbuf and remove 6LoWPAN dependency
 (Martine?)
 - consistent and extendable IPv6 Extension Header API (Martine?)
 - consistent and extendable ICMPv6 API (Lotte?)
 - Neighbor discovery according to
 http://tools.ietf.org/html/rfc4861 (Martine?, depends maybe on ICMPv6
 API, but can be done without it, I guess)
   * Transport layer
 - port to netapi and pktbuf (Cenk?)
  
   * optional tasks for full deprecation of `transceiver`:
 - port OpenWSN (would this also include an IEEE 802.15.4e MAC
 layer?) and CCNlite to netapi or netdev
 - port boards that use cc110x to periph API or port cc110x_legacy
 and cc110x_legacy_csma to netdev
 - either removal or port to netdev of redbee-econotag
  
  
   ___
   devel mailing list
   devel@riot-os.org
   http://lists.riot-os.org/mailman/listinfo/devel
  
  
   ___
   devel mailing list
   devel@riot-os.org
   http://lists.riot-os.org/mailman/listinfo/devel
  
 
 
  ___
  devel mailing list
  devel@riot-os.org
  http://lists.riot-os.org/mailman/listinfo/devel
 
 
  ___
  devel mailing list
  devel@riot-os.org
  http://lists.riot-os.org/mailman/listinfo/devel
 
  ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT/OpenWSN and TSCH support

[Adam Hunt]

I'd love to attend IETF93 if for no other reason than I have yet to get
myself to Prague. Unfortunately, I don't think I'll be about to swing the
US$1200 in airfare plus accommodations. I really need to find myself some
wealthy benefactor interested in WSN research.

On Thu, Nov 6, 2014 at 11:27 AM, Oleg Hahm oliver.h...@inria.fr wrote:

 Hi Thomas!

  Note that the 6TiSCH WG, in conjunction with ETSI, will organize a 6TiSCH
  interop event during IETF93 (July 2015, Prague) around 6TISCH technology,
  so including IEEE802.15.4e TSCH. You (and RIOT of course!) might be
  interested in participating. The plan is to come up with writing the test
  spec by March 2015.

 We will most certainly participate - and not only because Prague is just a
 stone's throw (how RIOTy...) away from Berlin. ;-)

  BTW, I happen to be giving a talk about OpenWSN in 90min (
 
 https://swarmlab.eecs.berkeley.edu/events/2014/8/22/5118/openwsn-technical-overview-status-and-road-ahead
 ),
  which is streamed live online. I'll talk about the RIOT integration, so
 you
  might be interested to listen.

 By the way, thanks for the nice mentioning of RIOT this morning at the
 IoT-Lab
 inauguration.

 Cheers,
 Oleg
 --
 /* panic??  These should never occur in our application. */
 linux-2.6.6/drivers/scsi/aic7xxx/aiclib.c

 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT/OpenWSN and TSCH support

[Adam Hunt]

What are the chances that there will be video of this talk available for
those of us who aren't so fortunate to live in the vicinity of IoT-Lab?

On Thu Nov 06 2014 at 11:36:53 AM Oleg Hahm oliver.h...@inria.fr wrote:

 Hey Thomas!

  Happy to mention RIOT, I didn't know you were there :-)

 Yes, tomorrow I'll give a tutorial about RIOT on IoT-Lab. It was very nice
 talk, by the way. Particular, taking the time of day into account. ;-)

 Cheers,
 Oleg
 --
 The best thing about declarative jokes is that you only have to prescribe
 laughter, no need to actually tell the joke.
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel