Re: [riot-devel] RPL DAO target concat from fib

2017-10-19 Thread Landsmann, Martin
Hey Rahul, Cenk, Koen,


> 6lo frag is not a good option to use and should be avoided as far as possible.
right, but as we all know it cannot be achieved all the time.

> Supporting target aggregation in DAO without depending on 6lo frag
I think that would be the right direction for mitigating the symptom of sending 
elidable redundant information in DAOs options, which exceed the MTU.

I don't remember exactly if the rfc6550 et al. restrict the behaviour of 
constructing and distributing DAO transit/target options to parents in solely a 
single packet.
If splitting the downward information does not violate the RFCs, then taking 
the MTU into account up to a cetrain degree, would be just an implementation 
specific detail and probably the way to go (again).

But I would always prefer letting the underlying layer to provide fragmentation 
over an customized approach.


Best regards,

Martin

Von: devel [devel-boun...@riot-os.org]" im Auftrag von "Koen Zandberg 
[k...@bergzand.net]
Gesendet: Donnerstag, 19. Oktober 2017 08:19
An: devel@riot-os.org
Betreff: Re: [riot-devel] RPL DAO target concat from fib


Hey Rahul,

Unfortunately I don't have time right now to read and comment on your email in 
depth :(
About the ETX metrics for RPL, please have a look at #6873 and #7450.

I want to take a better look at your ideas and proposal in the weekend.

Regards,
Koen Zandberg

#6873: https://github.com/RIOT-OS/RIOT/pull/6873
#7450: https://github.com/RIOT-OS/RIOT/pull/7450

On 10/19/2017 07:46 AM, Rahul Jadhav wrote:
Thanks Cenk for giving a clear picture. Some comments inline...
In general, I feel this is important to be handled, since even in small network 
this would result in DAO fragmentation and will impact its performance.

Also there are some other points i wanted to understand/clarify:
1. Currently RIOT does not handle L2 ACK for determining whether L2 send was 
successful or not.  This feedback is not used at RPL/6lo layer. Scenario: A 
node receives a DIO from parent and sends a DAO. But lets say this DAO could 
not reach the parent. In this case L2 ACK would have failed and the child node 
could have handled it to switch parent. Even if K bit is set in the DAO, and if 
DAO-ACK is not received, the child node wont come to know since there is no 
state/timer maintained to handle this. Essentially this will lead to child node 
believing that it is connected to the network but the downstream path is never 
actually established.
2. RIOT does not handle L2 retry-count feedback to maintain RPL metric (for 
e.g. ETX).
Pls correct if i m wrong.

Thanks,
Rahul

On 19 October 2017 at 01:00, Cenk Gündoğan 
<list-r...@cgundogan.de<mailto:list-r...@cgundogan.de>> wrote:
Hey Rahul,

you are correct. The current RPL DAO building routine does not take
into account the MTU size, which is IMO the appropriate approach,
because on that level (ICMPv6) there is usually no knowledge about the
link-layer in use.

[RJ] True.

If I understand you correctly, then you basically
want to move the fragmentation from the 6lowpan layer up to the
ICMPv6/RPL layer (and only for DAOs).

[RJ] Thats exactly what I had in mind.

I think in one of the older
iterations of our RPL implementation we once had a functionality to
limit the number of Target Options in the DAO to a specific number
(configurable on compile-time).

[RJ] This would have been a real nice feature. Supporting target aggregation in 
DAO without depending on 6lo frag. In the future, proposing/implementing prefix 
eliding (the way 6loRH does for SRH or by simply using 6lo CID) between target 
containers and standardising it would make sense ! Considering that DAO 
consumes the most amount of RPL control traffic, i feel this can be fairly 
important.

But with the addition of a proper
6lowpan fragmentation, we dropped that functionality.

[RJ] 6lo frag is not a good option to use and should be avoided as far as 
possible.


I may take a look at it during the weekend. If I remember correctly,
then we used to have a further parameter to the "send_DAO" function that
tracked the number of already sent Target Options. Further calls to
"send_DAO" would then add the next Target Options. If such functionality
is needed (@bergzand, @BytesGalore, @smlng any comments on this?) then
we should aim to come up with an unintrusive approach to activate /
deactivate such a behaviour with compile flags.

[RJ] Wouldn't a simple compile-time flag such as DAO_TARGET_CONCAT_NUM=X be 
sufficient, where X could be 0 (no concat, send only 1 target container which 
will be node self IP addr), -1(for full concat, current implementation), and 
anything else which means non-self target container count. The other way to 
define such a flag would be DAO_TARGET_CONCAT_SZ=Ybytes ... which defines 
number of bytes instead of target count.


Cheers,
Cenk Gündoğan

On 17-10-19 00:00:34, Rahul Jadhav wrote:
> Hello RIOT team,
>

Re: [riot-devel] edbg build failure in Vagrant VM due to missing libudev-devpackage + problems flashing Atmel samr21-xpro board

2017-05-30 Thread Martin

Hey,

should be fixed when https://github.com/RIOT-OS/RIOT/pull/7106 is merged.

Best regards,
Martin

Am 29.05.2017 um 20:28 schrieb Cenk Gündoğan:

Hey,

I updated the vagrant image. @Adrian can you test again? You probably
need a `vagrant destroy` first to clear the local vagrant cache.

BTW: edbg for samr21-xpro does not work for me (neither on my host, nor
on the guest system). Is this supposed to work? edbg throws:

Debugger: ATMEL EDBG CMSIS-DAP ATML212703188213 01.1A.00FB (S)
Error: unknown target device (DSU_DID = 0x10010319)

Looking at the code of edbg [1] I cannot find a definition of the above
target id. With which board was edbg tested? @Hauke @Kasper?

Cheers,
Cenk

[1] https://github.com/ataradov/edbg/blob/master/target_atmel_cm0p.c

On 17-05-29 14:47:14, Cenk Gündoğan wrote:

Hello Kaspar,

I am working on it. The process of building such an image is described
in [1]. I will also do the publishing to Hashicorp [2] (needs
authentication).

Cheers,
Cenk

[1] https://github.com/RIOT-OS/RIOT/tree/master/dist/tools/packer
[2] https://atlas.hashicorp.com/RIOT/boxes/ubuntu1604

On 17-05-29 13:29:11, Kaspar Schleiser wrote:

Hey all,

On 05/29/2017 10:21 AM, Adrian Herrmann wrote:

Attempting to flash with the edbg driver instead of OpenOCD results in
an error when using the Vagrant VM as building edbg requires the
libudev-dev package, which is not included in the image and cannot be
found in the configured package repositories either.

I've never used our Vagrant stuff. How do I change the VM template?
Can maybe someone who knows add the missing package? Maybe @cenk? :)

Cheers!
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


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

2017-03-21 Thread 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] Coding conventions amendment

2016-10-12 Thread Martin



Am 10/12/2016 um 05:00 PM schrieb Oleg Hahm:

Hi Martin!

On Wed, Oct 12, 2016 at 04:52:37PM +0200, Landsmann, Martin wrote:

On Wed, Oct 12, 2016 at 12:57:50PM +0200, Ludwig Knüpfer wrote:

Am 12. Oktober 2016 09:48:28 MESZ, schrieb Oleg Hahm <oliver.h...@inria.fr>:

as far I'm concerned it has been an undocumented coding convention so far
to use `int` or `unsigned int` for iterator variables in a loop instead of
fixed width integer types. Does anybody object to adding this to the coding
conventions explicitly?

What about `size_t`?

I don't see a reason against `size_t` - but also no good reason that speaks
for it. What's the rationale?

size_t is suited best to be used for iterating array indices and never
overflow holding them [1].

[1] http://stackoverflow.com/a/2550799

Sorry, I don't get this. Can you elaborate?
size_t is the type returned from sizeof() call that you may use to 
determine any object size (including length of static arrays),
so for my understanding the returned size_t value can not exceed the 
highest possible index for any array that can be allocated on the 
underlying platform.


But as Kaspar suggested we should probably state against using fixed 
width and only recommend size_t.


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] Coding conventions amendment

2016-10-12 Thread Martin

Hi,


Am 10/12/2016 um 04:37 PM schrieb Oleg Hahm:

Hi!

On Wed, Oct 12, 2016 at 12:57:50PM +0200, Ludwig Knüpfer wrote:

Am 12. Oktober 2016 09:48:28 MESZ, schrieb Oleg Hahm <oliver.h...@inria.fr>:

as far I'm concerned it has been an undocumented coding convention so far
to use `int` or `unsigned int` for iterator variables in a loop instead of
fixed width integer types. Does anybody object to adding this to the coding
conventions explicitly?

What about `size_t`?

I don't see a reason against `size_t` - but also no good reason that speaks
for it. What's the rationale?
size_t is suited best to be used for iterating array indices and never 
overflow holding them [1].


[1] http://stackoverflow.com/a/2550799

Cheers,
Oleg


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

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


Re: [riot-devel] Coding conventions amendment

2016-10-12 Thread Martin

Hi,

Am 10/12/2016 um 12:57 PM schrieb Ludwig Knüpfer:

Hi,



Am 12. Oktober 2016 09:48:28 MESZ, schrieb Oleg Hahm <oliver.h...@inria.fr>:

Dear rolling IoTlers,

as far I'm concerned it has been an undocumented coding convention so
far to
use `int` or `unsigned int` for iterator variables in a loop instead of
fixed
width integer types. Does anybody object to adding this to the coding
conventions explicitly?

What about `size_t`?

+1 for size_t


Cheers,
Ludwig

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

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


Re: [riot-devel] Porting a robot to RIOT

2016-08-29 Thread Martin

Hi Loïc,


your experiment to substitute Aversive++ with RIOT as HW abstraction 
looks great to me.
Its nice to see an example of coordinated actuators steered by a remote 
wireless RIOT node.

Actually I would love to see your robot running on the ground.
I think its a really nice example for a one hop and one way 
communication between nodes,
and It might give a good impression of the RIOT hardware abstraction 
possibilities

(Similar to the RC car example of @haukepetersen [1]).


> I was wondering if it was worth adding this to the RIOT's wiki. Maybe 
it is not complete enough. What do you think ?


IMHO I think the RIOT wiki would not be the right place for it.
Some time ago we also made an example project [2] which is also not 
present in the wiki pages of RIOT.
One reason why its not there is that it "just" uses a bunch of 
documented and described features provided by RIOT, such as RPL, CoAP etc.
The other and even more important reason is that the blog offers a lot 
of additional and,
regarding the RIOT wiki, redundant information which could confuse a new 
user searching for specific help on a topic.



I think if you could give more details on migrating from Aversive++ to 
RIOT,
like give a step by step guide for someone that wants to move to RIOT 
but does not know how to begin, it could perfectly fit in the RIOT wiki.

Maybe something comparable to [3].


Best regards,

Martin

[1] https://github.com/haukepetersen/Petabot
[2] http://watr.li/
[3] 
https://github.com/RIOT-OS/RIOT/wiki/How-to-install-6LoWPAN-Linux-Kernel-on-Raspberry-Pi



Am 08/18/2016 um 10:41 AM schrieb Loïc Dauphin:

Hello,

Some month ago, I made an experiment to make my personal robot work 
with RIOT. I should have done this sooner, but I just made a small 
document that describes how I did that :
https://github.com/astralien3000/test_riot_buggybot/wiki/From-AversivePlusPlus-to-RIOT 



I was wondering if it was worth adding this to the RIOT's wiki. Maybe 
it is not complete enough. What do you think ?


Cheers,

Loï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


Re: [riot-devel] Condition Variables

2016-08-17 Thread Martin

Hi Sam,


in its core RIOT only provides a small and efficient mutex implementation.

Condition variables are provided within the POSIX wrapper [1], 
specifically in the the pthread part [2].


To get an idea how use the provided condition variables you can have a 
look in our tests for it [3].


But as Simon stated you should consider if using the Message passing 
possibilities of RIOT could have the desired effect,


since using the POSIX condition variables in RIOT also comes with a 
certain overhead.



Best regards,

Martin

[1] http://riot-os.org/api/group__posix.html
[2] http://riot-os.org/api/group__pthread.html
[3] 
https://github.com/RIOT-OS/RIOT/tree/master/tests/pthread_condition_variable


Am 08/17/2016 um 11:21 AM schrieb Simon Brummer:

Dear fellow TCP implementor,

The common way implement something like this in RIOT is Message
passing. Your thread simply blocks by calling msg_receive() until it
received a message from another thread. As soon as you receive a
Packet, send a message to the via msg_send() function to wake the
blocked thread.

Cheers
Simon Brummer

Am Dienstag, den 16.08.2016, 12:49 -0700 schrieb Sam Kumar:

Hello,
I was looking at the synchronization primitives in RIOT OS. I noticed
that there is a mutex implementation, but I was unable to find a
condition variable.

I am currently porting the TCP logic from the FreeBSD operating
system to RIOT as part of the research work I am doing. I am
implementing the "conn" API for TCP, and I need to be able to block
the current thread until a packet is received, to implement some of
the functions.

I read the IPC implementation (msg.c), which also has a blocking API,
and saw that it interacts with the scheduler manually in order to
block and resume threads. Before I did the same thing for the conn
API (or perhaps implement/contribute my own condition variable), I
wanted to ask whether there are condition variables for RIOT, in case
I was just looking in the wrong place. If not, I want to learn if
there is another structured way to block a thread until an event,
that I should use instead.

Thanks,
Sam Kumar
___
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] Organizing device drivers

2016-07-12 Thread Martin

Hi Perter, all,

> this approach prohibits to use both devices simultaneously.
I think this is a blocking issue for merging akin device drivers.
IMHO If this situation happens the drivers should be separated back, 
even if bloating/doubling the code.


> For similar CPUs we maintain a "common" folder ...
Considering the mentioned "blocking issue" I would go for a "common" 
folder for solely collecting  utility functions, i.e. functions not 
using global/static variables or buffers.


