Re: [riot-devel] LGPL compliance testing

[Martin]

Hi,

yes, I will provide a diff patch to apply hooks to a closed library 
inside of a core .c file, that must be applied in the build process of 
RIOT to use the shipped library.

The patch and the hooks are of course open source and provided under LGPL.

So, building a specific RIOT version with the applied patch for the 
hooks, linked with the provided library should be equal with the binary 
(If I'm not confusing something)


Best regards,
Martin

On 27.01.2015 08:32, Kaspar Schleiser wrote:

Hey,

On 01/27/15 06:25, Martin wrote:

I will try today how it would be possible to replace and validate when
someone change parts of say the core, not the whole core though.
Well, if you change anything in the core, the resulting binary after 
relinking *will* be different.


Kaspar
___
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] LGPL compliance testing

[Kaspar Schleiser]

Hey,

On 01/27/15 06:25, Martin wrote:

I will try today how it would be possible to replace and validate when
someone change parts of say the core, not the whole core though.
Well, if you change anything in the core, the resulting binary after 
relinking *will* be different.


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

Re: [riot-devel] Hack'n'Ack tomorrow

[Martine Lenders]

Hi,
we'll be there from around 17:00 CET onwards. A route description to c-base
can be found on there website [1]. We'll be in the seminarraum. Just ask
around either for the room or for RIOT. Most people will help you out there.

Cheers,
Martine


[1] https://www.c-base.org/cv50f/core/impressum.html

2015-01-26 19:32 GMT+01:00 Frank Holtz :

> Hello,
>
> my plan is to visit Hack'n'Ack tomorrow. This is the first time i
> visiting c-base. Where/how we can find together?
>
> Regards,
>
> Frank
> ___
> 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] LGPL compliance testing

[Kaspar Schleiser]

Hi,

On 01/26/15 22:46, Hauke Petersen wrote:

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


Well, if your device driver compiles into object files, there's no 
difference to any "application" code. It doesn't matter if you recompile 
the rest of the code and relink. What pin mapping your driver uses 
doesn't matter, either.


If you have to change core RIOT's linkerscript or board defines, you are 
changing LGPLed code and have to share those changes to be LGPL compliant.


Kaspar
___
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 Paul,
the workshop will be held at Freie Universität Berlin and (probably, as far
as I can see from the attendees) HAW Hamburg, simultaneously, but will also
provide the PlaceCam-Link [1] that will connect the two events and allow
for remote participation.

Details for the schedule will be posted in the next few days.

Cheers,

Martine

[1] placecam.de
Am 26.01.2015 19:05 schrieb :

> Is this a webbased meeting or a meeting in Berlin ?.
>
> Paul.
>
> Peter Kietzmann  schreef:
>
>  Hi,
>>
>> I'm fine.
>>
>> Cheers,
>> Peter
>>
>> Am 26.01.2015 um 10:56 schrieb 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 >> >:
>>>
>>>Hi everyone,
>>>
>>>sandwiching the H&A 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"
mailto: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
>>>> wrote:

Hi,

I?d also like to attend. I?d prefer a date without H&A
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
>>>> 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
> -

Re: [riot-devel] LGPL compliance testing

[Martin]

Hi,

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


Best regards,
Martin

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

Nice!

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


Cheers,
Hauke

On 26.01.2015 16:43, Kaspar Schleiser wrote:

Hey guys,

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

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

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


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


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

Kaspar

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

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


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


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

Re: [riot-devel] Iot and machine learning experiment

[David Lyon]

On 2015-01-26 08:00, syed khalid wrote:

  I would like to set up a prototype up to demo IOT integration with
cloud computing and machine learning. Am going to use the RIOT
platform to collect the traffic necessary for the experiment.
  I am hoping to utilize health wearables as a source for this traffic
but really other sources can be used to define and refine the
workflow.   The goal is to first create datasets with health profiles
for use in training and testing as part of machine learning
  My question is 2 fold


That's interesting.

What type of traffic are you interested in?

Are you planning on writing that back to a database?

Regards

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

Re: [riot-devel] LGPL compliance testing

[Hauke Petersen]

Nice!

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


Cheers,
Hauke

On 26.01.2015 16:43, Kaspar Schleiser wrote:

Hey guys,

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

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

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


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


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

Kaspar

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

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


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

Re: [riot-devel] absolute timpanist in vtimer

[Oleg]

Hi Raphael!


> while I see the point of a timer task force, I am not sure I am of great
> help rewriting it. I have no clue how it works besides a bit experience
> with the API.

The first thing we should do before rewriting or even re-designing the timer 
system is collecting the requirements - and for this task, everybody having a 
(concrete) requirement is definitely of great help.

> But if I can help, sure. Are there wiki pages for the
> other task forces?

Not sure. You might look at the wiki pages about the network stack design or 
let inspire yourself by the TinyOS pages (Philipp, can you help with a link 
here?). But as far as I'm concerned: just start with any kind of form, we can 
work on this latter on. The content is much more important.

You could even start an issue in the Github tracker with a checklist or similar.

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

[riot-devel] Hack'n'Ack tomorrow

[Frank Holtz]

Hello,

my plan is to visit Hack'n'Ack tomorrow. This is the first time i
visiting c-base. Where/how we can find together?

Regards,

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

Re: [riot-devel] Network Stack Task Force

[gnupic]

Is this a webbased meeting or a meeting in Berlin ?.

Paul.

Peter Kietzmann  schreef:


Hi,

I'm fine.

Cheers,
Peter

Am 26.01.2015 um 10:56 schrieb 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  
mailto:hauke.peter...@fu-berlin.de>>:


   Hi everyone,

   sandwiching the H&A 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"
   mailto: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
   mailto:thomas.eichin...@fu-berlin.de>> wrote:

   Hi,

   I?d also like to attend. I?d prefer a date without H&A
   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
   mailto: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

   _

Re: [riot-devel] C++11 Support in RIOT

[Hiesgen, Raphael]

Hello,

the features that simply depend on the compiler, such as auto or lambdas, do 
work with a suitable compiler, e.g. the gcc-none-eabi from launchpad [1]. The 
header only part of chrono does work too. As Martin mentioned I am working on 
thread, mutex and condition variable. My current implementation is base on the 
RIOT threads and co. It does not support the full API, but you can find all 
necessary file here [2] with a small example.

It is not part of RIOT for now.

Raphael


[1] https://launchpad.net/gcc-arm-embedded
[2] https://github.com/josephnoir/RIOT/tree/topic/vtimer/tests/cpp_timer


On Jan 26, 2015, at 4:24 PM, Martin 
mailto:martin.landsm...@haw-hamburg.de>> wrote:

Hi Michael,

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

Currently @josephnoir is in the process to provide a bunch of C++11 features to 
RIOT [1]:
Beside other C++11 features `std::thread` [2] is available.

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

Best regards,
Martin

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

On 26.01.2015 15:48, Michael Frey wrote:
Hi,

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

TIA!
 Best,
  Michael

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

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

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

Re: [riot-devel] absolute timpanist in vtimer

[Hiesgen, Raphael]

Hello,

while I see the point of a timer task force, I am not sure I am of great help 
rewriting it. I have no clue how it works besides a bit experience with the 
API. But if I can help, sure. Are there wiki pages for the other task forces?

Raphael




> On Jan 22, 2015, at 1:28 PM, Oleg Hahm  wrote:
> 
> Hi Raphael!
> 
>> I think enabling vtimer to await an absolute point in time would be useful,
>> something like this [1]. Otherwise you end up subtracting the current time
>> and adding it again in vtimer_set.
> 
> I think something like this could indeed be helpful. However, I think we
> should try to collect all the different requirements for the timer system
> somewhere and think about a redesign. Not only that certain features are hard
> or even impossible to achieve with the current hwtimer/vtimer/RTC concept, but
> also the API could be improved and simplified quite a bit - not speaking about
> all the bugs and races in the current implementation.
> 
> All in all, I think it's quite urgent to establish a task force for the timer
> system in a similar fashion like we do for the network stack or OTA, for
> example. Would you be interested to participate in such a task force and maybe
> start already by setting up a wiki page or similar to collect the different
> requirements?
> 
> Cheers,
> Oleg
> -- 
> /*
> * We used to try various strange things. Let's not.
> */
>linux-2.2.16/fs/buffer.c
> ___
> 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] LGPL compliance testing

[Joakim Gebart]

Is RIOT_VERSION the only thing that is automatically generated for each
build?
I mean, if even a build date is included somewhere the result will not
be identical.

I like the idea, however.

Best regards,

Joakim Gebart
Eistec AB
www.eistec.se 

On 01/26/2015 04:43 PM, Kaspar Schleiser wrote:
> Hey guys,
>
> here's an initial draft on how to check for LGPL compliance:
>
> https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide
>
> This is for showing that some proprietary code has been compiled and
> linked with a specific version of RIOT.
>
> I wrote the wiki entry out of my head, so maybe I missed something,
> but the general method worked in prior testing. ;)
>
> Should we go and automate this, or am I missing something?
>
> Kaspar
>
> p.s.: This is in no way any conclusion to the license discussion, see
> it as purely technical please.
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel

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

Re: [riot-devel] LGPL compliance testing

[Kaspar Schleiser]

Hi,

On 01/26/2015 05:36 PM, Joakim Gebart wrote:

Is RIOT_VERSION the only thing that is automatically generated for each
build?

Seems like...


I mean, if even a build date is included somewhere the result will not
be identical.
I tried this on ARM (for the hello-world example) and the resulting 
files had a matching MD5.


Kaspar
___
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 :

> 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

[riot-devel] LGPL compliance testing

[Kaspar Schleiser]

Hey guys,

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

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

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


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


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

Kaspar

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

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

Re: [riot-devel] C++11 Support in RIOT

[Martin]

Hi Michael,

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


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

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

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

Best regards,
Martin

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

On 26.01.2015 15:48, Michael Frey wrote:

Hi,

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

TIA!
  Best,
   Michael

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


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

[riot-devel] C++11 Support in RIOT

[Michael Frey]

Hi,

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

TIA!
 Best,
  Michael

[1] https://gcc.gnu.org/projects/cxx0x.html
-- 
Dipl.-Inf. (FH), M. Sc. Michael Frey
Humboldt-Universität zu Berlin
Department of Computer Science
Rudower Chaussee 25
12489 Berlin, Germany

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

Re: [riot-devel] readline / writeline interface based on periph/uart

[Hauke Petersen]

Oh, forgot -> have a look at the system call _read and _write 
implementations (e.g. for the stm32f0), for the case UART0 is not 
defined, there you got a pretty good template how to implement some 
read/writeline features without using the uart_x_blocking functions


Cheers,
Hauke


On 24.01.2015 22:11, Christian Mehlis wrote:

hi,

is there any readline /writeline implementation based on the 
asynchronous periph/uart implementation?


I want to use the uart in a arduino style and I miss an (blocking) 
interface like:


char buf[100];
int buf_size = 100;
int timeout = 100; //ms
int num_of_bytes = readline(uart, buf, buf_size, timeout);

also

int num_of_bytes_written = writeline(uart, line, line_len, timeout);

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


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

Re: [riot-devel] readline / writeline interface based on periph/uart

[Hauke Petersen]

Hi Christian,

as far as I know it's not in riot directly, but you coult implement it 
in a couple of lines (simplified -> no error handling...):



char buf[100];
int num_of_bytes = readline_stdin(buf, sizeof(buf));
OR
int num_of_bytes = readline(UART_x, buf, sizeof(buf);

int readline_stdin(char *buf, int size) {
int i = 0;
char c;
do {
c = getchar();/** part of stdio.h */
buf[i++] = c;
} while (c == '\n');
return i;
}

int readline(uart_t uart, char *buf, int size) {
int i = 0;
char c;
do {
uart_read_blocking(uart, &c);
buf[i++] = c;
} while (c != '\n');
return i;
}

same for writing...

Cheers,
Hauke


On 24.01.2015 22:11, Christian Mehlis wrote:

hi,

is there any readline /writeline implementation based on the 
asynchronous periph/uart implementation?


I want to use the uart in a arduino style and I miss an (blocking) 
interface like:


char buf[100];
int buf_size = 100;
int timeout = 100; //ms
int num_of_bytes = readline(uart, buf, buf_size, timeout);

also

int num_of_bytes_written = writeline(uart, line, line_len, timeout);

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


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

Re: [riot-devel] New IPC API status

[Kaspar Schleiser]

Hi Adam,

On 01/24/2015 09:49 AM, Adam Hunt wrote:

filesystem/VFS, and maybe ELF loading). Back in November Kaspar
concluded that the approach he had been working on wasn't the correct
way forward and closed the PR.[1] I was wondering, is any further API
work was being done outside the view of the mailing list was being done
on the IPC or was it decided that the current implementation was deemed
good enough for now?


I've done a lot of research on this, with the intention of getting it 
right. My findings so far:


1. the old messaging, as simple as it is, is also very efficient, both 
cyle and memory wise


2. message queues get inefficient when using non fixed-size small messages

I'm currently at my fifth implementation (I've tried different ways to 
implement this), but I fear that the initial idea of having messages 
larger than msg_t will come with a compromise in rom/ram/cyle usage, 
which might be unacceptable.


Stay tuned. ;)

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

Re: [riot-devel] Network Stack Task Force

[Martin]

Hi,

I can probably attend on thursday from afternoon.
Thats bad for me, but I will just squeeze Lotte, Peter and Raphael ;) .
So it okay for me too.

Best regards,
Martin

On 26.01.2015 10:56, Martine Lenders wrote:

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 >:


Hi everyone,

sandwiching the H&A 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"
mailto: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
mailto:thomas.eichin...@fu-berlin.de>> wrote:

Hi,

I’d also like to attend. I’d prefer a date without H&A
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
mailto: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 

Re: [riot-devel] Why RIOT is partner of Ubuntu? (technical cosequences?)

[Jan Wagner]

> Your fears are entirely ungrounded :)
 
haha, why is everyone keep  (except the voices in my head) telling that? 
 
thanks for your clarifications and you replys Ludwig and Emmanuel they exactly
hit the spot ... and now back to the code :]
 

> Ludwig Ortmann  hat am 26. Januar 2015 um 11:22
> geschrieben:
>
>
> Hi Jan,
>
> Your fears are entirely ungrounded :)
>
> First of all, there are no concrete plans or even arrangements as of now.
> From our point of view, RIOT lacks human interfaces (among other things), and
> if Ubuntu snappy apps turn out to be a fitting front end, we will probably
> support it, but not exclusively.
>
> Second, as far add I know Ubuntu is criticized primarily for reasons that have
> to do with decision making.
> RIOT aims to be a proper open source project, so I'm not afraid of Canonical
> taking over the reins or something like that.
>
> We (the core developers) are also in contact/affiliation with several other
> entities (companies and institutes) that have interests in RIOT or which are
> already using/financing/shaping development. (This means the influence of
> financially involved parties is distributed and it will most likely stay this
> way.)
> In this regard: we are currently in the process of creating a legal entity (a
> German Verein) with the goal of catering to both, RIOT's free software and
> financial needs.
>
> Cheers, Ludwig
>
> PS: this is not an official statement, just my personal view on things.
>
> Am 26. Januar 2015 10:42:39 MEZ, schrieb Jan Wagner :
> >Hi devs,
> >
> >dont know if this is right the list - but are there any technical
> >consequences?
> >
> >What does RIOT want from Ubuntu?
> >Are there any technnical plans of cooperation and how should Ubuntu
> >help with
> >that?
> >What is the plan of Ubuntu? - 'market positionig' ? - "just a act pure
> >love?"
> >
> >Beside the critic about Ubuntu that you might know or just google - I
> >clearly
> >ask myself
> >what this heavy commercialized dist want from RIOT?
> >
> >" “ The open Ninja Sphere controller based on Ubuntu Core is a perfect
> >base for
> >building
> >apps that interact with devices and sensors in your home. We look
> >forward to the
> >growth
> >of a new ecosystem of inventors and creators and are delighted to
> >provide them
> >with a blank
> >canvas for their creativity. ”"
> >
> >My fear: Is RIOT is assimilated into a future 'EZ CRAZY COOL NInJA
> >Ubuntu Core"
> >soon?
> >
> >Regards (parnoid)
> >
> >Jan
> >
> >
> >
> >
> >
> >
> >___
> >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] Why RIOT is partner of Ubuntu? (technical cosequences?)

[Emmanuel Baccelli]

Hi Jan,

As far as I understood it, Ubuntu contacted us because they were looking
for expertise on how to communicate with embedded devices which cannot run
Linux.

A low-overhead solution that we suggested for their problem is: RIOT (and
its network stack) runs simultaneously on IoT devices, and as a Linux
process (native port) on whatever box they have in mind. This way, their
communication problem could be solved rather easily.

Such a solution has no substantial consequences for RIOT : development &
maintenance of RIOT's native port and network stack  are anyways part of
the plan, whether or not Ubuntu is interested in using these building
blocks.

Basically: RIOT is a free tool that can be used by anyone, why not by
Ubuntu ;). But as far as I can tell, I don't think we should fear RIOT
becoming Ubuntu-ized.

Best,

Emmanuel



On Mon, Jan 26, 2015 at 10:42 AM, Jan Wagner  wrote:

>   Hi devs,
>
>  dont know if this is right the list - but are there any technical
> consequences?
>
>  What does RIOT want from Ubuntu?
>  Are there any technnical plans of cooperation and how should Ubuntu help
> with that?
>  What is the plan of Ubuntu? - 'market positionig' ? - "just a act pure
> love?"
>
>  Beside the critic about Ubuntu that you might know or just google - I
> clearly ask myself
>  what this heavy commercialized dist want from RIOT?
>
>  " “ The open Ninja Sphere controller based on Ubuntu Core is a perfect
> base for building
>  apps that interact with devices and sensors in your home. We look
> forward to the growth
>  of a new ecosystem of inventors and creators and are delighted to
> provide them with a blank
>  canvas for their creativity. ”"
>
>  My fear: Is RIOT is assimilated into a future 'EZ CRAZY COOL NInJA
> Ubuntu Core" soon?
>
>  Regards (parnoid)
>
>  Jan
>
>
>
>
> ___
> 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] Why RIOT is partner of Ubuntu? (technical cosequences?)

[Ludwig Ortmann]

Hi Jan,

Your fears are entirely ungrounded :)

First of all, there are no concrete plans or even arrangements as of now.
From our point of view, RIOT lacks human interfaces (among other things), and 
if Ubuntu snappy apps turn out to be a fitting front end, we will probably 
support it, but not exclusively.

Second, as far add I know Ubuntu is criticized primarily for reasons that have 
to do with decision making.
RIOT aims to be a proper open source project, so I'm not afraid of Canonical 
taking over the reins or something like that.

We (the core developers) are also in contact/affiliation with several other 
entities (companies and institutes) that have interests in RIOT or which are 
already using/financing/shaping development. (This means the influence of 
financially involved parties is distributed and it will most likely stay this 
way.)
In this regard: we are currently in the process of creating a legal entity (a 
German Verein) with the goal of catering to both, RIOT's free software and 
financial needs.

Cheers, Ludwig

PS: this is not an official  statement, just my personal view on things.

Am 26. Januar 2015 10:42:39 MEZ, schrieb Jan Wagner :
>Hi devs,
> 
>dont know if this is right the list - but are there any technical
>consequences?
> 
>What does RIOT want from Ubuntu?
>Are there any technnical plans of cooperation and how should Ubuntu
>help with
>that?
>What is the plan of Ubuntu? - 'market positionig' ? - "just a act pure
>love?"
> 
>Beside the critic about Ubuntu that you might know or just google - I
>clearly
>ask myself
>what this heavy commercialized dist want from RIOT?
> 
>" “ The open Ninja Sphere controller based on Ubuntu Core is a perfect
>base for
>building
>apps that interact with devices and sensors in your home. We look
>forward to the
>growth
>of a new ecosystem of inventors and creators and are delighted to
>provide them
>with a blank
>canvas for their creativity. ”"
> 
>My fear: Is RIOT is assimilated into a future 'EZ CRAZY COOL NInJA
>Ubuntu Core"
>soon?
> 
>Regards (parnoid)
> 
>Jan
> 
> 
>
>
>
>
>___
>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

[Peter Kietzmann]

Hi,

I'm fine.

Cheers,
Peter

Am 26.01.2015 um 10:56 schrieb 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 >:


Hi everyone,

sandwiching the H&A 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"
mailto: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
mailto:thomas.eichin...@fu-berlin.de>> wrote:

Hi,

I’d also like to attend. I’d prefer a date without H&A
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
mailto: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

   

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 :

>  Hi everyone,
>
> sandwiching the H&A 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 H&A 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 
>>> 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

[riot-devel] Why RIOT is partner of Ubuntu? (technical cosequences?)

[Jan Wagner]

Hi devs,
 
dont know if this is right the list - but are there any technical consequences?
 
What does RIOT want from Ubuntu?
Are there any technnical plans of cooperation and how should Ubuntu help with
that?
What is the plan of Ubuntu? - 'market positionig' ? - "just a act pure love?"
 
Beside the critic about Ubuntu that you might know or just google - I clearly
ask myself
what this heavy commercialized dist want from RIOT?
 
" “ The open Ninja Sphere controller based on Ubuntu Core is a perfect base for
building
apps that interact with devices and sensors in your home. We look forward to the
growth
of a new ecosystem of inventors and creators and are delighted to provide them
with a blank
canvas for their creativity. ”"
 
My fear: Is RIOT is assimilated into a future 'EZ CRAZY COOL NInJA Ubuntu Core"
soon?
 
Regards (parnoid)
 
Jan
 
 
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel