[riot-devel] Changing the workflow.

[Martine Lenders]

Hello coding RIOTers,
After I needed to rebase several PRs multiple times last week I'm really
fed up with our current workflow. Furthermore, I discovered three things
that show that we are in need of a more established workflow.

   1. our community is growing
   2. our master branch is changing constantly and has features in it that
   are sometimes thrown out the window weeks after they where introduced (e.g.
   radio_types.h or the older versions of netapi/netdev)
   3. we introduced feature-centric task forces to our communities

This is why I propose we change to a slightly adapted topic branch workflow
(also known as feature branch) workflow [1]:

   - the main RIOT-OS/RIOT repository will get the following branches
  - master: points to the stable version of our latest release
 - one stable branch for every major release (?)
  - devel: points to current development version (what is currently our
  master), hot fixes can be cherry-picked to the master from here.
  - branching from devel: feature branch for every task force that is
  currently in active development, current changes will be merged regularly
  from devel by the branches maintainers
   - Pull Requests will be made either to devel (default) or the
   corresponding feature branch
   - feature branches will be merged into devel if the feature reaches
   sufficient stability.
   - devel will be merged into master, when a new release is out and
   master's new HEAD tagged with the release number.

I observed two extra benefits from that:

   - accidentally merged "SQUASH ME" commits can be squashed further
   upstream, before we add the commits to master or devel
   - we can make maintenance of features more granular (and maybe solve our
   maintenance problem) by enacting the "Dictator and Lieutenants Workflow",
   where the "Dictator(s)" are responsible for master and devel, and the
   feature branches can be maintained by the central persons of the Task Force
   (the Lieutenants).

What do you think?

Cheers,
Martine

[1]
http://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows#Topic-Branches
[2]
http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#Dictator-and-Lieutenants-Workflow
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] replace printf, puts issue

[Martine Lenders]

+1 thought about this for a long time, too. Though my approach would be
with macros and more global (similar to how DEBUG is now).

Am 23.02.2015 07:16 schrieb "Ludwig Ortmann" :
>
> Hi Jozef,
>
> AFAIK there has been no work on a solution so far.
> However, I thought about this the other day in the context of the
function pointer discussion and would like to propose a "logging" API
(maybe there is an issue for that as well somewhere) for `core`, which
offers things like `log.info(...)` and `log.error(...)`.
> Different logging modules can implement this API then, ranging from
`printf` over file based logging to network messages.
> And then there should also be a `(void) ...`  implementation which suits
production and ultra low memory needs.
>
> Opinions?
>
> Cheers, Ludwig
>
> Am 23. Februar 2015 03:16:33 MEZ, schrieb Jozef Maslik <
ma...@binarylemon.com>:
> >
> >Hi,
> >
> >Could you please give me information about actual state of "replace
> >printf and puts" issues? https://github.com/RIOT-OS/RIOT/issues/994,
> >https://github.com/RIOT-OS/RIOT/issues/641
> >
> >I’m working with MKL02Z32 which has 4kB RAM. Printf or puts which are
> >almost everywhere make a big problem. I removed them from my fork, but
> >it is not good or nice solution.
> >
> >If I miss something important around “printing issue” please correct
> >me.
> >How others deal with this issue? (printf or puts usage like here, is
> >not nessesary in real applications).
> >
> >Regards,
> >Jozef
> >
> >___
> >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] replace printf, puts issue

[Martine Lenders]

Hi,

Am 23.02.2015 10:04 schrieb "Ludwig Ortmann" :
> are you suggesting macros are better than APIs + functions?
> If so, please explain why and what better means ;)

I was not sure if the compiler optimizes out empty functions, so I assumed

#define INFO(msg) (void)0;

to be the better solution concerning code size.

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

Re: [riot-devel] Changing the workflow.

[Martine Lenders]

Hi,

2015-02-21 20:06 GMT+01:00 Ludwig Ortmann :

> Hi,
>
> On Sat, Feb 21, 2015 at 07:02:58PM +0100, Martine Lenders wrote:
> > This is why I propose we change to a slightly adapted topic branch
> workflow
> > (also known as feature branch) workflow [1]:
> >
> >- the main RIOT-OS/RIOT repository will get the following branches
> >   - master: points to the stable version of our latest release
> >  - one stable branch for every major release (?)
>
> (I understand "stable" to denote non-changing APIs, and a "stable
> branch" to denote a branch which is stable in this sense, and gets
> bugfixes, and possibly new features.)
>
> We don't have enough people to support this at the moment.
> Also, we would definitely need to make sure the releases are sensible
> for this to make sense.
> Let's keep this one open until there is a need, time and a codebase
> that makes sense to put this effort into.
>

I don't get this argument: With my workflow the only new task is the
merging of stable and devel and the maintenance of hot-fixes (which can be
labeled as such and are thus easily spotable). The merging of devel into
stable will happen at every release, and the merging of feature branches
into devel if a milestone for the feature is reached. Or were you referring
to my optional proposal of release branches?


>
> >   - devel: points to current development version (what is currently
> our
> >   master), hot fixes can be cherry-picked to the master from here.
>
> According to my first remark there is no need for a devel branch, we
> just keep using master.
>

Sure we first need a stable version to have a stable branch, but my
thinnking introducing it now was to avoid confusion we often encountered in
the whole transceiver/netdev/ng_netdev situation.


>
> >   - branching from devel: feature branch for every task force that is
> >   currently in active development, current changes will be merged
> regularly
> >   from devel by the branches maintainers
>
> "will be merged regularly" sounds like the amount of merging will
> increase in total. I'd rather leave it to the respective maintainers
> how they work on their feature branch.
>

That's why I left it at "regularly" as in "when it's needed" (e. g. merge
into devel would yield conflicts). Also: more merges mean less merging
conflicts over time so why does it sound like you think merging is a bad
thing ;-)?


>
> >- feature branches will be merged into devel if the feature reaches
> >sufficient stability.
>
> What does "stability" mean in this context?
>

When a certain milestone is reached (e.g. the "current" (apart from two
follow-up PRs ^^") state in netdev/netapi context, or when all critical
protocols are ready)


>
> > I observed two extra benefits from that:
> >
> >- accidentally merged "SQUASH ME" commits can be squashed further
> >upstream, before we add the commits to master or devel
>
> Actually, that is not the case as feature branches will also need to
> be PR'd against master, and might need fixing as well.
>

The "dictator" (as suggested below) can do this on it's own computer, too.
Sure a PR is more transparent but I don't agree that we NEED (from a
technical standpoint) it.


> Also, we could as well "fix" these accidental commits in our master branch.
>

And catch the fury of everyone on their next pull ;-).


> >- we can make maintenance of features more granular (and maybe solve
> our
> >maintenance problem) by enacting the "Dictator and Lieutenants
> Workflow",
> >where the "Dictator(s)" are responsible for master and devel, and the
> >feature branches can be maintained by the central persons of the Task
> Force
> >(the Lieutenants).
>
> We could just as well use the decentralized hierarchical development
> model as performed by the Linux community.
> https://www.kernel.org/doc/Documentation/SubmittingPatches
> This would mean less visibility of the "feature branches" (in
> possession of a "Lieutenant" in your terminology), but also less
> stress on the "Dictators", because they don't constantly see what
> doesn't need to concern them. At least I guess the GitHub interface
> would make it much easier to only follow repositories one is concerned
> with.
>

When you look at the text I've linked: they also give the Linux kernel as
an example for the Dictator/Lieutenant workflow ;-). The terms branch and
repository are more or less interchangable in this context (at least with
Git). I guess in the end its a style choice if we decide for task force
repositories or feature branches. I would welcome the visibility of
development in the feature branch solution, but understand that some might
not be interested in the development of some minor task force.

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

Re: [riot-devel] [PROJECT][RIOT-OS][STM32-L152RE]

[Martine Lenders]

Hi Tara,
have you tried to include your external library as an external module [1]?

Kind regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/wiki/Creating-external-modules

2015-02-24 15:19 GMT+01:00 Tararaina Klipffel :

> Hello,
>
> We are 4 French students in engineering school. We are currently working
> on a robotic project of telepresence. We have set up RIOT-OS on a STM32
> L152RE board and we are now attempting to add an external library in our
> project. We have a library libmded.a that contains every .o precompiled
> provided by mbed, and a folder with the corresponding headers. Then we
> added the .h path to the INCLUDES var in the makefile and the library to
> the USEMODULE var. But when we're trying to compile it, it seems that the
> makefile isn't able to find the functions include in this lib. That's why
> we would be grateful for any advice that could guide us.
>
> Kind regards.
> Tara
>
> ___
> 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] Changing the workflow.

[Martine Lenders]

Hi Attilio,

2015-02-24 16:30 GMT+01:00 Attilio Dona :

> Just for add a bit of documentation for helping discovering the best
> workflow:
>
> http://nvie.com/posts/a-successful-git-branching-model/
>
> The post contains some good points in my opinion, for example the
> guideline that a feature branch have to exists in developer repo and not in
> origin.
>
>
But that is how it is currently basically: A dev opens a branch in her
repository, makes changes and offers them to origin in form of a Pull
Request. The idea of the "feature branches" (let's rebrand this as task
force branches, since this is where I know I differ from the "normal" Git
workflow) is to collect the efforts of a task force in bulk first to add
them to the origin later, to avoid WIP APIs popping up in master. For
external (to the core community) task forces or similar groups it might be
the better solution to do their work in an external repository and merge
their work in a collective PR, but for internal task forces e.g. the NSTF
and OTA-TF (and when they start development the Timer TF) it makes much
more sense to push this kind of work directly to the main repository, but
to a different branch.

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

Re: [riot-devel] [PROJECT][RIOT-OS][STM32-L152RE]

[Martine Lenders]

Hi Tara,
[quotet from your digest reply]:

I tried to include my external library as an external module, but it
> doesn't work ! I have still the same issue. When we're trying to compile
> it, it seems that the makefile isn't able to find the functions include in
> this libmbed.a.
> As you can see in my Makefile, I use this var:
>   # AJOUT MODULE MBED
>   EXTERNAL_MODULE_DIRS += “YOUR_PATH”/RIOT-master/examples/test
>   USEMODULE += libmbed
>   INCLUDES += -I/”YOUR_PATH”/RIOT-master/MBED


2 things: Have you added the Makefile.base to the directory
"YOUR_PATH"/RIOT-master/examples/test?

It has to contain the following

MODULE = libmbed
include $(RIOTBASE)/Makefile.base

You can leave out the first line, if the directory it resides in is called
libmbed (in your example you would need to rename
"YOUR_PATH"/RIOT-master/examples/test to
"YOUR_PATH"/RIOT-master/examples/libmbed).

I export all .o depending on my board and create the libmed.a with the
> command "ar -q libmed.a" . I use the mbed export to gcc, compile it with
> the "GCC ARM Embedded 4.7 update 4" Toolchain and it works ! But when I
> tried to compile with RIOT-OS, its like it isn't able to find the functions
> include in this lib.


Mind that the external module approach only works if you have the source
files (the .c(pp) or .s files) in this directory. If you only have the
object files, try copying them into the directory "YOUR_PATH"/RIOT-master/
examples/bin/YOUR_BOARD/".

Good luck,
Martine

2015-02-24 15:39 GMT+01:00 Martine Lenders :

> Hi Tara,
> have you tried to include your external library as an external module [1]?
>
> Kind regards,
> Martine
>
> [1] https://github.com/RIOT-OS/RIOT/wiki/Creating-external-modules
>
> 2015-02-24 15:19 GMT+01:00 Tararaina Klipffel :
>
>> Hello,
>>
>> We are 4 French students in engineering school. We are currently working
>> on a robotic project of telepresence. We have set up RIOT-OS on a STM32
>> L152RE board and we are now attempting to add an external library in our
>> project. We have a library libmded.a that contains every .o precompiled
>> provided by mbed, and a folder with the corresponding headers. Then we
>> added the .h path to the INCLUDES var in the makefile and the library to
>> the USEMODULE var. But when we're trying to compile it, it seems that the
>> makefile isn't able to find the functions include in this lib. That's why
>> we would be grateful for any advice that could guide us.
>>
>> Kind regards.
>> Tara
>>
>> ___
>> 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] [PROJECT][RIOT-OS][STM32-L152RE]

[Martine Lenders]

Hi again

2015-02-24 20:16 GMT+01:00 Martine Lenders :

> […]
>
> 2 things: Have you added the Makefile.base to the directory
> "YOUR_PATH"/RIOT-master/examples/test?
>

Sorry I meant the Makefile, not the Makefile.base here.
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Changing the workflow.

[Martine Lenders]

Hi Adam,

2015-02-25 2:03 GMT+01:00 Adam Hunt :

> I really like the idea of task force branches (OTA, net, filesystem,
> platform, etc..). They seem somewhat reminiscent of Linux's
> *net, net-next* and similar trees. Would they be implemented as git
> branches within the main repository (e.g
> https://github.com/RIOT-OS/RIOT/OTA) or fully independent repositories
> (e.g. https://github.com/RIOT-OS/RIOT-OTA)? In the case of branches, is
> it possible to give a person write access to a specific branch without
> giving them access to pull things into *master*?
>

Up until this point I confused GitHub with Gitlab, GitHub's Open Source
cousin ;-). In Gitlab you can hand out branch-specific permissions [1],
since they are (or were (?) - its been a little while since I last hosted a
Gitlab server) build upon gitolite which allows for such magic. GitHub on
the other hand has a much coarse permission system [2] that works only on
repository level. So it probably would make more sense to put it into
seperate Repositories, as Ludwig and Attilio already suggested, too.


> I ask because I can imagine cases where you may want to give someone
> access to pull work for a specific feature or subsystem but not give them
> access to pull changes into the main development or stable branches, or say
> tag a release reserving that level of access for core maintainers.
>

Cheers,
Martine

[1]
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/permissions/permissions.md
[2]
https://help.github.com/articles/permission-levels-for-an-organization-repository/
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] LGPL compliance testing

[Martine Lenders]

Hi Murat,
You made the PR to your own repository. You have to open a Pull Request to
our repository.

Hope I could help,
Martine

2015-02-26 16:56 GMT+01:00 Murat CAKMAK :

> Hi Ludwig,
>
> Pull request link : https://github.com/cakmakmurat2000/RIOT/pull/1
> It is my first GIT experience. I might miss something :)
>
> Regards.
>
> -Original Message-
> From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Ludwig Ortmann
> Sent: Thursday, February 26, 2015 8:32 AM
> To: RIOT OS kernel developers
> Subject: Re: [riot-devel] LGPL compliance testing
>
> PS: can you send a link to your PR? I couldn't find it.
>
> Cheers, Ludwig
>
> Am 26. Februar 2015 07:23:52 MEZ, schrieb Ludwig Ortmann
> :
> >Hi Murat,
> >
> >Under what license are the generated files?
> >And also, how do you think your port is related to the discussion in
> >this thread?
> >
> >I can try to talk about this topic with a cypress representative today.
> >We are currently at the "embedded world" and they are too. They seemed
> >interested in RIOT in an initial chat.
> >BTW: As far as I understood it, their software can create object files
> >with library code for the psoc. Therefore I guess it should be possible
> >to link the generated psoc library with RIOT in our make system as
> >well.
> >
> >So, whatever it looks like today, please don't close your pull request
> >yet.
> >
> >Cheers, Ludwig
> >
> >Am 25. Februar 2015 21:46:45 MEZ, schrieb Murat CAKMAK
> >:
> >>Hi All,
> >>
> >>
> >>
> >>I was (still) busy to read mails about LGPL compliance so sorry for
> >>slience.
> >>
> >>
> >>As you know, I have initially ported RIOT to PsoC 5LP processor by
> >>creating a PsoC Creator IDE Projects.
> >>
> >>
> >>
> >>In my case:
> >>
> >>1.   This port not using the default RIOT build environment and
> >>PsoC
> >>Creator IDE hides linking and other details.
> >>
> >>2.   PsoC Creator IDE also creates automatically some source
> >codes.
> >>I
> >>have created an empty project with a small HW design under
> >>dist/PsoCCreator directory. But when you build project in PsoC Creator
> >>IDE, It is going to create a lot of files; system initialization, APIs
> >>for HW blocks which created for RIOT etc. I was not planning to commit
> >>those files to GIT repository because they are already created
> >>automatically by IDE.
> >>
> >>3.   Auto-generated files may be changed (e.g bug fixing) by the
> >>version
> >>of PSOC Creator IDE. So, md5 sums may be different for different
> >>versions of PsoC Creator IDE.
> >>
> >>
> >>
> >>On the other hand, I can also implemented required files instead of
> >>auto-generated PsoC Creator files, and use RIOT build system. But HEX
> >>files of PsoC processors also includes HW desing code (verilog)
> >>addition to firmware output(elf, hex etc.). I dont know how PsoC
> >>Creator IDE
> >merges
> >>Firmware code and HW design code into a single HEX file and I am not
> >>sure about PSOC Creator team share this information with me.
> >>
> >>It is the hard way and also I dont prefer to use this way. Because, in
> >>this way, we can not use advantages(ARM Core + Programmable
> >>Digital&Analog
> >>Blocks) of PsoC processors which only available by PsoC Creator IDE.
> >>
> >>
> >>
> >>So, What is the latest decision?
> >>
> >>Should I withdraw my "pull request" for PsoC 5LP port?
> >>
> >>
> >>
> >>Regards.
> >>
> >>
> >>
> >>Murat.
> >>
> >>
> >>
> >>
> >>
> >>-Original Message-
> >>From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Matthias
> >>Waehlisch
> >>Sent: Saturday, February 21, 2015 5:09 PM
> >>To: RIOT OS kernel developers
> >>Subject: Re: [riot-devel] LGPL compliance testing
> >>
> >>
> >>
> >>Hi Kaspar,
> >>
> >>
> >>
> >>On Fri, 20 Feb 2015, Kaspar Schleiser wrote:
> >>
> >>
> >>
> >>> Let me correct myself.
> >>
> >>>
> >>
> >>> There are no technical reasons against using LGPLed RIOT to develop
> >>
> >>> proprietary applications.
> >>
> >>>
> >>
> >>  it depends on how you define "technical reasons". Yes, it is not
> >>impossible to create separate object files. But you maybe don't want
> >to
> >>do
> >>this for technical optimization (see for example
> >> >>_FINAL
> >>.pdf>
> >>
> http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINA
> L.
> >>pdf).
> >>
> >>
> >>
> >>> Using a "weird compiler" that cannot output the required object
> >files
> >>
> >>
> >>> because it is closed source and proprietary is purely political.
> >That
> >>
> >>
> >>> compiler could be changed trivially *if it would be open source* or
> >>
> >>> the vendor was inclined to do so. This doesn't count as technical
> >>
> >>> reason.
> >>
> >>>
> >>
> >>  I agree with Oleg's comment on this.
> >>
> >>
> >>
> >> And btw, if a compiler can "be changed trivially" depends on details
> >I
> >>suppose.
> >>
> >>
> >>
> >>> >For me the sentence "RIOT allows LGPL + proprietary source code
> >
> >>
> >>> > at the sam

Re: [riot-devel] IRC channel #riot-os

[Martine Lenders]

Hi,
Normally there are 20-30 people online with varying activity. Make sure you
chose the correct server (irc.freenode.net) and the correct channel
(#riot-os).

Kind Regards,
Martine


2015-03-07 21:54 GMT+01:00 David Reinert :

> Hello all, I've been trying to find people on the IRC channel on freenode
> but so far the last few times I've logged on there has not been anyone else
> on. Is there a specific time to be on? I really would like to get a
> discussion started with the veteran RIOT developers so I can start forming
> a project proposal as soon as possible. I am quite eager to get the ball
> rolling. The channel is #riot-os correct?
>
> ___
> 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] Galileo-Board

[Martine Lenders]

Hi,
there is a second person now asking for support for the Galileo board.
Though there is a Wiki page I did not find any source files for this board.
I can't remember: Do we support the board or was the development aborted do
to the complications René encountered. If the latter one is the case, we
should remove the board from the wiki. If the first one is the case we
should fix the documentation accordingly about where to find it.

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

Re: [riot-devel] microcoap app

[Martine Lenders]

Hi,
I don't know how much expertise Martin has on the microcoap application,
but I tried to compile it against current master and it worked. Did you try
a `make distclean` before `make`? Sometimes the checkout points for the pkg
repositories get a little deprecated.

Cheers,
Martine

2015-03-16 10:26 GMT+01:00 Baptiste Clenet :

> Hello,
>
> I'm trying to build the microcoap app on Native.
> Here is what I get:
>
> workspace/applications-master/microcoap$ make
> ...
> gcc: error:
> workspace/applications-master/microcoap/bin/native/microcoap.a: Aucun
> fichier ou dossier de ce type
> make: *** [all] Erreur 1
>
>
> RIOT folder is in workspace as well.
>
> If I change the name "microcoap-example" by "microcoap", I get:
>
> workspace/applications-master/microcoap$ make
> ...
> workspace/applications-master/microcoap/bin/native/microcoap.a(main.o):
> dans la fonction « _microcoap_server_thread »:
> main.c:(.text+0x30a): référence indéfinie vers « coap_dump »
> main.c:(.text+0x336): référence indéfinie vers « coap_parse »
> main.c:(.text+0x384): référence indéfinie vers « coap_dumpPacket »
> main.c:(.text+0x3a4): référence indéfinie vers « coap_handle_req »
> main.c:(.text+0x3c4): référence indéfinie vers « coap_build »
> main.c:(.text+0x418): référence indéfinie vers « coap_dump »
> main.c:(.text+0x43e): référence indéfinie vers « coap_dumpPacket »
> collect2: error: ld returned 1 exit status
> make: *** [all] Erreur 1
>
> Btw, coap pkg is built without errors.
>
> Martin, did I do something wrong?
>
> Cheers,
>
> --
>
> *Clenet BaptisteFR: +33 6 29 73 05 39 <%2B33%206%2029%2073%2005%2039>*
>
>
>
> ___
> 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] 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

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

[riot-devel] New Event: Hack'n'ACK @ Monthly from 5pm to 10pm on the last Tuesday (RIOT Events)

[Martine Lenders]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20150331T17
DTEND;TZID=Europe/Berlin:20150331T22
RRULE:FREQ=MONTHLY;BYDAY=-1TU
DTSTAMP:20150319T120715Z
UID:lbk4mfucqdomcf7c8o9cg4c...@google.com
CREATED:20150319T120715Z
DESCRIPTION:View your event at https://www.google.com/calendar/event?action
 =VIEW&eid=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2cgazNxbDhzZXR2N2w0OG9mbm9sMHRmd
 XU2dHNAZw.
LAST-MODIFIED:20150319T120715Z
LOCATION:c-base Berlin\; HAW Hamburg
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Hack'n'ACK
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


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

Re: [riot-devel] CSMA MAC-layer, Open Issues

[Martine Lenders]

Hi Jonas,

2015-03-20 18:02 GMT+01:00 Jonas Remmert :

> Hi,
>
> […]
>
> 2. The drivers send function builds the IEEE 802.15.4 MAC header on its
> own. The alternative would be to let the MAC layer do this job. This would
> avoid code duplication and make it easier to implement new radio drivers.
> Is there any reason to do this in the driver implementation?
>

Yes, the MAC layers should be as independent from the drivers as possible
(with protocols like TSCH for IEEE 802.15.4e this is obviously not
possible, but your CSMA implementation might also be used with a cc1100 or
other radios). As for avoiding code duplication with IEEE 802.15.4 header
building, there is the `ieee802154` [1] module for that. There is  also an
older PR by Hauke [2], that hopefully will be updated to the new network
stack scheme soon ;-).


> […]
>
> 4. Generally, a successfull TX of a packet is not signalized to upper
> layers. But how do we handle a packet that could not be sent to the channel
> (e.g. channel busy)? Should upper layer be informed about the failure?
>

No, it just will be dropped (or the MAC must queue it).


> […]

a nice Weekend,
> Jonas
>

Have a nice weekend too,
Martine

[1]
https://github.com/RIOT-OS/RIOT/blob/master/sys/net/include/ieee802154_frame.h
[2] https://github.com/RIOT-OS/RIOT/pull/2355
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] C Bitfields and network_uint16_t

[Martine Lenders]

Hi Simon,
you can use network_uint16_t as integer by accessing it's u16 member, but
since bitfields are usually accessed using bit-arithmetics anyways I'm
wondering if it makes so much sense to use network_uint16_t, since they are
primarily used to warn about byteorder issues.

Cheers,
Martine

2015-03-21 21:01 GMT+01:00 Simon :

> Hi Everyone,
>
> I am trying to define the Header Datastructure for the new TCP
> implementation. I'd like to use C Bitfields in structs for the Control
> Bits and would like to use the Type of network_uint16_t (That seems to
> be common for most other Header Structures). My compiler tells me that
> thats not possible because network_uint16_t is not an integer type.
>
> In Byteorder.h it shows that its actually a union. Has anyone an Idea to
> solve this issue? I would really like to use only network types in my
> structure.
>
> Thanks in advance.
>
> Yours sincerly
> Simon Brummer
>
>
> ___
> 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] Updated Invitation: Biweekly virtual meeting @ Wed Mar 25, 2015 2pm - 3pm (RIOT Events)

[Martine Lenders]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20150325T14
DTEND;TZID=Europe/Berlin:20150325T15
DTSTAMP:20150324T154427Z
UID:jpp1u2ivlued8qdtp50jsb1...@google.com
RECURRENCE-ID;TZID=Europe/Berlin:20150325T10
CREATED:20141212T130850Z
DESCRIPTION:Developer discussions. Remote participation will be provided.\n
 View your event at https://www.google.com/calendar/event?action=VIEW&eid=an
 BwMXUyaXZsdWVkOHFkdHA1MGpzYjFzZ2tfMjAxNTAzMjVUMDkwMDAwWiBrM3FsOHNldHY3bDQ4b
 2Zub2wwdGZ1dTZ0c0Bn.
LAST-MODIFIED:20150324T154426Z
LOCATION:
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:Biweekly virtual meeting
TRANSP:OPAQUE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P0DT12H0M0S
END:VALARM
END:VEVENT
END:VCALENDAR


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

[riot-devel] IEEE 802.15.4 addressing

[Martine Lenders]

Hi,
now that we start to get in IEEE 802.15.4/6LoWPAN territory with
netdev/netapi [1-3] I wonder if it makes sense to not have 2
(16-bit/64-bit) but 3 addressing modes:

* 16-bit short address
* 32-bit (16-bit PAN ID + 16-bit short address) as originally introduced to
RIOT, but somehow ignored over since then in [4]
* 64-bit long address.

As far as I read [5], there is not really any use-case for PAN ID + long
address.

The API proposed in netdev/netapi need no change for this. It's rather a
question what the drivers and 6LoWPAN should accept and generate as
addressing formats for packets.

Tell me what you think.

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/2614
[2] https://github.com/RIOT-OS/RIOT/pull/2627
[3] https://github.com/RIOT-OS/RIOT/pull/2695
[4] https://github.com/RIOT-OS/RIOT/pull/925
[5] http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Mar 31, 2015 5pm - 10pm (RIOT Events)

[Martine Lenders]

Dear relentless IoTlers,
die to the storm currently brewing up above Berlin and a scheduling mistake
of my own I'll be a little bit late at c-base. If you are there before me,
grab a beer (or beverage of your choice) at the replicator or the bar and
wait in the mainhall and wait for me. If you were there before you also
might ask for the key to the meeting room at the bar. They might give it to
you if you tell them it's for the RIOT Hack'n'ACK.

Cheers,
Martine
Am 30.03.2015 17:01 schrieb "Google Calendar" <
calendar-notificat...@google.com>:

> more details »
> <https://www.google.com/calendar/event?action=VIEW&eid=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNTAzMzFUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn>
> Hack'n'ACK
> *When*
> Tue Mar 31, 2015 5pm – 10pm Berlin
> *Where*
> c-base Berlin; HAW Hamburg (map
> <https://maps.google.de/maps?q=c-base+Berlin;+HAW+Hamburg&hl=en>)
> *Calendar*
> RIOT Events
> *Who*
> •
> Martine Lenders - creator
>
> Invitation from Google Calendar <https://www.google.com/calendar/>
>
> You are receiving this email at the account peterschme...@gmail.com
> because you are subscribed for notifications on calendar RIOT Events.
>
> To stop receiving these emails, please log in to
> https://www.google.com/calendar/ and change your notification settings
> for this calendar.
>
> ___
> devel mailing list
> devel@riot-os.org
> https://riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Mar 31, 2015 5pm - 10pm (RIOT Events)

[Martine Lenders]

Hi,

Again sorry for the delay, but I finally managed to set up the video
conference:
http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-

Feel free to join. Please refer to the Wiki for a How-To

Cheers,
Martine

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

2015-03-31 16:30 GMT+02:00 Martine Lenders :

> Dear relentless IoTlers,
> die to the storm currently brewing up above Berlin and a scheduling
> mistake of my own I'll be a little bit late at c-base. If you are there
> before me, grab a beer (or beverage of your choice) at the replicator or
> the bar and wait in the mainhall and wait for me. If you were there before
> you also might ask for the key to the meeting room at the bar. They might
> give it to you if you tell them it's for the RIOT Hack'n'ACK.
>
> Cheers,
> Martine
> Am 30.03.2015 17:01 schrieb "Google Calendar" <
> calendar-notificat...@google.com>:
>
>> more details »
>> <https://www.google.com/calendar/event?action=VIEW&eid=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNTAzMzFUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn>
>> Hack'n'ACK
>> *When*
>> Tue Mar 31, 2015 5pm – 10pm Berlin
>> *Where*
>> c-base Berlin; HAW Hamburg (map
>> <https://maps.google.de/maps?q=c-base+Berlin;+HAW+Hamburg&hl=en>)
>> *Calendar*
>> RIOT Events
>> *Who*
>> •
>> Martine Lenders - creator
>>
>> Invitation from Google Calendar <https://www.google.com/calendar/>
>>
>> You are receiving this email at the account peterschme...@gmail.com
>> because you are subscribed for notifications on calendar RIOT Events.
>>
>> To stop receiving these emails, please log in to
>> https://www.google.com/calendar/ and change your notification settings
>> for this calendar.
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://riot-os.org/mailman/listinfo/devel
>>
>>
___
devel mailing list
devel@riot-os.org
https://riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Build issue on Windows (8.1)

[Martine Lenders]

Hi Oleg, Hi Murat,

Oleg, maybe it is a good idea if we download the images into the Wiki's
repository and link them from there?

Cheers,
Martine

2015-04-01 13:39 GMT+02:00 Oleg Hahm :

> Hi Murat!
>
> > I did not see any issue about picture. I have re-added same
> picture(address)
> > to page again.
>
> Funny! Yesterday the picture was showing a red car...
>
> Thanks,
> Oleg
> --
> The sad thing about IPv6 jokes is that almost no one understands them and
> no
> one is using them yet.
>
> ___
> devel mailing list
> devel@riot-os.org
> https://riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://riot-os.org/mailman/listinfo/devel

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

[Martine Lenders]

Hi,
in general I prefer 2pm, but tomorrow I'm not able to attend at this time.

Cheers,
Martine
Am 07.04.2015 10:08 schrieb "Oleg Hahm" :

> Hi,
>
> anyone opposed to permanently rescheduling this call to 2pm CEST?
>
> Cheers,
> Oleg
>
> On Tue, Apr 07, 2015 at 08:00:13AM +, Google Calendar wrote:
> > This is a notification for:
> >
> > Title: Biweekly virtual meeting
> > Developer discussions. Remote participation will be provided.
> > When: Every 2 weeks from 10am to 11am on Wednesday Berlin
> > Calendar: RIOT Events
> > Who:
> > * Ludwig Ortmann - creator
> >
> > Event details:
> https://www.google.com/calendar/event?action=VIEW&eid=anBwMXUyaXZsdWVkOHFkdHA1MGpzYjFzZ2sgazNxbDhzZXR2N2w0OG9mbm9sMHRmdXU2dHNAZw
> >
> > Invitation from Google Calendar: https://www.google.com/calendar/
> >
> > You are receiving this email at the account peterschme...@gmail.com
> because
> > you are subscribed for notifications on calendar RIOT Events.
> >
> > To stop receiving these emails, please log in to
> > https://www.google.com/calendar/ and change your notification settings
> for
> > this calendar.
>
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
>
>
> --
> printk("%s: TDR is ga-ga (status %04x)\n", ...);
> linux-2.6.6/drivers/net/eexpress.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] NSTF meeting - detail questions

[Martine Lenders]

Hi,

2015-04-08 17:31 GMT+02:00 Oleg Hahm :

> Dear redesigning IOTlers,
>
> […]
>
> In order to identify a good time, I set up a doodle:
> http://doodle.com/hst7m64madhhyxnb


Is it just me or do others have trouble to connect to this page to (both
firefox and chrome are claiming that the host is unreachable).

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

Re: [riot-devel] Task force ping

[Martine Lenders]

Hi Kaspar,
The organizational issue [1] for the NSTF gives a good overview I think. At
least I try to keep it current from the overview I have.

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/issues/2278

2015-04-09 8:44 GMT+02:00 Kaspar Schleiser :

> Hey guys,
>
> trying a new idea: task force pings.
>
> Every task force: please give a short status update.
>
> I'll start as only member of the timer task force:
>
> - requirements collection seems complete
> - some thought has gone into actual implementation
> - stalled for lack-of-time reasons
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] new network stack mini howto

[Martine Lenders]

Hey Kaspar,
Just take the current ng_icmpv6/feat/initial branch in my repo (PR'ed in
#2555) + your favorite device driver. Start your device in a nomac thread
(look into tests/driver_xbee for how to do it) and add ng_icmpv6_echo,
ng_netbase and ng_nomac to your application's modules. Currently you have
to set up your local IP addresses by hand using ifconfig in the shell and
you also have to populate the neighbor cache with the ncache command.

Then you can use the ping6 command to send echo requests. Echo relies are
answered automatically in the background. If you want to dump them to the
terminal register ng_pktdump for NG_NETTYPE_ICMPV6 (merge branch
pktdump/feat/dump-ipv6 (#2741) for nicer output).

If you need 6LoWPAN, merge the branch ng_sixlowpan_frag/feat/initial
(#2781) and add the module ng_sixlowpan_frag, but be aware that I need to
test if the reassembly on receive is working, yet ;). 6LoWPAN needs to be
initialized for the interface too. For now using ifconfig  6lo (or
simply set the NG_IPV6_NETIF_FLAGS_SIXLOWPAN flag for the ng_ipv6_netif_t
of your interface in your code).
Hope this was helpful.

Cheers,
Martine
Am 11.04.2015 12:15 schrieb "Kaspar Schleiser" :

> Hey guys,
>
> is there any kind of example on how to set up the new network stack as far
> as currently possible?
>
> So many PR's, components, etc. and all I want is ping my node...
>
> Kaspar
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] new network stack mini howto

[Martine Lenders]

Hi,

2015-04-12 11:33 GMT+02:00 Kaspar Schleiser :

> Hey Martine,
>
> thanks a lot, that was what I was looking for!
>
> On 04/11/15 22:31, Martine Lenders wrote:
>
>> Just take the current ng_icmpv6/feat/initial branch in my repo (PR'ed in
>> #2555) + your favorite device driver. Start your device in a nomac
>> thread (look into tests/driver_xbee for how to do it) and add
>> ng_icmpv6_echo, ng_netbase and ng_nomac to your application's modules.
>> Currently you have to set up your local IP addresses by hand using
>> ifconfig in the shell and you also have to populate the neighbor cache
>> with the ncache command.
>>
> That's exactly what I needed. I can now ping6 a native instance of riot
> using the dev_eth+tap driver.
>

Great!


> […]
>
> - our native tap drivers take the mac address from the tap interface. if
> using the same tap interface on the host, the mac addresses collide. I
> solved this by just incrementing the last byte of tap's mac address. As tap
> mac addresses are random, that *should* be ok with 1:2^48 probability,
> right?
>

Ah, why did I not realize this by now m). I think as an initial address
this is alright, but maybe you can allow for the user to set the MAC
address (using ng_netdev_driver_t::set) for the host side of the TAP then,
too.


>
> - (bug in icmpv6? [1])
>

Fixed


>
> It seems very reliable and quite fast:
> --snip--
> [kaspar@localhost sys]$ sudo ping6 2001:db8::2 -f -c 10
> PING 2001:db8::2(2001:db8::2) 56 data bytes
> ..
> --- 2001:db8::2 ping statistics ---
> 10 packets transmitted, 8 received, 0% packet loss, time 5905ms
> rtt min/avg/max/mdev = 0.028/0.040/1.384/0.017 ms, ipg/ewma 0.059/0.045 ms
> [kaspar@localhost sys]$
> --snip--
>

Awesome! :3

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

Re: [riot-devel] NSTF meeting - detail questions

[Martine Lenders]

Hi,
The doodle determined Tuesday afternoon as the time when most are
available. Are we gonna do it then?

Cheers,
Martine
Am 08.04.2015 21:19 schrieb "Cenk Gündogan" :

>  Hey Martine,
>
> I have no problems connecting to
> http://doodle.com/hst7m64madhhyxnb
>
> Best,
> Cenk
>
> On 08.04.2015 20:51, Martine Lenders wrote:
>
> Hi,
>
> 2015-04-08 17:31 GMT+02:00 Oleg Hahm :
>
>> Dear redesigning IOTlers,
>>
>> […]
>>
>> In order to identify a good time, I set up a doodle:
>> http://doodle.com/hst7m64madhhyxnb
>
>
>  Is it just me or do others have trouble to connect to this page to (both
> firefox and chrome are claiming that the host is unreachable).
>
>  Cheers,
> Martine
>
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://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] Testing Task Force

[Martine Lenders]

Hi,
there were ~40 new builds opened yesterday [1] and it takes travis ~30 min
to finish a build (and since we are in the fair-use queue it works of the
jobs more or less sequentially), so thats why the later ones are pending. I
think we can speed up things a little if everyone (who has rights to do
that) kills jobs that are not current anymore (due to a PR being updated or
force-pushed e.g.) as Kushal proposed in [2].

Cheers,
Martine

[1] https://travis-ci.org/RIOT-OS/RIOT/pull_requests
[2] https://github.com/RIOT-OS/RIOT/pull/2793#issuecomment-92205543

2015-04-15 16:02 GMT+02:00 Oleg Hahm :

> Hey folks from the testing task force,
>
> does anyone know what exactly is currently wrong with Travis? I have the
> impression that it didn't run a single test for RIOT today. E.g.
> https://github.com/RIOT-OS/RIOT/pull/2764 is pending for 24h hours now.
>
> Cheers,
> Oleg
> --
> The bad thing about Haskell jokes is that let understood = map (isJust .
> understand) $ repeat joke in or understood == False
>
> ___
> 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] Testing Task Force

[Martine Lenders]

Okay it takes ~1h to finish a build. My bad.

2015-04-15 17:30 GMT+02:00 Martine Lenders :

> Hi,
> there were ~40 new builds opened yesterday [1] and it takes travis ~30 min
> to finish a build (and since we are in the fair-use queue it works of the
> jobs more or less sequentially), so thats why the later ones are pending. I
> think we can speed up things a little if everyone (who has rights to do
> that) kills jobs that are not current anymore (due to a PR being updated or
> force-pushed e.g.) as Kushal proposed in [2].
>
> Cheers,
> Martine
>
> [1] https://travis-ci.org/RIOT-OS/RIOT/pull_requests
> [2] https://github.com/RIOT-OS/RIOT/pull/2793#issuecomment-92205543
>
> 2015-04-15 16:02 GMT+02:00 Oleg Hahm :
>
>> Hey folks from the testing task force,
>>
>> does anyone know what exactly is currently wrong with Travis? I have the
>> impression that it didn't run a single test for RIOT today. E.g.
>> https://github.com/RIOT-OS/RIOT/pull/2764 is pending for 24h hours now.
>>
>> Cheers,
>> Oleg
>> --
>> The bad thing about Haskell jokes is that let understood = map (isJust .
>> understand) $ repeat joke in or understood == False
>>
>> ___
>> 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] Testing Task Force

[Martine Lenders]

Hi Oleg,

2015-04-16 9:36 GMT+02:00 Oleg Hahm :

> Hi!
>
> > there were ~40 new builds opened yesterday [1]
>
> Sorry for the maybe stupid question, but how do zou see this? I find the
> Travis UI pretty confusing (and slow).
>

The date the build opened you sadly can't see, but I monitored
https://travis-ci.org/RIOT-OS/RIOT/pull_requests (I provided that link in
the reference) that day, that lists all incoming builds for PR (build on
push is disabled, so https://travis-ci.org/RIOT-OS/RIOT/builds only shows
older merges into master).

I concocted a little something yesterday night [1]. Maybe this will speed
things up a little.

Cheers,
Martine


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

Re: [riot-devel] Network Stack diagram

[Martine Lenders]

Hey Baptiste,
I don't know how useful they are for your context, but I drew up some
(preliminary) activity diagrams for my parts (IPv6 and 6LoWPAN) [1].

Cheers,
Martine

[1]
https://www.dropbox.com/sh/rn750v8r8ezszqw/AABKpegFODterMuE6X4g0kQSa?dl=0

2015-04-17 13:22 GMT+02:00 Baptiste Clenet :

> Thanks Hauke, I think it would be useful to anybody who want to take part
> of RIOT.
>
> Baptiste
>
> 2015-04-17 12:37 GMT+02:00 Hauke Petersen :
>
>>  Hi Baptiste,
>>
>> there is no official drawing at the moment, though we are working on
>> it... I will put it on my list for next week and let you know once we have
>> something.
>>
>> Cheers,
>> Hauke
>>
>>
>>
>> On 17.04.2015 12:20, Baptiste Clenet wrote:
>>
>> Hi,
>>
>>  Is there any diagram somewhere to get an overview of the New Network
>> Stack? (How it works, how it is connected from transceiver to UDP)
>> The links provided in [1] can't be read by draw io.
>>
>>  Cheers,
>>
>> [1]  https://github.com/RIOT-OS/RIOT/wiki/Model-for-the-network-stack
>>
>>  --
>>
>> *Clenet Baptiste *
>>
>>
>>
>>
>> ___
>> devel mailing 
>> listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] ENABLE_DEBUG per module?

[Martine Lenders]

Hi,
just to add my rational to the discussion: I don't like that I have to edit
files to activate debugging messages (and potentially adding the change to
my PR by accident). My PR eliminates - but does not prohibit (one can still
add the `#define ENABLE_DEBUG (1)` before the debug.h include) - the need
for that.

Cheers,
Martine

2015-04-21 11:26 GMT+02:00 Kaspar Schleiser :

> Hey,
>
> On 04/21/15 10:14, Oleg Hahm wrote:
>
>> some time ago Martine proposed to move the `ENABLE_DEBUG` macro from file
>> to
>> module context [1]. Since this would effect the whole RIOT printf
>> debugging, I
>> would like to call on the mailing list if someone thinks that this would
>> be a
>> bad idea.
>>
>
> I like that I can switch on debugging per file. Still you can easily use
> "#define ENABLE_DEBUG MY_MODULE_DEBUG_FLAG" before including debug.h. So we
> already have both options. Why change?
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] ENABLE_DEBUG per module?

[Martine Lenders]

Hi,

2015-04-21 13:29 GMT+02:00 Kaspar Schleiser :

> Hey,
>
> On 04/21/15 11:53, Martine Lenders wrote:
>
>> just to add my rational to the discussion: I don't like that I have to
>> edit files to activate debugging messages (and potentially adding the
>> change to my PR by accident). My PR eliminates - but does not prohibit
>> (one can still add the `#define ENABLE_DEBUG (1)` before the debug.h
>> include) - the need for that.
>>
> But it does treat core/ as one module, right?



Yes, because it is (at least in our current build system logic).

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

Re: [riot-devel] Traditional IP Stack usage

[Martine Lenders]

Hello Jori,
with the current implementation (the "old" one) this is not possible, but
there is currently a new one in the work, that will allow for it. The PRs
of interest are #2454 [1] for IPv6 and #2430 [2] for UDP. Keep in mind that
both are currently under review and might get changed before they are
merged into master. Ask around if you have any questions.

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/2454
[2] https://github.com/RIOT-OS/RIOT/pull/2430

2015-04-22 8:54 GMT+02:00 Jori Winderickx <
jori.winderi...@student.uhasselt.be>:

> Hi,
>
> I would like to utilize an more traditional IP Stack, so without the
> 6LoWPAN. Is this possible? How can I make it work?
>
> Kind regards,
>
> Jori Winderickx
>
> ___
> 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] RIOT Hack'n'ACK Mai

[Martine Lenders]

Hallo,
ich wollte kurz nachfragen, ob wir den Seminarraum wieder nächste Di nutzen
können, da wir nicht im Kalender eingetragen sind.

Viele Grüße,
Martine
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Fwd: [Seminarorga:] RIOT Hack'n'ACK Mai

[Martine Lenders]

FYI: we've got the room. The fact that the event doesn't show in their
calendar seems to be a bug.

-- Weitergeleitete Nachricht --
Von: Uwe Kamper 
Datum: 22. April 2015 um 14:44
Betreff: Re: [Seminarorga:] RIOT Hack'n'ACK Mai
An: Seminarorganisation , mlend...@inf.fu-berlin.de


Hallo Martine,

Am 22/04/15 um 14:38 schrieb Martine Lenders:

> ich wollte kurz nachfragen, ob wir den Seminarraum wieder nächste Di
> nutzen können, da wir nicht im Kalender eingetragen sind.
>

ich hab nochmal nachgeschaut. Ihr habt den Raum auf jeden Fall.

Warum der Termin in der öffentlichen Website nicht angezeigt wird, kann ich
mir nicht erklären. Evtl. ein Bug ...


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

Re: [riot-devel] Example/test ng_udp

[Martine Lenders]

Hi Baptiste,
as discussed in #2720 [1] an example will follow in a short amount of time.

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/2720#issuecomment-96582422

2015-04-28 10:10 GMT+02:00 Baptiste Clenet :

> Hi,
>
> Could you add an example/test for the new ng_udp? It will be easier to use
> it then.
> *@haukepetersen @authmillenon *
>
> Cheers,
>
> --
>
> *Clenet Baptiste*
>
>
>
> ___
> 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] Example/test ng_udp

[Martine Lenders]

Hey Baptiste,
though there is no example yet you can use the new network stack never the
less. Just take one of the test applications for the device you want to use
and compile them with the modules `ng_ipv6` and `ng_udp`. If you use an
IEEE 802.15.4 device (which are currently the only ones in master) you need
to add `ng_sixlowpan_frag`, too. The threads will be started properly by
`auto_init` (which should have been initialized automatically).

If you want to listen on a port just call

ng_netreg_t entry = { thread_getpid(), port };
ng_netreg_register(NG_NETTYPE_UDP, &entry);

while (1) {
msg_receive(&msg);

switch (msg.type) {
NG_NETAPI_MSG_TYPE_RCV:
/* do something with the ng_pktsnip_t* at msg.content.ptr */
break;
}
}

If you want to send a pktsnip payload via UDP use:

ng_netreg_t *sendto = ng_netreg_lookup(NG_NETTYPE_UDP,
NG_NETREG_DEMUX_CTX_ALL);
udp = ng_udp_hdr_build(payload, sport, 2, dport, 2);
ipv6 = ng_ipv6_hdr_build(udp, NULL, 0, (uint8_t *)dst_addr, 16);

ng_pktbuf_hold(ipv6, ng_netreg_num(NG_NETTYPE_UDP, NG_NETREG_DEMUX_CTX_ALL)
- 1);
while (sendto) {
ng_netapi_send(sendto->pid, ipv6);
sendto = sendto->next;
}

Be adviced that it is always a good idea to check if the returned values
are not NULL (in case of a full packet buffer). Also: I did not compile
this, so be warned of syntax errors ;-)

Cheers,
Martine

2015-04-28 13:54 GMT+02:00 Baptiste Clenet :

> Great Hauke! I'm looking forward to using the all new network stack from
> UDP to the transceiver :-)
>
> 2015-04-28 13:16 GMT+02:00 Hauke Petersen :
>
>>  Hi Baptiste,
>>
>> there is one small thing missing, namely a concept for initializing radio
>> drivers and MAC layers in an automated fashion (as in auto_init). But I
>> have already a concept in mind, hopefully I will get it done tomorrow - and
>> with that I will update the example for UDP. So stay tuned :-)
>>
>> Cheers,
>> Hauke
>>
>>
>> On 28.04.2015 10:10, Baptiste Clenet wrote:
>>
>> Hi,
>>
>>  Could you add an example/test for the new ng_udp? It will be easier to
>> use it then.
>> *@haukepetersen @authmillenon *
>>
>>  Cheers,
>>
>>  --
>>
>> *Clenet Baptiste *
>>
>>
>>
>>
>> ___
>> devel mailing 
>> listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
>
> --
> *Clenet Baptiste*
>
>
> ___
> 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] NSTF - Naming the stack

[Martine Lenders]

Hi,
I'm not in favor of keeping the prefix. Three reasons:

1. https://github.com/RIOT-OS/RIOT/pull/2731#discussion_r27350056
2. I'm really looking forward to the day when I don't need to prepend the
ng_ prefix anymore
3. "Angie" sounds to me like a political statement ;-)

In all seriousness: I think Ludwigs proposal is better.

Cheers,
Martine

2015-05-03 2:04 GMT+02:00 Oleg Hahm :

> Hi!
>
> > > What do you think?
> >
> > Due to its known meaning "ng" is as bad a name as "new" or "next",
> > because it will loose this meaning in the foreseeable future.
>
> Star Trek TNG hasn't lost its meaning even after twenty years... But I'm
> really not in favor of any particular name.
>
> > I'm not sure if naming is necessary at all. I think public/shared
> > headers can be used without a problem, and non-default implementations
> > (I assume the current "ng" implementation will be the default)
> > can as well get a characterizing suffix like "_light" or "_tiny" if
> > and when they arrive.
>
> As long as there are only headers to be shared, no problem, but for
> functions
> it's getting more complicated.
>
> Cheers,
> Oleg
> --
> /* When we have more time, we can teach the penguin to say
>  * "By your command" or "Activating turbo boost, Michael".
>  */
> linux-2.2.16/arch/sparc/prom/sun4prom.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] NSTF - Naming the stack

[Martine Lenders]

Hi Oleg,


2015-05-03 12:59 GMT+02:00 Oleg Hahm :
>
> > I'm not in favor of keeping the prefix. Three reasons:
>
> Forget about the ng, that's unrelated to the question that we need a name
> for
> the stack.
>

As stated in the previous e-mail:

> In all seriousness: I think Ludwigs proposal is better.

In other words: the new stack will be the default one, while smaller
implementations can be called `tiny_`, `micro_` or whatever. The proposed
architecture, that other implementations can use `ipv6/hdr.h`,
`ipv6/addr.h` or similar is mostly in place already.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Martine Lenders]

Hi Kaspar,

2015-05-03 13:42 GMT+02:00 Kaspar Schleiser :

> Hi,
>
> On 05/03/15 13:04, Martine Lenders wrote:
> >> In all seriousness: I think Ludwigs proposal is better.
> >
> > In other words: the new stack will be the default one, while smaller
> > implementations can be called `tiny_`, `micro_` or whatever. The proposed
> > architecture, that other implementations can use `ipv6/hdr.h`,
> > `ipv6/addr.h` or similar is mostly in place already.
>
> IMHO we should put implicit headers, like an ipv6 network header .h,
> into net/something. Everything stack related should go somewhere else,
> like "net/tiny/*" or even "net/angie/*".
>
> The idea is that if someone uses another stack, he should be able to
> remove e.g., the "tiny" folder in order to check for unintended
> dependencies.
>

This is already the case, at least with the stuff I implemented: `ng_ipv6`
is dependent on `ng_ipv6_addr` etc. while `ng_ipv6_addr` etc. is not
dependent on `ng_ipv6`.

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

Re: [riot-devel] NSTF - Naming the stack

[Martine Lenders]

Hi,

2015-05-03 14:50 GMT+02:00 Kaspar Schleiser :

> Hey,
>
> On 05/03/15 13:46, Martine Lenders wrote:
> >> The idea is that if someone uses another stack, he should be able to
> >> remove e.g., the "tiny" folder in order to check for unintended
> >> dependencies.
> >>
> >
> > This is already the case, at least with the stuff I implemented:
> `ng_ipv6`
> > is dependent on `ng_ipv6_addr` etc. while `ng_ipv6_addr` etc. is not
> > dependent on `ng_ipv6`.
>
> Perfect. Still, what do we refer to when talking about "this new tack"?
> "the default stack"?
>

Yes.

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

Re: [riot-devel] Network API task force

[Martine Lenders]

Hi Kaspar,
just to state the "opposite" opinion, too: while I see the need for an API
suitable for embedded use only and other stacks than the default one too,
I'm of the opinion, that the POSIX sockets (needed for library and
application ports) should also be as slim as possible. This means: A
wrapper (POSIX sockets) around a wrapper (the new new network API) around
some API (e. g. netapi) seems like overkill to me.

Cheers,
Martine

2015-05-08 10:18 GMT+02:00 Kaspar Schleiser :

> Hi,
>
> at the last Network Stack Task Force meeting, we came to the conclusion
> that a task force for defining API's for network functionality like
> sockets or coap would be useful.
>
> So I'd like to start this and invite everyone to join!
>
> I'll start the discussion with my opinion on the need for a new socket API.
>
> It was discussed if we couldn't just adopt the BSD/POSIX socket API, as
> we would need that API anyways.
>
> In my opinion, it has some drawbacks for embedded usage. Best example:
> (From "man 7 socket"):
> --- snip ---
> SYNOPSIS
>#include 
>
>sockfd = socket(int socket_family, int socket_type, int protocol);
> --- snip ---
>
> This is the function that creates a socket and returns a handle. In
> malloc-capable systems, this is perfectly fine. In RIOT, the question
> arises, what does the returned fd mean?
>
> The socket will definately need some state. This needs to be somewhere
> in memory. Using that API, we'd need to either preallocate a certain
> amount of socket state structures, or use malloc. Both ways suck.
>
> So a new socket library might more look like:
>
> --- snip ---
> socket = socket(socket_t *sock, blah) ...
> --- snip ---
> That way, the caller has to provide all memory needed for managing the
> socket.
>
> We do it like that all over RIOT, so I'd like to see this adopted for
> sockets.
>
> I also believe that it is very easy to implement BSD sockets once these
> RIOT sockets are in place, adding the memory burden. It is not possible
> to do it the other way around...
>
> Thoughts?
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Martine Lenders]

Hi Kaspar,

2015-05-08 11:09 GMT+02:00 Kaspar Schleiser :

> Hi,
>
> On 05/08/15 10:58, Martine Lenders wrote:
> > just to state the "opposite" opinion, too: while I see the need for an
> API
> > suitable for embedded use only and other stacks than the default one too,
> > I'm of the opinion, that the POSIX sockets (needed for library and
> > application ports) should also be as slim as possible. This means: A
> > wrapper (POSIX sockets) around a wrapper (the new new network API) around
> > some API (e. g. netapi) seems like overkill to me.
>
> If you agree that we need an API for embedded use, would you agree that
> this API should be the one that all RIOT internal libraries (e.g., for
> CoAP) should use?
>

Actually, yes. But I'm still trying to get my head around why netapi (or
it's wrapper functions [1], slightly renamed) could not be that API.

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/blob/master/sys/include/net/ng_netapi.h
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Martine Lenders]

Hi,

2015-05-08 11:25 GMT+02:00 Kaspar Schleiser :

> Hi,
>
> On 05/08/15 11:14, Martine Lenders wrote:
> > Actually, yes. But I'm still trying to get my head around why netapi (or
> > it's wrapper functions [1], slightly renamed) could not be that API.
>
> Because it requires the use of messages, which implicitly requires using
> seperate threads. This is not feasable for low-memory systems.
>

That's why I've put the emphasis on the wrapper functions of netapi.

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

Re: [riot-devel] Network API task force

[Martine Lenders]

Hi Kaspar,

2015-05-08 11:32 GMT+02:00 Kaspar Schleiser :

> Hey,
>
> On 05/08/15 11:29, Martine Lenders wrote:
> >> On 05/08/15 11:14, Martine Lenders wrote:
> >>> Actually, yes. But I'm still trying to get my head around why netapi
> (or
> >>> it's wrapper functions [1], slightly renamed) could not be that API.
> >>
> >> Because it requires the use of messages, which implicitly requires using
> >> seperate threads. This is not feasable for low-memory systems.
> >
> > That's why I've put the emphasis on the wrapper functions of netapi.
> Where can I find them? They're not in the header you cited?
>

Of course they are:

/**
 * @brief Shortcut function for sending @ref NG_NETAPI_MSG_TYPE_SND messages
 *
 * @param[in] pid PID of the targeted network module
 * @param[in] pkt pointer into the packet buffer holding the data to send
 *
 * @return 1 if packet was successfully delivered
 * @return -1 on error (invalid PID or no space in queue)
 */
int ng_netapi_send(kernel_pid_t pid, ng_pktsnip_t *pkt);

/**
 * @brief Shortcut function for sending @ref NG_NETAPI_MSG_TYPE_RCV messages
 *
 * @param[in] pid PID of the targeted network module
 * @param[in] pkt pointer into the packet buffer holding the received data
 *
 * @return 1 if packet was successfully delivered
 * @return -1 on error (invalid PID or no space in queue)
 */
int ng_netapi_receive(kernel_pid_t pid, ng_pktsnip_t *pkt);

/**
 * @brief Shortcut function for sending @ref NG_NETAPI_MSG_TYPE_GET
messages and
 * parsing the returned @ref NG_NETAPI_MSG_TYPE_ACK message
 *
 * @param[in] pid PID of the targeted network module
 * @param[in] opt option to get
 * @param[in] context (optional) context to the given option
 * @param[in] data pointer to buffer for reading the option's value
 * @param[in] max_len maximum number of bytes that fit into @p data
 *
 * @return value returned by the @ref NG_NETAPI_MSG_TYPE_ACK message
 */
int ng_netapi_get(kernel_pid_t pid, ng_netconf_opt_t opt, uint16_t context,
  void *data, size_t max_len);

/**
 * @brief Shortcut function for sending @ref NG_NETAPI_MSG_TYPE_SET
messages and
 * parsing the returned @ref NG_NETAPI_MSG_TYPE_ACK message
 *
 * @param[in] pid PID of the targeted network module
 * @param[in] opt option to set
 * @param[in] context (optional) context to the given option
 * @param[in] data data to set the given option to
 * @param[in] data_len size of @p data
 *
 * @return value returned by the @ref NG_NETAPI_MSG_TYPE_ACK message
 */
int ng_netapi_set(kernel_pid_t pid, ng_netconf_opt_t opt, uint16_t context,
  void *data, size_t data_len);

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

Re: [riot-devel] Implementing a new MAC protocol for IEEE 802.15.4

[Martine Lenders]

Hi,

Am 12.05.2015 08:08 schrieb "Oleg Hahm" :
>
> Hi Daniel!
>
> > >Is this not a requirement of the routing?
> > Did you have a look at the IEEE 802.15.4 specification? It's assumed to
have
> > a so called PAN coordinator that forces the network to a star topology.
It's
> > extendable to a tree of stars, but still you need a PAN coordinator in
every
> > region. This node is the mentioned single point of failure and
additionally
> > has increased energy consumption.
> >
> > This is exactly what I don't want.
>
> PAN coordinators are only required for the beacon enabled mode in IEEE
> 802.15.4. 6LoWPAN, for instance, does not require this mode (I'm not even
sure
> if it is supported by the spec) and thus, there is no need for a PAN
> coordinator or star topology.

I'm not 100% sure, since I'm not THAT knowledgeable in terms of IEEE
802.15.4, but isn't that what 6LoWPAN's mesh-under mode [1] is for? All we
need to do to support this mode is to implement support for 6LoWPAN's Mesh
[2] and Broadcast [3] headers.

Cheers,
Martine

[1] https://tools.ietf.org/html/rfc4944#section-11
[2] https://tools.ietf.org/html/rfc4944#section-5.2
[3] https://tools.ietf.org/html/rfc4944#section-11.1
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Martine Lenders]

Hey,

what about `ipc_stack` due to its utilization of the former? But still: I'm
still not convinced of the reason to give it a name. All operating systems
have a default stack but no one is bound to use it and can use their
`ultra` stack etc. (in Linux e.g. as a library). The naming of uIP is
mainly historic, since it started out as a seperate project. As far as I
know TinyOS' stack has no name either.

Cheers,
Martine

2015-05-12 13:02 GMT+02:00 Kaspar Schleiser :

> Hey,
>
> On 05/12/2015 09:54 AM, Oleg Hahm wrote:
>
>> I just stumbled across ng_netconf - we should rename this to avoid
>> confusion
>> with RFC 6241 [1]. If the stack would have a name, we could simply call it
>> _conf...
>>
>
> If "nameless" sticks, we could just replace all "ng_" with "nl_" ... Until
> we port libnl, of course.
>
> Kaspar
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Martine Lenders]

Hi,
given that I was asked today what the "R" means in RIOT (and Thomas W.
giving the most excellent to my "revelutionary" or "restricted": "RIOT") I
really like gnrc. Let's find some alternative meanings for that! :D
"Generic newly retained code"? "Great networking! RIOT certified"? "Google
never really called [us]"?

Cheers,
Martine

2015-05-18 16:17 GMT+02:00 Oleg Hahm :

> Hey Kaspar!
>
> > +1 for "generic", but do we need the abbrevation?
>
> Aren't you usually the one arguing for short variable names and the like?
>
> Cheers,
> Oleg
> --
> WHO HAS ANY ARP JOKES?
>
> ___
> 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] Neighbor Discovery finalized for now

[Martine Lenders]

Dear routing RIOTers,

with PR #3049 I'm happy to announce that I finally finished my work on
vanilla IPv6 neighbor discovery. Please test it extensive. Things still
missing is the Redirect Function [2] which I see as optional for now
(because it is not really needed for LoWPANs) and the 6LoWPAN optimization
[3] (which I will provide as a follow-up PR next around week).

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/3049
[2] https://tools.ietf.org/html/rfc4861#section-8
[3] https://tools.ietf.org/html/rfc6775
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] HACK'n'ACK tonight

[Martine Lenders]

Hi,
Just out of curiosity: who will be there on time at c-base? Because up
until now I've got the feeling I'm the only one, but would actually prefer
to come a little later if nobody else is coming at 5pm.

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

Re: [riot-devel] HACK'n'ACK tonight

[Martine Lenders]

Hi,
then this will be approximately the time me and the hardware will arrive at
c-base, too.

Cheers,
Martine
Am 26.05.2015 16:39 schrieb "Peter Kietzmann" <
peter.kietzm...@haw-hamburg.de>:

>  I addition: We'll also attend a bit later. I assume not before 5:45pm,
> because of room conflicts. Again..
>
> See you!
>
> Peter
>
> Am 26.05.2015 um 16:29 schrieb Martine Lenders:
>
> Hi,
> Just out of curiosity: who will be there on time at c-base? Because up
> until now I've got the feeling I'm the only one, but would actually prefer
> to come a little later if nobody else is coming at 5pm.
>
> Cheers,
> Martine
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel
>
>
> --
> Peter Kietzmann
>
> Hamburg University of Applied Sciences
> Dept. Informatik, Internet Technologies Group
> Berliner Tor 7, 20099 Hamburg, Germany
> Fon: +49-40-42875-8426
> Web: http://www.haw-hamburg.de/inet
>
>
> ___
> 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] Open Processes Task Force

[Martine Lenders]

Hi,
Just to be clear, we are talking about administrative processes on our work
in RIOT here, right? Not some kind of system processes. Because that's what
I was thinking first Manu's mail was about and I had a really hard time
wrapping my head around it.

Cheers,
Martine
Am 28.05.2015 00:09 schrieb "Kaspar Schleiser" :

> Hey,
>
> On 05/28/15 00:02, Emmanuel Baccelli wrote:
> > I propose to launch a task force focusing on open processes at work in
> > the RIOT community.
> +1
>
> We need to be careful not to over-design our processes, but a task force
> identifying possible improvements sounds very useful.
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] pktbuf question

[Martine Lenders]

Hey Kaspar,
You normally would mark the header out, not the payload, since this is the
marker for the packet buffer, that the packet is receiving:

pkt = ng_pktbuf_add(0,src,size,undef);
hdr = ng_pktbuf_add(pkt, pkt->data, hdr_size, hdr_type);

For sending you just add new snips to the packet:

payload = ng_pktbuf_add(0, pl_data, pl_size, undef);
hdr = ng_pktbuf_add(payload, hdr_data, hdr_size, hdr_type);

Does this answer your question?

Cheers,
Martine
Am 16.06.2015 23:01 schrieb "Kaspar Schleiser" :

> Hey,
>
> (this goes probably to Martine)
>
> The docs of ng_pktbuf_add say:
>
> "If @p data is already in the packet buffer (e.g. a payload of an
> already allocated packet) it will not be duplicated."
>
> Does this check for pointer equality, or would it correctly de-duplicate
> the snip if I add e.g., just the end of a packet a second time?
>
> e.g.
> pkt = ng_pktbuf_add(0,0,size,undef);
> memcpy(pkt->data, src, size);
>
> payload = ng_pktbuf_add(pkt, pkt->data + hdr_size, size-hdr_size,
> hdr_type);
>
> Would this allocate the space for pkt->data + hdr_size a second time?
>
> 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

[riot-devel] Black-box testing of ng_netapi modules

[Martine Lenders]

Hi,
since two days ago we have a module to black-box test ng_netapi modules:
ng_nettest. I've PR'd tests for UDP as an example for that [1] (there are
still some issues) and wrote a wiki page on how to write tests [2]. Please
consider testing the other ng_netapi modules with that.

Cheers,
Martine


[1] https://github.com/RIOT-OS/RIOT/pull/3248
[2] https://github.com/RIOT-OS/RIOT/wiki/Writing-tests-for-ng_netapi-modules
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] SourceForge Maintenance

[Martine Lenders]

Hi,
SourceForge is currently partly shut down for maintenance [1] so brace
yourself for failing `tests/coap` builds on Travis.

Regards,
Martine

[1] https://twitter.com/sfnet_ops/status/622236074052464641
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Connectivity between new NG stack and loopback

[Martine Lenders]

Hey Lennart,
at the IETF hackathon we started documenting this in the README of
`ng_networking`, since it seemed to be a better place for this (things tend
to get lost in the Wiki and most peoble trying to network with the GNRC
stack will probably stumble upon this app). Maybe you can just update there?

Cheers,
Martine

2015-07-27 15:35 GMT+02:00 Lennart Dührsen :

> Hi everyone,
>
> I'm sorry for answering so late (I had some other things to take care
> of), and I would like to thank you for your help.
>
> The reason why this wasn't working on my system was just my firewall
> that interfered. After turning it off, everything worked just as you
> described.
>
> To make it easier for other newcomers, who might have to deal with this,
> I created a wiki article that describes how to talk to your RIOT process
> and mentions some of the pitfalls. It's not published yet, for now it's
> just a gist, but feel free to check it out:
>
> https://gist.github.com/backenklee/2dbdaae90af5b5878200
>
> If you feel like something is missing or think something could be
> improved, please let me know.
>
> Cheers,
> Lennart
>
> ___
> 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] Connectivity between new NG stack and loopback

[Martine Lenders]

Forgot the link:
https://github.com/RIOT-OS/RIOT/blob/master/examples/ng_networking/README.md

2015-07-27 16:53 GMT+02:00 Martine Lenders :

> Hey Lennart,
> at the IETF hackathon we started documenting this in the README of
> `ng_networking`, since it seemed to be a better place for this (things tend
> to get lost in the Wiki and most peoble trying to network with the GNRC
> stack will probably stumble upon this app). Maybe you can just update there?
>
> Cheers,
> Martine
>
> 2015-07-27 15:35 GMT+02:00 Lennart Dührsen 
> :
>
>> Hi everyone,
>>
>> I'm sorry for answering so late (I had some other things to take care
>> of), and I would like to thank you for your help.
>>
>> The reason why this wasn't working on my system was just my firewall
>> that interfered. After turning it off, everything worked just as you
>> described.
>>
>> To make it easier for other newcomers, who might have to deal with this,
>> I created a wiki article that describes how to talk to your RIOT process
>> and mentions some of the pitfalls. It's not published yet, for now it's
>> just a gist, but feel free to check it out:
>>
>> https://gist.github.com/backenklee/2dbdaae90af5b5878200
>>
>> If you feel like something is missing or think something could be
>> improved, please let me know.
>>
>> Cheers,
>> Lennart
>>
>> ___
>> 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] Connectivity between new NG stack and loopback

[Martine Lenders]

Hi,
> If you want to, I can update the article and add a Pull Request, or you
can just copy&paste it (would be much faster), if the others agree..?

Please do. I would also have to make a PR, just like you do so it would not
be faster if you just do it as you think is best ;-). The review will
decide if others agree.

Cheers,
Martine

2015-07-27 17:14 GMT+02:00 Lennart Dührsen :

> Hi,
>
> that would be a good example for great communication :D
>
> Personally, I would add
>
> - the link to the Wikipedia page about link-local address
>
> - some short explanations what the netcat options are for (for people
>   like me, who are too lazy to open the man page and search for it)
>
> - the note at the end of my article about writing your own software
>
> - and, most important, the note at the beginning of my article
>   concerning the damn firewall and the modprobe ipv6 stuff on a
>   Raspberry Pi.
>
> If you want to, I can update the article and add a Pull Request, or you
> can just copy&paste it (would be much faster), if the others agree..?
>
> Cheers,
> Lennart
> ___
> 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] Introducing: Light-weight connection API

[Martine Lenders]

Hello *,

Kaspar and I discussed over the last week our new basis for POSIX socket
support: A stack-agnostic connection API (PR'd here [1]). Both of us want
to sit down on Wednesday to hammer down the last details. The API is
primarily designed to wrap around any stack with minimal-sized code, and
not to enable the full functionality that sockets do. Is there any input
that the list wants to share that might be of use for us on Wednesday?

Thank you,
Martine

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

[riot-devel] GNRC is one module now

[Martine Lenders]

Dear relentless IOTlers,

Yesterday we finally got rid of the `ng_` prefix by moving all GNRC-related
modules into the new `gnrc` module (see PR #3645 [1]). The structure is now
as follows:

* `ng_netbase` is now the `gnrc` module (and is not a pseudo-module
anymore, but still pulls in the same dependencies)
* everything that used to be `sys/include/net/ng_x.h` is now
`sys/include/net/gnrc/x.h`
* everything that used to be `sys/net/x/ng_y` is now `sys/net/gnrc/x/y`,
except `sys/net/crosslayer/ng_z` which is now `sys/net/gnrc/z`.
* module that used to be called `ng_x` are now called `gnrc_x`
* Functions and structures not related to GNRC stayed (e.g. UDP/IP-related
headers and addressing) in `sys/include/net` and `sys/net/x/` and got the
`ng_` prefix removed.
* the paths to GNRC sub-modules was moved from `sys/Makefile` to
`sys/net/gnrc/Makefile`

Cheers,
Martine

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

[riot-devel] Where's the iot-lab_M3 gone?

[Martine Lenders]

Hello renaming IoTlers,

First of all, sorry about cross-posting, but I think that could interest
both lists.

if you try to build with BOARD=iot-lab_M3 you will discover, that it is not
possible:

   *** The specified board iot-lab_M3 does not exist..  Stop.

This is because we just renamed it to the same name it has on Contiki and
FreeRTOS (and is more in line with our own board naming scheme): iotlab-m3
[1].

We all probably will need a while to get used to it, but that's only
because we were used to the weird old name and hopefully lead to far less
frustrations in the future ;-)

Cheers,
Martine

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

Re: [riot-devel] RIOT examples

[Martine Lenders]

Hey,

2015-08-19 14:47 GMT+02:00 Kaspar Schleiser :

> Hey,
>
> On 08/14/15 14:54, Oleg Hahm wrote:
> >> > But maybe we can even live with one examples directory holding all
> examples,
> >> > as that makes finding them very easy.
> > I think I would also prefer a flat hierarchy and keep it simple.
>
> Does anyone have an opinion on this?


 I also prefer flat hierarchies.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Pull request procedure

[Martine Lenders]

Hi,

+1 for your guideline (though I really need to put some work into point s 1
and 3 ^^).

On the somewhat-positive-feedback-side for the maintainers and reviewers in
general: If I saw and remember correctly we, brought the number of open PRs
of ~170 in the last few weeks finally down to ~140 again. Now let's get
below 100 again!

Cheers,
Martine

2015-08-20 21:18 GMT+02:00 Cenk Gündogan :

> Hi Oleg,
>
> Out of curiosity (and maybe to state the obvious):
> The rules you proposed would forbid WIP pull requests, right?
>
>
> On 20.08.2015 19:10, Cenk Gündogan wrote:
>
>> Hey Oleg,
>>
>> I like your proposed guideline.
>>
>> What's your opinion on adding some words about logically splitting a PR
>> across several commits. I always like it when a PR contains 1 commit for
>> the new feature / bugfix and 1 commit for new/modified (unit)tests. This
>> way I can review them separately in github.
>>
>> Cheers,
>> Cenk
>>
>> Dear requesting IoTlers,
>>>
>>> in order to improve and hopefully speed up the Pull request/review
>>> process, I
>>> think it would be beneficial to describe in a better defined way how a
>>> Pull
>>> request should be created and maintained. Therefore, I plan to put the
>>> following rules into the wiki:
>>>
>>> * The title and initial description of a Pull request must describe its
>>> basic
>>>idea and what goal is intended to be achieved in a brief and
>>> comprehensible
>>>manner.
>>> * The provided code and its documentation should make it very clear how
>>> this
>>>goal is intended to be solved.
>>> * Keep Pull requests as small as possible. The smaller a PR, the more
>>> likely
>>>it gets reviewed in short time.
>>> * Support your reviewer! Try to react as quick as possible to your
>>> reviewer's
>>>comments - and if only by letting her/him know, that you have
>>> currently no
>>>time to incorporate her/his feedback. Also, let the reviewer know if
>>> you do
>>>not plan to continue to work on a certain PR. Furthermore, if your
>>> reviewer
>>>don't react for some days, remind him!
>>>
>>> What do you think?
>>>
>>
> ___
> 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] Pull request procedure

[Martine Lenders]

Hi Cenk,

2015-08-20 21:18 GMT+02:00 Cenk Gündogan :

> Hi Oleg,
>
> Out of curiosity (and maybe to state the obvious):
> The rules you proposed would forbid WIP pull requests, right?


How did you come to this implication? If one marks a PR as WIP (either by
label because they are able to, or by stating it in the PRs description or
title) they are most likely still working on one of these points or
providing a new feature, which are most likely not able to fulfill the 3rd
anyway (but since they are only adding code, they still comparably easy to
review so this is okay, I would say). How we deal with WIP PRs is the more
important question. Usually I "ignore" them (in my workflow this means I
look over them quickly if something of great importance changed, at a
frequency of about every two weeks or so) until the PR gets out of WIP
(hopefully with a notification of the requester). Only then I start the
proper review, which would for the future also include this rule set.

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

Re: [riot-devel] The border router wi^H^H is ready!

[Martine Lenders]

Hi Ralph,
we use a very simple SLIP implementation over its second UART.

Regards,
Martine

2015-09-17 19:27 GMT+02:00 Ralph Droms (rdroms) :

> Congratulations!
>
> How do you use a samr21-xpro as a border router?  What's the second
> interface?
>
> - Ralph
>
> > On Sep 17, 2015, at 12:31 PM 9/17/15, Oleg Hahm 
> wrote:
> >
> > Ladies and gentlemen!
> >
> > I'm more than proud to announce that just a couple of minutes ago I sent
> the
> > first successful ping from an iotlab-m3 node over a RIOT powered border
> router
> > (running on a samr21-xpro) to my desktop PC and received its response!
> >
> > Let's celebrate this tonight!
> >
> > Cheers,
> > Oleg
> >
> > P.S. Everything you need is included in my pre-release branch:
> > https://github.com/OlegHahm/RIOT/tree/2015.09-RC0
> > --
> > The problem with mutex jokes is that they're race-ist.
> > ___
> > 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] Fwd: tapsetup problem

[Martine Lenders]

Hi,
make sure you have the `netdev2_tap` module included to your project. You
can do that by either adding the line

USEMODULE += netdev2_tap

to your project or - more generally for all boards, not just native

USEMODULE += gnrc_netif_default

If you want the OS to setup the device (recommended) also add the auto
initialization modules:

USEMODULE += auto_init
USEMODULE += auto_init_gnrc_netif

Cheers,
Martine

2015-09-26 21:50 GMT+02:00 Ludwig Knüpfer :

> Hi,
>
> Apparently your project is not configured to use a transceiver.
>
> Cheers,
> Ludwig
>
> Am 20. September 2015 21:22:49 MESZ, schrieb samira afzal <
> afzal.sam...@gmail.com>:
> >Hi all,
> >Ii had sent a question about my problem but i didn't get any answer, if
> >i
> >have to email to another address or sth is wrong please tell me. thanks
> >to
> >all
> >-- Forwarded message --
> >From: samira afzal 
> >Date: Fri, Sep 18, 2015 at 5:09 PM
> >Subject: tapsetup problem
> >To: us...@riot-os.org, devel@riot-os.org
> >
> >
> >Hi all,
> >
> >I hope that i write in a correct place. i am newer on RIOT.  I've
> >started
> >to learn about it. i amm using "
> >https://github.com/RIOT-OS/RIOT/wiki/Creating-your-first-RIOT-project";
> >as
> >tutorial.
> >
> >
> >In the mentioned website i used command
> >../../dist/tools/tapsetup/tapsetup
> >-c
> >
> >tap0 and tap1 created successfully. Then i used make and then,
> >./bin/native/my_project.elf
> >tap0.
> >the result is:
> >
> >usage: ./bin/native/my_project.elf [-i ] [-d] [-e|-E] [-o]
> > help: ./bin/native/my_project.elf -h
> >
> >Options:
> >-h  help
> >-i  specify instance id (set by config module)
> >-sspecify srandom(3) seed (/dev/random is used instead of
> >random(3) if the option is omitted)
> >-d  daemonize
> >-e  redirect stderr to file
> >-E  do not redirect stderr (i.e. leave sterr unchanged despite
> >daemon/socket io)
> >-o  redirect stdout to file (/tmp/riot.stdout.PID) when not
> >attached
> >to socket
> >
> >The order of command line arguments matters.
> >samira@samira-pc:~/RIOT/examples/my_project$
> >
> >
> >
> >could u please guide me, what is the problem and how can i solve it?
> >thanks
> >for your kind consideration
>
> ___
> 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] Notification: Hack'n'ACK @ Tue Sep 29, 2015 5pm - 10pm (RIOT Events)

[Martine Lenders]

Hi,
is anybody planning to be at c-base tomorrow?
Cheers,
Martine
Am 28.09.2015 17:01 schrieb "Google Calendar" <
calendar-notificat...@google.com>:

> more details »
> <https://www.google.com/calendar/event?action=VIEW&eid=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNTA5MjlUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn>
> Hack'n'ACK
> *When*
> Tue Sep 29, 2015 5pm – 10pm Berlin
> *Where*
> c-base Berlin; HAW Hamburg (map
> <https://maps.google.com/maps?q=c-base+Berlin;+HAW+Hamburg&hl=en>)
> *Calendar*
> RIOT Events
> *Who*
> •
> Martine Lenders - creator
>
> Invitation from Google Calendar <https://www.google.com/calendar/>
>
> You are receiving this email at the account peterschme...@gmail.com
> because you are subscribed for notifications on calendar RIOT Events.
>
> To stop receiving these emails, please log in to
> https://www.google.com/calendar/ and change your notification settings
> for this calendar.
>
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
>
> ___
> 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] Hack'n'Ack September '15 edition

[Martine Lenders]

Hello everybody,

You can join today's Hack'n'Ack via the usual PlaceCam link:
http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-

If you never used PlaceCam before, please refer to [1]

Have fun tonight,
Martine

[1]
https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT Release 2015.09

[Martine Lenders]

\o/ finally!

/goes to bed
Am 05.10.2015 22:17 schrieb "Oleg Hahm" :

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

[riot-devel] Update to documentation overview.

[Martine Lenders]

Hi everyone,
just a friendly reminder, that we need more people looking into and working
on the new introductory text [1]. We currently have two texts that have
this function one in the doxygen documenation [2] and one in the Wiki [3].
Both texts started as the same text and evolved from there on in different
directions (the Wiki version got all the spell and terminology fixes, the
doxygen version all the renames due to the usage of search-and-replace on
all of the repository). The text at [1] is a merged version of both texts.
This texts is supposed to go into the doxygen documentation and to be
linked in the Wiki instead of [2] (the later will be removed), since at
least from a technical standpoint the doxygen seems to receive more and
better updates.

Cheers,
Martine

[1] https://padlite.spline.inf.fu-berlin.de/p/mjtL88j5np
[2] http://doc.riot-os.org/
[3] https://github.com/RIOT-OS/RIOT/wiki/Introduction
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Documentation How-To

[Martine Lenders]

Hi,
I came up with some "rules" about where to put what documentation: [1].
They represent an idea of how it could be, not how it currently is. Does
anyone has any input on that.

Cheers,
Martine

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

Re: [riot-devel] Documentation How-To

[Martine Lenders]

Hi Oleg,

2015-10-20 19:14 GMT+02:00 Oleg Hahm :

> Hi Martine!
>
> > I came up with some "rules" about where to put what documentation: [1].
> > They represent an idea of how it could be, not how it currently is. Does
> > anyone has any input on that.
>
> I'm still not convinced that we need any rules for that, but if it helps
> some
> people, why not. However, what is the title of this page is supposed to
> mean?
> It looks a bit confusing to me.
>

Just a bit I took from our American friends ;-)
https://en.wikipedia.org/wiki/101_(number)#In_education but if it confuses
you, rename it ;-)

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

Re: [riot-devel] Network Stack Question

[Martine Lenders]

Hi Haoyang,


2015-10-23 20:08 GMT+02:00 Haoyang Yu :

>
>- txtsnd: I cannot set the interface, if I use tap0, which will echo:
>error: invalid interface given.
>
> You need to use the interface on the node, not the TAP. The TAP is the
endpoint on the host system for the "cable" you draw between host and
native node. Use `ifconfig` to see what interface to use (as documented in
the default example's README [1]).

>
>- I found the tutorial that said using addr, but I do not have the
>addr command when I use the R21 board.
>
> Can you point us to this tutorial? The addr command was dropped for the
last release. Everything can be done with `ifconfig` now (there is already
an address configured though).

>
>- And what is the mean for interface for txtsnd to use, if I
>have /dev/tty.usbmodem* MCU device
>
> I don't know what you mean by that? If you mean it in the same way as you
said you used `tap0` on the native node, see above, if you want to send
actual packets over the serial line, have a look at SLIP [2] (or the
gnrc_border_router example about how to use it).

[1] https://github.com/RIOT-OS/RIOT/tree/2015.09/examples/default#networking
[2] http://doc.riot-os.org/group__net__gnrc__slip.html
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network Stack Question

[Martine Lenders]

Hi Haoyang,

2015-10-24 21:17 GMT+02:00 Haoyang Yu :

>
>1. where can I find the txtsnd source codes?
>
> `txtsnd` is a default shell command for the `gnrc_netif` module pulled in
by the `shell_commands` module. As such you can find it in
`sys/shell/commands/sc_netif.c`.
(When I'm not sure were something is located in RIOT, I use `git grep` ;-))

>
>1. Does packet txtsnd sent is through RF based on GNRC protocol, not
>the serial right?
>
> Depends, normally (for physical boards) it sends over RF. On native there
is no RF, so we use TAP [1] [2] to virtualize an Ethernet connection. Since
native doesn't have a serial line either (since it is just a process in the
host OS, utilizing normal stdin/stdout) we decided to "misuse" the PORT
environment variable for native to point to the TAP instead to the serial
device (so that might be where your confusion stems from). For physical
boards you can however also send packets via serial line, if you wish to
(for a border router e.g.), using SLIP [3]. See my last mail for how to
activate that in RIOT.

[1] https://www.kernel.org/doc/Documentation/networking/tuntap.txt
[2] https://en.wikipedia.org/wiki/TUN/TAP
[3] https://tools.ietf.org/html/rfc1055
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Hack'n'ACK - October 27th

[Martine Lenders]

Hi,
for tomorrow's Hack'n'ACK we are currently only three people who will
definitely be there in Berlin (Cenk, Emmanuel, and me). Because of that we
will again meet at FU Berlin (room 137 in Takustr. 9 most likely). Anyone
else planning to join?

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

Re: [riot-devel] Update to documentation overview.

[Martine Lenders]

Hi,
as discussed in today offline I basically adopted most of your
restructuring (remainder: the pad is at
https://padlite.spline.inf.fu-berlin.de/p/mjtL88j5np). I wrote up to the
structure section and finished the hardware dependent part. Hauke, Peter,
and Thomas, maybe you can have a look if everything is in order. I also
stripped down the overview graphic for the main page a bit (also as
discussed with Hauke and Emmanuel offline):
https://github.com/authmillenon/RIOT/blob/doc/enh/overview-graphic/doc/doxygen/src/riot-structure.svg
.

Cheers,
Martine

2015-10-21 17:35 GMT+02:00 Emmanuel Baccelli :

> Hi Martine,
>
> thanks for the reminder. The pad is great to edit, but not very
> comfortable to visualize the rendering...
>
> I think both restructuring, and additional text would be welcome.
>
> How about a ToC such as the following.
> See below how we could ventilate existing content in this new ToC.
> Most of the additional text needed is in section 3 (about structural
> overview).
>
>
> 1. RIOT in a nutshell
> 2. The quickest start
> 3. Structural overview of RIOT
> 4. First steps using RIOT
> 5. Hints to customize RIOT and/or develop RIOT further
>
>
> RIOT in a nutshell
> 
>
> RIOT is an open-source, community-driven operating system for low-end
> devices in the Internet of Things (IoT).
> RIOT is based on a micro-kernel and requires only kBytes of memory (RAM
> and Flash) while providing high energy efficiency, real-time capabilities,
> modular and configurable communication stacks.
> RIOT provides a consistent API on a wide range of IoT hardware (32-bit,
> 16-bit, and 8-bit), enables ANSI C and C++ application programming, with
> multithreading, IPC, sytem timers, and mutexes.
> RIOT also provides utilities like a shell, cryptographic libraries, data
> structures (bloom filters, hash tables, priority queues etc.).
> RIOT supports a wide range of microcontrollers, radio drivers, sensors, and
> configurations for entire platforms, e.g. ATSAMR21, Zolertia Z1, STM32
> Discovery Boards etc.
>
> For developer questions: devel@riot-os.org
> For live support & discussions: irc.freenode.org #riot-os
> Code available at: https://github.com/RIOT-OS/RIOT
> For news: https://twitter.com/RIOT_OS
>
>
> The quickest start
> 
>
> You can run RIOT on most IoT devices, on open-access testbed hardware
> (e.g. IoT-lab), and also directly on your Linux/FreeBSD/OSX machine.
> Try it right now in your terminal window:
>
> git clone https://github.com/RIOT-OS/RIOT.git (assumption: git is
> pre-installed)
> cd RIOT/examples/default
> (git checkout LATEST-RELEASE-BRANCH)
> make all
> make term
>
> ... and you are in the RIOT shell!
> Type 'help' to discover available commands.
>
> To use RIOT directly on your embedded platform, and for more details
> hands-on with RIOT, see below section "First steps using RIOT".
>
> Before that, skimming through the next section is recommended (but not
> mandatory).
>
>
> Structural overview of RIOT
>
> 
>
> Display Martine's proposed graphic (see
> https://github.com/RIOT-OS/RIOT/issues/4072).
> Input some yet-to-be-written text that present each element briefly and
> how they interact.
>
>
> First steps using RIOT
> 
>
> Downloading RIOT code
> Compiling RIOT (+ toolchain + build system)
> Trying examples available in RIOT/example
>
>
> Hints on how to customize or develop RIOT further
>
> 
>
> We recommend you first read the above "structural overview" section.
>
> Create an application + the main function
> Creating threads + choosing the right stack size
> Using IPC
> Including modules (+ auto initialization)
> Networking
>
> explicit link to developing guide?
>
>
>
>
> On Mon, Oct 19, 2015 at 1:09 PM, Martine Lenders <
> mlend...@inf.fu-berlin.de> wrote:
>
>> Hi everyone,
>> just a friendly reminder, that we need more people looking into and
>> working on the new introductory text [1]. We currently have two texts that
>> have this function one in the doxygen documenation [2] and one in the Wiki
>> [3]. Both texts started as the same text and evolved from there on in
>> different directions (the Wiki version got all the spell and terminology
>> fixes, the doxygen version all the renames due to the usage of
>> search-and-replace on all of the repository). The text at [1] is a merged
>> version of both texts. This texts is supposed to go into the doxygen
>> documentation and to be linked in the Wiki instead of [2] (the later will
>> be removed), since at least from a technical standpoint the doxygen seems
>> to receive more

[riot-devel] Hack'n'ACK October '15

[Martine Lenders]

Hello fellow RIOTers,

Cenk and I are holding the castle for tonight's Hack'n'ACK at FU Berlin.
You can join via your favorite PlaceCam link:
http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-

If you never used PlaceCam before, please refer to [1]

Lots of fun and merges tonight,
Martine

[1]
https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] CoAP

[Martine Lenders]

Hi,
as libcoap uses POSIX sockets it should work without any porting effort to
gnrc. But since the socket API does not support options at the moment,
there might be some unexpected problems.

Cheers,
Martine

2015-10-29 15:32 GMT+01:00 Baptiste Clenet :

> Hi Lennart,
>
> >Also, you'd probably have to port it to RIOT first
> Just to let you know, libcoap has already been ported to RIOT (as a
> pkg as microcoap) [1]
> Yes it does network registering automatically but I don't if this port
> does it with the new network stack, need testing.
>
> [1] https://github.com/RIOT-OS/RIOT/tree/master/pkg/libcoap
>
> 2015-10-29 15:19 GMT+01:00 Lennart Dührsen  >:
> > Hi Ilias,
> >
> >> To use CoAP in my R21 boards should I rite the code of socket
> >> programming (open a udp port ,etc) or just use the coap library and it
> >> takes care about the socket?
> >
> > all the microcoap library does is create and parse payloads (CoAP
> > packets), and it let's you register callback functions for each URI.
> >
> > You have to handle all the networking stuff, i.e. sending and receiving
> > UDP packets, yourself.
> >
> > I'm currently working on the mostly absent documentation of microcoap,
> > you can find it in this fork:
> >
> > https://github.com/i2ot/microcoap
> >
> > It's not finished yet, but it might help you. For the networking stuff
> > on RIOT OS, check out
> >
> > https://github.com/RIOT-OS/RIOT/tree/master/examples/gnrc_networking
> >
> > and
> >
> > https://github.com/RIOT-OS/RIOT/tree/master/examples/posix_sockets
> >
> > if you haven't already done so.
> >
> > The example code Baptiste pointed you to is indeed out of date, but the
> > CoAP parts in it are still correct and should work, so you'd just have
> > to change the socket calls etc.
> >
> > Regarding libcoap: It's a *lot* more code than microcoap, and yes, it
> > does all the socket stuff for you. But its documentation, too, is pretty
> > much nonexistent. Also, you'd probably have to port it to RIOT first, so
> > I suggest you use microcoap for devices that will run RIOT OS.
> >
> > If you run into problems with microcoap, feel free to send me an e-mail.
> >
> > Best,
> > Lennart
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> --
> Baptiste
> ___
> 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] Canceled Event: Hack'n'ACK @ Tue Dec 29, 2015 5pm - 10pm (RIOT Events)

[Martine Lenders]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20151229T17
DTEND;TZID=Europe/Berlin:20151229T22
DTSTAMP:20151115T171645Z
UID:lbk4mfucqdomcf7c8o9cg4c...@google.com
RECURRENCE-ID;TZID=Europe/Berlin:20151229T17
CREATED:20150319T120715Z
DESCRIPTION:
LAST-MODIFIED:20151115T171645Z
LOCATION:c-base Berlin\; HAW Hamburg
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:Hack'n'ACK
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


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

Re: [riot-devel] module documentation

[Martine Lenders]

Hello Ralph,
Sorry for the delay. The module documentation for RIOT can be found here
[1]. The documentation for the particular modules you requested can be
found there too [2] [3]. As better documentation is one of our main goals
for the next release(s), we welcome feedback on those.

Best regards,
Martine

[1] http://doc.riot-os.org/
[2] http://doc.riot-os.org/group__net__gnrc__ipv6.html
[3] http://doc.riot-os.org/group__net__gnrc__sixlowpan.html


2015-11-12 16:04 GMT+01:00 Ralph Droms (rdroms) :

> Where can I find documentation about available modules?
>
> In particular, I want to learn about the use cases and properties of the
> gnrc_ipv6* and gnrc_sixlowpan* modules.
>
> - Ralph
>
>
>
> ___
> 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] module documentation

[Martine Lenders]

Hi,

Am 17.11.2015 11:16 schrieb "Emmanuel Baccelli" :

> I agree that some text would be very helpful. Actually, the plan was to
> indeed provide some such text very soon, right Martine?
>
yes, we are currently working on making the documentation more precise and
helpful for the whole system. Not just IPv6 and 6LoWPAN. Actually, that was
what I try to imply with "better documentation is one of our main goals for
the next release(s)".

> On Tue, Nov 17, 2015 at 11:03 AM, Kaspar Schleiser 
> wrote:
>
>> Hey Martine,
>>
>> […]
>> When I saw Ralph's question, I was looking forward to you using the
>> opportunity to put some light in how gnrc_ipv6, gnrc_ipv6_router,
>> ipv6_router_default, sixlowpan, sixlowpan_nd, sixlowpan_router_nd,
>> sixlowpan_border_router_sixlowpan_nd_host, ..., are related.
>>
>
Not to go into much detail (that's what a landing page in our future
documentation will be for; but thanks for pointing out, that pseudo-modules
will need documentation too :-)), but:
* gnrc_ipv6 is the main module implementing IPv6 for GNRC. Building just
gnrc_ipv6 gives you the bare minimum you need for IPv6 communication: 1-hop
sending and receiving
  * some sub-modules, like gnrc_ipv6_netif (IPv6-relevant interface data)
and gnrc_ipv6_nc (neighbor cache) are independently usable (good for
testing) from gnrc_ipv6, but essential to its functionality
  * gnrc_ipv6_router is a pseudo-module providing build-instructions to
include routing capabilities for IPv6 (forwarding of packets + FIB)
* gnrc_sixlowpan is the bare minimum implementation of 6LoWPAN for GNRC
  * gnrc_sixlowpan_frag and gnrc_sixlowpan_iphc implenent 6LoWPAN
fragmentation and IP header compression respectively
  * gnrc_sixlowpan_nd provides base functionality for 6Lo-ND (but no
behavior).
* gnrc_sixlowpan_nd_host provides host behavior of 6Lo-ND
* gnrc_sixlowpan_nd_router provides router behavior of 6Lo-ND
* gnrc_sixlowpan_nd_border_router provides border router behavior of
6Lo-ND
* either of the nd or router modules can be included or excluded from the
build to optimize in a size-feature axis. The stack should still be
operational, though the features of the missing modules would also be
missing of course.
* gnrc_.*_default are convenience modules that provide the required
neighbor discoveries of the given mode and other modules needed for
(size-wise) ideal full operation.

Hope this was more helpful,
Martine
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] module documentation

[Martine Lenders]

Hi,

> There is also *grnc_sixlowpan_ctx* for stateful compression (using the 6co
flag in RAs).

If you want to be precise, `gnrc_sixlowpan_ctx` is just the storage type
for the context -> IPv6 prefix mapping. The stateful comression is provided
by `gnrc_sixlowpan_iphc`.

Cheers,
Martine

2015-11-17 16:05 GMT+01:00 Oleg Hahm :

> Hi!
>
> One tiny addition:
>
> Am Tue, Nov 17, 2015 at 01:56:09PM +0100 schrieb Martine Lenders:
> > * gnrc_sixlowpan is the bare minimum implementation of 6LoWPAN for GNRC
> >   * gnrc_sixlowpan_frag and gnrc_sixlowpan_iphc implenent 6LoWPAN
> > fragmentation and IP header compression respectively
>
> There is also *grnc_sixlowpan_ctx* for stateful compression (using the 6co
> flag in RAs).
>
> Cheers,
> Oleg
> --
> printk (KERN_ALERT "You are screwed! " ...);
> linux-2.6.6/arch/i386/kernel/efi.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] module documentation

[Martine Lenders]

Hello Haoyang,
gnrc_netif_default is a pseudo-module, defined in Makefile.pseudomodules.
Pseudo-modules are modules, that don't have code, but are used by the
build-system to collect other modules as dependencies or to express a
certain build configuration. gnrc can be found in `sys/net/gnrc`. If the
directory the module resides in is called the same as the module, the
MODULE macro needs not be set in the module's Makefile.
Can you rephrase your second question. I have difficulties to understand
what you are going at.

Cheers,
Martine

2015-11-17 21:42 GMT+01:00 Haoyang Yu :

> Hi all,
>
> I followed that information provided by community, but did not find the
> MODULE gnrc, and also just find gnrc_netif MODULE in sys, but not
> gnrc_netif_default
>
>  # gnrc is a meta module including all required, basic gnrc networking
> modules
>   USEMODULE += gnrc
>   # use the default network interface for the board
>   USEMODULE += gnrc_netif_default
>
> # NOTE: 6LoWPAN will be included if IEEE802.15.4 devices are present
> If I just want to get IEEE802.15.4 data, from my perspective I directly
> use MODULE of gnrc_netif, right? And add packet header I defined by myself.
>
> Thanks for your answers.
>
> Cheers,
> Haoyang
>
> > On Nov 17, 2015, at 10:05, Oleg Hahm  wrote:
> >
> > Hi!
> >
> > One tiny addition:
> >
> > Am Tue, Nov 17, 2015 at 01:56:09PM +0100 schrieb Martine Lenders:
> >> * gnrc_sixlowpan is the bare minimum implementation of 6LoWPAN for GNRC
> >>  * gnrc_sixlowpan_frag and gnrc_sixlowpan_iphc implenent 6LoWPAN
> >> fragmentation and IP header compression respectively
> >
> > There is also *grnc_sixlowpan_ctx* for stateful compression (using the
> 6co
> > flag in RAs).
> >
> > Cheers,
> > Oleg
> > --
> > printk (KERN_ALERT "You are screwed! " ...);
> >linux-2.6.6/arch/i386/kernel/efi.c
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] module documentation

[Martine Lenders]

Hi Haoyang,
pseaudo-modules are used to describe certain module configurations (and
macro settings) in a way that is easy and convenient to use for a user. For
example: Without reading a lot about how networking is working under the
hoodit might not be immediately clear that for normal IPv6 communication
you need NDP and thus ICMPv6. The module `gnrc_ipv6_default` provides a
user with these modules without the requirement to know everything about
our network stack, while an experienced user might want to choose to
exclude NDP to optimize for size and configure the address resolution
manually.

If gnrc_netif_default pulls in 6LoWPAN without the presence of IPv6 this is
definitely an error of the dependencies. I will look into it tomorrow.

Good night (from Berlin),
Martine
Am 18.11.2015 22:26 schrieb "Haoyang Yu" :

> Hello Martine,
>
> Thanks for you answer, right now I fully understand how it works. But why
> do we need Pseudo-modules? Can we use other modules directly without
> indirect way.
>
> My last question is there is a note that:
> # NOTE: 6LoWPAN will be included if IEEE802.15.4 devices are present
> I use module only for gnrc_netif_default, it seems include the 6LoWPAN
> module too?
>
> Thanks!
> Haoyang
>
> On Nov 18, 2015, at 01:18, Martine Lenders  wrote:
>
> Hello Haoyang,
> gnrc_netif_default is a pseudo-module, defined in Makefile.pseudomodules.
> Pseudo-modules are modules, that don't have code, but are used by the
> build-system to collect other modules as dependencies or to express a
> certain build configuration. gnrc can be found in `sys/net/gnrc`. If the
> directory the module resides in is called the same as the module, the
> MODULE macro needs not be set in the module's Makefile.
> Can you rephrase your second question. I have difficulties to understand
> what you are going at.
>
> Cheers,
> Martine
>
> 2015-11-17 21:42 GMT+01:00 Haoyang Yu :
>
>> Hi all,
>>
>> I followed that information provided by community, but did not find the
>> MODULE gnrc, and also just find gnrc_netif MODULE in sys, but not
>> gnrc_netif_default
>>
>>  # gnrc is a meta module including all required, basic gnrc networking
>> modules
>>   USEMODULE += gnrc
>>   # use the default network interface for the board
>>   USEMODULE += gnrc_netif_default
>>
>> # NOTE: 6LoWPAN will be included if IEEE802.15.4 devices are present
>> If I just want to get IEEE802.15.4 data, from my perspective I directly
>> use MODULE of gnrc_netif, right? And add packet header I defined by myself.
>>
>> Thanks for your answers.
>>
>> Cheers,
>> Haoyang
>>
>> > On Nov 17, 2015, at 10:05, Oleg Hahm  wrote:
>> >
>> > Hi!
>> >
>> > One tiny addition:
>> >
>> > Am Tue, Nov 17, 2015 at 01:56:09PM +0100 schrieb Martine Lenders:
>> >> * gnrc_sixlowpan is the bare minimum implementation of 6LoWPAN for GNRC
>> >>  * gnrc_sixlowpan_frag and gnrc_sixlowpan_iphc implenent 6LoWPAN
>> >> fragmentation and IP header compression respectively
>> >
>> > There is also *grnc_sixlowpan_ctx* for stateful compression (using the
>> 6co
>> > flag in RAs).
>> >
>> > Cheers,
>> > Oleg
>> > --
>> > printk (KERN_ALERT "You are screwed! " ...);
>> >linux-2.6.6/arch/i386/kernel/efi.c
>> > ___
>> > devel mailing list
>> > devel@riot-os.org
>> > https://lists.riot-os.org/mailman/listinfo/devel
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Task Forces

[Martine Lenders]

Yes to both.

2015-11-19 17:54 GMT+01:00 Hauke Petersen :

>
>
> On 19.11.2015 16:50, Emmanuel Baccelli wrote:
>
> OK, I could go ahead and modify the wiki with some tentative text for
> that, which we could refine later on.
> In practice:
>
> - would Kaspar agree he was the shepherd of the timers task force?
>
> - would Martine & Hauke agree they were the shepherds of the nasty task
> force?
>
> yes
>
>
> - would Martine & Hauke agree they are the shepherds of the documentation
> task force?
>
> and yes
>
> Cheers,
> Hauke
>
>
>
> - who would take on the shepherding for the OTA task force? If no-one
> speaks up, we could classify this TF as dormant the time being.
>
>
>
> On Thu, Nov 19, 2015 at 4:04 PM, Oleg Hahm  wrote:
>
>> Hi!
>>
>> Sounds like a sensible proposal to me.
>>
>> Cheers,
>> Oleg
>>
>> Am Thu, Nov 19, 2015 at 03:51:36PM +0100 schrieb Emmanuel Baccelli:
>> > +1 here too.
>> > I think it is also important to describe to malloc and free :)
>> > I mean how to:
>> >
>> > 1 - create a new task force (hopefully we have a lot more to come!)
>> > 2 - join/ping/revive an existing task force (e.g. OTA is somewhat
>> dormant)
>> > 3 - dissolve an existing task force
>> >
>> > For creating: how about, simply stating something like:
>> > "If you wish to launch a new task force, go ahead, create your wikipage,
>> > and report your progress or summarize the latest stand of your
>> discussions
>> > on devel@riot-os.org"
>> > There's the slight possibility that duplicate work may happen down the
>> > line, if a lot of task forces are active at the same time.
>> > But this is not dangerous right now. If we want to cover this case,
>> maybe
>> > we can add: "RIOT maintainers will contact you if duplicate or very
>> > closely-related work has been detected elsewhere, and if joining forces
>> > might make sense."
>> >
>> > For ping/join/revive how about naming one or two shepherds per task
>> force,
>> > that could be pinged?
>> >
>> > For dissolving: how about "either (i) the shepherd(s) declares the TF is
>> > done, or gives up, or (ii) the shepherds are unreachable, the TF has
>> been
>> > dormant for a long time and RIOT maintainers declare the TF dissolved"
>> >
>> >
>> >
>> >
>> > On Thu, Nov 19, 2015 at 3:34 PM, Kaspar Schleiser 
>> > wrote:
>> >
>> > > Hey,
>> > > On 11/19/15 14:48, Oleg Hahm wrote:
>> > > > As an effort to "formalize" this idea of task forces a little bit
>> more,
>> > > I just
>> > > > created a small page in the Wiki:
>> > > >
>> > > > What do you think?
>> > >
>> > > +1
>> > >
>> > > I've updated the xtimer page.
>> > >
>> > > 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
>>
>>
>> --
>> /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any
>>  * way.
>>  */
>> linux-2.4.3/net/core/netfilter.c
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://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] Ubuntu to Riot Communication

[Martine Lenders]

Hi,

2015-11-24 17:49 GMT+01:00 Oleg Hahm :

> […]
> > Also I have some issue with pyterm the node. After successfully "make
> flash"
> >
> > I can not access the node via pyterm:
> > sudo pyterm -p "/dev/ttyACM0"
> 
> > Any idea? The debug light flash as the same frequency as the warning
> > information.
>
> That seems strange to me. Is there anything else that tries to access the
> ACM
> device? Maybe some Ubuntu magic? Maybe some of the other Ubuntu (derivate)
> users here can help (Hauke, Martine...)
>

Sometimes the udev rules need to be adapted. Maybe this is it?

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

[riot-devel] Arduino API merged

[Martine Lenders]

Hi,
the Arduino API wrapper [1] was finally merged. Do we want to advertise
that on devel and users?

Cheers,
Martine

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

Re: [riot-devel] Arduino API merged

[Martine Lenders]

Lol I need coffee.

Cheers,
Martine

2015-11-27 14:10 GMT+01:00 Hauke Petersen :

> You just did :-)
>
> Cheers,
> Hauke
>
>
> On 27.11.2015 14:03, Martine Lenders wrote:
>
> Hi,
> the Arduino API wrapper [1] was finally merged. Do we want to advertise
> that on devel and users?
>
> Cheers,
> Martine
>
> [1] https://github.com/RIOT-OS/RIOT/pull/3900
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://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 Wireshark Sniffer - unidentified frame format

[Martine Lenders]

Hi Mateusz,
as Kaspar already pointed out: the cc110x device is not a 802.15.4 device,
but has both different physical and link-layer from 802.15.4. However, our
sniffer script assumes the connected device is 802.15.4 device, so the PCAP
data you are receiving in wireshark are marked as 802.15.4 frames, but they
are not. As such the output is broken.

Hope this was helpful,
Martine

2016-01-04 1:49 GMT+01:00 Mateusz Kubaszek :

> Forgotten attachments...
>
> 2016-01-04 1:46 GMT+01:00 Mateusz Kubaszek :
>
>> Hi everyone!
>>
>> A few days ago I ran a sniffer application using CC1101 transceiver.
>> Sniffing device is connected via UART<->USB adapter to PC. A python sniffer
>> application redirects the frames to Wireshark (v. 2.0.0).
>> Sniffer was gathering frames from one node programmed with
>> gnrc-networking example application. This node was sending a frame in every
>> 10 seconds. The problem is that Wireshark did not recognize any 803.15.4
>> frames. Digging deeper into a 803.15.4 frame, controll part (first octet)
>> look like:
>>
>> bitsdescription
>> 0-2 frame type (000 Beacon, 001 Data, 010 Ack, 011 MAC command,
>> 100-111 Reserved)
>> 3security
>> 4frame pending
>> 5AR
>> 6PAN ID Compression
>> 7-9Reserved
>> 10-11Dest. Addressing Mode (00 PAN and addr. not present, 01
>> Reserved, 10 Short address, 11 Ext. Address)
>> 12-13Frame Version (00 IEEE802.15.4-2003 compatible, 01 IEEE802.15.4
>> compatible)
>> 14-15Source Addressing Mode (00 PAN and addr. not present, 01
>> Reserved, 10 Short address, 11 Ext. Address)
>>
>> The received data has wrong source address mode (picture in attachment).
>> Why is there no compatibility with IEEE802.15.4 standard?
>> Is there anyone with knowledge concerning sniffing radio packets in RIOT
>> powered mesh using Wireshark? Is there a possibility to recognize 802.15.4
>> packet types using standard Wireshark dissector?
>>
>> Best regards,
>> Kubaszek Mateusz
>>
>
>
> ___
> 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] Hack'N'ACK, January 2016

[Martine Lenders]

Hi,
just a kind reminder that next week it is Hack'n'ACK time again and (on the
time I write this Mail) we have 213 (!) open Pull Requests. I already
discussed locally here in Berlin with some colleagues, how we can maybe
optimize the Hack'n'ACK to get more Pull Requests merged or closed this
time. So here is my idea:


   - Every participant takes 5-10 of the PRs they authored and gets them in
   a working order with the code base as they see fit (ideally this happens
   *before* the Hack'n'ACK)
   - At the Hack'n'ACK they go to the maintainer of the PR (if one is
   assigned, otherwise a person they see fit) and discuss the PR in person (or
   via a chat platform of your choice if the person is not in the same room as
   you ;-)) until it is merged (for most PRs this should take maybe 15 min at
   maximum).
   - if the maintainer is occupied or not present at the Hack'n'ACK go to
  the next
  - if no maintainers are available be available for other authors to
  review their PRs
   - If you have nothing to do, see if you can review the PR of an absent
   person
   - If possible: don't open new PRs during the Hack'n'ACK, unless for the
   purpose of subdividing an existing PR.
   - As always: try not to be too nitpicky, when reviewing the PRs ;-)

What do you think about these guidelines?

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

Re: [riot-devel] Hack'N'ACK, January 2016

[Martine Lenders]

Hi Cenk,
> I also want to add and stress that we should make proper use of
the "Hack'n'ACK Candidate" label in GitHub to find those "5-10"
PRs during the Hack'n'ACK.

I kind of got the feeling that this label only is applied to PRs that are
easy to review. I'm not sure how the usage of this label would make the
situation better if everyone nows their PRs.

Just for clarification: those 5-10 PRs should be *per person*. I'm not
expecting all of them to be closed (I hope we get to 5 per author), the
rest is buffer in case we do get every one of the first 5 closed.

Cheers,
Martine

2016-01-18 15:41 GMT+01:00 Cenk Gündogan :

> Hello Martine,
>
> I also want to add and stress that we should make proper use of
> the "Hack'n'ACK Candidate" label in GitHub to find those "5-10"
> PRs during the Hack'n'ACK.
>
> In general, I also think that there is room for optimization regarding
> the way we deal with Hack'n'ACKs currently and I like your proposal so far.
>
> Best,
> Cenk
>
>
> On 18.01.2016 15:12, Martine Lenders wrote:
>
> Hi,
> just a kind reminder that next week it is Hack'n'ACK time again and (on
> the time I write this Mail) we have 213 (!) open Pull Requests. I already
> discussed locally here in Berlin with some colleagues, how we can maybe
> optimize the Hack'n'ACK to get more Pull Requests merged or closed this
> time. So here is my idea:
>
>
>- Every participant takes 5-10 of the PRs they authored and gets them
>in a working order with the code base as they see fit (ideally this happens
>*before* the Hack'n'ACK)
>- At the Hack'n'ACK they go to the maintainer of the PR (if one is
>assigned, otherwise a person they see fit) and discuss the PR in person (or
>via a chat platform of your choice if the person is not in the same room as
>you ;-)) until it is merged (for most PRs this should take maybe 15 min at
>maximum).
>- if the maintainer is occupied or not present at the Hack'n'ACK go to
>   the next
>   - if no maintainers are available be available for other authors to
>   review their PRs
>- If you have nothing to do, see if you can review the PR of an absent
>person
>- If possible: don't open new PRs during the Hack'n'ACK, unless for
>the purpose of subdividing an existing PR.
>- As always: try not to be too nitpicky, when reviewing the PRs ;-)
>
> What do you think about these guidelines?
>
> Cheers,
> Martine
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://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] Contiki as a RIOT thread

[Martine Lenders]

Hi,
Just on the subject on uIP: I'm currently working on an emb6 port (in
parallel to the lwIP port), which is a proto-thread-less fork of uIP. But
as discussed in [1] and by the advantages you have given additionally, it
would definitely make sense to run Contiki in RIOT.

Cheers,
Martine
Am 19.01.2016 11:59 schrieb "Joakim Nohlgård" :

> Many legacy applications are built on Contiki, and many papers on IoT
> are written around tests done on Contiki. Contiki also has a quite
> large community who work with applications on the platform.
>
> Because of this it would be useful to have a way of running Contiki
> applications and projects under RIOT with minimal porting effort.
>
> Contiki is effectively running on the hardware as a single thread with
> some preprocessor magic to make the protothread functions behave as if
> they are cooperatively multitasked threads, which makes it quite
> doable to run Contiki as a subprocess/thread inside a RIOT system.
>
> It would also be possible to use Contiki's uIP as an alternative
> network stack to gnrc, just like the lwIP port in
> https://github.com/RIOT-OS/RIOT/pull/3551.
>
> Some important points to know about Contiki from a RIOT perspective:
> - Tick-based (platform specific, but usually 64 Hz)
> - Cooperative scheduling of protothreads, which are not "full"
> threads, but more light weight, no individual stacks etc.
> - There is a native port which runs on Linux, just like RIOT native.
> - Contiki's network stack is somewhat modularised to allow for
> swapping radio devices, mac layer etc.
> - No real time guarantees, as far as I know.
>
> A starting point might be to use the native platform and to apply an
> adaptation layer to allow netdev2 devices to be used as output by
> Contiki's uIP stack. Another way would be to write an adaptation layer
> between Contiki uIP and RIOT conn, to use gnrc instead of uIP.
>
> Benefits from this would be that we could for example use 6TSCH in uIP
> on RIOT and/or the lwm2m and IPSO smart object implementation from
> Contiki. Since RIOT is, in my opinion, way superior with regards to
> hardware support and its hardware abstraction layers, and with many
> drivers for common sensor devices already implemented it might attract
> some Contiki users to try RIOT for their IoT projects.
>
> I would like to hear any ideas and opinions on this list on how to
> effectively implement this.
>
> Best regards,
> Joakim
> ___
> 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] Hack'N'ACK, January 2016

[Martine Lenders]

Hi,
Kind reminder to all to use the weekend (or Monday and Tuesday) to prepare
the PRs for the Hack'n'ACK.

Cheers,
Martine

2016-01-18 16:01 GMT+01:00 Martine Lenders :

> Hi Cenk,
> > I also want to add and stress that we should make proper use of
> the "Hack'n'ACK Candidate" label in GitHub to find those "5-10"
> PRs during the Hack'n'ACK.
>
> I kind of got the feeling that this label only is applied to PRs that are
> easy to review. I'm not sure how the usage of this label would make the
> situation better if everyone nows their PRs.
>
> Just for clarification: those 5-10 PRs should be *per person*. I'm not
> expecting all of them to be closed (I hope we get to 5 per author), the
> rest is buffer in case we do get every one of the first 5 closed.
>
> Cheers,
> Martine
>
> 2016-01-18 15:41 GMT+01:00 Cenk Gündogan :
>
>> Hello Martine,
>>
>> I also want to add and stress that we should make proper use of
>> the "Hack'n'ACK Candidate" label in GitHub to find those "5-10"
>> PRs during the Hack'n'ACK.
>>
>> In general, I also think that there is room for optimization regarding
>> the way we deal with Hack'n'ACKs currently and I like your proposal so
>> far.
>>
>> Best,
>> Cenk
>>
>>
>> On 18.01.2016 15:12, Martine Lenders wrote:
>>
>> Hi,
>> just a kind reminder that next week it is Hack'n'ACK time again and (on
>> the time I write this Mail) we have 213 (!) open Pull Requests. I already
>> discussed locally here in Berlin with some colleagues, how we can maybe
>> optimize the Hack'n'ACK to get more Pull Requests merged or closed this
>> time. So here is my idea:
>>
>>
>>- Every participant takes 5-10 of the PRs they authored and gets them
>>in a working order with the code base as they see fit (ideally this 
>> happens
>>*before* the Hack'n'ACK)
>>- At the Hack'n'ACK they go to the maintainer of the PR (if one is
>>assigned, otherwise a person they see fit) and discuss the PR in person 
>> (or
>>via a chat platform of your choice if the person is not in the same room 
>> as
>>you ;-)) until it is merged (for most PRs this should take maybe 15 min at
>>maximum).
>>- if the maintainer is occupied or not present at the Hack'n'ACK go
>>   to the next
>>   - if no maintainers are available be available for other authors
>>   to review their PRs
>>- If you have nothing to do, see if you can review the PR of an
>>absent person
>>- If possible: don't open new PRs during the Hack'n'ACK, unless for
>>the purpose of subdividing an existing PR.
>>- As always: try not to be too nitpicky, when reviewing the PRs ;-)
>>
>> What do you think about these guidelines?
>>
>> Cheers,
>> Martine
>>
>>
>> ___
>> devel mailing 
>> listdevel@riot-os.orghttps://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] Notification: Hack'n'ACK @ Tue Jan 26, 2016 5pm - 10pm (RIOT Events)

[Martine Lenders]

Thanks Cenk,
I just wanted to write that mail and saw you already did.

Cheers,
Martine
Am 25.01.2016 17:07 schrieb "Cenk Gündogan" :

> Correction, in Berlin the Hack'n'Ack will not be at the c-base, but at the
> FU Berlin (room 137 in Takustr. 9)
>
> Best,
> Cenk
>
> On 25.01.2016 17:00, Google Calendar wrote:
>
> more details »
> <https://www.google.com/calendar/event?action=VIEW&eid=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNjAxMjZUMTYwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn>
> Hack'n'ACK
>
> *When*
> Tue Jan 26, 2016 5pm – 10pm Berlin
>
> *Where*
> c-base Berlin; HAW Hamburg (map
> <https://maps.google.com/maps?q=c-base+Berlin;+HAW+Hamburg&hl=en>)
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> Invitation from Google Calendar <https://www.google.com/calendar/>
>
> You are receiving this email at the account peterschme...@gmail.com
> because you are subscribed for notifications on calendar RIOT Events.
>
> To stop receiving these emails, please log in to
> https://www.google.com/calendar/ and change your notification settings
> for this calendar.
>
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn More
> <https://support.google.com/calendar/answer/37135#forwarding>.
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://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 TCP Stack

[Martine Lenders]

Hello Sam,
You are right GNRC replaced the old stack (which was also developed as a
UDP stack first), since the old one was very buggy and not really
manageable. The TCP component is currently under development by Simon
Brunner at [1]. Since it is developed as part of a thesis which IIRC
encompasses Multipath-TCP, it might be that it is added as a feature. I
think it's best if you ask around in the PR, if you are interested in the
development of this particular module. There is currently no effort to
implement a pure TCP stack however (gnrc_tcp will just be the TCP layer for
the GNRC stack), mainly because our current interest was up until now into
WPANs (where TCP isn't feasible for the most part). However, I got my port
of lwIP [2] working yesterday. If you are in dire need for TCP you can try
it out. Be aware however, that there is no TCP support for the RIOT conn
interface yet (and because of that no support for the `posix_socket`
module). You can however try to use TCP with lwIP's own API (see their
documentation for that). Never tried it, but in theory it should work.

Regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/2827
[2] https://github.com/RIOT-OS/RIOT/pull/3551

2016-01-26 4:28 GMT+01:00 Sam Kumar :

> Hello,
> I am new to RIOT OS, and I am interested in working with the TCP stack.
> Looking at the release notes, it seems that ever since the 2015.09 release,
> when the gnrc networking stack was introduced, the TCP stack has been
> removed from the RIOT OS kernel and is being refactored.
>
> I was curious to learn what kinds of changes to the TCP stack that
> developers have been working on. I also want to learn about whether there
> are going to be new features and functionality added to the TCP stack, or
> whether the refactoring in progress is limited to a simple rewrite without
> changing functionality.
>
> So I am reaching out to the developer mailing list to learn about the
> developments in progress on the TCP stack for RIOT OS.
>
> 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

Re: [riot-devel] Hack'n'ACK tonight

[Martine Lenders]

Hi,
I think we did a great job tonight. We met our target to get under 200
pretty precise. Here's a little tally:

 * 44 PRs were updated (either discussed, pushed to, merged or closed):
   * 16 PRs were closed (of this 10 were merged)
   * 2 PRs were created

Of course before the Hack'n'ACK people were also busy so that we closed 29
PRs (and merged 21) in the last 24 h.

Thanks to all the reviewers and contributors for all the work.

Cheers,
Martine

2016-01-26 18:05 GMT+01:00 Cenk Gündogan :

> The PlaceCam session is online again. The link is the same.
>
>
> On 26.01.2016 18:03, Cenk Gündogan wrote:
>
>> Hello Francisco,
>>
>> we have some problems with the hardware (:
>> Should be back online in a jiffy
>>
>> On 26.01.2016 18:01, Francisco Javier Acosta Padilla wrote:
>>
>>> Hi there!
>>>
>>> I'm trying to join the PlaceCam session but it says that Riot is not
>>> online... Is the participation closed?
>>>
>>> Thanks!
>>>
>>> Francisco.
>>>
>>>
>>> On Tue, 2016-01-26 at 17:23 +0100, Hauke Petersen wrote:
>>>
 Hello everyone,

 Here's the link for the PlaceCam session tonight:

 http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-

 Cheers,
 Hauke

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

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

Re: [riot-devel] RIOT-OS file system?

[Martine Lenders]

Hi Zac,
short answer: no. Slightly longer answer: there is currently a person
working on that [1].

Hope that was helpful.

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/2474

2016-01-30 13:37 GMT+01:00 Zac Harvey :

> I *did* try to find some evidence of this in the RIOT-OS docs, but does
> RIOT support any type of file system (whatsoever)?
>
> Thanks!
> ___
> 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