Re: [riot-devel] Benchmarks

[Ludwig Ortmann]

Hi,

I think our only m0+/802.15.4 board is the samr21-xpro and there are problems 
with the current/old network stack because of its memory demands.
That said: which  protocol on top of IP are you interested in?
I assume you want to ignore RPL and any other side-tasks for this evaluation?

Cheers,
Ludwig

Am 17. März 2015 17:46:52 MEZ, schrieb Simon Vincent :
>Hi Craig,
>
>We have a 802.15.4 transceiver that is capable of 250kbps. We are 
>thinking of using this with a Cortex M0+ but wanted to make sure that 
>the M0+ would have the processing power to handle the 
>802.15.4/6lowpan/ipv6 stack at a datarate of 250kbps.
>
>I just wondered if anyone had done any datarate measurements on
>existing 
>development boards using the Cortex M0+?
>
>- Simon
>
>On 17/03/15 16:20, Craig Younkins wrote:
>> Hi Simon,
>>
>> Throughput will be highly dependent upon the RF environment and what 
>> transceiver you are using. The M0+ most likely has enough power to do
>
>> it under ideal conditions, but retransmissions due to collisions will
>
>> limit the effective bandwidth.
>>
>> You can use 900 mhz and 2.4 ghz transceivers with 15.4. ~900 is 
>> significantly less crowded but lower theoretical bandwidth. The Atmel
>
>> 212B is 900 Mhz and specs 1000 kbps as the max air data rate.
>>
>> Which transceiver are you using?
>>
>> Craig Younkins
>>
>> On Tue, Mar 17, 2015 at 11:42 AM, Simon Vincent 
>> mailto:simon.vinc...@xsilon.com>> wrote:
>>
>> Has anyone done any performance tests to see what throughput can
>> be achieved using RIOT?
>>
>> I would be interested to know if the Cortex M0+ is powerful
>enough
>> to sustain 250Kb/s TCP over 6lowpan/802.15.4.
>>
>> Does RIOT have any mechanism to measure CPU usage?
>>
>> - Simon
>> ___
>> 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

[riot-devel] BLE stack - GSoC

[Kausthub Naarayan]

hi ,

this is the diagram used for BLE software architecture
what is host and controller in this figure ?


​

Is this the correct way to approach the Project N2 - BLE stack?

thank you
-- 
Regards
Kausthub Naarayan B
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Google Summer of Code 2015

[Kasun Dinal Kurukulasooriya]

Hi,

I am a Computer Science Engineering undergraduate from University of
Moratuwa. I am very interested in IoT related projects and writing low
level high performance code with C/C++.

Most interesting idea I found was 'Support for Bluetooth Low Energy aka
Bluetooth Smart'. I think when it comes to IoT wireless transmission is
very crucial so I hope to work hard on this project. I have worked with
Bluetooth modules with controllers and sure it will give me a good base to
start.

As an intern I have experience with writing low level code to be ran on
embedded systems for Denso, Japan and I hope use my skills in contributing
to RIOT too.

Thank you.
Dinal Kurulasooriya,
University of Moratuwa,
Sri Lanka.
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Benchmarks

[Simon Vincent]

Hi Craig,

We have a 802.15.4 transceiver that is capable of 250kbps. We are 
thinking of using this with a Cortex M0+ but wanted to make sure that 
the M0+ would have the processing power to handle the 
802.15.4/6lowpan/ipv6 stack at a datarate of 250kbps.


I just wondered if anyone had done any datarate measurements on existing 
development boards using the Cortex M0+?


- Simon

On 17/03/15 16:20, Craig Younkins wrote:

Hi Simon,

Throughput will be highly dependent upon the RF environment and what 
transceiver you are using. The M0+ most likely has enough power to do 
it under ideal conditions, but retransmissions due to collisions will 
limit the effective bandwidth.


You can use 900 mhz and 2.4 ghz transceivers with 15.4. ~900 is 
significantly less crowded but lower theoretical bandwidth. The Atmel 
212B is 900 Mhz and specs 1000 kbps as the max air data rate.


Which transceiver are you using?

Craig Younkins

On Tue, Mar 17, 2015 at 11:42 AM, Simon Vincent 
mailto:simon.vinc...@xsilon.com>> wrote:


Has anyone done any performance tests to see what throughput can
be achieved using RIOT?

I would be interested to know if the Cortex M0+ is powerful enough
to sustain 250Kb/s TCP over 6lowpan/802.15.4.

Does RIOT have any mechanism to measure CPU usage?

- Simon
___
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] Benchmarks

[Craig Younkins]

Hi Simon,

Throughput will be highly dependent upon the RF environment and what
transceiver you are using. The M0+ most likely has enough power to do it
under ideal conditions, but retransmissions due to collisions will limit
the effective bandwidth.

You can use 900 mhz and 2.4 ghz transceivers with 15.4. ~900 is
significantly less crowded but lower theoretical bandwidth. The Atmel 212B
is 900 Mhz and specs 1000 kbps as the max air data rate.

Which transceiver are you using?

Craig Younkins

On Tue, Mar 17, 2015 at 11:42 AM, Simon Vincent 
wrote:

> Has anyone done any performance tests to see what throughput can be
> achieved using RIOT?
>
> I would be interested to know if the Cortex M0+ is powerful enough to
> sustain 250Kb/s TCP over 6lowpan/802.15.4.
>
> Does RIOT have any mechanism to measure CPU usage?
>
> - Simon
> ___
> 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] Benchmarks

[Simon Vincent]

Has anyone done any performance tests to see what throughput can be 
achieved using RIOT?


I would be interested to know if the Cortex M0+ is powerful enough to 
sustain 250Kb/s TCP over 6lowpan/802.15.4.


Does RIOT have any mechanism to measure CPU usage?

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

Re: [riot-devel] Radio duty cycling

[Emmanuel Baccelli]

On Tue, Mar 17, 2015 at 4:31 PM, Ken Bannister  wrote:

> Oleg,
>
>
>>>  There's definitely a need for generic MAC layer solutions in RIOT,
>> besides the
>> specific solutions like CSMA in the cc110x driver or TiSCH for 802.15.4e
>> as
>> part of the OpenWSN stack. As far as I know, at least two people are
>> currently
>> working on MAC layer implementations for RIOT. I will also take a look
>> into
>> this topic with the goal to use only the MAC layer part of the OpenWSN
>> stack
>> as a standalone module in RIOt.
>>
> I think your idea to cut its stack at the MAC layer is a good fit for both
> projects.
> Use OpenWSN for its efficient and reliable 15.4e and 6TiSCH MAC/adaptation
> layers,
> and RiOT for its higher level layers and libraries.



+1

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

Re: [riot-devel] Radio duty cycling

[Ken Bannister]

Oleg,

I'm a contributor to OpenWSN, making a first post here based on your 
mention below.



On 03/17/2015 02:58 PM, Oleg Hahm wrote:

Hi Joakim!


What is the current state of radio duty cycling in RIOT?
I know that radio drivers implement on and off functions for the chip, but
how do we make the best use of them?
​In order to reduce power consumption it will be necessary to duty cycle
the radio​

I would agree with Martine: usually, duty cycling should be rather part of the 
MAC
layer than of the driver. However, embedded transceiver devices usually are
designed for one particular MAC layer and splitting this up in a sensible way
is not always easy/feasible.

Do you have any concrete ideas of functionality for a generic radio
transceiver the driver (netdev) API should provide?


​For comparison, in
​Contiki there are multiple RDC drivers that can be switched​ between at
compile time, the most well-known is ContikiMAC [1]. Something similar
would be very useful in battery powered scenarios for RIOT.

There's definitely a need for generic MAC layer solutions in RIOT, besides the
specific solutions like CSMA in the cc110x driver or TiSCH for 802.15.4e as
part of the OpenWSN stack. As far as I know, at least two people are currently
working on MAC layer implementations for RIOT. I will also take a look into
this topic with the goal to use only the MAC layer part of the OpenWSN stack
as a standalone module in RIOt.
I think your idea to cut its stack at the MAC layer is a good fit for 
both projects.
Use OpenWSN for its efficient and reliable 15.4e and 6TiSCH 
MAC/adaptation layers,

and RiOT for its higher level layers and libraries.

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

Re: [riot-devel] OTA meetup 11.2.2015

[Baptiste Clenet]

Hi Ludwig,

That's fine :-)
Great! I'm looking forward to seeing it.
I'm not on a early deadline but you know the sooner it is, the better it
will be ;-)

Cheers,

2015-03-17 15:45 GMT+01:00 Ludwig Ortmann :

> Hi Baptiste,
>
> I was/am extremely busy with non-RIOT work, so please bear with me ;)
> An update will follow soonish.
>
> If you're on a deadline say so and I can look if I can squeeze it in
> somehow.
>
> Cheers,
> Ludwig
>
> Baptiste Clenet schrieb:
> > Arvid, Ludwig, any improvements concerning OTA?
> >
> > Cheers,
> >
> >
> >
> > 2015-03-09 15:12 GMT+01:00 Baptiste Clenet :
> >
> >> Hi,
> >>
> >> Ludwig, how is the planning going ?
> >> Could you create a wiki page (like [1]) or an issue (like [2])  with
> >> description of the work to do as well as assignment for each task?
> >> Everybody will know how it is going then.
> >> What do you think about it?
> >>
> >> Cheers,
> >>
> >> [1] https://github.com/RIOT-OS/RIOT/wiki/Timer-Task-Force
> >> [2] https://github.com/RIOT-OS/RIOT/issues/2278#issuecomment-73411503
> >>
> >> 2015-02-22 10:35 GMT+01:00 Ludwig Ortmann  >:
> >>
> >>> Hi,
> >>>
> >>> On Mon, Feb 16, 2015 at 06:41:05PM +0100, Oleg Hahm wrote:
> >>> > > the minutes from the meeting have been added to our wiki:
> >>> > > https://github.com/RIOT-OS/RIOT/wiki/minutes-OTA-meetup-13.2.2015
> >>> >
> >>> > Have there any concrete next steps been identified? Did you conclude
> >>> in
> >>> some
> >>> > kind of a schedule for upcoming tasks and who is gonna work on what?
> >>>
> >>> There has been some preliminary scheduling, we will announce more
> >>> concrete planning soon, possibly in the form of an issue.
> >>>
> >>> Cheers, Ludwig
> >>> ___
> >>> devel mailing list
> >>> devel@riot-os.org
> >>> http://lists.riot-os.org/mailman/listinfo/devel
> >>>
> >>
> >>
> >>
> >> --
> >> *Clenet Baptiste*
> >>
> >>
> >
> >
> > --
> >
> > *Clenet BaptisteFR: +33 6 29 73 05 39*
> > ___
> > 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
>



-- 

*Clenet BaptisteFR: +33 6 29 73 05 39*
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Radio duty cycling

[Oleg Hahm]

Hi Joakim!

> What is the current state of radio duty cycling in RIOT?
> I know that radio drivers implement on and off functions for the chip, but
> how do we make the best use of them?
> ​In order to reduce power consumption it will be necessary to duty cycle
> the radio​

I would agree with Martine: usually, duty cycling should be rather part of the 
MAC
layer than of the driver. However, embedded transceiver devices usually are
designed for one particular MAC layer and splitting this up in a sensible way
is not always easy/feasible.

Do you have any concrete ideas of functionality for a generic radio
transceiver the driver (netdev) API should provide?

> ​For comparison, in
> ​Contiki there are multiple RDC drivers that can be switched​ between at
> compile time, the most well-known is ContikiMAC [1]. Something similar
> would be very useful in battery powered scenarios for RIOT.

There's definitely a need for generic MAC layer solutions in RIOT, besides the
specific solutions like CSMA in the cc110x driver or TiSCH for 802.15.4e as
part of the OpenWSN stack. As far as I know, at least two people are currently
working on MAC layer implementations for RIOT. I will also take a look into
this topic with the goal to use only the MAC layer part of the OpenWSN stack
as a standalone module in RIOt.

Cheers,
Oleg
-- 
panic("do_trap: can't hit this");
linux-2.6.6/arch/i386/mm/extable.c


pgppiqJ16f3Gu.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] OTA meetup 11.2.2015

[Ludwig Ortmann]

Hi Baptiste,

I was/am extremely busy with non-RIOT work, so please bear with me ;)
An update will follow soonish.

If you're on a deadline say so and I can look if I can squeeze it in somehow.

Cheers,
Ludwig

Baptiste Clenet schrieb:
> Arvid, Ludwig, any improvements concerning OTA?
>
> Cheers,
>
>
>
> 2015-03-09 15:12 GMT+01:00 Baptiste Clenet :
>
>> Hi,
>>
>> Ludwig, how is the planning going ?
>> Could you create a wiki page (like [1]) or an issue (like [2])  with
>> description of the work to do as well as assignment for each task?
>> Everybody will know how it is going then.
>> What do you think about it?
>>
>> Cheers,
>>
>> [1] https://github.com/RIOT-OS/RIOT/wiki/Timer-Task-Force
>> [2] https://github.com/RIOT-OS/RIOT/issues/2278#issuecomment-73411503
>>
>> 2015-02-22 10:35 GMT+01:00 Ludwig Ortmann :
>>
>>> Hi,
>>>
>>> On Mon, Feb 16, 2015 at 06:41:05PM +0100, Oleg Hahm wrote:
>>> > > the minutes from the meeting have been added to our wiki:
>>> > > https://github.com/RIOT-OS/RIOT/wiki/minutes-OTA-meetup-13.2.2015
>>> >
>>> > Have there any concrete next steps been identified? Did you conclude
>>> in
>>> some
>>> > kind of a schedule for upcoming tasks and who is gonna work on what?
>>>
>>> There has been some preliminary scheduling, we will announce more
>>> concrete planning soon, possibly in the form of an issue.
>>>
>>> Cheers, Ludwig
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> http://lists.riot-os.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>> *Clenet Baptiste*
>>
>>
>
>
> --
>
> *Clenet BaptisteFR: +33 6 29 73 05 39*
> ___
> 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] NSTF radio driver

[Thomas Eichinger]

Hi Joakim,

sorry for the silence on this. The driver is almost ready I’ll open a
PR for it by Thursday at latest. I was discussing with Hauke the initialisation
process for the network stack and also initialisation in general.

I saw these memory corruptions too, but didn’t manage to identify the
source neither as I focused on the driver refactoring.

Looking forward for your review and testing.

Best, Thomas

> On 17 Mar 2015, at 12:42, Joakim Gebart  wrote:
> 
> Hi Thomas,
> 
> On Fri, Feb 20, 2015 at 10:53 AM, Thomas Eichinger
>  wrote:
>> Hi Joakim,
>> 
>> On 20 Feb 2015, at 9:31 CET(+0100), Joakim Gebart wrote:
>> 
>>> Thank you for the prompt response. I will start reading the existing
>>> drivers but I think I will wait at least until there is a PR for the rf231
>>> before I begin my implementation work.
>> 
>> As Peter mentioned I'm working hard on refactoring the rf2xx driver. As we
>> want to use it on EmbeddedWorld on Tuesday you can expect a PR for this
>> soonish. :-)
> 
> How is the new rf2xx driver coming along?
> 
> I have been seeing some memory corruption problems on my platform and
> I think it originates somewhere in the radio stack, but I have not
> managed to pinpoint it further. I would like to test the new driver
> before I spend more time chasing down a bug that might have already
> been fixed in the refactoring process.
> 
> Is there any WIP branch we can look at?
> Do you have any ETA for a PR?
> 
> Best regards,
> Joakim
> ___
> 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] NSTF radio driver

[Joakim Gebart]

Hi Thomas,

On Fri, Feb 20, 2015 at 10:53 AM, Thomas Eichinger
 wrote:
> Hi Joakim,
>
> On 20 Feb 2015, at 9:31 CET(+0100), Joakim Gebart wrote:
>
>> Thank you for the prompt response. I will start reading the existing
>> drivers but I think I will wait at least until there is a PR for the rf231
>> before I begin my implementation work.
>
> As Peter mentioned I'm working hard on refactoring the rf2xx driver. As we
> want to use it on EmbeddedWorld on Tuesday you can expect a PR for this
> soonish. :-)

How is the new rf2xx driver coming along?

I have been seeing some memory corruption problems on my platform and
I think it originates somewhere in the radio stack, but I have not
managed to pinpoint it further. I would like to test the new driver
before I spend more time chasing down a bug that might have already
been fixed in the refactoring process.

Is there any WIP branch we can look at?
Do you have any ETA for a PR?

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

Re: [riot-devel] ESP8266 - Easy tcp/ip support

[David Lyon]

Hi Martine,

On 2015-03-17 20:49, Martine Lenders wrote:

We currently don't have an example for an embedded stack, but I guess
the ESP8266 would be great to supply such an example. Since the
ESP8266 supplies, as far as I understand it, everything up to tcp and
udp, I would propose not to write a netdev driver for it, but writing
a netapi threads directly, one for TCP and one for UDP, so our future
new socket API speaks directly to it. If you need some inspiration how
to implement a transport layer thread have a look at Hauke's
prelimanary UDP implementation [1].


I will check that.


If there are no timing issues over speaking to the devices registers
over e.g. SPI directly (if it is possible this way at all), we can try
that, but in general I would prefer the solution that yields the
better performance.


It's a UART/Serial interface so there's no SPI. There's memory limits
on the LUA firmware so it's not suited to big amounts of data going
through. The Lua interface currently operates at 9600.


Since it would show the flexibility of our new network stack this chip
would be a great option! :-)


It would give TCP/UDP/MQTT pretty quickly.

Regards

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

Re: [riot-devel] Need help about RIOT radio communicate example

[Thomas Eichinger]

Hi Chen,

I can remember having the same problem with the telosb. I traced it down 
to the fact, that there are no interrupts triggered. Which is strange
as the same code is working on an other msp430/cc2420 platform (Zolertia Z1).
Maybe a misconfiguration somehow sneaked into the radio driver setup.

As I don’t have a TelosB anymore I can’t debug it in more detail right now,
but maybe this gives you a hint.

Best, Thomas

> On 16 Mar 2015, at 19:11, Oleg Hahm  wrote:
> 
> Hi Chen!
> 
>> I connect 2 telosb to 2 USB port and used 2 terminal to "make term" to each
>> telosb board.
> 
> I guess you're using the default example, right?
> 
>> Then I use one board to txtsnd to other board address. But there is no
>> reaction from the other board. (For native mode, the other should show
>> received packets).
> 
> Do you have the possibility to use a sniffer somehow? This could be helpful to
> check if it is a sender or a receiver problem. You could also try to use "make
> debug" or set ENABLE_DEBUG to 1 in drivers/cc2420/cc2420_rx.c (cc2420_tx.c
> respectively), to figure out what fails. The last time I checked the driver
> was working, but I cannot verify right now, because I don't have any
> cc2420-based hardware here.
> 
> Thomas, Kévin, could one of you verify the problem?
> 
>> I also use the .elf file in cooja simulation tool, there is no reaction for
>> receiving node also.
>> And I think the #1442 bug is not a matter about shell(explanation from 2014
>> dec version), I think it's a cc2420 driver related bug.
> 
> Have you tried without setting the channel and PAN?
> 
> Cheers,
> Oleg
> -- 
> The problem UDP jokes
> ___
> 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] OTA meetup 11.2.2015

[Baptiste Clenet]

Arvid, Ludwig, any improvements concerning OTA?

Cheers,



2015-03-09 15:12 GMT+01:00 Baptiste Clenet :

> Hi,
>
> Ludwig, how is the planning going ?
> Could you create a wiki page (like [1]) or an issue (like [2])  with
> description of the work to do as well as assignment for each task?
> Everybody will know how it is going then.
> What do you think about it?
>
> Cheers,
>
> [1] https://github.com/RIOT-OS/RIOT/wiki/Timer-Task-Force
> [2] https://github.com/RIOT-OS/RIOT/issues/2278#issuecomment-73411503
>
> 2015-02-22 10:35 GMT+01:00 Ludwig Ortmann :
>
>> Hi,
>>
>> On Mon, Feb 16, 2015 at 06:41:05PM +0100, Oleg Hahm wrote:
>> > > the minutes from the meeting have been added to our wiki:
>> > > https://github.com/RIOT-OS/RIOT/wiki/minutes-OTA-meetup-13.2.2015
>> >
>> > Have there any concrete next steps been identified? Did you conclude in
>> some
>> > kind of a schedule for upcoming tasks and who is gonna work on what?
>>
>> There has been some preliminary scheduling, we will announce more
>> concrete planning soon, possibly in the form of an issue.
>>
>> Cheers, Ludwig
>> ___
>> devel mailing list
>> devel@riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
>>
>
>
>
> --
> *Clenet Baptiste*
>
>


-- 

*Clenet BaptisteFR: +33 6 29 73 05 39*
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] GSoC 2015 Introduction - N1 BLE Project

[Alexis DUQUE]

Hi Oleg,

Thanks for your quick reply :-)

>
> May I ask you what exactly you're planning to do there? To the best of my
> knowledge the Thread specification will be only released to some members of
> the partners in June.
>

Your absolutely right. What I'm doing is trying to implement communication
over different nodes that use different protocols (BLE, Z-Wave, Zigbee)
using IPV6 packets. That not exactly Thread but, we work with what is at
hand ^^

I think just reading through the Wiki [1] and the mailing list archives [2]
> will already help to get a rough understanding of how the community works.
> Particular [3] might be interesting to read.
>
>
Sure, I've already read it. And I was asking for "informal" things, to
better get in touch with Riot community ;-)

Usually both, next call and Hack'n'ACK would happen next week (see also the
> calendar on the web page). For the call, we might provide an additional
> session this week for GSOC applications. We'll let you know ASAP. For the
> H&A:
> Martine, can you confirm that C-Base is reserved again?


Yeap, I'll try to attend.


> Probably Hauke and Martine know best of the new network stack and will most
> likely mentor this project.
>
> Ok, so I will contact them directly. To start, Hauke, Martine, can you
give me some pointers about the network stack ? Ideas and suggestions you
already have had ? I read Martine's RIOT network presentation about
refactoring, what's the current state of that ?

Cheers,

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

Re: [riot-devel] ESP8266 - Easy tcp/ip support

[Martine Lenders]

Hello David,

2015-03-17 0:02 GMT+01:00 David Lyon :

> Hello Ludwig,
>
> Lately, I've been putting a lot of time into the ESP8266 wifi modules, and
> learning how to get them to work.
>
> How is the unified network driver system going?
>
> Here's my conclusion on the ESP8266. If Riot has a unified network driver
> system, it might be worth looking at trying to integrate these modules with
> riot.
>

We currently don't have an example for an embedded stack, but I guess the
ESP8266 would be great to supply such an example. Since the ESP8266
supplies, as far as I understand it, everything up to tcp and udp, I would
propose not to write a netdev driver for it, but writing a netapi threads
directly, one for TCP and one for UDP, so our future new socket API speaks
directly to it. If you need some inspiration how to implement a transport
layer thread have a look at Hauke's prelimanary UDP implementation [1].


> The trick with the ESP8266 modules seems to be to use the LUA firmware.
> And use some simple serial bridging code from Riot to then talk to the
> modules.
>

If there are no timing issues over speaking to the devices registers over
e.g. SPI directly (if it is possible this way at all), we can try that, but
in general I would prefer the solution that yields the better performance.


> Let me know if this is an interesting option?
>

Since it would show the flexibility of our new network stack this chip
would be a great option! :-)

Regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/2430
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Radio duty cycling

[Martine Lenders]

Hello Joakim,
currently there are no specific plans to utilize the power modes of the
radios to my knowledge, except that mostly MAC/link layers will implement
it. So if you have any idea: feel free to speak about it.

Cheers,
Martine

2015-03-17 10:05 GMT+01:00 Joakim Gebart :

> Hello RIOTers,
> What is the current state of radio duty cycling in RIOT?
> I know that radio drivers implement on and off functions for the chip, but
> how do we make the best use of them?
> ​In order to reduce power consumption it will be necessary to duty cycle
> the radio​
> ​.
> ​
>
> ​For comparison, in
> ​Contiki there are multiple RDC drivers that can be switched​ between at
> compile time, the most well-known is ContikiMAC [1]. Something similar
> would be very useful in battery powered scenarios for RIOT.
>
> [1]: http://dunkels.com/adam/dunkels11contikimac.pdf
>
> Best regards,
> Joakim Gebart
> Eistec AB
> www.eistec.se
>
> ___
> 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] Radio duty cycling

[Joakim Gebart]

Hello RIOTers,
What is the current state of radio duty cycling in RIOT?
I know that radio drivers implement on and off functions for the chip, but
how do we make the best use of them?
​In order to reduce power consumption it will be necessary to duty cycle
the radio​
​.
​

​For comparison, in
​Contiki there are multiple RDC drivers that can be switched​ between at
compile time, the most well-known is ContikiMAC [1]. Something similar
would be very useful in battery powered scenarios for RIOT.

[1]: http://dunkels.com/adam/dunkels11contikimac.pdf

Best regards,
Joakim Gebart
Eistec AB
www.eistec.se
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel