[riot-devel] RIOT-OS Stammtisch in der c-base

[Martine Lenders]

Hallo,
wir, die Entwickler vom freien Betriebssystem RIOT [1] für embedded
systems, würden gerne (zukünftig) regelmäßig (zunächst aber erstmal
einmalig) unsere sogenannten Hack'n'ACK-Partys in der c-base veranstalten.
Hack'n'ACK-Partys sind, was wir unsere Kombination aus Stammtisch,
Bug-Squashing-Party und Code-Review-Come-Togethers nennen. Ein bis zwei
Mitentwickler und ich würden uns dann am Samstag beim nächsten
circle-Treffen vorstellen wollen.

Mit freundlichen Grüßen,
Martine Lenders

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

Re: [riot-devel] RIOT-OS Stammtisch in der c-base

[Martine Lenders]

Am 30. Oktober 2014 13:35 schrieb Martine Lenders mlend...@inf.fu-berlin.de
:

 Hallo,
 wir, die Entwickler vom freien Betriebssystem RIOT [1] für embedded
 systems, würden gerne (zukünftig) regelmäßig (zunächst aber erstmal
 einmalig) unsere sogenannten Hack'n'ACK-Partys in der c-base veranstalten.
 Hack'n'ACK-Partys sind, was wir unsere Kombination aus Stammtisch,
 Bug-Squashing-Party und Code-Review-Come-Togethers nennen. Ein bis zwei
 Mitentwickler und ich würden uns dann am Samstag beim nächsten
 circle-Treffen vorstellen wollen.

 Mit freundlichen Grüßen,
 Martine Lenders

 [1] riot-os.org


Sorry for this German mail to the development mailing list. It's mainly an
information for all Berlin-based developers. Here's a rough translation for
those who are interested anyhow:

Hello,
we, the developers of the free operating system RIOT [1] for embedded
systems, would like to host our regular (at least in the future, but at
least once for know) so-called Hack'n'ACK parties at the c-base [ann.: a
local hacker space]. Hack'n'ACK parties are what we call our combination of
Stammtisch, Bug Squashing Party and Code Review Come Together. One or two
co-developers and I would like to introduce ourselves this saturday at the
next circle [ann.: the c-base's self-organizing body] meeting.

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

Re: [riot-devel] RIOT-OS Stammtisch in der c-base

[Martine Lenders]

Hi,

2014-10-30 14:04 GMT+01:00 Emmanuel Baccelli emmanuel.bacce...@inria.fr:

 Thanks Martine. Who is available to accompany Martine Saturday at 8PM at
 C-Base?


Hauke already agreed to accompany, but a third person would be nice, I
guess :-)


 (I will try to attend myself, but I cannot confirm yet, thus the above
 question ;)
 Cheers
 Emmanuel


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

Re: [riot-devel] Regular Hack'n'ACK meetings at c-base, Berlin

[Martine Lenders]

Hi,
this is a reminder to attend the poll regarding regular Hack'n'ACKs at
c-base [1]. I plan to contact the orga team at c-base on sunday.

Cheers,
Martine

[1] https://dudle.inf.tu-dresden.de/riot-hacknack-regular-dow/

2014-11-01 23:08 GMT+01:00 Martine Lenders mlend...@inf.fu-berlin.de:

 Hi,
 as previously discussed we want to move our regular Hack'n'ACK meetings
 out of the context of FU and into the Berlin-based hacker space c-base [1]
 [2]. First of all, the c-base is approving our presence there, so we only
 have to communicate (fixed) date for our monthly meetings. Since the
 schedule of c-base is weekly I opened a doodle [3] to determine week (1st
 of month, 2nd of month, 2nd to last of month and last of month) and day of
 week for our future meetings. So if you live in or near Berlin, feel free
 to fill it out.

 Kind regards,
 Martine

 [1] https://www.c-base.org/
 [2] http://www.openstreetmap.org/#map=17/52.51297/13.42013
 [3] https://dudle.inf.tu-dresden.de/riot-hacknack-regular-dow/

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

Re: [riot-devel] Refectoring the network stack

[Martine Lenders]

Sorry for the many errors in grammar and spelling (and the
missing complimentary close). Accidentaly hit the send button before
reading through the mail again…

Kind regards,
Martine

2014-11-05 18:15 GMT+01:00 Martine Lenders mlend...@inf.fu-berlin.de:

 Hi,
 as discussed on the virtual meeting we aim to have the new network stack
 running with the next release (end of November or before christmas).
 Currently, I'm the only one directly involved into the development (appart
 from several radio driver implementations), and while parts of the model
 come from me, Hauke is currently refining it. As for development it is
 clear, that I can't be the only one working on it.

 I'm currently in the testing stage of 6LoWPAN but it is mostly done, but I
 still need some kind of way to communicate with the transceiver module for
 older boards (alternative would be to remove it, but for this we need #1772
 and #1733 merged and all boards moved to the low-level driver model). I
 hope I have this done at the end of next week.

 All in all it's still a long way to the transport layer and to speed
 things up, I thought some of you guys may want to help me. I tried to split
 down the tasks at hand and assigned preliminary some people who might be
 able to do it. If you do not want/can not do this task, please notify this.
 Also if you want to take over a task do tell so too, please. Every
 assignment with a question mark is not fixed yet.

 * Model (Martine? and Hauke)
 * 6LoWPAN
   - backwards compatibility with transceiver module (Martine)
   - bug-hunting (Martine)
   - ND according to https://tools.ietf.org/html/rfc6775 (Martine?,
 depends on a running ND for IPv6)
   - optional: Next header compression (Oleg?)
 * IPv6
   - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?)
   - consistent and extendable IPv6 Extension Header API (Martine?)
   - consistent and extendable ICMPv6 API (Lotte?)
   - Neighbor discovery according to http://tools.ietf.org/html/rfc4861
 (Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess)
 * Transport layer
   - port to netapi and pktbuf (Cenk?)

 * optional tasks for full deprecation of `transceiver`:
   - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?)
 and CCNlite to netapi or netdev
   - port boards that use cc110x to periph API or port cc110x_legacy and
 cc110x_legacy_csma to netdev
   - either removal or port to netdev of redbee-econotag


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

Re: [riot-devel] Refectoring the network stack

[Martine Lenders]

Hi Adam,

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

 Is support for TSCH in there somewhere? While I'm not entirely read up on
the spec it would seem to be fairly important these days.

 What is the current state of TSCH support in RIOT these days? I'm stuck
on my phone at the moment or I'd take a look for myself (really, it
probably has a bit more to do with my being hungover and slightly lazy this
morning).

Currently use the already existing TSCH implentation OpenWSN. So that's
where it is hiding ;)

Cheers,
Martine


 --adam

 On Nov 5, 2014 9:15 AM, Martine Lenders mlend...@inf.fu-berlin.de
wrote:

 Hi,
 as discussed on the virtual meeting we aim to have the new network stack
running with the next release (end of November or before christmas).
Currently, I'm the only one directly involved into the development (appart
from several radio driver implementations), and while parts of the model
come from me, Hauke is currently refining it. As for development it is
clear, that I can't be the only one working on it.

 I'm currently in the testing stage of 6LoWPAN but it is mostly done, but
I still need some kind of way to communicate with the transceiver module
for older boards (alternative would be to remove it, but for this we need
#1772 and #1733 merged and all boards moved to the low-level driver model).
I hope I have this done at the end of next week.

 All in all it's still a long way to the transport layer and to speed
things up, I thought some of you guys may want to help me. I tried to split
down the tasks at hand and assigned preliminary some people who might be
able to do it. If you do not want/can not do this task, please notify this.
Also if you want to take over a task do tell so too, please. Every
assignment with a question mark is not fixed yet.

 * Model (Martine? and Hauke)
 * 6LoWPAN
   - backwards compatibility with transceiver module (Martine)
   - bug-hunting (Martine)
   - ND according to https://tools.ietf.org/html/rfc6775 (Martine?,
depends on a running ND for IPv6)
   - optional: Next header compression (Oleg?)
 * IPv6
   - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?)
   - consistent and extendable IPv6 Extension Header API (Martine?)
   - consistent and extendable ICMPv6 API (Lotte?)
   - Neighbor discovery according to http://tools.ietf.org/html/rfc4861
(Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess)
 * Transport layer
   - port to netapi and pktbuf (Cenk?)

 * optional tasks for full deprecation of `transceiver`:
   - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?)
and CCNlite to netapi or netdev
   - port boards that use cc110x to periph API or port cc110x_legacy and
cc110x_legacy_csma to netdev
   - either removal or port to netdev of redbee-econotag


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


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

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

Re: [riot-devel] Refectoring the network stack

[Martine Lenders]

Hi Adam,

2014-11-07 11:38 GMT+01:00 Adam Hunt voxa...@gmail.com:

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


Yes this (and easier more modularity through less coherence = easier
testing) is the main reason for the refactoring.


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


The broken border router is mainly the fault of the broken 6LoWPAN Neighbor
Discovery and the restricted possibility of multiple interfaces (it used to
be just a thread, that scooped all packets not addressed to a node in the
PAN over the UART of a node with no other option available). Since the
refactoring effort also aims to squash this bugs once and for all (again
through easier testing) and the multiple interface support is build-in into
the model (you can even have SLIP over UART, if you do not have an Ethernet
or WiFi module; have a look at PR #1454 [1]), there is nothing that is in
the way of a functioning border router.

Cheers,
Martine

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

Re: [riot-devel] FIB redesign

[Martine Lenders]

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

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

Cheers,
Martine

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

  Hi Martine,

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

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

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


 Best regards,
 Martin


 On 15.11.2014 02:03, Martine Lenders wrote:

 Hi Martin,

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

  Hi Martine,

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


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

  Cheers,
 Martine

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


 ___
 devel mailing 
 listdevel@riot-os.orghttp://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] Dedicated RIOT Testing Meeting

[Martine Lenders]

Hi,
Sorry I couldn't attend. Will there be minutes?

Cheers,
Martine
Am 19.11.2014 12:58 schrieb Oleg Hahm oliver.h...@inria.fr:

 Here goes the PlaceCame link:
 http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE-

 Am Tue, Nov 11, 2014 at 09:13:23PM +0100 schrieb Philipp Rosenkranz:
  Hi everyone,
 
  I'd like to announce that the dedicated RIOT testing meeting will take
  place on:
 
  Wednesday the 19th of November at 01:00 pm CET.
 
 
  We will use PlaceCam for the meeting. If you are using Linux you need to
  install
  PlaceCam beforehand. PlaceCam can be found at [1].
  Please note that you don't need to create an PlaceCam account.
  Access to the conference call will be provided by a link which I will
 share
  on this
  list shortly before the meeting starts.
 
  [1] http://www.daviko.com/videokonferenz/3-1-Download.html
 
 
  Best regards,
  Philipp

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


 --
 /* Ugly, ugly fucker. */
 linux-2.6.6/include/linux/netfilter_ipv4/ipt_limit.h

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


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

Re: [riot-devel] Switch to BSD?

[Martine Lenders]

Hi,

2014-12-03 22:59 GMT+01:00 Emmanuel Baccelli emmanuel.bacce...@inria.fr:

 […]

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


Sorry for coming in late into the discussion, but I'm still quite undecided
on that topic, mainly because my expertise in free software and open
culture licenses (apart from CC License which is quite transparent) is not
that great to begin with. Fact is, everytime I speak with Free
Software/Open Source people more assured in that matter than me, no one
really understands the fear of (L)GPL in the industry. I can't find any
argument against it either, apart from the irrational arguments allegedly
introduced by some lawyers.

I also don't have much intuition on how a license change would change the
community, but personally I'm far more interested in input from hobbyists
and start-ups than from the big players. Maybe its quite naïve, but I
believe that with enough traction from the former we could attract the
latter, even without a license change. If a license change would
attract more of the former too, I can't really tell. I trust however the
Emmanuel's et al. opinion in the matter, that this might be the case.

If a license change is due I won't stand against it, but I would prefer MIT
over a BSD license.

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

Re: [riot-devel] RIOT on Arduino UNO

[Martine Lenders]

Hi,

2014-12-21 21:13 GMT+01:00 eric fleury eric.fle...@inria.fr:



 Eric Fleury, Professor
 DANTE INRIA TEAM
 ENS LYON
 Tel: +33 672 162974

 On 21 déc. 2014, at 20:15, Sudarshan S sudarshans.riot@gmail.com
 wrote:

 […]
 I would like to understand the following:
 1) I believe there are ways to expand RAM in Arduino UNO,  using SRAM ICs
 and SPI bus upto 32K . So would it be feasible or make sense  to port RIOT
 on such an expanded RAM arrangement ?


 I am afraid that such memory is only for data and will not be accessible
 via the program counter.


True, but since RIOT's program is written to the Flash ROM, there would be
no need for the IP to access those addresses. So the real question is: how
big is the Flash ROM, and how much memory does the .text part of RIOT
consume on 8-bit platforms. For our hello-world application this is 8524
bytes on the Arduino Mega 2560, for the somewhat more sophisticated default
application it's ~15 KiB (without any network support). @Sudarshan is that
remotely in the flash sizes of the Arduino Uno?

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

Re: [riot-devel] Example Application for testing microcoap in RIOT?

[Martine Lenders]

Hi Hasan,
can you open a Pull Request on GitHub, so we can review and discuss your
port there?

2014-12-22 10:41 GMT+01:00 Islam Hasan hasan.is...@aalto.fi:

 Hi,

 I have included microcoap as an external pkg in RIOT OS, but getting some
 frustrating warnings from RIOT as the followings:

 /RIOT/pkg/microcoap/microcoap/coap.c:68:26: warning: comparison between
 signed and unsigned integer expressions [-Wsign-compare]
  if (4 + hdr-tkl  buflen)


There is an implicit casting going on here, since 4 is signed, and hdr-tkl
and buflen are unsigned. Use 4U instead of 4, so 4 is unsigned, too.



 /RIOT/pkg/microcoap/microcoap/coap.c:354:5: warning: comparison is always
 true due to limited range of data type [-Wtype-limits]
  if (value=0xFF+13)
   ^


0xFF is the maximum of uint8_t… I'm not quiet sure what the use-case for
all of the if-statements in that function are for, maybe you get in touch
with the microcoap authors for that.



 However, I was looking for libcoap example application in RIOT, for
 instance, testing a client application with microcoap server. I notice that
 RIOT has supports for libcoap, but no example application there to play
 with it.


The ETSI coap plugtests are currently under review as an example
application: https://github.com/RIOT-OS/RIOT/pull/1801.

Hope I could help,
Martine
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] New IPC API status

[Martine Lenders]

Hi

2015-01-24 9:49 GMT+01:00 Adam Hunt voxa...@gmail.com:

 If memory serves there were a number of potential features that were on
 the back burner until RIOT's new IPC API was finalized (e.g.
 filesystem/VFS, and maybe ELF loading).


Just for clarification: FS would just be simplified by multiple IPC
endpoints per thread (as was also intended by the new IPC API), since an
easy mapping file descriptor == IPC endpoint is the most logical thing to
do. With some extra overhead an alternative would be possible to, but not
as beautiful ;-).
However, as far as I understood Kaspar's intend, multiple IPC endpoints per
thread is still on the.

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

Re: [riot-devel] git howto for a correct pulls

[Martine Lenders]

Hi Jan,

2015-02-04 21:18 GMT+01:00 Jan Wagner m...@jwagner.eu:

 why i am always feeling stupid using git... hub...

 in my naive way of thinking

 git clone https://u...@bitbucket.org/user/repo.git  me

 -- if sync needed
 git remote add upstream https://github.com/RIOT-OS/riot.git
 git fetch upstream
 --

 git checkout -b some-feature
 # Adds
 git commit -a -m Add first draft of some feature
 git push origin some-branch
 (trigger pull via web interface finaly)

 is fully githbu compatible- please tell me if i am dead wrong


Yes and no. As far as I know it is not possible to create a pull request to
a GitHub repository from a Bitbucket repository. As I said: The concept of
Pull Requests is a feature of Bitbucket or GitHub to implement a certain
workflow with Git, not git itself (even though Cenk pointed out there is
the command `git request-pull`, but that generates an email, which is part
of another workflow). There are other workflows possible with Git, just not
when you are centralizing your project on GitHub or Bitbucket or similar
services.

To be able to create a Pull Request you need a GitHub-Account. Then fork
the central RIOT repository at https://github.com/RIOT-OS/RIOT to your own
account by pressing by clicking the fork button in the upper right corner.
This copies the whole repository to your personal github account and it's
address will be something like https://github.com/jwagner/RIOT/. You can
then clone this to your local computer via

git clone g...@github.com:jwagner/RIOT/

and proceed as you already described.


  git merge FETCH_HEAD
 

 i dont get it - i dont want to merge(?)


Then don't use `git pull` (which is an alias for `git fetch  git merge
FETCH_HEAD`), but only `git fetch` instead. Per default tags are not
fetched, but with `git fetch -t` you can fetch those, too.





  The official documentation of git [4] is very good btw and includes
 also a
  book [5] on it's concepts with several examples of how to do stuff.
 

 hm aggain i dont think i am a person to stuid to read documentation, hehe
 - i do
 not realy like the github help


There are also videos available on Git's website ;-):
http://git-scm.com/videos and I'm sure YouTube provides a number of
Screencasts on GitHub.





 https://help.github.com/articles/fork-a-repo/  this one is nice - with
 command
 lines

 but the next page

 https://help.github.com/articles/fork-a-repo/  sux no command line

 ps. I remeber I saw the right commandline on githubhelp.


Because forking a repository is not a command-line thing. It's, as the
concept of Pull Requests, a feature of the repository provider (aka
GitHub). It's basically `git clone` on the server of GitHub into your own
GitHub account.


 I invested maybe in total 4h+ the last 3 weeks to understand and read
 github,
 and understand that github is !git

 I just want to add my c code that it.

 thanks for ur help but i realy starting to hate it


What version control system are you normally using? Maybe we can explain it
to you from this perspective.

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

Re: [riot-devel] git howto for a correct pulls

[Martine Lenders]

Hi,

2015-02-04 21:55 GMT+01:00 Jan Wagner m...@jwagner.eu:

  and dont get me worng - i did some pulls requests already - I think I
  did a misstake by deleting my github fork:

  https://github.com/RIOT-OS/RIOT/pull/2387

  https://github.com/RIOT-OS/RIOT/pull/2312  problem here
  I deleted the fork form my github user and therefore it says

  fswarm https://github.com/rfswarm  wants to merge 9 commits into
 RIOT-OS:master  from  unknown repository  unknown

  and I am unable to edit the files anymore.

  so I just want to do it right and not beeing able to ... grrr :]


My retrospective advice would be: Don't delete your fork while having a PR
open [?]

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

Re: [riot-devel] Network Stack Task Force

[Martine Lenders]

Hello Martin,

2015-02-06 9:02 GMT+01:00 Martin martin.landsm...@haw-hamburg.de:

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


Great!


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


Yesterday after the talk we discussed how to solve routing in the network
stack. Basically we decided, that for proactive routing the FIB (for a
given destination address it gives an PID/interface + next hop address) you
proposed is sufficient. For reactive routing we concluded, that it is
probably best for the FIB to return for a given destination address the PID
of the routing protocol with next hop address == NULL, if a next hop is not
available. This way we only need to check in IP if the next hop address is
!= NULL to lookup the link layer address in the NIB and then send the
packet to the given PID. The routing protocol is in case of reactive
routing then responsible for the packet and might either send it itself to
the link layer or resend it to IP after a next hop was found or drop it if
not.

We also discussed error management for sending and receiving. The result
was, that we introduce a 6th message type for netapi to communicate the
status of a packet for a certain layer, and a protocol can register to
those via netreg. I'll propose an interface for this at today's meeting.

The plan for today is to discuss Header Options, ICMPv6, neighbor discovery
and something something I forgot right now ^^

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

Re: [riot-devel] Memory Management

[Martine Lenders]

Hi Raphael,
for the native-stuff you have to ask Ludwig for the specifics as to of why,
but most of the hosts system's implementation of standard functions are
wrapped. I think this was because our POSIX interface would otherwise
colide with the system's POSIX interface. As for the other boards I'm
refrasing only what I've been told, so please correct me if I'm wrong,
anyone: newlib provides free() for most of our ARM boards (provided sbrk()
is implemented as a syscall). For msp430 there is currently only
oneway-malloc available and for AVR I'm not sure about the implementation.
Maybe Hinnerk can shed some light on this :-).

Cheers,
Martine

2015-01-22 10:41 GMT+01:00 Hiesgen, Raphael raphael.hies...@haw-hamburg.de
:


 Hello,

 I am curious as to how memory management works. Searching the code for
 void free( returns two implementations. One implements the function in
 the native port as a wrapper of the systems implementations (?) and the
 other does nothing (found in malloc.h in the folder oneway-malloc and
 implemented in oneway-malloc.c).

 Is there another implementation I have overlooked or is there no way to
 free memory on boards?

 Thanks
 Raphael



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

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

Re: [riot-devel] Network Stack Task Force

[Martine Lenders]

Hi,

2015-01-16 20:04 GMT+01:00 Oleg Hahm oliver.h...@inria.fr:

 Hey!

  For the workshop I propose January 27-28, but its just a proposal...
  Keep in mind, that the next HA is scheduled for January 27.
  Of course I did not. :-) But I think thats a perfect fit!

 I'm not so convinced about that. To my understanding the HA is mostly
 about
 speeding up the merge of existing code into RIOT, the task force is about
 concepts and designs. I think it would either decrease productivity of the
 HA
 event by to many people discussing (instead of reviewing and hacking), or
 set
 an early deadline for the task force event on the first day. Also, if we
 start
 heavy brainstorming and discussing about the network stack in the morning,
 I'm
 pretty sure that my mind won't be very fresh for the HA.


I think similar (and know me well enough to expect it), as Oleg does. I
would propose to just doodle it out for the span of the days after the HA
and the week after.

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

Re: [riot-devel] [i...@meetup.com: Invitation: Internet of Things Meetup 12 – Intel Edison]

[Martine Lenders]

Hi,

2015-01-30 20:56 GMT+01:00 Christian Mehlis christ...@m3hlis.de:

 Am 29.01.2015 um 14:02 schrieb Thomas Eichinger:

 See you there!


 Me 2

 Christian


Made a note to my calendar, too. :-)
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network Stack Task Force

[Martine Lenders]

Hi,
looks like it's gonna be February 5th and 6th (a Thursday and a Friday).
Martin is the only one that is not available on Thursday. Is everyone okay
with that?

Cheers,
Martine

2015-01-19 17:30 GMT+01:00 Hauke Petersen hauke.peter...@fu-berlin.de:

  Hi everyone,

 sandwiching the HA is indeed not a good idea, I agree.

 Thanks Martine for the doodle, let's wait until Thursday and decide on the
 dates based on the outcome of the doodle then.

 Cheers,
 Hauke



 On 19.01.2015 13:17, Martine Lenders wrote:

 Hi,
 Since this thread has gained some traction now I would propose to use to
 dudle it out. The two days adjacent to each other where most are available
 would be the date: https://dudle.inf.tu-dresden.de/RIOT-NSFT1/

 Cheers,
 Martine
 Am 19.01.2015 12:29 schrieb Emmanuel Baccelli 
 emmanuel.bacce...@inria.fr:

 Hi Thomas,
 damn, your right, I misread the dates. So Hack'nAck would be sandwiched
 inside the workshop, and I guess that's not great. How about 28-29, or
 29-30, then?
 Best
 Emmanuel

 On Mon, Jan 19, 2015 at 11:24 AM, Thomas Eichinger 
 thomas.eichin...@fu-berlin.de wrote:

 Hi,

 I’d also like to attend. I’d prefer a date without HA in-between (as
 these tend to
 end late at night, which would make it hard to start with NSTF early
 again) but
 wouldn’t object if there is a majority in favour of this.

 Best, Thomas

  On 16 Jan 2015, at 19:08, Hauke Petersen hauke.peter...@fu-berlin.de
 wrote:
 
  Dear RIOTers,
 
  we recently came up with the idea to create task forces around special
 topics in RIOT to concentrate and speed up the development of key parts.
 The idea is to bring all people that are interested in this topic and are
 prepared to spend some on it together in a (virtual) room and start out by
 a 2-3 day workshop style event. This first period should be used to discuss
 the topic in detail to bring everyone involved on the same page, to come up
 with a clear architecture, and define interfaces and sub-modules. The hope
 is, that we can go into a very productive implementing phase afterward and
 speed up the overall development.
 
  The first key topic we want to try out this concept is the ongoing
 re-structuring of the network stack. I propose the following plan for this:
  - we use next week to coordinate (who wants to join, what is the
 current state, what are the most pressing open questions)
  - we block 2 days in the last week of January for a (virtual)
 white-board centered workshop
 
  For the workshop I propose January 27-28, but its just a proposal...
 
 
  Regarding technical aspects that are currently under (heavy)
 construction or need to be clarified (@Martine: please hit me if I have it
 completely wrong here...):
  - optimizations to the netdev interface
  - optimizations to the netapi interface
  - analysis of possible data loss using netapi in its current state
  - how to pass data/headers/packets around the stack
  - possible generalization and/or quotas in the packet buffer
  - concepts of global protocol/module list and global protocol handler
 registry
  - API definition for the neighbor table
  - API definition for the forwarding table
  - possible join for neighbor and forwarding table
  - hooks for various routing protocols
  - ???
 
  This is just a initial list of topics to be further discussed - I hope
 we can detail it out over the next week to have a good idea about the
 questions that need time for discussion!
 
 
  So concluding:
  - who is interested (and/or) wiling to joing this effort?
  - are there any ideas on the concrete organization of such a
 task-force?
  - are there technical aspects I forgot?
 
  Looking forward to your feedback!
 
  Cheers,
  Hauke
 
  ___
  devel mailing list
  devel@riot-os.org
  http://lists.riot-os.org/mailman/listinfo/devel

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



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



 ___
 devel mailing 
 listdevel@riot-os.orghttp://lists.riot-os.org/mailman/listinfo/devel



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


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

Re: [riot-devel] Network refactoring

[Martine Lenders]

Hello Baptiste,
since I was mostly in charge of the refactoring last year and we want to
split up this task this year a little bit, I'm currently in the process of
compiling such a TODO list/progress report. Hope I have something to show
end of the week.

Best,
Martine

2015-01-05 9:50 GMT+01:00 Baptiste Clenet bapcle...@gmail.com:

 Hello RIOTers,

 Concerning the network refactoring, do you have a TODO list which lets us
 see the progress? We're looking forward to using it with the SAMR21 board
 and hope it will be finished soon.
 Is there a deadline set for this?

 Best,

 Baptiste

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


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

Re: [riot-devel] Network refactoring

[Martine Lenders]

Hi,
Am 05.01.2015 18:06 schrieb Ludwig Ortmann ludwig.ortm...@fu-berlin.de:

 Hi,

 On Mon, Jan 05, 2015 at 06:00:34PM +0100, Oleg Hahm wrote:
  Maybe we can discuss a tentative schedule and set some milestones for
the
  refactoring during a (PlaceCam) conf call this week? What do you think?

 How about making the milestone setting part of the bi-weekly virtual
 meeting next week? I guess more interested parties (me among others)
 can attend then ;)

 It would be great if there is some pre-discussed input for that topic
 in that meeting though, so please: do have a preliminary talk.

I'll try to manage to prepare some slides.
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Reference Radio-driver Implementation

[Martine Lenders]

Hello Jonas,
truth is we are currently somewhat in a transition phase. We want the new
netdev interface and have in place as soon as possible, but there are still
modules and applications that use the old transceiver interface. Moreover,
the cc2420 is older than the netdev API and was just adapted to it (to
avoid confusion: the adaption to netdev is not even merged, yet [1]). I
think a better (though in my eyes still not perfect, since it's also
serving the transceiver API) reference implementation is the new cc110x
driver by Fabian Nack. For IEEE 802.15.4 maybe the Xbee driver by Kévin
Roussel [2] is a better reference than the cc2420.

[1] https://github.com/RIOT-OS/RIOT/pull/1733
[2] https://github.com/RIOT-OS/RIOT/pull/2250/files

2015-01-06 14:55 GMT+01:00 Jonas Remmert j.remm...@phytec.de:

 Dear RIOTers,

 at Phytec, we are currently working on a Radio-driver implementation for
 the Freescale Kinetis-MKW2x CPU. Basic Radio-functionalities exists using
 the old RIOT-network interface. Before we start a pull request, we want to
 adapt the driver to the new RIOT-network interface.

 I´ve also looked at PR/1733, that provides the adaption of the CC2420
 driver to the new network interface. But in this Radio-driver,
 transceiver.h is also included. Thats a bit confusing to me. Is the
 transceiver interface needed for the CC2420-driver?

 As I understand it, the old transceiver interface must not be used anymore?

 Is there currently any driver interface that can be used as reference, to
 understand the complete system?

 Thanks in advance,

 Best regards
 Jonas Remmert
 ___
 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] 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 bapcle...@gmail.com:

 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] ESP8266 - Easy tcp/ip support

[Martine Lenders]

Hello David,

2015-03-17 0:02 GMT+01:00 David Lyon david.l...@clixx.io:

 Hello Ludwig,

 Lately, I've been putting a lot of time into the ESP8266 wifi modules, and
 learning how to get them to work.

 How is the unified network driver system going?

 Here's my conclusion on the ESP8266. If Riot has a unified network driver
 system, it might be worth looking at trying to integrate these modules with
 riot.


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


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


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


 Let me know if this is an interesting option?


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

Regards,
Martine

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

Re: [riot-devel] Radio duty cycling

[Martine Lenders]

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

Cheers,
Martine

2015-03-17 10:05 GMT+01:00 Joakim Gebart joakim.geb...@eistec.se:

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

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

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

 Best regards,
 Joakim Gebart
 Eistec AB
 www.eistec.se

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


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

[riot-devel] 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
 =VIEWeid=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 j.remm...@phytec.de:

 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

[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

[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=VIEWeid=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

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 oliver.h...@inria.fr:

 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: 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=VIEWeid=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+Hamburghl=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] 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 ludwig.ortm...@fu-berlin.de:

 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] Changing the workflow.

[Martine Lenders]

Hi,

2015-02-21 20:06 GMT+01:00 Ludwig Ortmann ludwig.ortm...@fu-berlin.de:

 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 tei...@gmail.com:

 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 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 authmille...@gmail.com:

 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 tei...@gmail.com:

 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 authmille...@gmail.com:

 […]

 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] 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 m...@muratcakmak.net:

 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
 ludwig.ortm...@fu-berlin.de:
 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
 m...@muratcakmak.net:
 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
 DigitalAnalog
 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
 http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration
 _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 same level of comfort compared to Linux sounds like a
 cheap
 
 
   marketing slogan making clear that the persons are not aware of
 the
 
 
   IoT diversity.
 
  Saying otherwise makes clear that the persons are not aware of the
 
  troubles embedded linux companies go through when developing
 
  proprietary devices using (L)GPLed linux + libraries.
 
 
 
   Both systems address different types of devices.
 
 
 
  From a 

[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

[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] MIPS platform (PIC32)

[Martine Lenders]

Hi,

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

 […]

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


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

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

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 if 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 kas...@schleiser.de:

 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

[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 u...@c-base.org
Datum: 22. April 2015 um 14:44
Betreff: Re: [Seminarorga:] RIOT Hack'n'ACK Mai
An: Seminarorganisation seminaro...@c-base.org, 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

[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

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 oliver.h...@inria.fr:

 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] 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 kas...@schleiser.de:

 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 sys/socket.h

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 kas...@schleiser.de:

 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 kas...@schleiser.de:

 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 kas...@schleiser.de:

 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] 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 kas...@schleiser.de:

 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
 NAME_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 oliver.h...@inria.fr:

 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

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 oliver.h...@inria.fr:

 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 oliver.h...@inria.fr:

 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] 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 kas...@schleiser.de:

 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]

Hi,

2015-04-12 11:33 GMT+02:00 Kaspar Schleiser kas...@schleiser.de:

 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] 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 bapcle...@gmail.com:

 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 hauke.peter...@fu-berlin.de:

  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] 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 oliver.h...@inria.fr:

 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=VIEWeid=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

[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

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 kas...@schleiser.de:

 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

[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] 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

[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

Re: [riot-devel] RIOT examples

[Martine Lenders]

Hey,

2015-08-19 14:47 GMT+02:00 Kaspar Schleiser kas...@schleiser.de:

 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 cenk.guendo...@fu-berlin.de:

 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 cenk.guendo...@fu-berlin.de:

 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

[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] 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] 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] 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

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

[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] 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] 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

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

Re: [riot-devel] Arduino API merged

[Martine Lenders]

Lol I need coffee.

Cheers,
Martine

2015-11-27 14:10 GMT+01:00 Hauke Petersen <hauke.peter...@fu-berlin.de>:

> 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] 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" <haoyang...@rutgers.edu>:

> 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 <authmille...@gmail.com> 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 <haoyang...@rutgers.edu>:
>
>> 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 <oliver.h...@inria.fr> 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] 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 <haoyang...@rutgers.edu>:

> 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 <oliver.h...@inria.fr> 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] MAC Layer Implementation in RIOT

[Martine Lenders]

Dear Alper,
what exactly do you mean by "IEEE 802.15.4 MAC" layer? As far as I know,
IEEE 802.15.4 still only has 802.15.4e as an "official" MAC layer in an
extended specification, but it is not part of the official standard yet.
`/sys/net/link_layer/ieee802154` only implements the handling of IEEE
802.15.4 headers, but a very basic MAC (just send/receive data without any
assurance) is implemented in
`sys/net/gnrc/link_layer/netdev2/gnrc_netdev2_ieee802154.c` for the GNRC
stack. There are however several other solutions for MAC with IEEE 802.15.4
currently under development (see [1] [2] [3] [4]). For IEEE 802.15.4e
support we currently use the OpenWSN stack [5] [6], but a stand-alone
module is planned. In general, both solutions (within the stack using one
of the provided MAC modules or using capabilities provided by the device)
are possible, depending on the features provided by the device.

Hope this made things clearer for you.
Best regards,
Martine Lenders

[1] https://github.com/RIOT-OS/RIOT/pull/3730
[2] https://github.com/RIOT-OS/RIOT/pull/4180
[3] https://github.com/RIOT-OS/RIOT/pull/4184
[4] https://github.com/RIOT-OS/RIOT/pull/4213
[5] https://openwsn.atlassian.net/wiki/pages/viewpage.action?pageId=688187
[6] https://github.com/RIOT-OS/RIOT/tree/master/pkg/openwsn

2016-06-09 12:02 GMT+02:00 Alper Kamil Demir <akde...@adanabtu.edu.tr>:

> Dear Martine,
> IEEE 802.15.4 MAC layer is implemented within RIOT operating system
> Or IEEE 802.15.4 MAC layer is implemented within RF tranceiver such as
> CC2420 ???
> If IEEE 802.15.4 MAC layer is implemented within RIOT operating system, is
> it in \sys\net\link_layer\ieee802154 ??? (If so, it seems so simple.)
> If It is not implemented within RIOT, what is the function
> of \sys\net\link_layer\ieee802154 directory? (is it an interface to IEEE
> 802.15.4 MAC layer?)
>
> I appreciate if you can answer my question.
> Best regards,
> Assist. Prof. Dr. Alper K. Demir
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT Vs Iotivity, AllJoyn, Thread

[Martine Lenders]

Hi,

2016-06-08 20:29 GMT+02:00 Iván Briano :

> On Wed, 08 Jun 2016 19:58:50 +0200, Baptiste Clenet wrote:
> > 2016-06-08 17:14 GMT+02:00 Emmanuel Baccelli  >:
> >
> > > Hi Ivan,
> > > it would be great to have it as a pkg indeed!
> > > That's the standard way third-party stacks are integrated in RIOT.
> > > Looking forward to that,
> > > Emmanuel
> > >
> > > On Wed, Jun 8, 2016 at 3:41 PM, Iván Briano 
> wrote:
> > >
> > >> On Wed, 08 Jun 2016 09:46:31 +0200, Baptiste Clenet wrote:
> > >> > Thanks for your answers.
> > >> > Could we integrate Soletta OIC implementation part as a pkg in RIOT?
> > >> >
> > >>
> > >> The OIC implementation is tightly integrated to the core of Soletta,
> so
> > >> you need the whole thing in.
> > >
> > > Yes but could we find a way to separate it a bit so we can run a OIC
> > server using GNRC quickly?
>
> That's not straight forward. The OIC implementation uses the CoAP one in
> Soletta, which uses the socket abstractions as well. GNRC is all the way
> under that. Using Soletta means that you'll need one thread to run the
> main loop, from where all events will be dispatched.
>

Porting to GNRC won't be necessary for early integration (maybe later on we
can cherry-pick the best parts to make it work with GNRC). The emb6 stack
(a fork of Contiki's uIP) [1] I ported for RIOT [2] had similar
requirements for running in a single thread. If you want to I can help you
with integrating a foreign network stack into RIOT using `pkg`.
It's mainly about providing an adaption layer between whatever HAL the
stack uses and `netdev2`. `conn` can also be ported, but as your
descriptions sounds like Soletta is running above transport layer, this
might not be needed/suitable.

Cheers,
Martine

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

[riot-devel] API CHANGE: msg_t now carries void pointers

[Martine Lenders]

Hello revising IOTlers,

another day another API change: After some discussion in [1] we decided to
unify the typing of pointers of unspecified type. The first fall-out from
that discussion was the changing of the pointer of the `content.ptr` field
of `msg_t`. It is now `void *` instead of `char *`, so no explicit casting
is needed anymore when using it.

Cheers,
Martine

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

Re: [riot-devel] API CHANGE: msg_t now carries void pointers

[Martine Lenders]

Hi again,
sorry, forgot to quote the PR that changed it: [2].

Cheers,
Martine

[2] https://github.com/RIOT-OS/RIOT/pull/5498

2016-06-03 14:02 GMT+02:00 Martine Lenders <authmille...@gmail.com>:

> Hello revising IOTlers,
>
> another day another API change: After some discussion in [1] we decided to
> unify the typing of pointers of unspecified type. The first fall-out from
> that discussion was the changing of the pointer of the `content.ptr` field
> of `msg_t`. It is now `void *` instead of `char *`, so no explicit casting
> is needed anymore when using it.
>
> Cheers,
> Martine
>
> [1] https://github.com/RIOT-OS/RIOT/issues/5497
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] arduino-uno support

[Martine Lenders]

Hi Laurent,
don't want to discourage you, but you do not have to update on this mailing
list for every step you do. Just the major ones are enough ;-). Those of us
interested (as for example me) will most likely follow your PR anyways.

BTW: when you write your wiki page on the board can you add a section on
how to use the emulator?

Regards,
Martine

2016-05-25 22:26 GMT+02:00 Laurent Navet :

> Hi,
>
> Shared code between atmega260 and atmega328p now live in atmega_common,
> except startup.c which I dont find how to move it yet, certainly due
> to the "export UNDEF += $(BINDIR)cpu/startup.o" directive.
>
> Tests has been done on emulator since I don't have the mega2560.
>
> Regards,
> Laurent
>
>
> https://github.com/RIOT-OS/RIOT/pull/5451/commits/e1a317f807ed12785ec8d2c53bcbb0d470964676
> ___
> 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] API change in netdev2

[Martine Lenders]

Hi,
quick note to all network device driver and MAC protocol developers: The
API of netdev2 was changed slightly [1] in that the event_callback now
doesn't expect a `void *` argument anymore. This argument has proven to be
superfluous, since the data was always stored in the `netdev2_t` struct
anyway. As a consequence this member of the struct was renamed from
`isr_arg` to `context`.

If you are working currently on a network device driver implementing
netdev2 or on a MAC protocol utilizing netdev2, please rebase!

Thanks for your attention,
Martine

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

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

[Martine Lenders]

Hi,
we finally managed to set-up here in Berlin. If you like to join via
PlaceCam [1] feel free to do so at

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

Cheers,
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] Problem with UDP and SAMR21-XPRO

[Martine Lenders]

Hi Mattia, hi Alex,
due to having my head mostly on the defense of my master thesis I have
next monday I wasn't able to look into this as promised. :(

Thanks however Mattia for the in-depth analysis and the bisect! As
soon as I find some head space I will look into it, too.

Cheers,
Martine

2016-06-23 23:56 GMT+02:00 MATTIA ANTONINI :
> Hi all!
> I found the problem in the commit 0de34c9 [1]. Can anyone check this commit?
> I've also tried  the commit before ( f7bd237) and everything works.
>
> Cheers,
>
> Mattia
>
>
>
> [1]
> https://github.com/RIOT-OS/RIOT/commit/0de34c91c618829a845feef753b3ea32683365ed
>
> 2016-06-22 15:14 GMT+02:00 Alexandre Abadie :
>>
>> Hi,
>>
>> > though I do not have the same setup ready for testing, I _cannot_
>> > confirm any
>> > problems with UDP on latest RIOT master branch.
>> >
>> > I just tested UDP on a SAMR21-XPRO running gnrc_networking example and
>> > successfully send and received UDP data from and to a RasPi with
>> > Openlabs
>> > transceiver running netcat on latest Raspbian-Linux.
>> >
>> > Could you clarify which RIOT branch/commit you use?
>>
>> Latest master. From what you say, the problem comes from the RIOT BR.
>>
>> Cheers,
>>
>> Alex
>>
>>
>> >
>> > Best,
>> >   Sebastian
>> >
>> > > Am 21.06.2016 um 21:42 schrieb Alexandre Abadie
>> > > :
>> > >
>> > > Hi Mattia,
>> > >
>> > > Thanks for reporting this issue.
>> > >
>> > >> I've discovered a possible bug in RIOT. I'm working with 2
>> > >> samr21-xpro: on
>> > >> the first is running gnrc_border_router (I'll call it A) and on the
>> > >> other
>> > >> (I'll call it B) is running gnrc_networking. I've well configured my
>> > >> scenario infact I can ping both my nodes from linux shell. But, when
>> > >> I
>> > >> send
>> > >> a UDP packet to B (with nc) it is forwarded correctly on tap
>> > >> interface (I
>> > >> seen it on wireshark) but it arrives corrupted (wrong checksum) to B
>> > >> and
>> > >> it
>> > >> is dropped by UDP thread. I've enabled packet dump and the packet
>> > >> arrives
>> > >> with different packet lengths in ipv6 and udp headers (fixed to 8, it
>> > >> is
>> > >> the UDP header length) and the udp payload is removed.
>> > >
>> > > I have the exact same problem although I didn't track it as deep as
>> > > you
>> > > did.
>> > >
>> > >> How can I fix this problem?
>> > >
>> > > A regression was introduced 2 or 3 weeks ago in master and you could
>> > > first
>> > > "git bisect" to try to identify the incriminated commit.
>> > >
>> > > Thanks,
>> > >
>> > > Alex
>> > > ___
>> > > 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, Windows, and Code Composer Studio

[Martine Lenders]

Hey Clark,
that sounds something like the path to your make installation isn't
set in the environment variable PATH. I know from the past, that you
can set them somewhere in the system config, but I haven't used
Windows in years and when I did I had it in German, so don't ask me
were exactly (in WinXP you did it like this [1], just add the path to
make to the semicolon-seperated list of the variable PATH [or create
it, if it doesn't exist]). But maybe this hint is enough to give you
some context for a web search to get some more current information.

Cheers,
Martine

[1] https://support.microsoft.com/en-us/kb/310519

2016-06-24 17:50 GMT+02:00 Clark Leach :
> Hello Malo,
> I gather that you are building this as a CCS project rather than an
> "external makefile project"?  I would prefer to build it using the
> "standard" make system so that it fits with the general scheme of things.
>
> So far, I'm having no luck figuring this out.  All I get at this point is
> 'Error: Program "make" not found in PATH".
> Maybe I'd have better luck with Contiki since it is "officially" supported
> by TI.  Though there's not much eveidence to support that...
>
> I'm stuck and need to make progress.
>
> On Fri, Jun 24, 2016 at 5:49 AM, malo  wrote:
>>
>> Hello Clark,
>>
>> I'm happily building/flashing/debugging riot with windows CCS. At the
>> moment have working only some older riot code base build by TI compiler.
>> Have it working with newlib and 20 bits support as well. The problem is that
>> is ugly, since TI compiler does not support naked functions and have to move
>> SP manually at few places.
>> Nevertheless I have 6lowpan host - atmel RF233 attached to msp430f2618
>> with coap server on top working with RPI2 on other side .
>>
>> The plan is to move to GNU compiler and make official 20bits/newlib
>> support. At the mo have msp-exp430f5529lp on my table - that could be nice
>> kit for the official port.
>>
>> I'm not aware of any documents how to build riot with CCS (was not
>> searching that hard) but in general I just took core files one by one and
>> defined few macros to make it happy. After had the core working just added
>> networking and radio driver.
>>
>> wbr
>> malo
>>
>> On 20 June 2016 at 15:59, Clark Leach  wrote:
>>>
>>> Nothing? Really?
>>>
>>> On Tue, Jun 14, 2016 at 2:43 PM, Clark Leach 
>>> wrote:

 I am intersted in developing with RIOT for a few different TI targets
 and have Code Composer Studio installed on Windoze 8.1 which I have used 
 for
 several projects.  Since CCS already has all the tool chains and debugger
 interfaces, it seems like it would make sense to use it for these projects
 as well.

 Is there any hope of making such a configuration work?  Is there any
 guidance available?  I have read the howto on using Eclipse and found the
 information lacking and, at times, incomprehensible (what is a "speaking
 Variable Name", anyways).

 Any feedback would be appreciated.

>>>
>>>
>>> ___
>>> 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] 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 <cenk.guendo...@fu-berlin.de>:

> 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

[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] 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] IoT

[Martine Lenders]

Hi Doni,
A lot of what you asked for can be found in our documentation [1]. For an
introduction of how to use an existing application you can read [2]. To
create an application there is this page [3] and to create a module (a new
functionality for RIOT), there is also information on this [4]. If you have
further questions about the process you can always ask here.

Hope this was helpful,
Martine

[1] http://doc.riot-os.org
[2] http://doc.riot-os.org/getting-started.html
[3] http://doc.riot-os.org/creating-an-application.html
[4] http://doc.riot-os.org/creating-modules.html

2016-02-08 12:17 GMT+01:00 Doni Pradana :

> hello I' am Doni Pradana, i'am student , and i from indonesia..
> I interest using RIOT OS in my project, i wiil build a wireless sensor
> network with 6lowpan based using RIOT OS
> my question is, how to strated  with RIOT OS and how to programming using
> RIOT?? can you tell step by step using RIOT??
> i was read article about RIOT, and do not understand about this..
> honestly, my promamming not fruently 
>
> 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

Re: [riot-devel] Odd problems with xtimer

[Martine Lenders]

Hi,
normally you can guess where the timer came from by looking at the address
(or the debugger straight tells you). Is this somehow possible for your
case (i.e. 0x200010a4)? That might be helpful for the timer people.

Regards,
Martine

2016-02-10 23:08 GMT+01:00 Michael Andersen :

> Hi
>
> Thanks for the reply. I am on a platform essentially equal to a
> samr21xpro.
>
> The short answers:
>  - samr21xpro
> - only one declared xtimer_t object that is used more than once. I use it
> with xtimer_set_msg for a thread to send itself a message. Both the timer
> and the msg object are statically allocated. On the other hand, I have RPL
> and all sorts of network things going and I have no doubt there are a ton
> of timers involved. In terms of ephemeral timers, I call xtimer_usleep a
> LOT with intervals of between 1ms and 100ms from multiple threads. I also
> send packets every 200ms or so and receive them every 500ms or so.
>  -The interrupt load might be pretty steep if the radio is interrupting on
> every packet (promiscuous mode). I don't think it is. Otherwise I would
> imagine that other than the timers it is less than ten per second.
>
> As for memory corruption, that may well be the case. I will double check
> my code. I thought it was somewhat unusual that multiple boards would all
> get a timer pointing to itself, but I suppose not all corruption is
> non-deterministic and they all run identical firmware, so it might be
> corruption.
>
> One question, in the network stacks, are there ever two threads possibly
> using the same timer object? I ask because the timer_remove and the insert
> are in two different critical sections, and if there are concurrent calls
> with the same timer object then it might be possible to interrupt between
> the critical sections and insert a timer that is already in the list. What
> would then happen is that this loop
> 
>  would
> end with list_head equal to the timer (assuming no other timer has the same
> time), and then the next two lines would basically link the timer to itself.
>
> I could be wrong though, that is just a guess.
>
>
> On Wed, Feb 10, 2016 at 2:45 AM, Kaspar Schleiser 
> wrote:
>
>> Hey Michael,
>>
>> On 02/10/2016 07:57 AM, Michael Andersen wrote:
>> > it seems that one of the nodes in the list points to itself, hence the
>> > endless loop.
>> >
>> > My first question is: when is this possible? It seems at first glance
>> > that all code paths that lead here call remove_timer to prevent this
>> > sort of problem.
>> It should not be possible (tm).
>>
>> I took another look at the code, it seems to me that timer->next gets
>> overwritten whenever a timer is set, so there can't be some outdated
>> value.
>>
>> It might be that the list logic has a bug somewhere, but I remember
>> testing them quite rigourously.
>>
>> > I don't access a the same timer object from two
>> > different threads. My code using xtimer functions is not reentered.
>> >
>> > I don't use that many timer operations in my application code, but I do
>> > assume that the following functions don't require any freeing or
>> > removing afterwards, am I wrong?
>> Completely right.
>>
>> Could you tell us more on how you are using timers?
>>
>> Interesting would be things like
>>
>> - what platform are you on
>> - how many timers are simultaneously active
>> - how are the intervals
>> - how is the interrupt load
>>
>> ... that might help corner the issue.
>>
>> You should consider xtimer just showing a problem which might be caused
>> by memory corruption.
>>
>> Kaspar
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT 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] netdev2 - some hints about the relationships between the 6lowpan protocol

[Martine Lenders]

Hi Bernhard,
there was an update to the netdev2 API [1]. Please rebase and adapt your
driver accordingly (4646 is adapted too already).

Best,
Martine

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

2016-02-24 12:36 GMT+01:00 Bernhard Nägele :

> Hello everyone,
> I tried to reproduce the work witch was done in the PR 4646
> (implementation of a netdev2 driver).
> So far I build a structure of directories and files as mentioned in this
> PR.
> But when I try to compile this I got the following message:
>
> "make" -C /c/Users/./RIOT/sys/net/gnrc/link_layer/netdev2
> c:/Users/../RIOT/sys/net/gnrc/link_layer/netdev2/gnrc_netdev2_eth.c:
> In function '_recv':
> c:/Users/../RIOT/sys/net/gnrc/link_layer/netdev2/gnrc_netdev2_eth.c:31:26:
> error: too few arguments to function 'dev->driver->recv'
>  int bytes_expected = dev->driver->recv(dev, NULL, 0);
>   ^
> I think there is a missing statement regarding dependancies that the
> ethernet-file is involked in the build process. Can anyone reproduce this
> behaviour?
>
> Best regards,
>
> Bernhard
> ___
> 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] netdev2 - some hints about the relationships between the 6lowpan protocol

[Martine Lenders]

Hi Bernhard,
that's not what I said: cc11xx is the only *radio* in master. Since netdev2
was introduced around the time we introduced Ethernet, there are also
several Ethernet devices (netdev2_tap, enc28j60, encx24j600) that support
the netdev2 interface. Our IEEE 802.15.4 radios work with the predecessor
of netdev2 that is very similar, but bound to the GNRC stack: gnrc_netdev.
PR 4646 and its dependencies introduce a glue code layer for netdev2 and
GNRC and allows thus for easy porting of gnrc_netdev devices to netdev2
(when it is merged). PR 4646 provides the port for the at86rf2xx radio as
an example.

Hope this was helpful enough. If you have further questions just ask :-)

Best regards,
Martine

2016-02-26 22:04 GMT+01:00 Bernhard Nägele :

> Hello everyone,
> that sounds not goodonly one device in master und one not yet merged!?
>
>
> Best regards,
> Bernhard
> ___
> 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] netdev2 - some hints about the relationships between the 6lowpan protocol

[Martine Lenders]

Hi,
what radio is the nrf24l01p using? The only radio in master currently
implementing netdev2 is the cc11xx driver (all others are either Ethernet
drivers or not merged yet). As stated before: there is a move to port the
IEEE 802.15.4 devices (which are currently implementing the older
GNRC-specific interface gnrc_netdev), starting with PR 4646 [1] (with the
at86rf2xx radio).

Cheers,
Martine

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

2016-02-26 12:43 GMT+01:00 Bernhard Nägele :

> Hello everyone,
> today I compiled the example/gnrc_minimal with the nrf24l01p module
> included in the boards Makefile.dep file (Riot Release package RIOT-2015.12)
> . The compile process was successful and the compiler output show the the
> driver for the radio module was compiled. But when I searched with the
> debugger for driver subroutines, it seems that they are not really linked
> into the result.
> Is there anyone who can explain me where I have to include the driver in
> the makefile-structure (USEMODULES +=) that it will be involked by the
> example-application? In the board makefiles? In the application makefiles?
> Auto-Init? Wherelse?
>
> Thank you very much!
>
>
> Best regards,
> Bernhard
> ___
> 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 <authmille...@gmail.com>:

> 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 <cenk.guendo...@fu-berlin.de>:
>
>> 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] 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] netdev2 - some hints about the relationships between the 6lowpan protocol

[Martine Lenders]

Hi Bernhard,
Have you seen [1] and [2]? Let us know if they are lacking any information
you need.

Since the MRF24J40 is an IEEE 802.15.4 radio I think it's best to look into
my PR 4646 [3], which ports the at86rf2xx driver (currently based on
gnrc_netdev in master) to the stack agnostic netdev2. I introduced a lot of
consolidation of common IEEE 802.15.4 code, making the implementation of
such device drivers simpler than it used to be.

Best regards,
Martine

[1] http://doc.riot-os.org/group__net__gnrc.html#details
[2] http://doc.riot-os.org/group__drivers__netdev__netdev2.html#details
Am 18.02.2016 12:31 schrieb "Bernhard Nägele" :

> Hello everyone,
> I just want to help Tobias in bringing the MRF24J40 radio network driver
> further on.
> 1. Have you got a hint where I can find information how the parts of the
> networking stack fit together - from the radio-module (hardware) up to the
> working
> connection.
> 2. Is there any documentation/specification about the interface between
> those parts?
> 3. As far as I have seen the CC1101 networking device driver is based on
> netdev2. Is
> it a good idea to port this to the MRF24J40?
>
> Best regards
> Bernhard
>
> ___
> 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