> Another solution would be to handle common and individual functions 
in one file (without #ifdef). ...
You mean putting all required functions in each driver without 
considering similarities?
At least this would be safe, since every driver then truly operates in 
defined bounds.
But obviously this would most probably introduce a lot 
developing/debugging repetition.


Best regards,
Martin

Am 07/12/2016 um 10:49 AM schrieb Peter Kietzmann:

Hi devs,

on several occasions the question about how to merge similar device 
drivers occurred. That means covering different derivatives of a 
device with one device driver, to avoid code duplication. Compare 
discussions in these PRs:


https://github.com/RIOT-OS/RIOT/pull/5604
https://github.com/RIOT-OS/RIOT/pull/5484
https://github.com/RIOT-OS/RIOT/pull/5433

For the dht11/22 or at86rf212b/232/233 we already merged drivers by 
putting #ifdef around different code parts. This does not affect code 
readability as long as differences are small (which is not 
guaranteed). On the other hand, this approach prohibits to use both 
devices simultaneously. Furthermore, naming schemes might get 
confusing. E.g. merging "MPU6000", "MPU6050" and "MPU9150" might lead 
to "MPUXXX0". I've no idea about further and future version names.


For similar CPUs we maintain a "common" folder next to the dedicated 
CPU version. Different code parts were maintained separately in 
individual folders. The question is, if this approach is reasonable 
for pretty simple device drivers where multiple derivatives might exist.


Another solution would be to handle common and individual functions in 
one file (without #ifdef). This might bloat code size but allows usage 
of different versions in parallel. Also, it does not bloat the file 
structure. The problem about naming schemes is still present here.


I'd like to have a general principle for this. What is your opinion 
about the above described procedures? Are there other/better ideas?


Best
Peter



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


Re: [riot-devel] IoT technology survey

2016-04-15 Thread Landsmann, Martin
Hi Michael, hi Emmanuel,

IMHO its not a really surprising outcome.
We (especially me) just have a very restricted, not saying stubborn, impression 
that IoT is only == "some kind of sensor/actuator network driven by small 
microcontrollers".
But the buzzword IoT is commonly considered everything not being a classic 
computer and connected with the internet, preferably but not necessarily over 
some wireless connection.
So a smartphone, tablet, a fritzbox with a webserver, heating system 
steerable/configurable with an App over wifi, fringe that spams me with tweets 
to buy milk ... fits this buzzword. And in the named cases the devices often 
use some sort of linux providing a web-service for login/configure stuff.

Best regards,
Martin

Von: devel [devel-boun...@riot-os.org]" im Auftrag von "Emmanuel Baccelli 
[emmanuel.bacce...@inria.fr]
Gesendet: Freitag, 15. April 2016 13:49
An: RIOT OS kernel developers
Betreff: Re: [riot-devel] IoT technology survey

Hi Michael,
Yes, the results are somewhat puzzling.
Maybe the people who answered the survey were probably of the "rasberryPi=IoT" 
type, which might explain some results.
With this in mind, there is probably something to get out of the results.
Best,
Emmanuel

On Fri, Apr 15, 2016 at 2:43 PM, Michael Frey 
<f...@informatik.hu-berlin.de<mailto:f...@informatik.hu-berlin.de>> wrote:
Hi,

Am Di, 15.03.2016, 11:15, schrieb Emmanuel Baccelli:

> https://www.surveymonkey.com/r/AGILEIoT

so, here are (if I see this correctly) are the results

https://ianskerrett.wordpress.com/2016/04/14/profile-of-an-iot-developer-results-of-the-iot-developer-survey/

I'm a bit puzzled about the 11.2 % considering php an IoT programming
language (and apparently using it) - on the other hand there are 73 % who
consider Linux an IoT operating system. Anyway, maybe it's worthwhile for
somebody to read it during hers/his lunch break.

Best,
 Michael
--
Dipl.-Inf. (FH), M. Sc. Michael Frey
Humboldt-Universität zu Berlin
Department of Computer Science
Rudower Chaussee 25
12489 Berlin, Germany

___
devel mailing list
devel@riot-os.org<mailto: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] Populating neighbor cache without ND

2016-03-10 Thread Landsmann, Martin
Hi all,

> @Emmanuel: Maybe we should consider creating a STALE entry in the neighbor 
> cache for neighbors heard of, but without bidirectional check at ND level yet?
I think this will not help in a situation where a neighbor node does not use ND.
The entry will be pruned after some timeout when no update has been done, and 
the update-interval is then highly dependent on the routing-protocol(-settings).
But generally I think its a good idea to have a STALE state for neighbor-cache 
entries in lossy networks.

I propose that the FIB updates the neighbor-cache with LL-addresses of added 
FIB-entries.
They are supposed to be used in forwarding and considered as a reachable 
next-hop by a routing-protocol.
I think there's no need to extend RPL to fill the neighbor-cache.

Best regards,
Martin

Von: devel [devel-boun...@riot-os.org]" im Auftrag von "Joakim Nohlgård 
[joakim.nohlg...@eistec.se]
Gesendet: Donnerstag, 10. März 2016 16:30
An: RIOT OS kernel developers
Betreff: [riot-devel] Populating neighbor cache without ND

(Continuing from a thread on Github: 
https://github.com/RIOT-OS/RIOT/issues/5025)

tldr; It should be possible to use RPL standalone without 6lowpan-ND.

Currently the only way to add neighbor cache entries is through neighbor 
solicitations+neighbor advertisements (ND) or through the shell. My initial 
opinion was that RPL should add neighbor cache entries for all DAOs it receives
​.

​@cgundogan
 argued that the lowpan network may be asymmetrical in what packets get through 
between nodes, so a DAO reception may not guarantee
​ reliable​
bidirectional communication between two link-local addresses
​:​

​RPL states in the RFC that it requires bidirectional links to function 
properly. (6Lo-)ND is one way to get those bidirectional links, so that the 
ncache itself only contains entries that are bidirectional. Receiving a DAO is 
not a strong indication whether the link is bidirectional or not. DIO traffic 
is (mostly) multicast (and sparse) in the downwards direction, while DAO 
traffic is (mostly) unicast in the upwards direction. Due to the known problems 
of wireless technology (interference, etc.) and "enhancements" of link layers 
(e.g. to apply QoS for certain traffic patterns, multicast, unicast, etc.) the 
link can be highly asymmetric. Receiving a DAO does not mean that my DIO, which 
I send out e.g. 1 minute ago, has reached that same child.​

So, a summary of the scenario, written by Cenk:

To summarize again so that I understand you correctly:
You have 2 nodes (A and B)
A is the RPL root and has a neighbor cache (+ (6Lo-)ND is running)
B is a normal rpl router who joins the DODAG of A and has no neighbor cache and 
no ND running.
A will always expect an entry in its neighbor cache before it can send out 
traffic to B,
but since B is not participating in the RS/RA-NS/NA exchange with A, A will 
never get an entry for B in its ncache.

​Emmanuel further suggested:

Maybe we should consider creating a STALE entry in the neighbor cache for 
neighbors heard of, but without bidirectional check at ND level yet?

It was suggested that we would continue the discussion on the devel mailing 
list.

Does anyone have more ideas or suggestions on how to populate the neighbor 
cache without ND?

This is especially interesting for interoperability with ​other systems which 
may not even have a 6lowpan ND implementation, and can only do RPL.

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


Re: [riot-devel] accidentally commited to master

2016-02-11 Thread Landsmann, Martin
Did revert, again sorry for that ):
and @gebart thx for the hint

Best regards,
Martin


Von: devel [devel-boun...@riot-os.org]" im Auftrag von "Joakim Nohlgård 
[joakim.nohlg...@eistec.se]
Gesendet: Donnerstag, 11. Februar 2016 13:17
An: RIOT OS kernel developers
Betreff: Re: [riot-devel] accidentally commited to master

I think it is better to make a revert commit and push that as well, that avoids 
the problem of rewritten history.

git revert 30ab6883331e29ce8453ebc1057f939575e6
git push

To prevent mistakes like this in the future, change the upstream repo URL to 
use the https:// or git:// links instead of ssh://

Best regards,
Joakim

On Thu, Feb 11, 2016 at 1:11 PM, Landsmann, Martin 
<martin.landsm...@haw-hamburg.de<mailto:martin.landsm...@haw-hamburg.de>> wrote:
Hi guys,

I accidentally commited directly to master ): [1]
Is there a way to revert it?

Best Regards,
Martin

[1] 
https://github.com/RIOT-OS/RIOT/commit/30ab6883331e29ce8453ebc1057f939575e6

___
devel mailing list
devel@riot-os.org<mailto: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] RIOT Hack'n'ACK

2015-07-28 Thread Martin

Hi!

Hack'n'ACK PlaceCam is open at
http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE-

Cheers,
Martin

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


[riot-devel] ping6 on samr21-xpro

2015-07-15 Thread Martin

Hi all,

I try to ping between 2 samr21-xpro nodes using the ng_networking example.
But now this does not work anymore.

Before PR #3388 [1] has been merged the nodes generated a local /64 
address like:

`inet6 addr: fe80::ff:fe00:3702/64  scope: local`

now the address is:
inet6 addr: fe80::585a:6667:bdbf:3702/64  scope: local

`ping6 fe80::ff:fe00:3702` works (I disabled #3388)
`ping6 fe80::585a:6667:bdbf:3702` does not

Do I use a wrong destination address?

Best regards,
Martin


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


Re: [riot-devel] question on a possibility for a netdev deadlock

2015-06-24 Thread Martin

Ahh, thx for clarification.

Best regards,
Martin

Am 24.06.2015 um 10:14 schrieb Daniel Krebs:

Hi Martin,

all the mentioned function are not called in interrupt context. Take a 
look at ng_at86rf2xx.c. There you find the real ISR that sends a msg 
to the next higher level notifying about the IRQ. Then from there 
everything else in the driver is executed from thread context.


So I guess this is unrelated to the problems you are having.

Cheers,
Daniel

Am 24. Juni 2015 09:54:09 MESZ, schrieb Martin 
martin.landsm...@haw-hamburg.de:


Hi all,

I've tested the ng_ stack with samr21-xpro boards using the new
ng_at86rf2xx driver.
Since I sometimes encountered hardfaults I took a look in the ISR
handling of the driver [1].

There we handle incoming packets when the receiver has finished the RX
process [2].
Since we are in a ISR, all other processes has been interrupted.

Now when we call _receive_data() function inside the ISR, that in turn
calls pktbuf handling/manipulating functions [3],
we try to acquire the mutex protecting the pktbuf [4].

Since we are still inside of the ISR probably the mutex is acquired by
someone else.
If true this leads to a deadlock since the ISR would wait forever to
acquire the mutex and never return to leave the ISR.

Additionally if we successfully acquire the mutex,
we could produce inconsistencies iff the protection is not performed
consistently.

Just wanted to ask if I'm mistaken here and missed something.

Best regards,
Martin

[1]

https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L671
[2]

https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L688
[3]

https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L271
[4]

https://github.com/RIOT-OS/RIOT/blob/master/sys/net/crosslayer/ng_pktbuf/ng_pktbuf.c#L81


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] How to install 6LoWPAN Linux Kernel on Raspberry Pi

2015-06-10 Thread Martin

Hi all,

I extended the wiki from @haukepetersen with a new section [1] 
describing the complete process to make a recent kernel successfully run 
on the raspi.
I don't want to remove the initial section from Hauke until someone else 
then me tested if the process is described appropriately.

So feel free to test change and extend the instructions.

Best regards,
Martin

[1] 
https://github.com/RIOT-OS/RIOT/wiki/How-to-install-6LoWPAN-Linux-Kernel-on-Raspberry-Pi#how-to-install-and-use-6lowpan-on-a-raspberry-pi-with-linux-kernel-405 


___
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

2015-05-22 Thread Landsmann, Martin
Hi Adam, hi Cenk,

 Has anyone tested the amount of time it takes for a node (full or reduced 
 function) to join an RPL routed 6lowpan network?
Not a particular range, but I can confirm that the time varies until a RPL 
topology converges in whole, and that it varies for a single node to join.

Regarding the further discussion, I'm not convinced if we should send periodic 
DIS messages.
Even if they get lost, DIOs are disseminated repeatedly by all nodes in a DODAG 
when trickle fires [1].
Concerning LLNs I don't like to send additional packets periodically at all.
In my opinion it just drains the energy of a node with small to no benefit.
Even if a node is not answered with a DIO directly when sending a DIS, 
eventually a DIO will arrive from a neighbor node (assuming one is present).

Resetting the trickle timer from applications sounds like a good opportunity 
for debugging and testing things.
Just as Adam I also think such feature should be only available for debugging 
and testing.
Resetting the trickle timer in normal operation from an application sounds 
for me like interfering with the routing protocol,
or even attacking the topology ;)

 ...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
I think the most impacting problem with such approach is that every convenience 
function/structure we provide will produce more bytes used on the ROM and RAM.
RPL is used on nodes with few kB RAM and ROM and it must share this room with a 
network stack and further productive applications.
Concerning this, I obviously vote for compile time configuration :)

These are just some thoughts and my personal opinion.

Best regards,
Martin

[1] https://tools.ietf.org/html/rfc6550#section-8.3

Von: devel [devel-boun...@riot-os.org] im Auftrag von Adam Hunt 
[voxa...@gmail.com]
Gesendet: Freitag, 22. Mai 2015 07:09
An: RIOT OS kernel developers
Betreff: Re: [riot-devel] Association time in mobile RPL/6lowpan networks


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.semailto:joakim.geb...@eistec.se wrote:

On May 21, 2015 8:37 AM, Cenk Gündogan 
cenk.guendo...@fu-berlin.demailto: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.frmailto: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

[riot-devel] NTSF: FIB status and future plans

2015-04-29 Thread Martin

Hi all,

unfortunately I cannot attend the NTSF meeting tomorrow :(
So I hacked some words on the current status and the future palns of the 
FIB on a wiki page [1].


Best regards,
Martin

[1] https://github.com/RIOT-OS/RIOT/wiki/NSTF:-FIB-Status-and-future-plans
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] oonf

2015-04-13 Thread Martin

Hi guys,

I want to test some stuff using the oonf pkg[1].
It is cloned and successfully and  patched with the provided RIOT 
compatibility patches, but then it fails on compile with:
`./pkg/oonf_api/oonf_api/src-api/common/autobuf.c:84:3: warning: 
implicit declaration of function ‘getpagesize’ 
[-Wimplicit-function-declaration]`

and
`./pkg/oonf_api/oonf_api/src-api/common/netaddr.h:348:16: error: 
‘sockaddr6_t’ has no member named ‘__in6_a’` for native

and
`./pkg/oonf_api/oonf_api/src-api/common/netaddr.h:48:30: fatal error: 
netinet/if_ether.h: No such file or directory` for iot-lab_M3


Did I missed to configure?

Best regards,
Martin

[1] https://github.com/RIOT-OS/RIOT/tree/master/pkg/oonf_api
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Notification: Biweekly virtual meeting @ Every 2 weeks from 10am to 11am on Wednesday (RIOT Events)

2015-04-08 Thread Martin

Hi,

please unlock the etherpad

Best regards,
Martin

On 08.04.2015 13:53, Oleg Hahm wrote:

Hi,

the meeting will start in about 5 minutes at
http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE-

Minutes will be at http://riot.pad.spline.de/11

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] Network Stack Task Force

2015-02-06 Thread Martin

Hi,

thx again for recording the audio for the introducing presentation.
It was a great help to get a more descend look at the information from 
the slides and the idea for the message based network stack approach.


Yesterday we got the foundamental concept how the new network stack will 
evolve, which  modules are covered yet and what parts are open for 
discussion/definition.
As I couldn't attend, I humbly ask how the meeting will proceed today, 
and if there was discussion/consensus on open topics?


Best regards,
Martin

On 05.02.2015 15:22, Landsmann, Martin wrote:

Hi,

thx

Best regards,
Martin

*Von:* devel [devel-boun...@riot-os.org] im Auftrag von Martine 
Lenders [authmille...@gmail.com]

*Gesendet:* Donnerstag, 5. Februar 2015 15:08
*An:* RIOT OS kernel developers
*Betreff:* Re: [riot-devel] Network Stack Task Force

Hello,
attached you find the links to the audio recordings of the talks of 
the network stack task force meeting.


http://download.riot-os.org/nstf/meeting1/nstf-meeting1.mp3
http://download.riot-os.org/nstf/meeting1/nstf-meeting2.mp3

Regards,
Martine

2015-02-05 11:18 GMT+01:00 Jan Wagner m...@jwagner.eu 
mailto:m...@jwagner.eu:


they mean this in a context of a mutli user operating system? or not?

Emmanuel Baaccelli emmanuel.bacce...@inria.fr
mailto:emmanuel.bacce...@inria.fr hat am 5. Februar 2015 um
11:16 geschrieben:

the paper I'm about to mention in the meeting:
https://www.usenix.org/system/files/conference/osdi12/osdi12-final-183.pdf


On Thu, Feb 5, 2015 at 10:03 AM, Martine Lenders
authmille...@gmail.com mailto:authmille...@gmail.com wrote:

Good Morning,

here is the placecam link

http://placecam.de/call.php?c=0~dA5j0OrfTdsesyQKlqIZvQi7bo1YKYGdMORGFmqL8-

http://placecam.de/call.php?c=0%7EdA5j0OrfTdsesyQKlqIZvQi7bo1YKYGdMORGFmqL8-


How-To use it?

https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation


Cheers,
Martine

2015-02-04 22:32 GMT+01:00 Matthias Waehlisch
m.waehli...@fu-berlin.de mailto:m.waehli...@fu-berlin.de:

Hi Jan,

On Wed, 4 Feb 2015, Jan Wagner wrote:

 i just installed placecam, do you send out the meeting
link to this
 mailing list or person based emails?. i would like to
join tomorrow
 and if needed would request that link.

Hauke will provide the link tomorrow via the mailing list.

 ps. do i need a cam or is audiio only ok?

You don't need a cam, audio is fine.


Cheers
matthias

--
Matthias Waehlisch
. Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
. Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehli...@ieee.org mailto:waehli...@ieee.org
.. http://www.inf.fu-berlin.de/~waehl
http://www.inf.fu-berlin.de/%7Ewaehl
:. Also: http://inet.cpt.haw-hamburg.de ..
http://www.link-lab.net
___
devel mailing list
devel@riot-os.org mailto:devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


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

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



___
devel mailing list
devel@riot-os.org mailto: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] 802.15.4 for Linux

2015-02-03 Thread Martin

Hi Christian,

I plan to test the RPL router daemon on Linux.
Currently we want to use the sticks as interface not as node/platform.

Best regards,
Martin

On 03.02.2015 19:30, Christian Mehlis wrote:

Am 02.02.2015 um 18:16 schrieb Martin:


There is also a RPL Edge router daemon available [2], which we want to
test with the boards.


Hi Martin,

do you plan to test the RPL edge router in Linux or in the contiki on 
the stick?


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] 802.15.4 for Linux

2015-02-02 Thread Martin

Hi,

we have the R-IDGE 6LoWPAN router USB sticks running on Linux. We 
succesfully made them talk with the samr21-xpro and the iot-lab_M3.
But, currently no unicast communication was succesfull from board to 
stick only with multicast address as next-hop.
However, we succesfully transmitted UDP packets forth and back using 
multicast next-hop.


As Raphael wrote, when plugged the stick is directly recognized by Linux 
as NIC and shows up on `ifconfig`.
The 6LoWPAN specific configurations, such as setting the PAN/context or 
the channel, are made with a provided configuration tool (cfgtool [1]) 
which can be built from source.
There is also a RPL Edge router daemon available [2], which we want to 
test with the boards.


Best regards,
Martin

[1] http://rosand-tech.com/products/r-idge/doc.html
[2] http://www.rosand-tech.com/downloads/index.html

On 02.02.2015 17:54, Hiesgen, Raphael wrote:

Hi,

we have a couple of these USB things [1]. Martin has made a few tests 
with them. If I am not mistaken the sticks show up on Linux as a 
network interface without any problems.


Raphael

[1] http://rosand-tech.com/products/r-idge/feat.html?

On Jan 30, 2015, at 11:02 AM, Oleg Hahm oliver.h...@inria.fr 
mailto:oliver.h...@inria.fr wrote:


Dear reasoning IoTlers,

I know, we had this question already several times before , but I'm 
not sure
about the current state and if some of you have made new experiences 
in this
domain: is there any off-the-shelf hardware available that provides 
an IEEE
802.15.4 interface for Linux systems - preferable something like a 
USB stick?
If yes, does this hardware work with a standard Linux vanilla kernel 
and which
version is required? Or does it need any custom/developer version of 
a driver?
How well are upper layers like 6lowpan supported by Linux in the 
meantime? And

has anyone ever tried to connect such a device to a RIOT driven device?

Thanks,
Oleg
--
printk(autofs: Out of inode numbers -- what the heck did you do??\n);
   linux-2.0.38/fs/autofs/root.c
___
devel mailing list
devel@riot-os.org mailto: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] C++11 Support in RIOT

2015-01-26 Thread Martin

Hi Michael,

we have no feature matrix (yet) for C++11 features, as they are all in 
development status.


Currently @josephnoir is in the process to provide a bunch of C++11 
features to RIOT [1]:

Beside other C++11 features `std::thread` [2] is available.

Maybe @josephnoir can give more details on the available features.

Best regards,
Martin

[1] https://github.com/josephnoir/RIOT/tree/topic/caf
[2] https://github.com/josephnoir/RIOT/tree/topic/caf/tests/std_thread_like

On 26.01.2015 15:48, Michael Frey wrote:

Hi,

I'm wondering what the current status of the C++11 support in RIOT is? Is
there a matrix like overview [1] available? I'm particularly interested in
std::shared_ptr and std::thread support in RIOT. I would also be happy if
somebody could share his/her thoughts on implementing C++11 features for a
libstdc++/libc++ for RIOT.

TIA!
  Best,
   Michael

[1] https://gcc.gnu.org/projects/cxx0x.html


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


Re: [riot-devel] LGPL compliance testing

2015-01-26 Thread Martin

Hi,

nice,
I will try today how it would be possible to replace and validate when 
someone change parts of say the core, not the whole core though.


Best regards,
Martin

On 01/26/2015 10:46 PM, Hauke Petersen wrote:

Nice!

I'm too tired to really think through it, but how does this fit in 
when keeping parts more close to the hardware proprietary? Say I don't 
want to publish my device driver, and maybe I don't want to share my 
pin-mapping?


Cheers,
Hauke

On 26.01.2015 16:43, Kaspar Schleiser wrote:

Hey guys,

here's an initial draft on how to check for LGPL compliance:

https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide

This is for showing that some proprietary code has been compiled and 
linked with a specific version of RIOT.


I wrote the wiki entry out of my head, so maybe I missed something, 
but the general method worked in prior testing. ;)


Should we go and automate this, or am I missing something?

Kaspar

p.s.: This is in no way any conclusion to the license discussion, see 
it as purely technical please.

___
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] Network Stack Task Force

2015-01-18 Thread Martin

Hi,

I would also like to attend.

Best regards,
Martin

On 16.01.2015 19:08, Hauke Petersen wrote:

Dear RIOTers,

we recently came up with the idea to create task forces around special 
topics in RIOT to concentrate and speed up the development of key 
parts. The idea is to bring all people that are interested in this 
topic and are prepared to spend some on it together in a (virtual) 
room and start out by a 2-3 day workshop style event. This first 
period should be used to discuss the topic in detail to bring everyone 
involved on the same page, to come up with a clear architecture, and 
define interfaces and sub-modules. The hope is, that we can go into a 
very productive implementing phase afterward and speed up the overall 
development.


The first key topic we want to try out this concept is the ongoing 
re-structuring of the network stack. I propose the following plan for 
this:
- we use next week to coordinate (who wants to join, what is the 
current state, what are the most pressing open questions)
- we block 2 days in the last week of January for a (virtual) 
white-board centered workshop


For the workshop I propose January 27-28, but its just a proposal...


Regarding technical aspects that are currently under (heavy) 
construction or need to be clarified (@Martine: please hit me if I 
have it completely wrong here...):

- optimizations to the netdev interface
- optimizations to the netapi interface
- analysis of possible data loss using netapi in its current state
- how to pass data/headers/packets around the stack
- possible generalization and/or quotas in the packet buffer
- concepts of global protocol/module list and global protocol handler 
registry

- API definition for the neighbor table
- API definition for the forwarding table
- possible join for neighbor and forwarding table
- hooks for various routing protocols
- ???

This is just a initial list of topics to be further discussed - I hope 
we can detail it out over the next week to have a good idea about the 
questions that need time for discussion!



So concluding:
- who is interested (and/or) wiling to joing this effort?
- are there any ideas on the concrete organization of such a task-force?
- are there technical aspects I forgot?

Looking forward to your feedback!

Cheers,
Hauke

___
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] Flashing the Samr21 xpro

2015-01-13 Thread Martin

Hi,

my flashing speed is roughly equal to Thomas' for the Samr21-xpro:

```
wrote 65536 bytes from file RIOT/tests/pnet/bin/samr21-xpro/pnet.hex in 
32.083557s (1.995 KiB/s)

verified 49688 bytes in 4.114729s (11.793 KiB/s)
```

My openocd version:
`Open On-Chip Debugger 0.9.0-dev-00186-g30203b3 (2014-11-12-11:49)`

Best regards,
Martin
On 12.01.2015 21:07, Baptiste Clenet wrote:

Flashing is slow for us too, how do you get the speed?

2015-01-12 11:13 GMT+01:00 Lucas Jenß li...@x3ro.de 
mailto:li...@x3ro.de:


Hi Thomas,

verification was much faster as 0.4KiB/s, I think around 10 or so
for me.
I checked out OpenOCD on the 9th. I’m also running Linux inside VMware
though, so maybe it’s just caused by the virtualization. I’ll see
how fast
it is on the host.

Cheers,
Lucas

A couple of days ago.

On 12 Jan 2015, at 11:00, Thomas Eichinger
thomas.eichin...@fu-berlin.de
mailto:thomas.eichin...@fu-berlin.de wrote:

 Hi Lucas,

 I was playing with the openocd configuration a bit, mainly
 `adapter_speed`, back when support for this was added without
 any significant outcome.
 Problem is, the EDBG chip, on the bottom of the board, handling
 communication with the MCU is specified to run on 1MHz and the
 openocd docs mention, for CMSIS-DAP, it is not advised to let
 signal frequency exceed half of the operating frequency.
 (I’d guess Nyquist-Shannon applies)

 That said, 0.481KiB/s still seems slow for this. I’m at least
 reaching 1.787KiB/s for flashing and 11.190KiB/s for verification.
 When did you check out the OpenOCD code?

 Best, Thomas

 On 10 Jan 2015, at 14:25, Lucas Jenß li...@x3ro.de
mailto:li...@x3ro.de wrote:

 Hey everyone,

 I’ve been playing around with the Samr21 xpro and flashing
 the device is _really_ slow, i.e. 0.481 KiB/s. Is this expected
 or is there a way to improve it? I’m using the current OpenOCD
 Git HEAD because the 0.8.0 release does not seem to contain the
 configs for the board yet. I tried to flash the hello-world
 example.

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

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


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




--
/Clenet Baptiste
FR: +33 6 29 73 05 39/
/Élève-Ingénieur ESEO Angers, dernière année, spécialisation: 
Architecte système temps réél embarqué//

/
/Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014

/


___
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-users] Switch to BSD?

2014-12-15 Thread Martin

(sorry for the post in users)
Hi all,

sorry for the late reply.

I'm not against a license change in general.

I understand the positions of companies to be restrained on LGPL.
They will not provide much effort, in manpower and finance, to find a
way to link their implementations to RIOT not violating LGPL.
Just as Joakim stated, RD always produce an amount confidential parts
of code that cannot be released to the public.

I see a license change pragmatically, I don't expect that most companies
that insist turning from LGPL to a less restrictive license such as
BSD/MIT before even think about using RIOT,  will contribute back to
the RIOT codebase.
But if we can lure companies to actively use RIOT, this may gain the
visibility in serious markets and promote RIOT as the Product of
choice for the IoT.
Still I'm a little bit sceptical if a license change will result in the
desired pull effect.

In this context I'm in favour of an Apache like license over BSD/MIT.

Best regards,
Martin
___
users mailing list
us...@riot-os.org
http://lists.riot-os.org/mailman/listinfo/users



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


Re: [riot-devel] FIB redesign

2014-11-19 Thread Martin

Hi all,

 a significant question is of course how to deal with competing 
routing protocols
Form my understanding we have two distinct directions we can choose to 
approach the problem:


1. We strictly push it away from the FIB, i.e. only allowing to have 
unique entries for each global prefix.
pro: no handling needed here, the process, e.g. routing protocol, 
adding next hops to the FIB must care about this.
con: we loose the possibility to take link/topology/interface 
capabilities into account to forward a packet


2. We allow competing entries and apply (sort of) policies to always 
return a unambiguous next hop from the FIB.
pro: we are able to direct data and control plane flows, taking the 
routing protocol capabilities into account.
con: to have a preference on one FIB entry over another competing 
entry, requires a valuing weighting
and decision mechanism. This creates overhead and lowers 
the lookup/response time on next hop requests.


 Typically, these routing protocols split horizon according to IP 
address ranges
Using a separation on IP address ranges would shift the problem away 
from the FIB to the RIB.
This approach is definitely useful on non-moving routers with an 
organized and static hierarchy and a good argument for following 1.


But I think in some IoT scenarios with moving routers, this approach 
might have a poor performance

when the connected networks between the IoT routers periodically change.

 how does the FIB decide which next hop to choose if more than routing 
protocol made an entry pointing to it?
I've built in [1] to the FIB to provide an entry point to handle such 
conflicts.



Best Regards,
Martin

[1] 
https://github.com/BytesGalore/RIOT/blob/add_fib/sys/net/network_layer/fib/fib.c#L260


On 19.11.2014 00:47, Thomas C. Schmidt wrote:

Hi Martine,

a FIB always only provides unique forwarding rules. So there are no 
priorities attached to FIB entries. Priorities of routes may occur in 
RIBs associated with routing protocols ... and a significant question 
is of course how to deal with competing routing protocols that feed 
the FIB. (Typically, these routing protocols split horizon according 
to IP address ranges.)


Still, a routing protocol either overrides FIB entries or it doesn't.

Cheers,

Thomas

On 18.11.2014 21:56, Martine Lenders wrote:

Hi,
it's me again, dumping my latest brainstorm into the thread :D.

Don't we need some kind of priorities for the routing protocols, too? Or
how does the FIB decide which next hop to choose if more than routing
protocol made an entry pointing to it?

Cheers,
Martine

2014-11-17 8:05 GMT+01:00 Martin martin.landsm...@haw-hamburg.de
mailto:martin.landsm...@haw-hamburg.de:

Hi Martine,

... Except you mean the routing protocol by this.
yes, the `prot_id` is the actual used (running) protocol, i.e. RPL.
This identifier must be unique for the running RIOT on the node,
i.e. arbitrary but fixed for the lifetime.

The binding of FIB table entries to a specific (running) protocol
is necessary only for updates on them.

Probably `kernel_pid_t` for the would be a waste of one byte for
each FIB table entry.
I will keep it `uint8_t` for now, but test a bit with 
`kernel_pid_t`.



Best regards,
Martin


On 15.11.2014 02:03, Martine Lenders wrote:

Hi Martin,

2014-11-14 15:23 GMT+01:00 Martin martin.landsm...@haw-hamburg.de
mailto:martin.landsm...@haw-hamburg.de:

Hi Martine,

I will change the interface and protocol IDs to
`kernel_type_t` as you suggested.
For the FIB handling perspective this seems also to be the
best (and easiest) way to have the IDs unique on one RIOT/node.


For protocol IDs I suggest `netdev_proto_t` [1]. Except you mean
the routing protocol by this. It aims, at least regarding my
design, to be the RIOT-global identifier for all network protocol
RIOT supports.

Cheers,
Martine

[1]
https://github.com/RIOT-OS/RIOT/blob/038beb0f99215207c09fd862ac7712982cedb3ef/drivers/include/netdev/base.h#L57


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



___
devel mailing list
devel@riot-os.org mailto: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] FIB redesign

2014-11-16 Thread Martin

Hi Martine,

... Except you mean the routing protocol by this.
yes, the `prot_id` is the actual used (running) protocol, i.e. RPL.
This identifier must be unique for the running RIOT on the node, i.e. 
arbitrary but fixed for the lifetime.


The binding of FIB table entries to a specific (running) protocol is 
necessary only for updates on them.


Probably `kernel_pid_t` for the would be a waste of one byte for each 
FIB table entry.

I will keep it `uint8_t` for now, but test a bit with `kernel_pid_t`.


Best regards,
Martin

On 15.11.2014 02:03, Martine Lenders wrote:

Hi Martin,

2014-11-14 15:23 GMT+01:00 Martin martin.landsm...@haw-hamburg.de 
mailto:martin.landsm...@haw-hamburg.de:


Hi Martine,

I will change the interface and protocol IDs to `kernel_type_t` as
you suggested.
For the FIB handling perspective this seems also to be the best
(and easiest) way to have the IDs unique on one RIOT/node.


For protocol IDs I suggest `netdev_proto_t` [1]. Except you mean the 
routing protocol by this. It aims, at least regarding my design, to be 
the RIOT-global identifier for all network protocol RIOT supports.


Cheers,
Martine

[1] 
https://github.com/RIOT-OS/RIOT/blob/038beb0f99215207c09fd862ac7712982cedb3ef/drivers/include/netdev/base.h#L57



___
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] iot-lab_M3

2014-11-12 Thread Martin

Hi Thomas,

it worked! :D

1. I had to install `libftdi-dev` first. ./configure complained 
`checking for LIBFTDI... no` using your provided options.


2. I used:
`./configure --disable-dependency-tracking --prefix=my/desired/path 
--enable-dummy --enable-buspirate --enable-jtag_vpi 
--enable-remote-bitbang --enable-usb_blaster_libftdi 
--enable-presto_libftdi --enable-openjtag_ftdi 
--enable-legacy-ft2232_libftdi`

as you provided.

This didn't helped alone.

3. I applied `git revert e455664cfc75f9b5dfb3a8f04349dadac6a85c7d` as 
Oleg stated,

and

4. I removed the `ftdi_device_desc` form `iot-lab_M3_jtag.cfg`
and viola, it flashes.

Now the spooky part (confirms Oleg's observation):
After flashing the device once I reverted the revert, and can flash with 
the current `iot-lab_M3_jtag.cfg` configuration (still have to remove 
`ftdi_device_desc`)


Thx Thomas, thx Oleg.

Best regards,
Martin

On 12.11.2014 11:42, Thomas Eichinger wrote:


Hi Martin,

below the configuration options I use to build for OS X

```
./configure —disable-dependency-tracking —prefix=your/desired/path 
—enable-dummy —enable-buspirate —enable-jtag_vpi 
—enable-remote-bitbang —enable-usb_blaster_libftdi 
—enable-presto_libftdi —enable-openjtag_ftdi —enable-legacy-ft2232_libftdi

```
Let me know if this helps, I’d update the wiki accordingly.

Best, Thomas


On 12 Nov 2014, at 11:13, Martin martin.landsm...@haw-hamburg.de 
mailto:martin.landsm...@haw-hamburg.de wrote:







Hi Oleg,



tried it, but still no luck.

I also tried it together with @PeterKietzmann on a different linux
distribution but all the same results for all steps.



Best regards,

Martin



On 11.11.2014 17:39, Oleg Hahm wrote:




Hi Martin!




sorry for bothering.



No problem.
  



invoking `make BOARD=iot-lab_M3 flash` results in
```
...
DEPRECATED! use 'adapter_khz' not 'jtag_khz'
adapter speed: 1000 kHz
Error: The specified debug interface was not found (ft2232)
...
```



If you have built OpenOCD yourself, make sure to run the configure script with
  --enable-legacy-ft2232_ftd2xx
to enable the legacy interface (IIRC). Thomas might correct me if I'm wrong.

Cheers,
Oleg






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







___
devel mailing list
devel@riot-os.org mailto: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] iot-lab_M3

2014-11-11 Thread Martin

Hi all,

I'm trying to flash the iot-lab_M3 board and constantly fail on:
```
...
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description 
'FITECO M3' and serial '*'

```

I've compiled and installed OpenOCD (0.9.0-dev-00186-g30203b3) which 
perfectly works with the SAMR21-xpro board.


I use `make BOARD=iot-lab_M3 flash` to try flashing.
I also tried to invoke the flash script manually:
`sudo BOARD=iot-lab_M3 ./flash.sh hello-world.hex`
with the same result.

Has anyone a hint for me what I'm doing wrong.

Thanks and best regards,
Martin
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] iot-lab_M3

2014-11-11 Thread Martin

Hi Oleg,

thx for the reply and the PR, its better now, but now fails with:

```
...
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, 
part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, 
part: 0x6414, ver: 0x0)

Error: Failed to read memory at 0x
Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Error: MEM_AP_CSW 0x2342, MEM_AP_TAR 0xe000edf0
...
```


Best regards,
Martin

On 11.11.2014 16:38, Oleg Hahm wrote:

Hi Martin!

Sorry, my bad.


I'm trying to flash the iot-lab_M3 board and constantly fail on:
```
...
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description
'FITECO M3' and serial '*'
```

I was told that on the newer nodes they changed the device description from
FITECO M3 to simply M3 (or A8-M3 for the nodes connected over an A8).

So, changing this in boards/iot-lab_M3/dist/iot-lab_M3_jtag.cfg should help.

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


Re: [riot-devel] FIB redesign

2014-11-04 Thread Martin

Hi Martine,

thx for the input :)

 Are you planning to only consider stateless compression (Prefix is 
assumed link-local) or also stateful compression (Prefix is determined 
by a 4-bit context ID [1] ...


I plan to make it more generic, e.g. allow for providing even 
proprietary solutions for FIB table entry compression. LOWPAN_IPHC 
provides wonderful mechanisms to save bytes in transmissions, but there 
are probably (most likely) more possibilities to save bytes on the 
individual nodes RAM when maintaining a FIB table.
Eventually the FIB will resolve the applied compression to provide the 
type required by a `get_next_hop()` request.


... we might want to consider to put those information into the same 
data structure (so the later of my 2 suggestions above would be)


Indeed, that would by great. That's the reason I want to outsource the 
Generic address from the FIB table entry. These blobs can be shared 
among processes, e.g. FIB, routing protocol and ND.

Liftime invalidation and such is controlled by the individual process.
For instance, an expired FIB table entry would mark its internal 
structure as invalid and decrease the usecount of the Generic address.


 Also: have you considered Mesh-under routing [5]? (Do we have to 
consider this here I wonder myself? We don't have support for it 
anyways, so far.) [6] states some requirements for this.


No, I only considered to play at the network layer level for now. But 
I will have a look.



Best Regards,
Martin

Hi,
I finally came to it to read your suggestions, too. Regarding the fact 
that you keep 6LoWPAN header compression in mind, too: Are you planning 
to only consider stateless compression (Prefix is assumed link-local) or 
also stateful compression (Prefix is determined by a 4-bit context ID 
[1], disseminated through the PAN via the context identifier option in 
RS [2]). Since Neighbor Cache [3], Prefix Information [4], Forwarding 
information, and Context Information are all very related, and we may 
want to save memory, we might want to consider to put those information 
into the same data structure (so the later of my 2 suggestions above 
would be). Keep in mind though, that both Prefix Information Base and 
Context information Base have their own lifecycles (see regarding RFCs).


Also: have you considered Mesh-under routing [5]? (Do we have to 
consider this here I wonder myself? We don't have support for it 
anyways, so far.) [6] states some requirements for this.


Hope this was more helpful, than confusing ;-).

Cheers,
Martine

[1] https://tools.ietf.org/html/rfc6282#section-3.1.2
[2] https://tools.ietf.org/html/rfc6775#section-4.2
[3] http://tools.ietf.org/html/rfc4861#section-5.1
[4] https://tools.ietf.org/html/rfc4861#section-4.6.2
[5] https://tools.ietf.org/html/rfc4944#section-11
[6] http://tools.ietf.org/html/rfc6606
___
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] FIB redesign

2014-11-03 Thread Martin

Hi Emmanuel, hi all,

 - the way I read it, the current content aims at some sort of list of 
requirements, and a description the current FIB design in RIOT, right?
right, somehow. It figures the problematic areas that have to be handled 
for a clean interaction as sketched in the diagram.


 - more in particular: it does not contain so far any concrete 
proposal for a FIB redesign. Am I correct?
Yes and no, the diagram at the bottom should give a conceptual overview 
how the interaction of the FIB in the RIOT context finally could be.

It does not reflect anything present RIOT.
I didn't wanted to go to much into possible implementation details, as 
long as the concept is not considered as sane.


The FIB itself will be a lightweight interface providing access and 
manipulation decoupling the data, i.e. FIB tables, from the routing 
protocols (or RIB).
The FIB table will provide a generalized data management/structure. I 
updated the page with a concept of a FIB table data overview.

This should allow to take advantage of non IP addressing.
The access functions as sketched from RIB and RIOT processes will 
provide a KISS and clean interface.
For instance just `add(...) remove(...)` and `update(...)` from RIB side 
and `get_next_hop(...)` from a RIOT process.
The dispatching on FIB table entries and weight of them over others on 
collisions happens behind the FIB-wall.


If this sounds sane, I could provide some code till mid/end of this week 
reflecting the FIB tables and FIB-wall.


Best Regards,
Martin
On 03.11.2014 15:18, Emmanuel Baccelli wrote:

Hi Martin,

thanks for the initial wiki input on the topic (i.e. 
https://github.com/RIOT-OS/RIOT/wiki/Rough-sketch-of-a-possible-FIB-modularization).


I briefly scanned though it, and I have two quick questions for starters:

- the way I read it, the current content aims at some sort of list of 
requirements, and a description the current FIB design in RIOT, right?


- more in particular: it does not contain so far any concrete proposal 
for a FIB redesign. Am I correct?


Best,

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