Re: [riot-devel] questions about riot os

[Kaspar Schleiser]

Hi,

On 03/22/2017 12:13 AM, Arjun Hary wrote:
> Is there a plan or a timeline for it? 

Nordic seems to have released its BLE stack for Mynewt under a
compatible license. AFAIK someone is already looking into porting that
to RIOT, but I don't know what's the state there.

Help is very appreciated!

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

Re: [riot-devel] questions about riot os

[Arjun Hary]

Is there a plan or a timeline for it?

On Tue, Mar 21, 2017 at 4:07 PM, Kaspar Schleiser 
wrote:

> Hi,
>
> On 03/21/2017 11:38 PM, Arjun Hary wrote:
> > Thanks a lot. I have one more follow up question. Does RIOT have a full
> > Bluetooth stack?
>
> Not yet.
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



-- 
Arjun Hary

 : +1 (425) 381-7722
 : zGlue Inc., Mountain View, CA

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

Re: [riot-devel] questions about riot os

[Arjun Hary]

Thanks a lot. I have one more follow up question. Does RIOT have a full
Bluetooth stack?

On Mon, Mar 20, 2017 at 10:02 AM, Kaspar Schleiser 
wrote:

> Hi Arjun,
>
> On 03/20/2017 05:03 PM, Arjun Hary wrote:
> > 1) After adding the softdevice the code size jumped to 46K bytes which
> > includes compilation of 6lowpan, ipv6. Is there a way to compile the
> > nordic ble linbrary without adding these modules. I tried the
> > DISABLE_MODULE macro and though the makefile complained , the code size
> > still remained the same. It looks like 6lowpan and ipv6 are required
> > modules. How do I change this.
>
> You'll need to remove the corresponding nordic softdevice dependencies
> from Makefile.dep. Currently, if you add modules to DISABLE_MODULE, they
> get removed *after* dependency resolution. In this case, meta-modules
> that are just used for dependency tracking are removed after their
> dependencies are added in.
>
> > 2)  Also as a general question, I see that RIOT claims the FLASH size
> > usage is around 5K. What features does the 5K include. Does it incude
> > pthreads, task switching, synchronization , messaging etc.
>
> That very much depends. Please take a look at tests/minimal, which
> currently compiles to ~2.7k flash for ARM platforms.
>
> 5k flash is enough for RIOT's threading, synchronization and messaging.
> The pthreads wrapper will not fit, though. Also, newlib's POSIX stdio is
> quite large, e.g., a simple printf will pull in ~4k of code on ARM
> platforms.
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



-- 
Arjun Hary

 : +1 (425) 381-7722
 : zGlue Inc., Mountain View, CA

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

Re: [riot-devel] RIOT's CI system

[Oleg Hahm]

Hi Martin!

On Tue, Mar 21, 2017 at 01:21:22PM +0100, Landsmann, Martin wrote:
> While going through the spreadsheet I stumbled upon row 28, i.e. 'Cope with
> dynamic set of workers'.
> 
> I would appreciate to get more information why the scoring seems to state,
> what I interpret of it,
> 
> that Jenkins is totally unable to handle the cases, or does it in an abysmal
> way.

I think it's probably Cenk who can answer this question in the most detailed
way, but in general we judged only the current state of the CI
(configuration) to avoid fortune telling. In the current state of Jenkins it
cannot deal with failing workers, but would require some non-trivial exception
handling in a groovy file.

To all the other members of the task force: correct me if I remembered this
wrong.

Cheers,
Oleg
-- 
/* Fuck.  The f-word is here so you can grep for it :-)  */
linux-2.4.3/include/asm-mips/mmu_context.h


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

Re: [riot-devel] RIOT's CI system

[Martin]

Hi Oleg,


first thx all for the effort collecting the requirements, pros and cons 
for the proposed CIs.


While going through the spreadsheet I stumbled upon row 28, i.e. 'Cope 
with dynamic set of workers'.


I would appreciate to get more information why the scoring seems to 
state, what I interpret of it,


that Jenkins is totally unable to handle the cases, or does it in an 
abysmal way.



Best regards,

Martin


Am 21.03.2017 um 12:23 schrieb Oleg Hahm:

Hi Thomas!

On Mon, Mar 20, 2017 at 11:17:07AM -0700, Thomas Eichinger wrote:

Reading the document provided it seems to me that Jenkins actually
got a better score than Murdock 2. (Please tell me if I am mistaken
and misinterpret the table.)

No, you are correct. Jenkins got a slightly higher score than Murdock, but the
scoring system is not really balanced and the difference is only ~5% and hence
negligible.


Because of this I'd very much appreciate a little bit more of information
on why this group came to the conclusion Murdock 2 is still better
fitting RIOT than Jenkins.

I do not intend to bash the task force results just try to better
understand the reasoning.

No worries, actually, I appreciate your inquiry. Indeed the conclusion was
that both CI systems are well suited for our needs. Jenkins may be a bit
stronger in some aspects while Murdock 2 scores in other aspects. Finally, we
wanted to come up with a concrete proposal and decided to recommend Murdock 2
for a rather indirect argument: whatever CI is chosen, we can never be certain
that we're gonna to be happy with that decision forever (as the past has
shown). However, if we now decide for Jenkins it is very likely that the
development of Murdock 2 will stop and we can never go back - while the other
way should be always possible.

I hope that answers your question(s). Otherwise, please let me know and I will
happily try to explain it better.

Cheers,
Oleg


___
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's CI system

[Oleg Hahm]

Hi Thomas!

On Mon, Mar 20, 2017 at 11:17:07AM -0700, Thomas Eichinger wrote:
> Reading the document provided it seems to me that Jenkins actually
> got a better score than Murdock 2. (Please tell me if I am mistaken
> and misinterpret the table.)

No, you are correct. Jenkins got a slightly higher score than Murdock, but the
scoring system is not really balanced and the difference is only ~5% and hence
negligible.

> Because of this I'd very much appreciate a little bit more of information
> on why this group came to the conclusion Murdock 2 is still better
> fitting RIOT than Jenkins.
> 
> I do not intend to bash the task force results just try to better
> understand the reasoning.

No worries, actually, I appreciate your inquiry. Indeed the conclusion was
that both CI systems are well suited for our needs. Jenkins may be a bit
stronger in some aspects while Murdock 2 scores in other aspects. Finally, we
wanted to come up with a concrete proposal and decided to recommend Murdock 2
for a rather indirect argument: whatever CI is chosen, we can never be certain
that we're gonna to be happy with that decision forever (as the past has
shown). However, if we now decide for Jenkins it is very likely that the
development of Murdock 2 will stop and we can never go back - while the other
way should be always possible.

I hope that answers your question(s). Otherwise, please let me know and I will
happily try to explain it better.

Cheers,
Oleg
-- 
printk(KERN_ERR "msp3400: chip reset failed, penguin on i2c bus?\n");
linux-2.2.16/drivers/char/msp3400.c


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

Re: [riot-devel] Sending the udp packets does not work with the xbee module

[Martine Lenders]

Hi,

2017-03-21 11:09 GMT+01:00 Wiegel, Friedrich (IAI) :
> […]

I try to get my hands on the hardware, and try it out myself.

> Is there a way to avoid the failed assertion when I increase the number of 
> interfaces to 2 but use one or is it only one interfaces available?

if there is enough memory space on your board you can set the
`DEBUG_ASSERT_VERBOSE` macro [1] so you can at least find out which
assertion is hit. You can also deactivate the assertion by unsetting
the DEVELHELP macro [2] (in gnrc_networking this is set), but usually
a failed assertion points to a problem ;-).

Hope this was helpful for now.

Best regards,
Martine

[1] 
http://doc.riot-os.org/group__core__util.html#ga2200149ba880bf26fed140bdcf318113
[2] http://doc.riot-os.org/group__utils.html#ga8dac5ebebf5f229a9fca90dcdf37e913
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Sending the udp packets does not work with the xbee module

[Wiegel, Friedrich (IAI)]

Ah ok. I did not know that the failed assertion behaves exactly like stack 
overflow. Then it must be the failed assertion. That behavior with the increase 
of the number of interfaces I find out as I tried to realize a border router. I 
really can not understand why sending, the UDP packets with two interfaces 
works and with only one not. 

With the help of your master thesis I have also tried to understand in which 
layer that problem occurs but didn't found what's going wrong. The one thing I 
know is that the gnrc_netdev2 does not receive a massage that he is now 
supposed to send something.

Is there a way to avoid the failed assertion when I increase the number of 
interfaces to 2 but use one or is it only one interfaces available?

Best regard,

Friedrich

-Ursprüngliche Nachricht-
Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Martine Lenders
Gesendet: Dienstag, 21. März 2017 09:11
An: RIOT OS kernel developers 
Betreff: Re: [riot-devel] Sending the udp packets does not work with the xbee 
module

Hi Friedrich,
then it is indeed weird, that you have to increase the number of static 
interfaces. Same goes for the stack overflow. Usually the stack should be big 
enough. Are you sure it is a stack overflow and not just a failed assertion? 
They look very similar in RIOT, since both let the node crash.

Best regards,
Martine

2017-03-20 17:44 GMT+01:00 Wiegel, Friedrich (IAI) :
> Hi Marine,
> for xbee I use arduino zero board this haven’t other radio on board.
>
> Best regards,
>
> Friedrich
>
> -Ursprüngliche Nachricht-
> Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Martine 
> Lenders
> Gesendet: Montag, 20. März 2017 17:07
> An: RIOT OS kernel developers 
> Betreff: Re: [riot-devel] Sending the udp packets does not work with 
> the xbee module
>
> Hi Friedrich,
> on what board are you using the xbee? Is there an on-board radio? It seems 
> like there is another interface already initialized.
> Best regards,
> Martine
>
> 2017-03-20 16:05 GMT+01:00 Wiegel, Friedrich (IAI) :
>> Hi Marine,
>>
>> first of all, thanks for your answer. The payload of my udp massage is only 
>> "TEST", the maximum PSDU size for xbee modul is 100 bytes and my payload is 
>> only 80 bytes. The next thing I noticed is following, if I set 
>> "GNRC_NETIF_NUMOF  :=2" then I can send the udp messages. And the 
>> transceiver send periodically some messages as the samd21-xpro does.
>>
>> Is this helpful in any way?
>>
>> The Problem is when I set " GNRC_NETIF_NUMOF  :=2" I get some stack overflow 
>> if I want to set some global address of my interface.
>>
>> Best regard,
>>
>> Friedrich
>>
>> -Ursprüngliche Nachricht-
>> Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Martine 
>> Lenders
>> Gesendet: Montag, 20. März 2017 15:08
>> An: RIOT OS kernel developers 
>> Betreff: Re: [riot-devel] Sending the udp packets does not work with 
>> the xbee module
>>
>> Hi Friedrich,
>> the xbee module has some tricky restrictions on sent packets. Did you 
>> make sure that the (link-layer) payload fits these? Regarding
>> debugging: Try compiling with CFLAGS_OPT=-O0 and CFLAGS="-g3 -gdwarf-3". 
>> This usually leads to more satisfying results. I don't have an xbee module 
>> at hand at the moment, otherwise I would test it myself.
>>
>> Best regards,
>> Martine
>>
>> 2017-03-20 12:07 GMT+01:00 Wiegel, Friedrich (IAI) 
>> :
>>> Hello everybody,
>>>
>>>
>>>
>>> I just played little bit with the gnrc_networking example and tried 
>>> to send an udp package with xbee module. Unfortunately this doesn’t work.
>>>
>>>
>>>
>>> To see what the problem is, I switched on the debugging in the 
>>> gnrc_netdev2_xbee.c but the program does not address this adaptation layer.
>>> Even the gnrc_netdev2.c is not addressed.
>>>
>>>
>>>
>>> Ping6 works perfectly and the creation of an udp server and the 
>>> receiving of udp packets goes well. Only sending makes problems, and 
>>> only with xbee module with samr21-xpro everything goes perfectly.
>>>
>>>
>>>
>>> Does any of you know what is going wrong?
>>>
>>>
>>>
>>> Best regards,
>>>
>>>
>>>
>>> Friedrich
>>>
>>>
>>>
>>>
>>> ___
>>> 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
> 

Re: [riot-devel] Sending the udp packets does not work with the xbee module

[Martine Lenders]

Hi Friedrich,
then it is indeed weird, that you have to increase the number of
static interfaces. Same goes for the stack overflow. Usually the stack
should be big enough. Are you sure it is a stack overflow and not just
a failed assertion? They look very similar in RIOT, since both let the
node crash.

Best regards,
Martine

2017-03-20 17:44 GMT+01:00 Wiegel, Friedrich (IAI) :
> Hi Marine,
> for xbee I use arduino zero board this haven’t other radio on board.
>
> Best regards,
>
> Friedrich
>
> -Ursprüngliche Nachricht-
> Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Martine Lenders
> Gesendet: Montag, 20. März 2017 17:07
> An: RIOT OS kernel developers 
> Betreff: Re: [riot-devel] Sending the udp packets does not work with the xbee 
> module
>
> Hi Friedrich,
> on what board are you using the xbee? Is there an on-board radio? It seems 
> like there is another interface already initialized.
> Best regards,
> Martine
>
> 2017-03-20 16:05 GMT+01:00 Wiegel, Friedrich (IAI) :
>> Hi Marine,
>>
>> first of all, thanks for your answer. The payload of my udp massage is only 
>> "TEST", the maximum PSDU size for xbee modul is 100 bytes and my payload is 
>> only 80 bytes. The next thing I noticed is following, if I set 
>> "GNRC_NETIF_NUMOF  :=2" then I can send the udp messages. And the 
>> transceiver send periodically some messages as the samd21-xpro does.
>>
>> Is this helpful in any way?
>>
>> The Problem is when I set " GNRC_NETIF_NUMOF  :=2" I get some stack overflow 
>> if I want to set some global address of my interface.
>>
>> Best regard,
>>
>> Friedrich
>>
>> -Ursprüngliche Nachricht-
>> Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Martine
>> Lenders
>> Gesendet: Montag, 20. März 2017 15:08
>> An: RIOT OS kernel developers 
>> Betreff: Re: [riot-devel] Sending the udp packets does not work with
>> the xbee module
>>
>> Hi Friedrich,
>> the xbee module has some tricky restrictions on sent packets. Did you
>> make sure that the (link-layer) payload fits these? Regarding
>> debugging: Try compiling with CFLAGS_OPT=-O0 and CFLAGS="-g3 -gdwarf-3". 
>> This usually leads to more satisfying results. I don't have an xbee module 
>> at hand at the moment, otherwise I would test it myself.
>>
>> Best regards,
>> Martine
>>
>> 2017-03-20 12:07 GMT+01:00 Wiegel, Friedrich (IAI) 
>> :
>>> Hello everybody,
>>>
>>>
>>>
>>> I just played little bit with the gnrc_networking example and tried
>>> to send an udp package with xbee module. Unfortunately this doesn’t work.
>>>
>>>
>>>
>>> To see what the problem is, I switched on the debugging in the
>>> gnrc_netdev2_xbee.c but the program does not address this adaptation layer.
>>> Even the gnrc_netdev2.c is not addressed.
>>>
>>>
>>>
>>> Ping6 works perfectly and the creation of an udp server and the
>>> receiving of udp packets goes well. Only sending makes problems, and
>>> only with xbee module with samr21-xpro everything goes perfectly.
>>>
>>>
>>>
>>> Does any of you know what is going wrong?
>>>
>>>
>>>
>>> Best regards,
>>>
>>>
>>>
>>> Friedrich
>>>
>>>
>>>
>>>
>>> ___
>>> 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
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel