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

[Ludwig Ortmann]

Hi,

apparently there was a copy/paste error, the correct URL is:
http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE-

See
https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation
for instructions on how to participate.

Currently the session is not live due to some technical problem on the
hosting side, though. Keep your fingers crossed ;)

Cheers,
Ludwig

On Tue, Mar 01, 2016 at 05:56:54PM +0100, Oleg Hahm wrote:
> Dear reviewing IOTlers,
> 
> in Berlin we're having an interim Hack'n'ACK session tonight. If someone wants
> to join us remotely, you can do so at
> http://placecam.de/call.php?c=3DVBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE-
> 
> Cheers,
> Oleg
> -- 
> /* We are root, all done! */
> RIOT/sys/net/rpl/rpl.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] samr21-xpro / watr.li ADC

[Ludwig Ortmann]

Hi,

I just noticed that the samr21-xpro still has no ADC support and was
wondering if maybe someone from the watr.li team could upstream their
implementation..?
Or take over the existing PR https://github.com/RIOT-OS/RIOT/pull/2063 ?

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

Re: [riot-devel] RIOT rtos compatibility question

[Ludwig Ortmann]

Hi,

Short answer: no.
Long answer: RIOT is focused on microcontrollers and low power. Therefore it 
probably also has no support for most of the remaining hardware of a system 
that can host a 10gb network controller.

Cheers,
Ludwig

Am 23. Mai 2015 00:31:53 MESZ, schrieb Samuel Hutchinson 
:
>I need to have a 10Gb network connection to my RTOS. Does RIOT have a
>driver for any 10Gb cards?
>
>-Samuel Hutchinson
>Applied Math Coop
>CTF MEG ISL

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

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

[Ludwig Ortmann]

Hi,

Am 12. Mai 2015 20:26:58 MESZ, schrieb Oleg Hahm :
>Hi!
>
>> 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.
>
>Contiki has uIP and RIME, TinyOS has BLIP if I remember correctly. We
>have
>ccn-lite, OpenWSN, and this one.

Isn't ccn-lite using the lower layer(s) (MAC, LLC, driver - correct me if I'm 
wrong) of the old stack and should be upgraded to use the lower layer(s) of the 
new stack? (What about OpenWSN?) Or are those layers not considered part of the 
stack?

>I think we cannot compare to Linux,
>BSD, and
>the like here. They can afford to make different modules somehow
>interoperable
>at cost of memory, we cannot.

As far as I remember, the modularization of the new stack had exactly this as a 
goal.

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

Re: [riot-devel] LPM idle_thread

[Ludwig Ortmann]

Hi,

DEVELHELP should not be used to change the semantics of things.

Cheers,
Ludwig

Am 9. Mai 2015 18:43:36 MESZ, schrieb Oleg Hahm :
>Hi Frank!
>
>> why is LPM_SLEEP or LPM_POWERDOWN is commented out?
>
>I think it's mostly commented out for debugging. Debugging with power
>save
>modes can become really nasty (even printf() debugging).
>
>However, I agree this shouldn't be solved like this. Another case for
>DEVELHELP, maybe?
>
>Cheers,
>Oleg

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

Re: [riot-devel] Fwd: 64bit and multi core support

[Ludwig Ortmann]

Hi Alex,

RIOT does not offer either.

When I first wrote the native platform, I tried to support 64 bit but there 
were so many issues that I just chose to ignore it as there were no 64 bit 
platforms on the roadmap anyways.
Since then two things changed:
First, much work has gone into making integer types more explicit. Second, the 
native platform is relatively stable and offers valgrind support, so I think it 
could be used to make RIOT 64 bit safe relatively quickly.

As for the scheduler - I'm not aware of any attempts at multicore support, but 
RIOT is very modular, so the scheduler could be changed/replaced with little 
trouble.

Cheers,
Ludwig


Am 7. Mai 2015 20:33:41 MESZ, schrieb Alex Mavrin :
>Dear RIOT team,
>
>
>Thanks for RIOT I personally think it is GREAT!
>
>We are considering using RIOT on our ARM v8 64bit multicore (SMP)
>hardware.
>The platform requires 64bit memory addressing (DDR is at higher than
>32bit
>address range). We would appreciate if you could help us understand if
>using RIOT is feasible by answering below questions:
>
>   1. Does RIOT support 64bit memory addressing? For example if I build
>“hello-world” sample project on native platform then 32bit binary
>generated. Is it possible to build it for 64bit? Have this been tested?
>
>
>  2. Does RIOT support multi core? I.e. scheduling threads on different
>cores, synchronizing threads running on different cores? Have this been
>done before?
>
>
>Best Regards,
>
>
>Alex

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

Re: [riot-devel] help

[Ludwig Ortmann]

Hi,

This is often called "firmware update" or "OTA" for "(firmware) over the air".

We don't have support for this yet, but it is planned, and there is some 
information in the wiki (look for "OTA").

Cheers,
Ludwig

Am 8. Mai 2015 00:50:30 MESZ, schrieb Sonda Bousnina :
>Hi,
>Thanks for your quick reply
>yes exactly, that what I mean
>
>On Fri, May 8, 2015 at 12:35 AM, Kaspar Schleiser 
>wrote:
>
>> Hi,
>>
>> On 05/08/15 00:23, Sonda Bousnina wrote:
>> > I'm wondering if it is possible to flash or update the code in the
>target
>> > board in real time while it is working without switching it off.
>> Not sure I understand the question.
>>
>> You mean, add/replace code while the device is running?
>>
>> Are you referring to updating the device in the field?
>>
>> 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] ISL29125

[Ludwig Ortmann]

Too late, I already opened a PR.
But no worries, of course I saw and evaluated your driver, the sensors are 
highly incompatible. I recycled some documentation/header strings only..

Cheers, Ludwig

Am 4. Mai 2015 15:52:48 MESZ, schrieb Hauke Petersen 
:
>Hi,
>
>once I wrote the I2C driver for the ISL29020, though I have no idea
>what 
>the differences between these sensors are... But maybe you can re-use
>code?
>
>Cheers,
>Hauke
>
>
>On 01.05.2015 16:07, Ludwig Ortmann wrote:
>> Hi,
>>
>> I just started working on a driver implementation for the ISL29125
>RGB
>> light sensor. In case anyone has worked on it already: please speak
>up
>> now ;)
>>
>> Cheers, Ludwig
>> ___
>> 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] NSTF - Naming the stack

[Ludwig Ortmann]

Hi,

On Sat, May 02, 2015 at 05:12:55PM +0200, Oleg Hahm wrote:
> After thinking just for some minutes over a new name for the stack, I thought
> that "NG" (pronounced Angie? ;)) may be not a bad idea after all and would
> save us from quite some renaming... All we would have to do then is to extract
> the common functionality and move it generic IPv6 and co. files.
> 
> 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.

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.

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

Re: [riot-devel] Skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc.a when searching for -lgcc

[Ludwig Ortmann]

Hi,

we are already discussing this in IRC, the problem was missing 32 bit
toolchain support.

Cheers, Ludwig

On Fri, May 01, 2015 at 05:20:50PM +0200, Drasko DRASKOVIC wrote:
> Hi all,
> just downloaded RIOT and I am trying hello-world example build on my
> Debian machine:
> 
> drasko@Lenin:~/riot/examples/hello-world$ make
> Building application "hello-world" for "native" with MCU "native".
> 
> "make" -C /home/drasko/riot/boards/native
> "make" -C /home/drasko/riot/boards/native/drivers
> "make" -C /home/drasko/riot/core
> "make" -C /home/drasko/riot/cpu/native
> "make" -C /home/drasko/riot/cpu/native/periph
> "make" -C /home/drasko/riot/drivers
> "make" -C /home/drasko/riot/sys
> "make" -C /home/drasko/riot/sys/auto_init
> /usr/bin/ld: skipping incompatible
> /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc.a when searching for -lgcc
> /usr/bin/ld: cannot find -lgcc
> /usr/bin/ld: skipping incompatible
> /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_s.so when searching for
> -lgcc_s
> /usr/bin/ld: cannot find -lgcc_s
> collect2: error: ld returned 1 exit status
> /home/drasko/riot/examples/hello-world/../../Makefile.include:175:
> recipe for target 'all' failed
> make: *** [all] Error 1
> 
> Is there any particular reason why these libraries would be incompatible?
> 
> Also, how to get verbose Make? I tried make V=1 and make V=s, do not work.
> 
> BR,
> Drasko
> ___
> 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] ISL29125

[Ludwig Ortmann]

Hi,

I just started working on a driver implementation for the ISL29125 RGB
light sensor. In case anyone has worked on it already: please speak up
now ;)

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

Re: [riot-devel] ENABLE_DEBUG per module?

[Ludwig Ortmann]

On Tue, Apr 21, 2015 at 01:52:38PM +0200, Kaspar Schleiser wrote:
> Hi,
> 
> On 04/21/15 13:36, Martine Lenders wrote:
> >(one can still add the `#define ENABLE_DEBUG (1)` before the debug.h
> >include) - the need for that.
> >
> >But it does treat core/ as one module, right?
> >
> >Yes, because it is (at least in our current build system logic).
> So we can't merge it without making core debugging practically useless...

You still can enable debugging on a per file base.

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

Re: [riot-devel] Task force ping

[Ludwig Ortmann]

Hi,

Kaspar Schleiser schrieb:
> Every task force: please give a short status update.

OTA/Firmware upgrade: stalled (at least I'm not aware of any activity)

Cheers,
Ludwig

___
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)

[Ludwig Ortmann]

Hi,

I updated the calendar entry.

Cheers,
Ludwig

Am 8. April 2015 08:07:40 MESZ, schrieb Oleg Hahm :
>Hi!
>
>Ok, then let's have the meeting at 2pm CEST from _today_.
>
>Cheers,
>Oleg
>
>On Wed, Apr 08, 2015 at 03:36:37AM +0200, Philipp Rosenkranz wrote:
>> Hi,
>> 
>> I am also for that change (even though I won't be able to join the
>meeting
>> today)
>> 
>> Best,
>> Philipp
>> 
>> 2015-04-07 20:24 GMT+02:00 Martine Lenders :
>> 
>> > Hi,
>> > in general I prefer 2pm, but tomorrow I'm not able to attend at
>this time.
>> >
>> > Cheers,
>> > Martine
>> > Am 07.04.2015 10:08 schrieb "Oleg Hahm" :
>> >
>> >> Hi,
>> >>
>> >> anyone opposed to permanently rescheduling this call to 2pm CEST?
>> >>
>> >> Cheers,
>> >> Oleg
>> >>
>> >> On Tue, Apr 07, 2015 at 08:00:13AM +, Google Calendar wrote:
>> >> > This is a notification for:
>> >> >
>> >> > Title: Biweekly virtual meeting
>> >> > Developer discussions. Remote participation will be provided.
>> >> > When: Every 2 weeks from 10am to 11am on Wednesday Berlin
>> >> > Calendar: RIOT Events
>> >> > Who:
>> >> > * Ludwig Ortmann - creator
>> >> >
>> >> > Event details:
>> >>
>https://www.google.com/calendar/event?action=VIEW&eid=anBwMXUyaXZsdWVkOHFkdHA1MGpzYjFzZ2sgazNxbDhzZXR2N2w0OG9mbm9sMHRmdXU2dHNAZw
>> >> >
>> >> > Invitation from Google Calendar:
>https://www.google.com/calendar/
>> >> >
>> >> > You are receiving this email at the account
>peterschme...@gmail.com
>> >> because
>> >> > you are subscribed for notifications on calendar RIOT Events.
>> >> >
>> >> > To stop receiving these emails, please log in to
>> >> > https://www.google.com/calendar/ and change your notification
>settings
>> >> for
>> >> > this calendar.
>> >>
>> >> > ___
>> >> > devel mailing list
>> >> > devel@riot-os.org
>> >> > https://lists.riot-os.org/mailman/listinfo/devel
>> >>
>> >>
>> >> --
>> >> printk("%s: TDR is ga-ga (status %04x)\n", ...);
>> >> linux-2.6.6/drivers/net/eexpress.c
>> >>
>> >> ___
>> >> devel mailing list
>> >> devel@riot-os.org
>> >> https://lists.riot-os.org/mailman/listinfo/devel
>> >>
>> >>
>> > ___
>> > devel mailing list
>> > devel@riot-os.org
>> > https://lists.riot-os.org/mailman/listinfo/devel
>> >
>> >
>
>> ___
>> 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] CC2538dk support

[Ludwig Ortmann]

Hi Andre,

as far as I see, the radio support is still in PR state (and in need of
work):
https://github.com/RIOT-OS/RIOT/pull/2198

Cheers,
Ludwig

Andre Guedes schrieb:
> Hi all,
>
> I can see from RIOT wiki that CC2538dk board is supported, but I
> couldn't find any information about its networking support.
>
> So could anyone confirm that networking pieces (e.g. radio, 6lowpan) are
> properly working in CC2538dk board?
>
> Thanks,
>
> Andre
> ___
> 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] EZR32LG

[Ludwig Ortmann]

Dear RIOTers,

I just found these Silicon Labs EZRadio Transceiver / EZR32 SOC families
and was wondering if any of you already had experience with any of them:

http://www.silabs.com/products/wireless/wirelessmcu/Pages/default.aspx#ezr32

http://www.silabs.com/products/wireless/EZRadio/Pages/default.aspx
http://www.silabs.com/products/wireless/EZRadioPRO/Pages/default.aspx

Cheers,
Ludwig

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

Re: [riot-devel] Cross Compilation

[Ludwig Ortmann]

Hi Maxence,

You need to figure out if the ucontext API is available on the target 
platform/architecture, translate the functions in tramp.S and add MIPS register 
access in irq_cpu.c.

Cheers, Ludwig

Am 28. März 2015 11:58:35 MEZ, schrieb Maxence Chotard 
:
>Ok thank you for your answer Ludwig. I am going to try to port native
>on mips architecture. 
>
>Cheers,
>Maxence
>
>-Message d'origine-
>De : devel [mailto:devel-boun...@riot-os.org] De la part de Ludwig
>Ortmann
>Envoyé : samedi 28 mars 2015 02:52
>À : RIOT OS kernel developers
>Objet : Re: [riot-devel] Cross Compilation
>
>If you want to run the RIOT hardware emulator "native" as a Linux
>process on the MIPS architecture, you have to port it to this
>architecture first.
>Native has some some assembler lines which are only written for x86 and
>arm as of now.
>
>Cheers, Ludwig
>
>Am 28. März 2015 00:53:54 MEZ, schrieb Maxence Chotard
>:
>>Ludwig, do you mean that I can't compile RIOT with a mips toolchain 
>>adapted to my openwrt version and to my hardware platform ?
>>
>>Cheers,
>>Maxence
>>
>>-Message d'origine-
>>De : devel [mailto:devel-boun...@riot-os.org] De la part de Ludwig 
>>Ortmann Envoyé : vendredi 27 mars 2015 17:04 À : RIOT OS kernel 
>>developers Objet : Re: [riot-devel] Cross Compilation
>>
>>Hi,
>>
>>RIOT native does not currently run on MIPS anyways.
>>
>>Cheers, Ludwig
>>
>>Am 27. März 2015 16:04:56 MEZ, schrieb Maxence Chotard
>>:
>>>Hello,
>>>
>>>Is there anybody who knows how to cross compile hello-world example
>on
>>
>>>RIOT for an openwrt distribution, which is using a MIPS architecture
>?
>>>
>>>Cheers,
>>>Maxence
>>>
>>>___
>>>devel mailing list
>>>devel@riot-os.org
>>>https://lists.riot-os.org/mailman/listinfo/devel
>>
>>___
>>devel mailing list
>>devel@riot-os.org
>>https://lists.riot-os.org/mailman/listinfo/devel
>>
>>___
>>devel mailing list
>>devel@riot-os.org
>>https://lists.riot-os.org/mailman/listinfo/devel
>
>___
>devel mailing list
>devel@riot-os.org
>https://lists.riot-os.org/mailman/listinfo/devel
>
>___
>devel mailing list
>devel@riot-os.org
>https://lists.riot-os.org/mailman/listinfo/devel

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

Re: [riot-devel] Cross Compilation

[Ludwig Ortmann]

If you want to run the RIOT hardware emulator "native" as a Linux process on 
the MIPS architecture, you have to port it to this architecture first.
Native has some some assembler lines which are only written for x86 and arm as 
of now.

Cheers, Ludwig

Am 28. März 2015 00:53:54 MEZ, schrieb Maxence Chotard 
:
>Ludwig, do you mean that I can't compile RIOT with a mips toolchain
>adapted to my openwrt version and to my hardware platform ? 
>
>Cheers,
>Maxence
>
>-Message d'origine-
>De : devel [mailto:devel-boun...@riot-os.org] De la part de Ludwig
>Ortmann
>Envoyé : vendredi 27 mars 2015 17:04
>À : RIOT OS kernel developers
>Objet : Re: [riot-devel] Cross Compilation
>
>Hi,
>
>RIOT native does not currently run on MIPS anyways.
>
>Cheers, Ludwig
>
>Am 27. März 2015 16:04:56 MEZ, schrieb Maxence Chotard
>:
>>Hello,
>>
>>Is there anybody who knows how to cross compile hello-world example on
>
>>RIOT for an openwrt distribution, which is using a MIPS architecture ?
>>
>>Cheers,
>>Maxence
>>
>>___
>>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] Cross Compilation

[Ludwig Ortmann]

Hi,

RIOT native does not currently run on MIPS anyways.

Cheers, Ludwig

Am 27. März 2015 16:04:56 MEZ, schrieb Maxence Chotard 
:
>Hello,
>
>Is there anybody who knows how to cross compile hello-world example on
>RIOT
>for an openwrt distribution, which is using a MIPS architecture ?
>
>Cheers,
>Maxence 
>
>___
>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] Wakaama & LWM2M

[Ludwig Ortmann]

Hi,

are they willing to support this endeavor in the form of a license change?

Cheers, Ludwig

Emmanuel Baccelli schrieb:
> Hi everyone,
>
> I was recently in contact with Wakaama [1] community (part of the Eclipse
> IoT foundation), and which maintains an open source implementation of
> LWM2M.
>
> More to the point, they told me that the code base [3] is deprecated (it
> was their repo prior to joining Eclipse), and that their supported
> codebase
> is now [2].
>
> They would be very happy if their implementation would be ported to RIOT,
> and would provide some support for that (they suggest whoever is
> interested
> in that contacts them through [4]).
>
> I thought this information may be of interest for us, and in particular
> for
> GSoC project proposals on this topic.
>
> Best,
>
> Emmanuel
>
> [1] http://eclipse.org/proposals/technology.liblwm2m/
> [2] https://github.com/eclipse/wakaama
> [3] https://github.com/01org/liblwm2m
> [4] https://dev.eclipse.org/mailman/listinfo/wakaama-dev
> ___
> 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 Software Update

[Ludwig Ortmann]

Hi,

Yes, I think (and wrote in a separate mail in this thread already): working 
groups for different distribution implementations should be created by people 
who are interested in those.
If it helps preventing confusion I'm happy with renaming the first iteration to 
whatever you suggest, or "OTA/FAF" (firmware activation framework).

Cheers, Ludwig

Am 24. März 2015 19:10:36 MEZ, schrieb Oleg Hahm :
>Hi Ludwig!
>
>> yes, we agreed that in order to get software updates we need a
>foundation
>> for activating new firmware images first.
>> The working assumption for the first incarnation/iteration of this is
>that
>> an image has been saved to some memory of the device already.
>
>Okay, basically my question was: do the OTA task force wants to work on
>the
>actual update distribution mechanisms (including security) in a second
>step or
>would it make more sense trying to charter a task force that works on
>this in
>parallel? (If the latter, I would recommend to rename it.)
>
>Cheers,
>Oleg

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

Re: [riot-devel] Riot Software Update

[Ludwig Ortmann]

Hi,

yes, we agreed that in order to get software updates we need a foundation
for activating new firmware images first.
The working assumption for the first incarnation/iteration of this is that
an image has been saved to some memory of the device already.

Cheers,
Ludwig

Oleg Hahm schrieb:
> Hi!
>
>> I see the upgrade distribution process as mostly independent from the
>> software infrastructure needed to activate new images.
>
> Do I get this right, that the OTA task force is excluding the OTA part of
> the
> software update from their work? Or are you just considering the single
> hop
> case?
>
> Cheers,
> Oleg
> --
> My computer is so slow that sometimes it gets a timeout from
> http://localhost.
> ___
> 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 Software Update

[Ludwig Ortmann]

Hi,

I see the upgrade distribution process as mostly independent from the
software infrastructure needed to activate new images.
Also, there are probably several ways to do this right (depending on the
requirements, environment, ...), so there will be no single best
distribution model.
In this sense: Knock yourselves out and create working groups for your
respective favorite protocols!

Cheers,
Ludwig

Cédric Adjih schrieb:
>   Hello,
>
>   Indeed, that presentation was rather interesting.
> and secure updates indeed as part of security;
>
> Looking at the OTA, the discussions are "excluding
> network protocol", so maybe one step in that direction
> would be to have some secure protocol for sending them ?
>
> Is there something already envisionned ?
>
> best regards,
> -- Cedric
>
> - Original Message -
> | From: "Thomas C. Schmidt" 
> | To: "RIOT OS kernel developers" 
> | Sent: Tuesday, March 24, 2015 10:01:01 AM
> | Subject: [riot-devel] Riot Software Update
> |
> | Hi,
> |
> | yesterday in the IAB technical plenary, Hannes Tschofening stressed
> | the
> | need for system software maintenance. This raises the question: Have
> | we
> | spent enough thoughts on automated secure software updates for RIOT,
> | are
> | we approaching this subject?
> |
> | It might be some thing worth while considering??
> |
> | Cheers,
> |   Thomas
> | --
> |
> | Prof. Dr. Thomas C. Schmidt
> | ° Hamburg University of Applied Sciences   Berliner
> | Tor 7 °
> | ° Dept. Informatik, Internet Technologies Group20099 Hamburg,
> | Germany °
> | ° http://www.haw-hamburg.de/inet   Fon:
> | +49-40-42875-8452 °
> | ° http://www.informatik.haw-hamburg.de/~schmidtFax:
> | +49-40-42875-8409 °
> __
> | 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] OTA meetup 11.2.2015

[Ludwig Ortmann]

Hi,

I'm not familiar with the LWM2M specifications, but the everything
that has to do with mechanisms for upgrade availability detection,
downloading etc have been excluded so far.
It is excluded precisely because there are way too many right ways to do
this.
We agreed that we need to build an infrastructure that supports
activating a downloaded image first, before we can go ahead and
implement specific update management facilities on top of this
infrastructure.

Cheers,
Ludwig


On Sun, Mar 22, 2015 at 07:06:09PM +0100, Emmanuel Baccelli wrote:
> Hi everyone,
> 
> reading the minutes from the OTA workforce meeting [1], it's not obvious
> what the position is with respect to the mechanism OMA LWM2M specified for
> firmware updates. Is it planned to use this spec as base for some of the
> mechanisms we need? If not, why? If yes, let's clearly separate the
> mechanisms that we need/plan which are not specified by LWM2M.
> 
> Best,
> 
> Emmanuel
> 
> [1] https://github.com/RIOT-OS/RIOT/wiki/minutes-OTA-meetup-13.2.2015
> 
> On Tue, Mar 17, 2015 at 4:14 PM, Baptiste Clenet 
> wrote:
> 
> > Hi Ludwig,
> >
> > That's fine :-)
> > Great! I'm looking forward to seeing it.
> > I'm not on a early deadline but you know the sooner it is, the better it
> > will be ;-)
> >
> > Cheers,
> >
> > 2015-03-17 15:45 GMT+01:00 Ludwig Ortmann :
> >
> >> Hi Baptiste,
> >>
> >> I was/am extremely busy with non-RIOT work, so please bear with me ;)
> >> An update will follow soonish.
> >>
> >> If you're on a deadline say so and I can look if I can squeeze it in
> >> somehow.
> >>
> >> Cheers,
> >> Ludwig
> >>
> >> Baptiste Clenet schrieb:
> >> > Arvid, Ludwig, any improvements concerning OTA?
> >> >
> >> > Cheers,
> >> >
> >> >
> >> >
> >> > 2015-03-09 15:12 GMT+01:00 Baptiste Clenet :
> >> >
> >> >> Hi,
> >> >>
> >> >> Ludwig, how is the planning going ?
> >> >> Could you create a wiki page (like [1]) or an issue (like [2])  with
> >> >> description of the work to do as well as assignment for each task?
> >> >> Everybody will know how it is going then.
> >> >> What do you think about it?
> >> >>
> >> >> Cheers,
> >> >>
> >> >> [1] https://github.com/RIOT-OS/RIOT/wiki/Timer-Task-Force
> >> >> [2] https://github.com/RIOT-OS/RIOT/issues/2278#issuecomment-73411503
> >> >>
> >> >> 2015-02-22 10:35 GMT+01:00 Ludwig Ortmann  >> >:
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> On Mon, Feb 16, 2015 at 06:41:05PM +0100, Oleg Hahm wrote:
> >> >>> > > the minutes from the meeting have been added to our wiki:
> >> >>> > > https://github.com/RIOT-OS/RIOT/wiki/minutes-OTA-meetup-13.2.2015
> >> >>> >
> >> >>> > Have there any concrete next steps been identified? Did you conclude
> >> >>> in
> >> >>> some
> >> >>> > kind of a schedule for upcoming tasks and who is gonna work on what?
> >> >>>
> >> >>> There has been some preliminary scheduling, we will announce more
> >> >>> concrete planning soon, possibly in the form of an issue.
> >> >>>
> >> >>> Cheers, Ludwig
> >> >>> ___
> >> >>> devel mailing list
> >> >>> devel@riot-os.org
> >> >>> http://lists.riot-os.org/mailman/listinfo/devel
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> *Clenet Baptiste*
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> >
> >> > *Clenet BaptisteFR: +33 6 29 73 05 39*
> >> > ___
> >> > 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
> >>
> >
> >
> >
> > --
> >
> > *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
> de...@lists.stillroot.org
> https://lists.stillroot.org/mailman/listinfo/devel

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

[riot-devel] Nucleo L1 Wiki article renamed

[Ludwig Ortmann]

Hi,

in case anyone wonders what happened to the Wiki entry;
https://github.com/RIOT-OS/RIOT/wiki/Board%3A-ST-nucleo-l1

I renamed it to
https://github.com/RIOT-OS/RIOT/wiki/Board:-Nucleo-L1
in order to match the naming scheme of the other Nucleo boards.

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

Re: [riot-devel] Benchmarks

[Ludwig Ortmann]

Hi,

I think our only m0+/802.15.4 board is the samr21-xpro and there are problems 
with the current/old network stack because of its memory demands.
That said: which  protocol on top of IP are you interested in?
I assume you want to ignore RPL and any other side-tasks for this evaluation?

Cheers,
Ludwig

Am 17. März 2015 17:46:52 MEZ, schrieb Simon Vincent :
>Hi Craig,
>
>We have a 802.15.4 transceiver that is capable of 250kbps. We are 
>thinking of using this with a Cortex M0+ but wanted to make sure that 
>the M0+ would have the processing power to handle the 
>802.15.4/6lowpan/ipv6 stack at a datarate of 250kbps.
>
>I just wondered if anyone had done any datarate measurements on
>existing 
>development boards using the Cortex M0+?
>
>- Simon
>
>On 17/03/15 16:20, Craig Younkins wrote:
>> Hi Simon,
>>
>> Throughput will be highly dependent upon the RF environment and what 
>> transceiver you are using. The M0+ most likely has enough power to do
>
>> it under ideal conditions, but retransmissions due to collisions will
>
>> limit the effective bandwidth.
>>
>> You can use 900 mhz and 2.4 ghz transceivers with 15.4. ~900 is 
>> significantly less crowded but lower theoretical bandwidth. The Atmel
>
>> 212B is 900 Mhz and specs 1000 kbps as the max air data rate.
>>
>> Which transceiver are you using?
>>
>> Craig Younkins
>>
>> On Tue, Mar 17, 2015 at 11:42 AM, Simon Vincent 
>> mailto:simon.vinc...@xsilon.com>> wrote:
>>
>> Has anyone done any performance tests to see what throughput can
>> be achieved using RIOT?
>>
>> I would be interested to know if the Cortex M0+ is powerful
>enough
>> to sustain 250Kb/s TCP over 6lowpan/802.15.4.
>>
>> Does RIOT have any mechanism to measure CPU usage?
>>
>> - Simon
>> ___
>> 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 list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] OTA meetup 11.2.2015

[Ludwig Ortmann]

Hi Baptiste,

I was/am extremely busy with non-RIOT work, so please bear with me ;)
An update will follow soonish.

If you're on a deadline say so and I can look if I can squeeze it in somehow.

Cheers,
Ludwig

Baptiste Clenet schrieb:
> Arvid, Ludwig, any improvements concerning OTA?
>
> Cheers,
>
>
>
> 2015-03-09 15:12 GMT+01:00 Baptiste Clenet :
>
>> Hi,
>>
>> Ludwig, how is the planning going ?
>> Could you create a wiki page (like [1]) or an issue (like [2])  with
>> description of the work to do as well as assignment for each task?
>> Everybody will know how it is going then.
>> What do you think about it?
>>
>> Cheers,
>>
>> [1] https://github.com/RIOT-OS/RIOT/wiki/Timer-Task-Force
>> [2] https://github.com/RIOT-OS/RIOT/issues/2278#issuecomment-73411503
>>
>> 2015-02-22 10:35 GMT+01:00 Ludwig Ortmann :
>>
>>> Hi,
>>>
>>> On Mon, Feb 16, 2015 at 06:41:05PM +0100, Oleg Hahm wrote:
>>> > > the minutes from the meeting have been added to our wiki:
>>> > > https://github.com/RIOT-OS/RIOT/wiki/minutes-OTA-meetup-13.2.2015
>>> >
>>> > Have there any concrete next steps been identified? Did you conclude
>>> in
>>> some
>>> > kind of a schedule for upcoming tasks and who is gonna work on what?
>>>
>>> There has been some preliminary scheduling, we will announce more
>>> concrete planning soon, possibly in the form of an issue.
>>>
>>> Cheers, Ludwig
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> http://lists.riot-os.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>> *Clenet Baptiste*
>>
>>
>
>
> --
>
> *Clenet BaptisteFR: +33 6 29 73 05 39*
> ___
> 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] GSoC 2015 Introduction - N1 BLE Project

[Ludwig Ortmann]

Hi Alexis,

You don't necessarily need to implement everything from scratch.
Maybe you can find parts of the BLE stack implemented under a
compatible license somewhere.

Cheers,
Ludwig

Am 16. März 2015 10:13:15 MEZ, schrieb Alexis DUQUE :
>HI RIOT Developers !
>
>I'm Alexis, from Lyon, France, student in Telecom Engineering.
>I'm fond of IoT, embedded development, FOS Projects,  and
>I'm currently doing a master thesis in Barcelona, wich focus on Thread
>(
>http://www.threadgroup.org/) protocols stack.
>
>I will be really interested to take part of RIOT community as
>developer,
>starting working on BLE Project.
>Even if I've no experience with RIOT development (I just use it on
>MSP430)
>, I well know BLE at different level of the stack : I've worked on
>Nordic
>nrf1822 eval board, nrf8001 with Arduino, Android API, and Bluez driver
>on
>Unix system.
>Obviously, I'm familiar with C/C++ and embedded development, on
>different
>platforms such as Arduino, STM32L0, MSP430 or M2M Gateways (arm poky
>toolchain with Yocto builded distro).
>
>As this is just an introduction and presentation post, I've not yet
>technical questions (but they will come :-) ) But if can someone
>introduce
>me the community, core developers, processes, to know you a bit more,
>that
>will be great !
>Some questions: When are next virtual meeting, or call (18/03) ? the
>next
>Hack'n'ACK (26/03)?
>Who is the potential mentor for N1 BLE project (or the dev that best
>known
>RIOT network implementation) ?
>In my point of view, implementing complete BLE stack is a huge work for
>4
>month project. What do you think about that ? Which is the priority
>(central, peripheral roles) ? For you, what's better for the community
>:
>unachieved work on bigger project, or reduced but well tested and
>documented keys functionalities ?
>
>To conclude, I've participated (with success :-)) on GSoC2014 with
>OpenMRS (
>openmrs.org) on Atlas project. And I'm currently the lead dev and
>maintainer of OpenMRS Atlas server (atlas.openmrs.org), and OpenMRS
>Atlas
>Module (https://dev.openmrs.org/#/show/atlas/).
>
>Cheers,
>
>Alexis DUQUE
>
>
>
>
>___
>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] Fwd: Need help about RIOT radio communicate example

[Ludwig Ortmann]

Hi Chen,

How exactly does the example not work?
Or the other way around: what does work?

Cheers, Ludwig

Am 12. März 2015 16:31:55 MEZ, schrieb Chen Xie :
>Hi,
>
>  I'm a USC(University of Southern California) student. and I'm new to
>RIOT and I have a project based on RIOT.
>  Firstly, I want to make 2 TelosB boards(Sky Tmote) talk through radio
>(CC2420).
>I tried to use default example, but it seems do not work. I am not sure
>which part goes wrong.
>  I searched several days, and no radio examples found.
>Do you have examples related to radio communication? No shell related
>is
>better. Can you help?
>
>  Thanks for your attention.
>
> Best,
> Chen
>
>
>
>
>___
>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] GSoC'15 project

[Ludwig Ortmann]

Hi Prudhvee,

What kind of help do you need?

The specifications of both technologies are open, so you can get familiar with 
those.
The RIOT sources are open and documented as well.
The wiki and issue tracker contain information about current work on the 
network stack (look out for "network stack task force").

Cheers, Ludwig


Am 13. März 2015 02:26:36 MEZ, schrieb Prudhvee Narasimha Sadha 
:
>Hi,
>  My name is Prudhvee Narasimha. I'm an undergraduate student
>in National Institute of Technology, India.
>
>   My interest lies in OS and Networking Concepts and their
>programming in UNIX environment. I have gone through the ideas page of
>RIOT. The projects "Project N2: Implementation of LwM2M" and "Project
>N1: Support for Bluetooth Low Energy aka Bluetooth Smart".
>
>Project N1: Support for Bluetooth Low Energy aka Bluetooth Smart
>
> I'm a learning at work type student. Right now, I am a
>novice programmer for application level programming. But, I promise to
>work dedicatedly towards my project with my best. Regarding, Bluetooth
>Low Energy, I had gone through the web about this and learned
>somethings about it and I'm interested in working to reduce the power
>consumption using Bluetooth Smart.
>
>Project N2: Implementation of LwM2M
>
>   I had gone through web about LwM2M, it is Light Weight
>Member 2 member protocol.  liblwm2m is an implementation of the Open
>Mobile Alliance's LightWeight M2Mprotocol (LWM2M). We can base our
>work on this or we can code from scratch depending on the seniors
>decision on optimization or ease.
>
> I'm willing to work in either of the projects but priorly, Project N2.
>
> I will be very much thankful and grateful if you would
>provide me with the necessary resources and information on
>contributing to these projects.
>
>
> As of my experience to RIOT, I'm a novice. I installed RIOT
>in my UBUNTU 14.04. Completed my first newbie project  and hacking the
>source code.
>
> Awaiting your response and thanks in advance for reading my
>mail and helping me.
>
>Thanks,
>Prudhvee
>___
>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 N2- BLE stack - GSoc 2015

[Ludwig Ortmann]

Hi Kausthub,

What exactly do you want to know?

Cheers, Ludwig

Am 16. März 2015 02:31:04 MEZ, schrieb Kausthub Naarayan 
:
>Hi all,
>I am currently trying for the network project that is : implementing
>BLE
>stack for RIOT .
>After doing a bit of searching a found out that I need to implement GAP
>and
>GATT protocol and HCI protocol to implement this project !
>But I do not know how to proceed further in terms of coding these !
>Please
>help !
>Thanks in advance
>
>Regards
>Kausthub Naarayan
>
>
>
>
>___
>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] IRC channel #riot-os

[Ludwig Ortmann]

Hi,

Also, please keep in mind that most people in our IRC channel live in timezones 
close to CET.

Cheers, Ludwig

Am 7. März 2015 22:07:03 MEZ, schrieb Martine Lenders :
>Hi,
>Normally there are 20-30 people online with varying activity. Make sure
>you
>chose the correct server (irc.freenode.net) and the correct channel
>(#riot-os).
>
>Kind Regards,
>Martine
>
>
>2015-03-07 21:54 GMT+01:00 David Reinert :
>
>> Hello all, I've been trying to find people on the IRC channel on
>freenode
>> but so far the last few times I've logged on there has not been
>anyone else
>> on. Is there a specific time to be on? I really would like to get a
>> discussion started with the veteran RIOT developers so I can start
>forming
>> a project proposal as soon as possible. I am quite eager to get the
>ball
>> rolling. The channel is #riot-os correct?
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
>
>
>
>___
>devel mailing list
>devel@riot-os.org
>http://lists.riot-os.org/mailman/listinfo/devel

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

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

[Ludwig Ortmann]

Hi,

Here's the PR:
https://github.com/RIOT-OS/RIOT/pull/2503

Please discuss!

Cheers, Ludwig

On Fri, Feb 27, 2015 at 07:08:43AM +0100, Ludwig Ortmann wrote:
> Hi,
> 
> Yes, we came to the same conclusion while driving to embedded world.
> I've got the implementation and API  specification ready as well and will 
> open a PR later.
> 
> Cheers, Ludwig
> 
> Am 27. Februar 2015 02:14:51 MEZ, schrieb Jozef Maslik 
> :
> >Hi,
> >
> >Yes compiler do not optimize (remove out) empty function defined as is
> >suggested.
> >But if RIOT does not want use macros, we can define empty function as
> >static inline function in header and then will be removed by
> >optimization.
> >
> >log_api.h
> >
> >#if MODULE_LOG
> >void log_info(...);
> >#else
> >static inline void log_info(...) {}
> >#endif
> >
> >
> >BTW. Hauke idea use modules is nice.
> >
> >Regards,
> >Jozef
> >
> >
> >
> >
> >
> >> On 23 Feb 2015, at 13:00, Martine Lenders 
> >wrote:
> >> 
> >> Hi,
> >> 
> >> Am 23.02.2015 10:04 schrieb "Ludwig Ortmann"
> >:
> >> > are you suggesting macros are better than APIs + functions?
> >> > If so, please explain why and what better means ;)
> >> 
> >> I was not sure if the compiler optimizes out empty functions, so I
> >assumed
> >> 
> >> #define INFO(msg) (void)0;
> >> 
> >> to be the better solution concerning code size.
> >> 
> >> Regards, 
> >> Martine
> >> ___
> >> devel mailing list
> >> devel@riot-os.org
> >> http://lists.riot-os.org/mailman/listinfo/devel
> >
> >___
> >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] Feedback from emworld and future plans (partnerships AND licensing)

[Ludwig Ortmann]

Hi,

because you asked and to give a more encompassing picture:

On Thu, Feb 26, 2015 at 08:23:29AM +0100, Jan Wagner wrote:
> - RIOT is an OS that is mostly powered by the community with alot
> of students of european universities(?)

This has been the case but is changing as RIOT is on the brink of
being robust, stable and feature-rich enough for instant product
development. There are several companies visibly investing time
(in this case equalling money) in RIOT already, and there are several
companies actively evaluating RIOT for fitness for their products.

> - Why is RIOT searching for partnerships is it only about money? -
> and for what is that money exatly needed?
> - Why are Business Partnerships needed? - the business gets a free
> OS and saves tons of development months,

In order to achieve our goal of making the IoT a better place TM, we
want products to be based on RIOT. RIOT can only maintain its current
speed of development if people continue to put work into it. If RIOT
stops improving, there will be no products based on RIOT and our
vision of the IoT might not come to life.
We believe that individuals hacking on RIOT in their spare time is not
enough to make this happen. Contributions from universities and other
research institutions can not be relied upon for financing.

What we are looking for is enterprises willing to invest in the
development of RIOT in tune with our vision. What that means in detail
(in-house developers, consulting, shared financing of maintainers ...)
is not important. The important thing is that companies need to
dedicate resources.

It's really quite analogues to Linux kernel development. Ideally,
hardware vendors contribute code for their architectures, platforms,
devices etc so that others will use those to realize products, and
product developers contribute whatever they need as a software basis
for their applications so that development and maintenance costs can
be shared.

> Q: I am straight spitter: I have heard that RIOT will have a "full
> time worker/developer" hired - or was already hired - Where does the
> money for the salery of this person comes from?

I was hired by airfy as a regular in-house software developer. This
means I will not be working as a full time RIOT maintainer.
However, as you can already read in the OTA thread, airfy is planning
to contribute in the development efforts of RIOT.

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

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

[Ludwig Ortmann]

Hi,

Yes, we came to the same conclusion while driving to embedded world.
I've got the implementation and API  specification ready as well and will open 
a PR later.

Cheers, Ludwig

Am 27. Februar 2015 02:14:51 MEZ, schrieb Jozef Maslik :
>Hi,
>
>Yes compiler do not optimize (remove out) empty function defined as is
>suggested.
>But if RIOT does not want use macros, we can define empty function as
>static inline function in header and then will be removed by
>optimization.
>
>log_api.h
>
>#if MODULE_LOG
>void log_info(...);
>#else
>static inline void log_info(...) {}
>#endif
>
>
>BTW. Hauke idea use modules is nice.
>
>Regards,
>Jozef
>
>
>
>
>
>> On 23 Feb 2015, at 13:00, Martine Lenders 
>wrote:
>> 
>> Hi,
>> 
>> Am 23.02.2015 10:04 schrieb "Ludwig Ortmann"
>:
>> > are you suggesting macros are better than APIs + functions?
>> > If so, please explain why and what better means ;)
>> 
>> I was not sure if the compiler optimizes out empty functions, so I
>assumed
>> 
>> #define INFO(msg) (void)0;
>> 
>> to be the better solution concerning code size.
>> 
>> Regards, 
>> Martine
>> ___
>> devel mailing list
>> devel@riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
>
>___
>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

[Ludwig Ortmann]

PS: can you send a link to your PR? I couldn't find it.

Cheers, Ludwig

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

Re: [riot-devel] LGPL compliance testing

[Ludwig Ortmann]

Hi Murat,

Under what license are the generated files?
And also, how do you think your port is related to the discussion in this 
thread?

I can try to talk about this topic with a cypress representative today. We are 
currently at the "embedded world" and they are too. They seemed interested in 
RIOT in an initial chat.
BTW: As far as I understood it, their software can create object files with 
library code for the psoc. Therefore I guess it should be possible to link the 
generated psoc library with RIOT in our make system as well.

So, whatever it looks like today, please don't close your pull request yet.

Cheers, Ludwig

Am 25. Februar 2015 21:46:45 MEZ, schrieb Murat CAKMAK :
>Hi All,
>
> 
>
>I was (still) busy to read mails about LGPL compliance so sorry for
>slience.
>
>
>As you know, I have initially ported RIOT to PsoC 5LP processor by
>creating
>a PsoC Creator IDE Projects. 
>
> 
>
>In my case:
>
>1.   This port not using the default RIOT build environment and
>PsoC
>Creator IDE hides linking and other details. 
>
>2.   PsoC Creator IDE also creates automatically some source codes.
>I
>have created an empty project with a small HW design under
>dist/PsoCCreator
>directory. But when you build project in PsoC Creator IDE, It is going
>to
>create a lot of files; system initialization, APIs for HW blocks which
>created for RIOT etc. I was not planning to commit those files to GIT
>repository because they are already created automatically by IDE. 
>
>3.   Auto-generated files may be changed (e.g bug fixing) by the
>version
>of PSOC Creator IDE. So, md5 sums may be different for different
>versions of
>PsoC Creator IDE.  
>
> 
>
>On the other hand, I can also implemented required files instead of
>auto-generated PsoC Creator files, and use RIOT build system. But HEX
>files
>of PsoC processors also includes HW desing code (verilog) addition to
>firmware output(elf, hex etc.). I dont know how PsoC Creator IDE merges
>Firmware code and HW design code into a single HEX file and I am not
>sure
>about PSOC Creator team share this information with me. 
>
>It is the hard way and also I dont prefer to use this way. Because, in
>this
>way, we can not use advantages(ARM Core + Programmable Digital&Analog
>Blocks) of PsoC processors which only available by PsoC Creator IDE. 
>
> 
>
>So, What is the latest decision? 
>
>Should I withdraw my "pull request" for PsoC 5LP port? 
>
> 
>
>Regards. 
>
> 
>
>Murat. 
>
> 
>
> 
>
>-Original Message-
>From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Matthias
>Waehlisch
>Sent: Saturday, February 21, 2015 5:09 PM
>To: RIOT OS kernel developers
>Subject: Re: [riot-devel] LGPL compliance testing
>
> 
>
>Hi Kaspar,
>
> 
>
>On Fri, 20 Feb 2015, Kaspar Schleiser wrote:
>
> 
>
>> Let me correct myself.
>
>> 
>
>> There are no technical reasons against using LGPLed RIOT to develop 
>
>> proprietary applications.
>
>> 
>
>  it depends on how you define "technical reasons". Yes, it is not
>impossible to create separate object files. But you maybe don't want to
>do
>this for technical optimization (see for example
>.pdf>
>http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINAL.
>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 professional point of view, I would not base strategic 
>
>> > decisions on the discussed PR/idea.
>
>> What profession would that be?
>
>> 
>
>  Having an almost complete picture of the landscape.
>
> 
>
> 
>
>Cheers
>
>  matthias
>
> 
>
>--
>
>Matthias Waehlisch
>
>.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST .  Takustr.
>9,
>D-14195 Berlin, Germany ..  
>mailto:waehli...@ieee.org ..  
>http://www.inf.fu-berlin.de/~waehl
>
>:. Also:  
>http://inet.cpt.haw-hamburg.de ..
> http://www.link-lab.net
>___
>
>devel mailing list
>
> 

Re: [riot-devel] Switch to BSD?

[Ludwig Ortmann]

Hi,

I'm opposed to the eclipse public license because of its (L)GPL incompatibility 
and therefore to joining the Eclipse foundation.

Cheers, Ludwig

Am 25. Februar 2015 11:39:08 MEZ, schrieb Emmanuel Baccelli 
:
>Hi everyone,
>
>GPL with linking exception seems relevant in this discussion --
>especially
>since eCOS, which is also a well-known embedded OS, uses this license.
>
>As a side note, but highly related: at Embedded World yesterday, we met
>with the Eclipse Foundation [1] guys.
>RIOT is now officially invited to become an Eclipse project.
>
>There are a number of advantages to be under the Eclipse umbrella: they
>provide legal services, and the IoT part of this umbrella [2] is
>actively
>helping communities such as RIOT to grow organically: in particular
>they
>promise promotion, and matchmaking with other FOSS communities and
>relevant
>industrial partners.
>
>There are however strings attached: Eclipse has good reputation as far
>as I
>can tell, but nevertheless some of our independence is lost if we join,
>and
>we have to use the Eclipse Public License [3].
>
>In any case, the Eclipse Foundation guys were stressing that CLAs [4]
>are
>crucial, whatever we do, whether we join Eclipse Foundation or not.
>
>Best,
>
>Emmanuel
>
>
>[1] https://eclipse.org/org/foundation/
>[2] http://iot.eclipse.org
>[3] https://eclipse.org/legal/eplfaq.php#CPLEPL
>[4] http://en.wikipedia.org/wiki/Contributor_License_Agreement
>
>
>On Wed, Feb 25, 2015 at 2:28 AM, Adam Hunt  wrote:
>
>> I'd be willing to bet that GNU Classpath is one of the oldest
>projects
>> licensed under the GPL with a linking exception.
>>
>> Classpath is distributed under the terms of the GNU General Public
>License
>>> with the following clarification and special exception.
>>>
>>
>>
>> Linking this library statically or dynamically with other modules is
>>> making a combined work based on this library. Thus, the terms and
>>> conditions of the GNU General Public License cover the whole
>combination.
>>> ​​
>>>
>>
>>
>>
>> As a special exception, the copyright holders of this library give
>you
>>> permission to link this library with independent modules to produce
>an
>>> executable, regardless of the license terms of these independent
>modules,
>>> and to copy and distribute the resulting executable under terms of
>your
>>> choice, provided that you also meet, for each linked independent
>module,
>>> the terms and conditions of the license of that module. An
>independent
>>> module is a module which is not derived from or based on this
>library. If
>>> you modify this library, you may extend this exception to your
>version of
>>> the library, but you are not obliged to do so. If you do not wish to
>do so,
>>> delete this exception statement from your version.
>>> ​[1 ]​
>>>
>>
>> ​--adam​
>>
>>
>> ​[1] https://www.gnu.org/software/classpath/license.html​
>>
>>
>> On Tue Feb 24 2015 at 5:08:12 PM Oleg Hahm 
>wrote:
>>
>>> Hi Matthias!
>>>
>>> >   but the name (or license branding). We had this discussion
>before.
>>> > Rather unknown licenses need to be explained. Using eCos license
>is
>>> > similar to use a RIOT license.
>>>
>>> Yes, I agree, but at least it's listed (approved?) by FSF. Another
>option
>>> (see
>>> citation from the OSI list from my previous mail) we could just
>state GPL
>>> as a
>>> license and point to the exception for commercial users. I think the
>text
>>> on
>>> the eCos page is pretty comprehensible.
>>>
>>> The Wikipedia is even claiming that the perception "that without
>applying
>>> the
>>> linking exception, code linked with GPL code may only be done using
>a
>>> GPL-compatible license" is "unsupported by any legal precedent or
>>> citation".
>>>
>>> >   I'm just wondering if eCos is the first license with the
>introduced
>>> > exception -- I will not research on this ;).
>>>
>>> I don't think so, but it's the only listed license from FSF that
>>> specifies the
>>> linking exception.
>>>
>>> >   I never said it's impossible. In this type of discussion you
>will
>>> > always find counterexamples. I just wanted to point out that I see
>it as
>>> > an advantage to use an OSI approved license.
>>>
>>> I agree, but if the choice is between a FSF approved license (as I
>>> understand
>>> eCos License is) that matches our needs and a less matching OSI
>approved
>>> license, I'm willing to bite this bullet.
>>>
>>> > > At least eCos, ERIKA and ChibiOS are very similar to RIOT from a
>>> > > software architecture point of view (OS for embedded hardware).
>>> > >
>>> >   No comment ;).
>>>
>>> For clarification: I was referring to the fact that these systems
>have a
>>> similar use case as RIOT, not that there concept or feature set is
>>> similar to
>>> RIOT.
>>>
>>> > > Long story short: I see your concerns, but for me GPL + Linking
>>> > > Exception is a common license model that works well for many
>>> > > well-known and mature projects. Personally, I would think t

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

[Ludwig Ortmann]

Hi Attilio, Martine,

are you suggesting macros are better than APIs + functions?
If so, please explain why and what better means ;)

Cheers, Ludwig

On Mon, Feb 23, 2015 at 09:26:34AM +0100, Attilio Dona wrote:
> Also for me the MACRO approach has to be considered in a design review,
> eventually in addition to a tracing API layer.
> 
> Just to add my bit of experience with RIOT about porting msp430 family on
> new TI/redhat gcc 4.9:
> 
> the default nanolib bundled with the toolchain implies a big printf memory
> usage, not suitable for a lot of msp430 chips.
> 
> At the moment my solution is to use tinyprintf:
> 
> https://github.com/cjlano/tinyprintf
> 
> It works as expected, with some minor modification to suit my port.
> 
> Greetings
> Attilio
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Feb 23, 2015 at 8:24 AM, Martine Lenders 
> wrote:
> 
> > +1 thought about this for a long time, too. Though my approach would be
> > with macros and more global (similar to how DEBUG is now).
> >
> > Am 23.02.2015 07:16 schrieb "Ludwig Ortmann"  > >:
> >
> > >
> > > Hi Jozef,
> > >
> > > AFAIK there has been no work on a solution so far.
> > > However, I thought about this the other day in the context of the
> > function pointer discussion and would like to propose a "logging" API
> > (maybe there is an issue for that as well somewhere) for `core`, which
> > offers things like `log.info(...)` and `log.error(...)`.
> > > Different logging modules can implement this API then, ranging from
> > `printf` over file based logging to network messages.
> > > And then there should also be a `(void) ...`  implementation which suits
> > production and ultra low memory needs.
> > >
> > > Opinions?
> > >
> > > Cheers, Ludwig
> > >
> > > Am 23. Februar 2015 03:16:33 MEZ, schrieb Jozef Maslik <
> > ma...@binarylemon.com>:
> > > >
> > > >Hi,
> > > >
> > > >Could you please give me information about actual state of "replace
> > > >printf and puts" issues? https://github.com/RIOT-OS/RIOT/issues/994,
> > > >https://github.com/RIOT-OS/RIOT/issues/641
> > > >
> > > >I’m working with MKL02Z32 which has 4kB RAM. Printf or puts which are
> > > >almost everywhere make a big problem. I removed them from my fork, but
> > > >it is not good or nice solution.
> > > >
> > > >If I miss something important around “printing issue” please correct
> > > >me.
> > > >How others deal with this issue? (printf or puts usage like here, is
> > > >not nessesary in real applications).
> > > >
> > > >Regards,
> > > >Jozef
> > > >
> > > >___
> > > >devel mailing list
> > > >devel@riot-os.org
> > > >http://lists.riot-os.org/mailman/listinfo/devel
> > >
> > > ___
> > > devel mailing list
> > > devel@riot-os.org
> > > http://lists.riot-os.org/mailman/listinfo/devel
> >
> >
> > ___
> > devel mailing list
> > devel@riot-os.org
> > http://lists.riot-os.org/mailman/listinfo/devel
> >
> >

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

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

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

[Ludwig Ortmann]

Hi Jozef,

AFAIK there has been no work on a solution so far.
However, I thought about this the other day in the context of the function 
pointer discussion and would like to propose a "logging" API (maybe there is an 
issue for that as well somewhere) for `core`, which offers things like 
`log.info(...)` and `log.error(...)`.
Different logging modules can implement this API then, ranging from `printf` 
over file based logging to network messages.
And then there should also be a `(void) ...`  implementation which suits 
production and ultra low memory needs.

Opinions?

Cheers, Ludwig

Am 23. Februar 2015 03:16:33 MEZ, schrieb Jozef Maslik :
>
>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

Re: [riot-devel] Repository for Docker builds

[Ludwig Ortmann]

Hi,

fine with me, thank you for the initiative =)

Cheers,
Ludwig

On Sun, Feb 22, 2015 at 11:54:16AM +0100, Joakim Gebart wrote:
> Dear relentless RIOTers,
> I would like to introduce an official repository for keeping Dockerfiles
> used for building Docker images. The images can be used to build RIOT in
> conjunction with the work being proposed in [1]. The images will contain
> supported versions of tool chains to make getting started with RIOT more
> convenient. I volunteer as maintainer for the Dockerfile repository and the
> pre-built images which will be published at the Docker hub [2]. The reason
> for making a separate repository instead of using /dist/X is that we
> can more easily keep track of tool chain updates, and we can use the Docker
> hub automatic build feature to automatically update the images. Using the
> core RIOT code repo for Dockerfiles will cause an unnecessary amount of
> rebuilds when watching it with the automatic build feature of the Docker
> hub.
> 
> [1]: https://github.com/RIOT-OS/RIOT/pull/2392
> [2]: https://registry.hub.docker.com/repos/riot/
> 
> Best regards,
> Joakim

> ___
> 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] OTA meetup 11.2.2015

[Ludwig Ortmann]

Hi,

On Mon, Feb 16, 2015 at 06:41:05PM +0100, Oleg Hahm wrote:
> > the minutes from the meeting have been added to our wiki:
> > https://github.com/RIOT-OS/RIOT/wiki/minutes-OTA-meetup-13.2.2015
> 
> Have there any concrete next steps been identified? Did you conclude in some
> kind of a schedule for upcoming tasks and who is gonna work on what?

There has been some preliminary scheduling, we will announce more
concrete planning soon, possibly in the form of an issue.

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

Re: [riot-devel] Changing the workflow.

[Ludwig Ortmann]

Hi,

On Sat, Feb 21, 2015 at 07:02:58PM +0100, Martine Lenders wrote:
> This is why I propose we change to a slightly adapted topic branch workflow
> (also known as feature branch) workflow [1]:
> 
>- the main RIOT-OS/RIOT repository will get the following branches
>   - master: points to the stable version of our latest release
>  - one stable branch for every major release (?)

(I understand "stable" to denote non-changing APIs, and a "stable
branch" to denote a branch which is stable in this sense, and gets
bugfixes, and possibly new features.)

We don't have enough people to support this at the moment.
Also, we would definitely need to make sure the releases are sensible
for this to make sense.
Let's keep this one open until there is a need, time and a codebase
that makes sense to put this effort into.

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

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

>- feature branches will be merged into devel if the feature reaches
>sufficient stability.

What does "stability" mean in this context?

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

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

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

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

Re: [riot-devel] tool chain recommendation

[Ludwig Ortmann]

Hi,

I'm glad you found the wiki ;)
Is there any way you would have found it even quicker, some location where we 
should put a link for example?

Cheers, Ludwig

Am 20. Februar 2015 04:52:11 MEZ, schrieb "Ralph Droms (rdroms)" 
:
>I answered my own question by a little searching on the wiki -
>according to github.com/RIOT-OS/RIOT/wiki/Board%3A-Samr21-xpro I should
>use GNU Tools for ARM Embedded Processors toolchain.
>
>> On Feb 19, 2015, at 9:52 PM 2/19/15, Ralph Droms (rdroms)
> wrote:
>> 
>> What's the recommended toolchain for the SAMR21-XPRO board?
>> 
>> - Ralph
>> 
>> ___
>> 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] redbee-econotag board

[Ludwig Ortmann]

Hello and welcome Ralph,

In principal, all examples should work on all boards unless the build system 
says otherwise. (Or there should be an issue in the tracker).
I'm not familiar with this board, but if I remember correctly, there exist 
several hardware versions of it. Which one do you have?

Also: did you try and enter commands (e.g. "help")?

Cheers,
Ludwig


Am 17. Februar 2015 22:41:36 MEZ, schrieb "Ralph Droms (rdroms)" 
:
>Is redbee-econotag board code still in active development or use?
>
>I'm new to RIOT ... tried compiling the "default" example for
>redbee-econotag and found an error (maybe more correctly a construct
>that doesn't work as expected) in the conditional assembly in common.s 
>I put in a patch but now all I get from "default" is:
>
> .CONNECT
> Size: 69440 bytes
>Sending
>/home/rdroms/RIOT/examples/default/bin/redbee-econotag/default.hex
> done sending files.
> Board initialized.
>kernel_init(): This is RIOT! (Version:
>2014.12-415-g1e6e-instant-contiki)
> kernel_init(): jumping into first task...
>
>Should "default" work?
>
>- Ralph
>
>___
>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] reserve main and let application define thread(s)

[Ludwig Ortmann]

Hi,

On Sat, Feb 14, 2015 at 03:28:56PM +0100, Kaspar Schleiser wrote:
> On 02/14/15 12:28, Ludwig Ortmann wrote:
> >I created quick&dirty branches for both methods:
> >
> >plain c:
> >https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-application-init
> >macro magic:
> >https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-make
> >
> >Not sure which one I dislike better ;)
> ;)
> 
> I think we should come up with a method that enables inclusion of multiple
> application threads. Maybe we can even replace auto_init in the process.

A possible removal of auto_init is a separate concern from my point of
view, so I'd like to keep it out of the discussion for now. If you
disagree you need to elaborate, because I don't see how this fits in.

> We could have something like
> ...
> All that we parse and auto-generate the corresponding C code.
> 
> Not sure if we're entering a world of pain this way. ;)

Call me bourgeois, but I would rather use macros than generating C
code somewhere in the build system. (Or you could try to convince me
with the power of code ;)

I liked the idea with the list, though.

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

Re: [riot-devel] reserve main and let application define thread(s)

[Ludwig Ortmann]

Hi,

On Sat, Feb 14, 2015 at 05:17:06PM +0100, Joakim Gebart wrote:
> > On 02/14/15 12:28, Ludwig Ortmann wrote:
> >>
> >> I created quick&dirty branches for both methods:
> >>
> >> plain c:
> >> https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-application-init
> >> macro magic:
> >> https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-make
> >>
> >> Not sure which one I dislike better ;)
> 
> I like the main-application-init version because it is still somewhat
> simple to follow. Perhaps it would be possible to still keep the
> trampoline but make it execute application_init instead of main and
> let auto_init() execute from the trampoline. This eliminates the need
> to modify the example applications.

My reason for moving autoinit to the application threads was that it
is currently also executed in a thread context. I wasn't sure (and too
lazy to find out) if there are good reasons for this.

The test and example applications would need to be modified anyways.
First to add the application_init function, and also because the main
function need to be renamed.

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

Re: [riot-devel] Regarding Hardware Timer

[Ludwig Ortmann]

Hi,

these tests print out everything you need to know, but here you go:

```
$ cd tests/hwtimer
$ make clean all term
...
kernel_init(): This is RIOT! (Version: 2014.12-421-gb6eeb)
kernel_init(): jumping into first task...
hwtimer test application...

  Timers should print "callback x" once when they run out.
  The order for x is 1, n-1, n-2, ..., 2 where n is the number of available 
hardware timers (4 on this platform).
  In 1 second, one timer should fire every second/100 until all timers have run 
out.
  Additionally the message "hwtimer set." should be printed once 1 second from 
now.

Setting timers:

set callback  1
set callback  2
set callback  3

All timers set.

callback  1
hwtimer set.
callback  3
callback  2
```

```
$ cd tests/hwtimer_spin
$ make clean all term
...
kernel_init(): This is RIOT! (Version: 2014.12-421-gb6eeb)
kernel_init(): jumping into first task...
This is just a functionality test for hwtimer_spin.

You should see the message "success" after a while if this test was
successful.
If you do not see that message, something went wrong.

success
```

Cheers, Ludwig


On Tue, Feb 17, 2015 at 08:54:47PM +0530, shishir tiwari wrote:
> Hi All ,
> 
> I have configure one hardware timer and testing example hwtimer and
> hwtimer_spin.
> 
> This is working and i just want to verify can you please provide me
> expected output of these examples . Readme are not available .
> 
> 
> Thanks
> Shishir tiwari
> ___
> 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] PlaceCam on Linux with echo-cancellation

[Ludwig Ortmann]

Hi,

On Mon, Feb 16, 2015 at 04:31:51PM +0100, Oleg Hahm wrote:
> > PS:
> > Open Research Topic:
> > Find out how to automatically or at least super-conveniently (I'm thinking
> > push-to-talk) mute the microphone when not speaking.
> 
> Well, you can mute yourself, whenever you're not speaking, so it would be
> something like click-to-talk.

I do this, but it does not qualify as super-convenient.
Mainly because it requires me to navigate my mouse to the PlaceCam window and 
click the tiny button.

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

[riot-devel] PlaceCam on Linux with echo-cancellation

[Ludwig Ortmann]

Hi,

I just figured out how to enable echo cancellation for PlaceCam in Linux with 
PulseAudio.
It is possible to PulseAudio configuration hints using environment variables.
When using the command line, you can tell it to activate echo-cancellation like 
this:

PULSE_PROP="filter.want=echo-cancel" ./PlaceCam/opt/PlaceCam/PlaceCam

Oleg and me tested this and were surprised how well it works.
I hereby encourage anyone using Linux to adopt this method so the audio in our 
virtual meetings will be less painful.

Cheers, Ludwig


PS:
Open Research Topic:
Find out how to automatically or at least super-conveniently (I'm thinking 
push-to-talk) mute the microphone when not speaking.
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] reserve main and let application define thread(s)

[Ludwig Ortmann]

Hi,

On Sat, Feb 14, 2015 at 11:50:38AM +0100, Ludwig Ortmann wrote:
> On Fri, Feb 13, 2015 at 06:49:56PM +0100, Kaspar Schleiser wrote:
> > On 02/13/15 15:55, Ludwig Ortmann wrote:
> > >My proposal:
> > >Let the application Makefile export one or possibly several names to
> > >be used for the initial application thread(s). kernel_init will then
> > >take care of creating those.
> > I'd like to see a nice (idea on how to do an) implementation of this...
> > I hope we don't end up with too much macro magic.
> 
> A solution without any macro magic would be to require
> "application_init" to exist, call that from kernel_init, and let the
> application create its own threads.
> Not overly convenient, but as the usual workflow for creating
> applications is copy'n'paste of an existing application it wouldn't
> hurt much either.

I created quick&dirty branches for both methods:

plain c:
https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-application-init
macro magic:
https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-make

Not sure which one I dislike better ;)

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

Re: [riot-devel] reserve main and let application define thread(s)

[Ludwig Ortmann]

Hi,

On Fri, Feb 13, 2015 at 06:49:56PM +0100, Kaspar Schleiser wrote:
> On 02/13/15 15:55, Ludwig Ortmann wrote:
> >My proposal:
> >Let the application Makefile export one or possibly several names to
> >be used for the initial application thread(s). kernel_init will then
> >take care of creating those.
> I'd like to see a nice (idea on how to do an) implementation of this...
> I hope we don't end up with too much macro magic.

A solution without any macro magic would be to require
"application_init" to exist, call that from kernel_init, and let the
application create its own threads.
Not overly convenient, but as the usual workflow for creating
applications is copy'n'paste of an existing application it wouldn't
hurt much either.

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

Re: [riot-devel] OTA meetup 11.2.2015

[Ludwig Ortmann]

Hi,

the minutes from the meeting have been added to our wiki:
https://github.com/RIOT-OS/RIOT/wiki/minutes-OTA-meetup-13.2.2015

Thank you all for participating (or at least trying to ;),
and kiwi.ki for hosting the meeting.

Cheers,
Ludwig

On Fri, Feb 13, 2015 at 07:00:02PM +0100, Arvid Picciani wrote:
> Hi, 
> 
> please join us on appear.in online. Make sure to use chrome or opera in order 
> to receive the slide sharing.
> 
> https://appear.in/riot 
> 
> Arvid
> 
> 
> > On Feb 13, 2015, at 4:27 PM, Joël Chotard  wrote:
> > 
> > Hi, which is the Google hangouts address ?
> > Regards
> > Joel
> > 
> > Le 11 févr. 2015 22:41, Arvid Picciani  a écrit :
> >> 
> >> Hi, 
> >> 
> >> by popular demand, we will be meeting this Friday at 19:00 at the kiwi.ki 
> >> office 
> >> 
> >> KIWI.KI GmbH 
> >> Lehrter str. 17 
> >> 10557 Berlin, DE 
> >> 
> >> as well as online over appear.in or google hangouts (whatever i can get 
> >> working). 
> >> 
> >> Attached are the slides i will be presenting for about 15minutes. 
> >> Feel free to bring your own slides or notes. Especially for topics not 
> >> covered by me. 
> >> 
> >> see ya there! 
> >> 
> >> best, 
> >> Arvid 
> >> 
> >> 
> >> 
> >> 
> >> ___ 
> >> 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 list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] reserve main and let application define thread(s)

[Ludwig Ortmann]

Dear RIOTers,

today's question from Murat and my past efforts with native have one
thing in common: our environments have a hard (or impossible) to
change dependency on main() as the system's entry point.

For native, I was able to navigate around this, but past mails to this
list show that this has (negative) implications for c++ (which are
unfixed as of today). Murat says with PsoC it is impossible to
navigate around this restriction.

I imagine we might see more platforms with a fixed idea of main in the
future where RIOT's use of main for the first application thread
function is a problem.

My proposal:
Let the application Makefile export one or possibly several names to
be used for the initial application thread(s). kernel_init will then
take care of creating those. 
The function name "main" will be reserved for boards/cpus to
implement.
In case of native/PsoC, the cpu's or board's main function can then
call kernel_init (after possibly taking care of their respective
initialization).

Bonus benefits/implications:
The application gets to define the name(s) of (all) it's thread(s),
the setting of this thread's priority, stacksize, flags etc. become
more obvious, it will be possible to have applications without any
application thread (maybe auto_init is enough for a router in the
future?), and possibly more I didn't think of immediately ;)

Please discuss!

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

[riot-devel] msba2 with gcc 4.9 2014q4 vs 4.8 2014q2

[Ludwig Ortmann]

Hi,

this mornings updates brought GCC 4.9 2014q4 to my system. Now I'm
wondering which projects didn't work how exactly with the old gcc
version so I can test whether to add it to the "working" section of
the msba2 toolchain section in the RIOT wiki.

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

Re: [riot-devel] Port RIOT to Different Environments (IDE)

[Ludwig Ortmann]

Hi Murat,

If I understand correctly what you are doing, there is nothing in
principal that speaks against this.
Just open a PR so we can see how it fits.

Regarding RIOT's file hierarchy, I would put it in `/dist/`, either in
a subdirectory if it is more than one file, or directly if it is a
single file.

Cheers, Ludwig

On Thu, Feb 12, 2015 at 10:41:33AM +0200, Murat CAKMAK wrote:
> Hi All,
> 
>  
> 
> Is there any objection about porting RIOT to different build environments;
> e.g. IDE.
> 
>  
> 
> Because;
> 
>  
> 
> PsoC's are different than the other IC's. PsoC's have programmable digital
> and analog HW block. So, developer can create own custom IC. 
> 
> After HW creation, specific firmware(application) can be developed. 
> 
> This is important because sensor side of IoT can be managed more efficient
> than classical MCU's. For example; get data from sensor, process it in
> custom hw block which designed for this purpose and give processed data to
> Firmware by a register. Processing on HW will not effect to Core CPU(ARM
> Cortex) execution time. 
> 
>  
> 
> But PsoC development are very strongly dependent to PsoC Creator IDE. You
> can only develop digital and analog hw blocks via PsoC Creator IDE. 
> 
> This IDE merges HEX output of Firmware(Application) code and HW Creation
> code (Verilog) and creates a different HEX file. This process is complex and
> it is internal for Cypress. I dont think PsoC Creator Team gives those
> details to me. 
> 
>  
> 
> So, I think we can craete a PsoC Creator Project and we can add RIOT to PSOC
> Creator project with required porting modules for PsoCs.
> 
> In this way, PsoC creator developer can use RIOT and developers can also
> create own HW blocks to use in own applications with RIOT. 
> 
> Otherwise, all advantages of PsoCs will not be available for developers. 
> 
>  
> 
> Solution hierarchy can be like as below : 
> 
> http://tinypic.com/view.php?pic=15me3wz
>  &s=8#.VNxk2_msXVA
> 
> Developer may use different advantages on IDE. For example; step by step
> debugging on IDE. 
> 
>  
> 
> Developers will only open PsoC Creator project to use RIOT on PsoCs an they
> will not use default build environment of RIOT. 
> 
>  
> 
> I have almost finished to port RIOT according to above strategy. 
> 
>  
> 
> If there is no objection to port RIOT to PsoC Creator IDE, I will submit my
> codes to GIT repository. 
> 
> But I did not make a decision about where shall I locate psoc creator
> project in RIOT repository hieararcy (In my implementation it is located at
> out of RIOT directory)
> 
>  
> 
> Regards.
> 
>  
> 
> Murat.
> 
> SW Engineer at Cypress Semi.
> 

> ___
> 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] Meeting 11/02/2015

[Ludwig Ortmann]

Hi Baptiste,

in theory yes, in practice I am unable to contact one of the persons
who can host the session.

The link however is always the same.

Cheers, Ludwig

On Wed, Feb 11, 2015 at 09:56:58AM +0100, Baptiste Clenet wrote:
> Hi,
> 
> Is there a meeting today?
> Could you provide the PlaceCam link of it (10am today)?
> 
> Cheers,
> 
> -- 
> *Clenet 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] Context Switching

[Ludwig Ortmann]

Hi,

On Tue, Feb 10, 2015 at 02:08:08PM +0530, shishir tiwari wrote:
> So to put it short: in cpu_switch_context_exit() you simply must load
> the main threads context into the CPUs register and point the stack
> pointer to the main threads stack.

That's not entirely accurate. You need to call `sched_run` and load
the context of `sched_active_thread`.

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

Re: [riot-devel] Event driven drivers

[Ludwig Ortmann]

On Sun, Feb 08, 2015 at 04:48:00PM +0100, Ludwig Ortmann wrote:
> Hi Frank,
> 
> On Sun, Feb 08, 2015 at 11:47:25AM +0100, Frank Holtz wrote:
> > i have looked into periph drivers and found a lot of single line "while"
> > statements waiting for finishing things.
> >  ...
> > Slow devices like ADC, Flash, UART or Random number generation are
> > wasting a lot of CPU cycles while waiting to finish an action. This
> > blocks task switching(right?) and preventing to go into sleep mode.
> 
> Wrong =)
> 
> As long as the calling thread (or the respective implementation) does
> not disable interrupts, the caller may be preempted.
> 
> Cheers, Ludwig

PS:
Going into sleep is prevented, yes, but in most cases the task
switching should take longer than waiting does.
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Event driven drivers

[Ludwig Ortmann]

Hi Frank,

On Sun, Feb 08, 2015 at 11:47:25AM +0100, Frank Holtz wrote:
> i have looked into periph drivers and found a lot of single line "while"
> statements waiting for finishing things.
>  ...
> Slow devices like ADC, Flash, UART or Random number generation are
> wasting a lot of CPU cycles while waiting to finish an action. This
> blocks task switching(right?) and preventing to go into sleep mode.

Wrong =)

As long as the calling thread (or the respective implementation) does
not disable interrupts, the caller may be preempted.

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

Re: [riot-devel] Problem socket UDP

[Ludwig Ortmann]

Hi Baptiste,

could you open an issue please?

Cheers, Ludwig

On Fri, Feb 06, 2015 at 03:05:05PM +0100, Baptiste Clenet wrote:
> After pluging a second sender, I got the problem:
> if ((socket > MAX_SOCKETS) || (socket_base_sockets[socket -
> 1].socket_id == 0)) {
> return false;
> }
> socket = 11534388
> socket_base_sockets[socket - 1].socket_id = 64
> 
> And then the program goes to isr_hard_fault
> 
> 2015-02-06 14:19 GMT+01:00 Baptiste Clenet :
> 
> > I have let my program running with two boards: one sender and one
> > receiver. It seems to work for the moment (longer than with three sender
> > boards)
> >
> > 2015-02-06 10:53 GMT+01:00 Baptiste Clenet :
> >
> >> Hi Oleg,
> >>
> >> I tried on native by simulating the value from sensor and it works after
> >> one hour of running.
> >> So it seems to be a platform specific problem.
> >>
> >> Any clues? Which test shoud I do then? and where the variable socket is
> >> incremented?
> >>
> >> Cheers,
> >>
> >> 2015-02-06 8:18 GMT+01:00 Oleg Hahm :
> >>
> >>> Hi Maxence!
> >>>
> >>> > You mean than I should slow down the number of transmission? I send a
> >>> > packet every second on three boards which means that the other board
> >>> > receives three packets a second.
> >>> > How may I check apart from slowing down the rate of the transmission?
> >>>
> >>> Three packets every second shouldn't be a problem. Have you checked if
> >>> same
> >>> (or similar code) works on native. That would be always the first
> >>> indicator if
> >>> it's a general problem in - let's say the network stack - or if it's
> >>> something
> >>> particular to this hardware.
> >>>
> >>> Cheers,
> >>> Oleg
> >>> --
> >>> panic ("Splunge!");
> >>> linux-2.2.16/drivers/scsi/psi240i.c
> >>>
> >>> ___
> >>> devel mailing list
> >>> devel@riot-os.org
> >>> http://lists.riot-os.org/mailman/listinfo/devel
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> *Clenet BaptisteFR: +33 6 29 73 05 39 <%2B33%206%2029%2073%2005%2039>*
> >> *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
> >> système temps réél embarqué*
> >>
> >>
> >> *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
> >>
> >
> >
> >
> > --
> >
> > *Clenet BaptisteFR: +33 6 29 73 05 39 <%2B33%206%2029%2073%2005%2039>*
> > *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
> > système temps réél embarqué*
> >
> >
> > *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
> >
> 
> 
> 
> -- 
> 
> *Clenet BaptisteFR: +33 6 29 73 05 39*
> *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
> système temps réél embarqué*
> 
> 
> *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*

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

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

Re: [riot-devel] 'defalut' example on SAMR21 Xplained Pro

[Ludwig Ortmann]

Hi,

Please try connecting to a different USB port, I've seen this before.

Cheers, Ludwig

Am 6. Februar 2015 11:42:05 MEZ, schrieb "ROUSSEL Kévin" 
:
>Hello everyone,
>
>Does the 'default' example work correctly on SAMR21 Xplained Pro? I 
>compiled and flashed successfully this application on the Xplained Pro
>I 
>have; but when doing 'make term', I just can't obtain any output from 
>the board (via the same debug USB port I used to flash).
>
>Was anyone able to run this example successfully on the SAM R21, or 
>there a known problem?
>
>Thanks,
>-- 
>
>
>  Kévin Roussel
>  Doctorant, projet LAR
>  Équipe MADYNES, INRIA Nancy Grand-Est / LORIA
>  Tél. : +33 3 54 95 86 27
>  kevin.rous...@inria.fr
>
>___
>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] How low can you go?

[Ludwig Ortmann]

Hi,

On Fri, Feb 06, 2015 at 09:03:31AM +0100, Oleg Hahm wrote:
> Am Thu, Feb 05, 2015 at 02:09:52PM -0800 schrieb Adam Hunt:
> > There's already a driver for for Atmel's AT86RF231 in the tree and while
> > the AT86RF230 on the Raven boards are nearly the same the 230 lacks a
> > couple minor features, namely a crypto processor and RNG. So, the RF link
> > would be wide open but for experimentation and learning sacrifices are
> > often necessary.
> 
> As far as I know there were some considerations and work done towards a
> generic AT86RF23x or even AT86RF2xx driver. Thomas, am I right?

Yes, I'm working on that (almost done).

Cheers, Ludwig
___
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] Call for OTA (Over the Air Update) Task Force

[Ludwig Ortmann]

Hi Jeff,

On Thu, Jan 22, 2015 at 04:00:14PM +, Katz, Jeff wrote:
> Currently:
> 1) New image downloaded to spare storage (external SPI NOR flash)
> 2) When new image verified, relocate important functions to RAM
> 3) Wipe internal flash
> 4) Copy new image to internal flash
> 5) Reboot
> 
> Obviously between 3 and 4 if there is an issue, the device is a brick. In
> practice, 2-3-4-5 takes place in under a few milliseconds, which is shorter
> than the amount of power provided by the bulk capacitors on the input, so
> it's "OK". 

Are you checking for an "external" power failure before starting phase
3? Otherwise the period length is irrelevant ;)

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

Re: [riot-devel] Call for OTA (Over the Air Update) Task Force

[Ludwig Ortmann]

Hi Frank,

On Thu, Jan 22, 2015 at 10:52:36AM +0100, Frank wrote:
> Am 22.01.2015 um 10:50 schrieb Ludwig Ortmann:
> > On Thu, Jan 22, 2015 at 10:20:47AM +0100, Frank wrote:
> >> it's possible to brick the device when flash code crashes every time
> >> when it writes a new image. Then we have an corrupt image and an non
> >> working image.
> > I have trouble making sense of this - could you please elaborate a
> > bit? (This is what I read: "If there is an error in the firmware update
> > code it might not work.")
> This is what i mean.

OK, but (quoting more from the original mail):

> > To recover from this point i think it's sufficient implementing an
> > simple low level broadcast receiver without cryptographic checks or
> > an network stack. Alternatively there is space needed for an third
> > firmware image.

How would adding a second flashing mechanism help with this
problem? My fear so far is that throwing more code at this problem
will only deplete memory and introduce new errors.

I'd rather have a thoroughly tested and well designed implementation
in the first place ;)

Also, what would the third image change?

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

Re: [riot-devel] Memory Management

[Ludwig Ortmann]

Hi,

On Thu, Jan 22, 2015 at 10:56:22AM +0100, Martine Lenders wrote:
> 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.

That's mostly correct ;)
In this particular case it's wrapped to guard against side effects of
letting an application directly call the host implementation, though.

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

Re: [riot-devel] Memory Management

[Ludwig Ortmann]

Hi Raphael,

On Thu, Jan 22, 2015 at 09:41:31AM +, Hiesgen, Raphael wrote:
> 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).

Yes, the native "implementation" just wraps the system implementation.

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

Please have a look at 
https://github.com/RIOT-OS/RIOT/wiki/Static-vs-Dynamic-Memory

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

Re: [riot-devel] Call for OTA (Over the Air Update) Task Force

[Ludwig Ortmann]

Hi,

On Thu, Jan 22, 2015 at 10:20:47AM +0100, Frank wrote:
> it's possible to brick the device when flash code crashes every time
> when it writes a new image. Then we have an corrupt image and an non
> working image.

I have trouble making sense of this - could you please elaborate a
bit? (This is what I read: "If there is an error in the firmware update
code it might not work.")

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

Re: [riot-devel] PIC16 and/or PIC18 platform ?

[Ludwig Ortmann]

Hi

yes, every thread has it's own stack. You need to be able to store and
restore a thread's context per request and on interrupts.

Cheers, Ludwig

On Fri, Jan 16, 2015 at 10:43:49PM +0100, gnu...@dds.nl wrote:
> Is it possible to port RIOT OS to PIC16 platform (no stack manipulation
> possible)or the PIC18 platform (limited stack manipulation possible)
> 
> I have been looking into the atmel ported code to see what is all needed to
> do and most is not a problem but what are the stack manipulations needed ?.
> Does every thread have its own stack ?.
> 
> thanks.
> 
> ___
> 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] Virtual Meeting tomorrow

[Ludwig Ortmann]

Hi,

On Tue, Jan 13, 2015 at 09:03:20PM +0100, Oleg Hahm wrote:
> I've set up a pad with a tentative agenda here:
> http://riot.pad.spline.de/6

"Guests are not allowed to join that pad.  Please sign in."

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

Re: [riot-devel] ESP8266 WIFI transceiver

[Ludwig Ortmann]

Hi,

I've got two of those and they appear to be working ;)
I can bring them to the university if you are interested in first hand 
experience.

Cheers, Ludwig

Am 12. Januar 2015 19:38:02 MEZ, schrieb "Cenk Gündogan" 
:
>Hi *,
>
>Does anyone has any experience with this cheap WiFi transceiver
>(ESP8266)?
>
>May be of interest to some of you, too.
>
>http://www.ebay.de/itm/ESP8266-Serial-WIFI-Wireless-TransceiveR-Module-SPI-Send-Receive-LWIP-Arduino-/171530595640?pt=Wissenschaftliche_Ger%C3%A4te&hash=item27f0052d38
>
>Cheers,
>
>CG
>___
>devel mailing list
>devel@riot-os.org
>http://lists.riot-os.org/mailman/listinfo/devel

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

Re: [riot-devel] Flashing the Samr21 xpro

[Ludwig Ortmann]

Hi,

does anyone know if it's possible to flash this board faster in
principal?

Cheers, Ludwig

On Sat, Jan 10, 2015 at 02:25:50PM +0100, Lucas Jenß wrote:
> Hey everyone, 
> 
> I’ve been playing around with the Samr21 xpro and flashing
> the device is _really_ slow, i.e. 0.481 KiB/s. Is this expected
> or is there a way to improve it? I’m using the current OpenOCD
> Git HEAD because the 0.8.0 release does not seem to contain the
> configs for the board yet. I tried to flash the hello-world
> example.
> 
> Cheers,
> Lucas
> ___
> devel mailing list
> devel@riot-os.org
> 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] Open IoT Challenge

[Ludwig Ortmann]

Dear Developers,

The Eclipse Foundation is holding a challenge:
http://iot.eclipse.org/open-iot-challenge/

The focus is on open technology and community, so by using RIOT and
involving our fabulous community you've already half won ;)

To participate, you'd need to register until January, 17th.
The deadline for submission of the solution is February 27th.

The rules:
"""
* The challenge is open to any individual aged 18 years or older
* The solution submitted by the applicants must be a new
  solution created for this challenge
* More than one individual can participate in creating a
  solution but any prize will be awarded to the key contact who
  completed the entry form
"""

The criteria:
"""
* Innovation of the solution and applicability to the application
  domain
* Completeness of solution
* Use of open standards and open source technology
* Amount of community discussion from the participant
  when they built their solution
"""

The prices:
"""
$750 gift card
$500 gift card
$250 gift card
"""

In case you have an idea for a project but hesitate to do it alone,
just ask others to join forces on the mailing lists or on the IRC.

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

Re: [riot-devel] Network refactoring

[Ludwig Ortmann]

Hi,

we've also got a Google calendar (embedded on the website under
www.riot-os.org#community) you might be interested in:
https://www.google.com/calendar/embed?src=k3ql8setv7l48ofnol0tfuu6ts%40group.calendar.google.com

In case you are using a Google account for calendaring you could also
import the calendar (in the calendar view add a new calendar with
the URL k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com).

Cheers, Ludwig


On Wed, Jan 07, 2015 at 10:38:00AM +0100, Baptiste Clenet wrote:
> Great! Thanks
> 
> I found the page which says when the meeting is as well.
> Wednesday at 10:00 AM, I'll try to attend.
> 
> 
> 2015-01-07 10:31 GMT+01:00 Ludwig Ortmann :
> 
> > Hi Baptiste,
> >
> > No need to register, we have a license.
> >
> > Please have a look at the Wiki page for further information:
> > https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation
> >
> > Cheers, Ludwig
> >
> > On Wed, Jan 07, 2015 at 09:36:20AM +0100, Baptiste Clenet wrote:
> > > Hi,
> > >
> > > I would like to attend the meeting in order to see the progress and ask
> > > some questions, if necessary, at the end of the meeting.
> > > When is it planned?
> > > Btw, is PlaceCam a free software? It seems to have only 30 days trial ...
> > >
> > >
> > >
> > > 2015-01-06 5:59 GMT+01:00 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
> > > >
> > > >
> > >
> > >
> > > --
> > > *Clenet 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
> >
> 
> 
> 
> -- 
> 
> *Clenet BaptisteFR: +33 6 29 73 05 39*
> *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
> système temps réél embarqué*
> 
> 
> *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*

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

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

Re: [riot-devel] Network refactoring

[Ludwig Ortmann]

Hi Baptiste,

No need to register, we have a license.

Please have a look at the Wiki page for further information:
https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation

Cheers, Ludwig

On Wed, Jan 07, 2015 at 09:36:20AM +0100, Baptiste Clenet wrote:
> Hi,
> 
> I would like to attend the meeting in order to see the progress and ask
> some questions, if necessary, at the end of the meeting.
> When is it planned?
> Btw, is PlaceCam a free software? It seems to have only 30 days trial ...
> 
> 
> 
> 2015-01-06 5:59 GMT+01:00 Martine Lenders :
> 
> > Hi,
> > Am 05.01.2015 18:06 schrieb "Ludwig Ortmann"  > >:
> > >
> > > 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
> >
> >
> 
> 
> -- 
> *Clenet 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

[Ludwig Ortmann]

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.

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

[riot-devel] Tomorrow's virtual meeting cancelled

[Ludwig Ortmann]

Hi,

Due to too few participants and low activity, tomorrow's meeting has been 
cancelled.
The next virtual meeting is in two weeks.

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

Re: [riot-devel] RIOT Porting other platform

[Ludwig Ortmann]

Hi Shishir,

can you please rephrase the question?

Cheers, Ludwig

On Tue, Dec 30, 2014 at 04:34:39PM +0530, shishir tiwari wrote:
> hi Ludwig,
> 
> 
> Is Porting for ARC600/ ARC700 (Synopsys) has been done. Any idea?
> 
> Thanks
> Shishir tiwari
> 
> On Wed, Dec 24, 2014 at 8:13 PM, Ludwig Ortmann
>  wrote:
> > Hello Shishir,
> >
> > Please have a look at the porting guide in our wiki:
> > https://github.com/RIOT-OS/RIOT/wiki/Porting-Guide
> > Also keep in mind that all files have to have an LGPL 2.1 compatible 
> > license.
> > Finally, you should look at the  development procedures and coding 
> > conventions:
> > https://github.com/RIOT-OS/RIOT/wiki/Development-procedures
> > https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions
> >
> > Happy hacking!
> > Cheers, Ludwig
> >
> > Am 24. Dezember 2014 15:24:01 MEZ, schrieb shishir tiwari 
> > :
> >>Hi All ,
> >>
> >>I want to port RIOT OS to new platform (ARC 600 microncontroller ).
> >>What is need to done.
> >>
> >>Any documentation is available for this.
> >>
> >>
> >>thanks
> >>___
> >>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 list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT Porting other platform

[Ludwig Ortmann]

Hello Shishir,

Please have a look at the porting guide in our wiki:
https://github.com/RIOT-OS/RIOT/wiki/Porting-Guide
Also keep in mind that all files have to have an LGPL 2.1 compatible license.
Finally, you should look at the  development procedures and coding conventions:
https://github.com/RIOT-OS/RIOT/wiki/Development-procedures
https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions

Happy hacking!
Cheers, Ludwig

Am 24. Dezember 2014 15:24:01 MEZ, schrieb shishir tiwari 
:
>Hi All ,
>
>I want to port RIOT OS to new platform (ARC 600 microncontroller ).
>What is need to done.
>
>Any documentation is available for this.
>
>
>thanks
>___
>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] Suggested new platform for RIOT: calling for volunteers

[Ludwig Ortmann]

Hi Kevin,

"cheap" starter kit is relative, but the MCU sound interesting indeed!
Presumably I won't have any time to port, but I'd be happy to help with 
reviewing ;)

In case anyone is interested in actually porting this and only held back by the 
investment, I'm confident a sponsored starter kit can be arranged.

Jolly seasons greetings everyone!
Cheers, Ludwig

Am 23. Dezember 2014 14:30:11 MEZ, schrieb "ROUSSEL Kévin" 
:
>Hello everyone,
>
>Since RIOT has been adapted to the AVR architecture, there is a chip 
>that--I think--would be a great platform for development and
>production: 
>the ATmega 256RFR2.
>
>The RFR2 family is presented here:
> http://www.atmel.com/devices/ATMEGA256RFR2.aspx
>but to sum it up, this MCU has the following advantages:
>- the well-known, low-power AVR 8-bit architecture
>- an integrated 802.15.4 transceiver, quite similar to the AT86RF231
>- 256 Kb or Flash and, even better, 32 Kb of RAM (a huge amount for an 
>8-bit MCU!)
>- a complete set of integrated peripherals: the usual timers, PWM,
>UART, 
>SPI, I2C, ADC, JTAG... as well as a some less common, very nice
>features 
>like a true random number generator or a 32-bit symbol counter
>- it is available in a cheap "starter kit" board that is in itself a 
>simple but functional mote with MCU, antenna socket, temperature
>sensor, 
>and extension slots (see
>http://www.atmel.com/tools/ATMEGA256RFR2-XSTK.aspx)
>
>As such, it seems to make an ideal platform for future motes, and I 
>think it is bound to be quite successful in the market.
>
>That's why I plan to make an extensive use of this device as soon as 
>possible.
>
>As usual, I will start the port and try to have it up and running as 
>fast as I can, but since I am now in the last year of my PhD, my time 
>schedule is now really tight.
>Consequently, it will be extremely hard for me to push the porting 
>effort further that the bare minimum (CPU and transceiver). It means 
>that my code probably won't represent a "clean", production-ready port 
>by itself.
>
>Since running RIOT on this platform would benefit everyone in the 
>community, it would be nice if I could receive help in this task; 
>knowing that I will most likely be the first to use it, and as such 
>feedback on the port is guaranteed.
>
>Thanks in advance, and best regards.
>-- 
>
>
>  Kévin Roussel
>  Doctorant, projet LAR
>  Équipe MADYNES, INRIA Nancy Grand-Est / LORIA
>  Tél. : +33 3 54 95 86 27
>  kevin.rous...@inria.fr
>
>___
>devel mailing list
>devel@riot-os.org
>http://lists.riot-os.org/mailman/listinfo/devel

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

Re: [riot-devel] RIOT on Arduino UNO

[Ludwig Ortmann]

Hi,

On Mon, Dec 22, 2014 at 08:44:55AM +0100, Martine Lenders wrote:
> 2014-12-21 21:13 GMT+01:00 eric fleury :
> > On 21 déc. 2014, at 20:15, Sudarshan S 
> > 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?

http://arduino.cc/en/Main/arduinoBoardUno says:
"32 KB (ATmega328) of which 0.5 KB used by bootloader"

About the original question:
I don't think adding RAM via SPI makes any sense in order to work
around the memory limitations imposed by RIOT's code.
The way it works is that you need to actively store/load data to/from
the external RAM. So you would have to rewrite code that needs more
memory to work on smaller chunks and take care of loading/storing them
in between steps. Such a change would most likely not be incorporated
into RIOT.
Now, one could think about swapping entire threads, but this would
make thread switches very very slow (no acceptable realtime behavior
anymore). Also, this would probably require changes in several other
places like the messaging code. These changes would most likely not be
incorporated into RIOT either.

But the most important question is: What do you want to do with it?
If you just want to drive I/O and don't need a shell, I guess this
could work. What will definitely not work with this little memory is
RIOT's network stack.

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

Re: [riot-devel] Switch to BSD?

[Ludwig Ortmann]

Hi,

On Thu, Dec 18, 2014 at 02:35:58PM +0100, Kaspar Schleiser wrote:
> On 12/18/2014 02:10 PM, Ludwig Ortmann wrote:
> >>>>(L)GPL tries to put some restrictions on that. Mostly, the source code
> >>>>cannot realistically be sold as long it's (L)GPL.
> >>>
> >>>This is not correct (depending on your definition of code and selling
> >>>of course).
> >>I know that you know what my definition of selling is with respect to the
> >>discussion.
> >
> >Actually, I'm not sure this is the case, please elaborate.
> If you sell (L)GPLed source code, that code *must* be under (L)GPL, so the
> first buyer can freely distribute it (under those libraries terms).
> 
> So practically you can sell that code only once.

Maybe I'm missing something, but the BSDs say:

"""
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this
   list of conditions and the following disclaimer. 
...
"""

This means that if you sell BSD licensed source code to someone, they
can freely distribute it just like they could with LGPL'd code.
The BSD licenses do not allow you to change the license ("sublicense") [1].

Cheers, Ludwig

[1] Exemplary web search result:
https://forums.freebsd.org/threads/how-to-sublicense.47390/
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Switch to BSD?

[Ludwig Ortmann]

Hi,

On Wed, Dec 17, 2014 at 01:06:24PM +0100, Kaspar Schleiser wrote:
> Hey,
> 
> On 12/16/2014 06:09 PM, Ludwig Ortmann wrote:
> >>(L)GPL tries to put some restrictions on that. Mostly, the source code
> >>cannot realistically be sold as long it's (L)GPL.
> >
> >This is not correct (depending on your definition of code and selling
> >of course).
> I know that you know what my definition of selling is with respect to the
> discussion.

Actually, I'm not sure this is the case, please elaborate.

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

Re: [riot-devel] Switch to BSD?

[Ludwig Ortmann]

Hi,

On Thu, Dec 18, 2014 at 01:46:52PM +0100, Kaspar Schleiser wrote:
> BSD changes the whole picture. It makes me feel exploited if I contribute a
> lot of ressources building free roads and others just invest a little but
> profit from the combination of all roads (even charging me) instead of
> pooling ressources to improve the free network and finding a way to profit
> from something else.

I don't understand where BSD changes this picture in contrast to LGPL.
In either case, we provide building blocks which allow others to
create proprietary applications, services and devices.

Please explain without analogies and use concrete examples instead.

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

Re: [riot-devel] Switch to BSD?

[Ludwig Ortmann]

Hi,

On Tue, Dec 16, 2014 at 06:42:37PM +0100, Oleg Hahm wrote:
> > So in that case, you can't even (legally) sell a product based on RIOT
> > without it (and you) being mentioned.
> 
> Referring to a discussion I had with Hauke over lunch: would have RIOT to be
> mentioned only in the code or on the sold product (let's say an Internet
> connected toy dinosaur)?

After thinking a bit about this and searching a bit on the web [1], I
conclude that the quoted MIT license requires this implicitly while
the BSD licenses are explicit about it.

Cheers, Ludwig

[1]
Exemplary result:
http://info.protecode.com/bid/33956/How-you-can-comply-with-open-source-license-attribution
"""
Most licenses, open source or commercial, require that a copy of the
copyright, patent, trademark, and attribution notices from the source
software be distributed verbatim with the product using that software.
Examples are GNU Public License (GPL), Microsoft Public License (MPL),
and MIT license.  Note that even if the source code is not distributed
with your product, the copyright and other attribution must be
distributed with your software.
"""
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Switch to BSD?

[Ludwig Ortmann]

Hi,

On Tue, Dec 16, 2014 at 05:58:20PM +0100, Kaspar Schleiser wrote:
> On 12/16/2014 03:12 PM, Emmanuel Baccelli wrote:
> >BSDing turns it into work I do for other companies, for free. I will
> >probably not contribute much this way, unless I become one of the
> >companies taking RIOT and selling it somehow.
> >
> >
> >I don't see how any company could "sell RIOT". RIOT is more a component
> >of something "bigger" that is the actual business. So as a RIOT
> >developer, it's not like there is no room to exploit this situation,
> >should it occur. Isn't this win-win, essentially?
> My work on RIOT is mostly about code, code review and development
> environment. I'm aware that "RIOT" is more than the source, but the license
> mostly affects that part.
> 
> If you want to sell an Iot OS software product, as soon as RIOT is *BSD'ed,
> all of that can be taken *as is* and then be sold under whatever terms
> anyone seems fit. Always based on that code & infrastructure work.
> 
> (L)GPL tries to put some restrictions on that. Mostly, the source code
> cannot realistically be sold as long it's (L)GPL.

This is not correct (depending on your definition of code and selling
of course).

http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMoney
"""
Yes, the GPL allows everyone to do this. The right to sell copies is
part of the definition of free software. Except in one special
situation, there is no limit on what price you can charge. (The one
exception is the required written offer to provide source code that
must accompany binary-only release.)
"""

and

http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowDownloadFee
"""
Yes. You can charge any fee you wish for distributing a copy of the
program. If you distribute binaries by download, you must provide
“equivalent access” to download the source—therefore, the fee to
download source may not be greater than the fee to download the
binary.
"""


Also, on a related note, the MIT license (for example) says:
"""
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
"""

So, even if someone sells the code under the MIT license, you're still
visibly the copyright holder.

In addition to that, the BSD licenses also contain:
"""
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the
   distribution.
"""

So in that case, you can't even (legally) sell a product based on RIOT
without it (and you) being mentioned.

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

Re: [riot-devel] AVR platform maturity

[Ludwig Ortmann]

Hi Kévin,

On Tue, Dec 16, 2014 at 03:05:52PM +0100, ROUSSEL Kévin wrote:
> It's been a few months now since an AVR device (Arduino Mega) port has been
> available in RIOT.
> 
> Does somebody use it regularly? I would like to try some developments on
> AVR, and I was wondering if AVR support was production-ready, or if there
> was still "rough edges" to aware of?

https://github.com/RIOT-OS/RIOT/wiki/Board%3A-Arduino-Mega2560#state
"""
While there is basic support in RIOT, there are still some parts missing:
- Timer implementation needs love (ideally simulate a 32bit timer by
  adding an overflow counter to the implementation)
- LPM driver missing
- GPIO driver missing
- SPI/I2C/TWI driver missing
- ADC driver missing
"""

PWM is also missing, even from the list of missing things ;)

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

Re: [riot-devel] Switch to BSD?

[Ludwig Ortmann]

Hi,

On Mon, Dec 15, 2014 at 05:32:14PM +0100, Martine Lenders wrote:
> Hi,
> speaking of proprietary smart phones: seems like Android decided against
> LGPL for more or less the same reasons as we discuss right now:
> https://source.android.com/source/licenses.html#why-apache-software-license.

But they are explicitly not talking about the kernel (not that they
could change it if the wanted, it being Linux under GPL2 and all). It
doesn't say whether they would have chosen differently for the kernel
if they were at liberty to do so.

Of course we could do a similar thing and get crazy with licenses. GPL
for /core, Apache for /sys, BSD for /cpu, /drivers, ... ;)

Finally, the post-sale support situation of Android devices is a point
against letting manufacturers do whatever they want with the code, at
least according to my personal views on the longevity of computing
devices.

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

Re: [riot-devel] Switch to BSD?

[Ludwig Ortmann]

Hi,

On Mon, Dec 15, 2014 at 05:23:32PM +0100, Kaspar Schleiser wrote:
> On 12/15/2014 05:07 PM, Oleg Hahm wrote:
> >>Giving away source code which strenghtens those is contraproductive to the
> >>common good.
> >
> >Says the man earning a shit load of money from one of these evil companies,
> >using a proprietary smart phone, and buying Facebook goggles. ;-)
> That implies I'm buying Facebook goggles. For the record: that's not the
> case.
> 
> >Let's keep the discussion non-political/-philosophical - otherwise there's no
> >end.
> Sure. Keep the discussion "GPL or not" non-political/-philosophical. Why
> discuss at all?

While I think this discussion can not be lead without political or
philosophical considerations, I agree that this particular subtopic is
noise in the discussion. Let's get back on topic.

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

Re: [riot-devel] Switch to BSD?

[Ludwig Ortmann]

Hi,

On Mon, Dec 15, 2014 at 01:08:24PM +0100, Kaspar Schleiser wrote:
> On 12/15/2014 11:10 AM, Ludwig Ortmann wrote:
> >I'd rather add a static linking exception to our
> >current license (or switch to GPL with linking exception which amounts
> >to the same as far as I remember)
> What kind of "static linking exception" do you have in mind?

The regular kind ;) http://en.wikipedia.org/wiki/GPL_linking_exception
I'm not aware if there is another kind with different characteristics.

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

Re: [riot-devel] Switch to BSD?

[Ludwig Ortmann]

Hi,

All in all, dual licensing is an interesting thought, but I'm afraid
it inevitably leads to extra work and frustration.
Because the users of the commercial branch will most likely be a major
contributer of resources, the "free" branch would end up being treated
as a second class citizen.
(Please refer me to examples where this has not been the outcome if
they exist.)


As for the general topic of relicensing:

I would wish for a license with patent clauses for Christmas. But such
a clause is supposed to scare the big company lawyers away. So, a
switch to Apache would probably not help with the goal of getting big
companies to consider RIOT.

Personally, I'm not convinced these companies are really needed for
RIOT to stay alive. In order to cater to commercial use *today*
(because we don't currently have tools to help satisfy the linking
clause of the LGPL), I'd rather add a static linking exception to our
current license (or switch to GPL with linking exception which amounts
to the same as far as I remember). I am aware that this probably makes
the license even more troublesome for the lawyers in question as it
would probably need extra ratification, but it would help smaller
companies.

One aspect of this rationale is that we currently have several
interested smaller companies, while the big companies could as well
implement the missing bits themselves.

That being said I would also be excited to see some bigger company
contribute to RIOT. If switching to MIT is what it takes to achieve
this, I'm fine with it.

Cheers,
Ludwig


On Mon, Dec 15, 2014 at 09:51:13AM +0100, ROUSSEL Kévin wrote:
> Hello everyone,
> 
> Maybe was it already envisioned, but another strategy would be dual
> licensing, something akin to what FreeRTOS does for example.
> 
> Using this scheme:
> * we got (L)GPL by default, for academic contributors and everyone that has
> nothing against open-source;
> * the same code can be licensed under an alternative license for those that
> don't want to contribute back. Financial resources could even be drawn from
> this, as the project could charge for such a proprietary license.
> 
> Of course, I guess this approach has its drawbacks; I was just citing a
> possible alternative, I have not really thought about it.
> 
> Best regards,
> 
> 
> KR
> 
> 
> 
> Le 12/12/2014 17:55, Emmanuel Baccelli a écrit :
> >Hi Johann,
> >
> >Le 12 déc. 2014 00:48, "Johann Fischer"  >> a écrit :
> > >
> > > Can you explain exactly what you expect of licence change? That more
> >hardware
> > > will be supported? That RIOT will be more spread?
> >
> >The motivation for a more permissive license now is that the RIOT
> >community has significantly more chances to spread and reach a critical
> >mass fast enough to not let the current momentum go to waste.
> >
> >There might be other strategies to reach critical mass, but for now,
> >none have been brought forward.
> >
> >Reaching critical mass is arguably an important goal. If the community
> >does not reach this goal, it might not survive -- and none of us wants that.
> >
> >Thus this thread, to propose and discuss a strategy based on a license
> >change allowing direct and indirect interactions with more industrial
> >partners.
> >
> >I agree this strategy is not without potential drawbacks. Other strategy
> >proposals are very welcome ;). My main point is: we need a strategy.
> >
> >Cheers,
> >
> >Emmanuel
> >
> >
> >
> >
> >
> >
> >
> >___
> >devel mailing list
> >devel@riot-os.org
> >http://lists.riot-os.org/mailman/listinfo/devel
> >
> 
> -- 
> 
> 
>  Kévin Roussel
>  Doctorant, projet LAR
>  Équipe MADYNES, INRIA Nancy Grand-Est / LORIA
>  Tél. : +33 3 54 95 86 27
>  kevin.rous...@inria.fr
> 
> ___
> 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] Problem with RPL-UDP example for SAMR21

[Ludwig Ortmann]

Hi,

Maybe I misunderstand what you mean by "probably system architecture".. please 
elaborate if none of this makes any sense.

Regarding memory requirements, this depends on your application entirely.
How many threads does it need, how much memory do they each need.. You could 
sketch the application and use the ps command to see how much memory is 
actually being used within each thread.
Depending on which modules you want use, they might introduce more threads. So 
make sure to add everything you are going to use to the application Makefile.

As for the need of dynamic heap memory (via malloc), maybe Martine and Cenk 
could shed some light on how much is needed?

Finally, there is some room for optimization in the network stack.
In case your applications needs are too large, there should be some low hanging 
fruit.
Also, the stack is under heavy reconstruction right now, so it's kind of hard 
to predict for me how the situation will look in a month.. Martine and Cenk, 
maybe you want to do some wild guessing? ;)

By the way:
If you want to start optimizing but don't know where to start, I wrote 
https://github.com/LudwigOrtmann/otm to quickly assess static memory 
consumption in a graphical manner.

For rpl (1997 rebased on master) on the sam it looks like this (BSS+data): 
http://ludwig.spline.inf.fu-berlin.de/samr21-xpro%20rpl_udp%20RAM.jpeg
(368 + 32144 = 32144/32768 RAM)

After merging 2155, it changes to:
http://ludwig.spline.inf.fu-berlin.de/samr21-xpro%20rpl_udp%20RAM%202155.jpeg
(368 + 29016 = 29384/32768 RAM)

Cheers, Ludwig

PS:
The command to create the graphics was:
`otm.py -t dDbB bin/samr21-xpro/rpl_udp.elf -m 60`
`-t dDbB` selects un/Initialized data and BSS symbols, so only RAM is shown.
`-m 60` filters out symbols which are smaller than 60 bytes to unclutter the 
plot.
Note that the box sizes are proportional to the sum of all symbols shown, 
therefore the image itself does not shrink.
The otm branch is "section_hue_2".

Am 14. Dezember 2014 09:00:34 MEZ, schrieb Akshay Mishra :
>Hello RIOTers,
>   I wanted to know if the 32KB of SRAM on the SAMR21 will be
>sufficient to run the RPL ? Is there some footprint statistic that one
>can
>consider when planning a probable system architecture.
>
>-Akshay
>
>On 12 December 2014 at 19:28, Akshay Mishra  wrote:
>>
>> Thanks Ludwig,
>> We are using the SAMR21 and the bss is nearly 32k which is as good as
>the
>> RAM size (for the rpl_udp) ! No wonder it crashes.
>>
>> -Akshay
>>
>>
>> On 12 December 2014 at 19:25, Ludwig Ortmann
>
>> wrote:
>>>
>>> Hi,
>>>
>>> sorry, I misread the "and RPL" to mean "without RPL" because I had
>>> that question the other day.
>>> To get sizes with RPL, just use the examples/rpl_udp instead of
>>> sixlowapp from applications.
>>>
>>> BTW: You might also want to look at this while you're at it.
>>> https://github.com/RIOT-OS/RIOT/pull/2155
>>>
>>> It should reduce the RAM need quite a bit.
>>>
>>> Cheers, Luwig
>>>
>>> On Fri, Dec 12, 2014 at 02:44:17PM +0100, Ludwig Ortmann wrote:
>>> > Hi Akshay,
>>> >
>>> > that depends on the board.
>>> >
>>> > Please checkout this application
>>> > https://github.com/RIOT-OS/applications/tree/master/sixlowapp
>>> > and compile (make clean all) it for your board.
>>> >
>>> > Note: This only works if there is a transceiver configured. For
>the
>>> > samr21-xpro that means you have to merge the branch of the pull
>>> > request which adds transceiver support first.
>>> >
>>> > Afterwards, add the values printed for bss and data to get the
>static
>>> > RAM usage.
>>> > Similarly, add bss and text to calculate ROM usage.
>>> >
>>> > Cheers, Ludwig
>>> >
>>> > On Fri, Dec 12, 2014 at 06:59:58PM +0530, Akshay Mishra wrote:
>>> > > Hello Oleg,
>>> > >   What is the RAM size required for running a RIOT with
>full
>>> > > 6LoWPAN and RPL ?
>>> > >
>>> > > -Akshay
>>> > >
>>> > > On 9 December 2014 at 20:20, Oleg Hahm 
>wrote:
>>> > > >
>>> > > > Hi Maxence!
>>> > > >
>>> > > > > Did you find something about my problem ?
>>> > > >
>>> > > > Sorry for the lack of responsiveness. I had some weird
>problems
>>> with the
>>> > > > board
>>> > > > last Friday (couldn't get any outp

Re: [riot-devel] Problem with RPL-UDP example for SAMR21

[Ludwig Ortmann]

Hi,

sorry, I misread the "and RPL" to mean "without RPL" because I had
that question the other day.
To get sizes with RPL, just use the examples/rpl_udp instead of
sixlowapp from applications.

BTW: You might also want to look at this while you're at it.
https://github.com/RIOT-OS/RIOT/pull/2155

It should reduce the RAM need quite a bit.

Cheers, Luwig

On Fri, Dec 12, 2014 at 02:44:17PM +0100, Ludwig Ortmann wrote:
> Hi Akshay,
> 
> that depends on the board.
> 
> Please checkout this application
> https://github.com/RIOT-OS/applications/tree/master/sixlowapp
> and compile (make clean all) it for your board.
> 
> Note: This only works if there is a transceiver configured. For the
> samr21-xpro that means you have to merge the branch of the pull
> request which adds transceiver support first.
> 
> Afterwards, add the values printed for bss and data to get the static
> RAM usage.
> Similarly, add bss and text to calculate ROM usage.
> 
> Cheers, Ludwig
> 
> On Fri, Dec 12, 2014 at 06:59:58PM +0530, Akshay Mishra wrote:
> > Hello Oleg,
> >   What is the RAM size required for running a RIOT with full
> > 6LoWPAN and RPL ?
> > 
> > -Akshay
> > 
> > On 9 December 2014 at 20:20, Oleg Hahm  wrote:
> > >
> > > Hi Maxence!
> > >
> > > > Did you find something about my problem ?
> > >
> > > Sorry for the lack of responsiveness. I had some weird problems with the
> > > board
> > > last Friday (couldn't get any output using the rpl_udp example, while 
> > > other
> > > examples work fine). Will investigate further and let you know as soon as 
> > > I
> > > figure something out.
> > >
> > > Cheers,
> > > Oleg
> > > --
> > > panic("Fod fight!");
> > > linux-2.2.16/drivers/scsi/aha1542.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
> 
> ___
> 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] Problem with RPL-UDP example for SAMR21

[Ludwig Ortmann]

Hi Akshay,

that depends on the board.

Please checkout this application
https://github.com/RIOT-OS/applications/tree/master/sixlowapp
and compile (make clean all) it for your board.

Note: This only works if there is a transceiver configured. For the
samr21-xpro that means you have to merge the branch of the pull
request which adds transceiver support first.

Afterwards, add the values printed for bss and data to get the static
RAM usage.
Similarly, add bss and text to calculate ROM usage.

Cheers, Ludwig

On Fri, Dec 12, 2014 at 06:59:58PM +0530, Akshay Mishra wrote:
> Hello Oleg,
>   What is the RAM size required for running a RIOT with full
> 6LoWPAN and RPL ?
> 
> -Akshay
> 
> On 9 December 2014 at 20:20, Oleg Hahm  wrote:
> >
> > Hi Maxence!
> >
> > > Did you find something about my problem ?
> >
> > Sorry for the lack of responsiveness. I had some weird problems with the
> > board
> > last Friday (couldn't get any output using the rpl_udp example, while other
> > examples work fine). Will investigate further and let you know as soon as I
> > figure something out.
> >
> > Cheers,
> > Oleg
> > --
> > panic("Fod fight!");
> > linux-2.2.16/drivers/scsi/aha1542.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

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

Re: [riot-devel] SAMR21 Implementation

[Ludwig Ortmann]

Hi,

On Thu, Dec 04, 2014 at 09:07:31AM +0100, Baptiste Clenet wrote:
> I've got some questions about the implementation of RIOT on the SAMR21:
> 
>- RNG: There is no HW module in samd21 but the transceiver at86rf233
>provides one (see 40.2 in datasheet). Should we implement it anyway?

Yes, the source for random data is up to the platform. As long as it's
documented it can even be an unconnected pin of the CPU.

>- What's the difference between RTT (Real Time Timer) and RTC (Real Time
>Counter) for the SAMR21?

>From the RIOT documentation of the RTC interface:
"Low-level RTC (Real Time Clock) peripheral driver."
The RTC is intended to count calendar time, not system time. Therefore
it is treated differently from other timers. Refer to the R21
datasheet chapter 17. for details.

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

Re: [riot-devel] vtimer in native port

[Ludwig Ortmann]

Hi,

Thank you!

Cheers, Ludwig

On Tue, Nov 25, 2014 at 08:24:54PM +, Hiesgen, Raphael wrote:
> Hi Ludwig,
> 
> my setup uses CAF (C++) together with RIOT on a 64 bit Linux (Debian).
> 
> I created a branch in my RIOT fork which includes all the code to make the 
> example work [1]. You can find it under "test/cpp_timer/“. It depends on an 
> implementation for thread, mutex and condition_variable that is mostly STL 
> compliant and is based on RIOT. Not STL compliant is, e.g., the chrono 
> implementation used in the test … (it is atm. only sufficient to make CAF 
> work).
> 
> I added your fixes to the branch. Btw, there are some errors on OS X [2].
> 
> Raphael
> 
> 
> [1] https://github.com/josephnoir/RIOT/tree/topic/vtimer
> [2] https://gist.github.com/josephnoir/a46ce587c87b43a11222
> 
> > On Nov 25, 2014, at 6:11 PM, Ludwig Ortmann  
> > wrote:
> > 
> > Hi,
> > 
> > any chance for me to get access to the application aka test case?
> > Also the specs of your system might be interesting (CPU).
> > 
> > Cheers, Ludwig
> > 
> > On Tue, Nov 25, 2014 at 05:56:19PM +0100, Raphael Hiesgen wrote:
> >> Hi Ludwig,
> >> 
> >> this does not change the behavior of my tests:
> >> * multiple timers still work
> >> * short consecutive ones stop after a while
> >> 
> >> Raphael
> >> 
> >> On Mon, 2014-11-24 at 18:57 +0100, Ludwig Ortmann wrote:
> >>> Hi Raphael,
> >>> 
> >>> please test again.
> >>> 
> >>> The last commit is a kludge, but should at least work for most cases
> >>> until I come up with a better solution.
> >>> 
> >>> Cheers, Ludwig
> >>> 
> >>> On Mon, Nov 24, 2014 at 02:14:18PM +0100, Ludwig Ortmann wrote:
> >>>> Hi,
> >>>> 
> >>>> Thanks, I'll send a notification when there is further progress.
> >>>> 
> >>>> Cheers, Ludwig
> >>>> 
> >>>> Am 24. November 2014 14:06:52 MEZ, schrieb "Hiesgen, Raphael" 
> >>>> :
> >>>>> Hello Ludwig,
> >>>>> 
> >>>>> looks better. Some of the tests that did not work before, work fine
> >>>>> now, e.g. using multiple timers.
> >>>>> Setting a consecutive timer around 1 milliseconds still seem to end up
> >>>>> in a freeze.
> >>>>> Most often with the error: "schedule_timer(): timer is already due (3),
> >>>>> mitigating.”.
> >>>>> 
> >>>>> Thanks,
> >>>>> Raphael
> >>>>> 
> >>>>>> On Nov 22, 2014, at 4:08 PM, Ludwig Ortmann
> >>>>>  wrote:
> >>>>>> 
> >>>>>> Hi Raphael,
> >>>>>> 
> >>>>>> On Wed, Nov 19, 2014 at 06:51:25PM +0100, Ludwig Ortmann wrote:
> >>>>>>> On Wed, Nov 19, 2014 at 05:12:42PM +, Hiesgen, Raphael wrote:
> >>>>>>>> Hey there,
> >>>>>>>> 
> >>>>>>>> more questions! We encountered some problems using vtimer.  For
> >>>>> once, setting multiple short timers consecutively leads to a segfault.
> >>>>> We tired this with the timer_msg test reducing the intervals to around
> >>>>> 150ms.
> >>>>>>>> 
> >>>>>>>> A second problem showed up when setting multiple timers at once,
> >>>>> e.g., from different threads. After a short time the "timer is already
> >>>>> due” warning from schedule timer in hwtimer_cpu.c flashed and soon
> >>>>> after the timers simply stopped.
> >>>>>>>> 
> >>>>>>>> So, I am not sure if these problems originate in our own
> >>>>> implementation or the native port. In order to test the short timers,
> >>>>> we executed the same program on the iot-lab_M3 board, where it worked
> >>>>> even with much shorter timers. 
> >>>>>>>> 
> >>>>>>>> Anything I should know?
> >>>>>>> 
> >>>>>>> There is some problem I didn't get around to fixing, yes.
> >>>>>>> I guess your issue it is related to this:
> >>>>>>> https://github.com/RIOT-OS/RIOT/issues/715
> >>>>>> 
> >>>>>> Could you

Re: [riot-devel] vtimer in native port

[Ludwig Ortmann]

Hi,

any chance for me to get access to the application aka test case?
Also the specs of your system might be interesting (CPU).

Cheers, Ludwig

On Tue, Nov 25, 2014 at 05:56:19PM +0100, Raphael Hiesgen wrote:
> Hi Ludwig,
> 
> this does not change the behavior of my tests:
> * multiple timers still work
> * short consecutive ones stop after a while
> 
> Raphael
> 
> On Mon, 2014-11-24 at 18:57 +0100, Ludwig Ortmann wrote:
> > Hi Raphael,
> > 
> > please test again.
> > 
> > The last commit is a kludge, but should at least work for most cases
> > until I come up with a better solution.
> > 
> > Cheers, Ludwig
> > 
> > On Mon, Nov 24, 2014 at 02:14:18PM +0100, Ludwig Ortmann wrote:
> > > Hi,
> > > 
> > > Thanks, I'll send a notification when there is further progress.
> > > 
> > > Cheers, Ludwig
> > > 
> > > Am 24. November 2014 14:06:52 MEZ, schrieb "Hiesgen, Raphael" 
> > > :
> > > >Hello Ludwig,
> > > >
> > > >looks better. Some of the tests that did not work before, work fine
> > > >now, e.g. using multiple timers.
> > > >Setting a consecutive timer around 1 milliseconds still seem to end up
> > > >in a freeze.
> > > >Most often with the error: "schedule_timer(): timer is already due (3),
> > > >mitigating.”.
> > > >
> > > >Thanks,
> > > >Raphael
> > > >
> > > >> On Nov 22, 2014, at 4:08 PM, Ludwig Ortmann
> > > > wrote:
> > > >> 
> > > >> Hi Raphael,
> > > >> 
> > > >> On Wed, Nov 19, 2014 at 06:51:25PM +0100, Ludwig Ortmann wrote:
> > > >>> On Wed, Nov 19, 2014 at 05:12:42PM +, Hiesgen, Raphael wrote:
> > > >>>> Hey there,
> > > >>>> 
> > > >>>> more questions! We encountered some problems using vtimer.  For
> > > >once, setting multiple short timers consecutively leads to a segfault.
> > > >We tired this with the timer_msg test reducing the intervals to around
> > > >150ms.
> > > >>>> 
> > > >>>> A second problem showed up when setting multiple timers at once,
> > > >e.g., from different threads. After a short time the "timer is already
> > > >due” warning from schedule timer in hwtimer_cpu.c flashed and soon
> > > >after the timers simply stopped.
> > > >>>> 
> > > >>>> So, I am not sure if these problems originate in our own
> > > >implementation or the native port. In order to test the short timers,
> > > >we executed the same program on the iot-lab_M3 board, where it worked
> > > >even with much shorter timers. 
> > > >>>> 
> > > >>>> Anything I should know?
> > > >>> 
> > > >>> There is some problem I didn't get around to fixing, yes.
> > > >>> I guess your issue it is related to this:
> > > >>> https://github.com/RIOT-OS/RIOT/issues/715
> > > >> 
> > > >> Could you try if/how this changes the effect you are seeing in
> > > >native?
> > > >> 
> > > >> https://github.com/RIOT-OS/RIOT/pull/2071
> > > >> 
> > > >> I am still able to freeze the timer (especially in Valgrind), but it
> > > >> does so less often.
> > > >> 
> > > >> Cheers, Ludwig
> > > >> ___
> > > >> 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 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] vtimer in native port

[Ludwig Ortmann]

Hi Raphael,

please test again.

The last commit is a kludge, but should at least work for most cases
until I come up with a better solution.

Cheers, Ludwig

On Mon, Nov 24, 2014 at 02:14:18PM +0100, Ludwig Ortmann wrote:
> Hi,
> 
> Thanks, I'll send a notification when there is further progress.
> 
> Cheers, Ludwig
> 
> Am 24. November 2014 14:06:52 MEZ, schrieb "Hiesgen, Raphael" 
> :
> >Hello Ludwig,
> >
> >looks better. Some of the tests that did not work before, work fine
> >now, e.g. using multiple timers.
> >Setting a consecutive timer around 1 milliseconds still seem to end up
> >in a freeze.
> >Most often with the error: "schedule_timer(): timer is already due (3),
> >mitigating.”.
> >
> >Thanks,
> >Raphael
> >
> >> On Nov 22, 2014, at 4:08 PM, Ludwig Ortmann
> > wrote:
> >> 
> >> Hi Raphael,
> >> 
> >> On Wed, Nov 19, 2014 at 06:51:25PM +0100, Ludwig Ortmann wrote:
> >>> On Wed, Nov 19, 2014 at 05:12:42PM +, Hiesgen, Raphael wrote:
> >>>> Hey there,
> >>>> 
> >>>> more questions! We encountered some problems using vtimer.  For
> >once, setting multiple short timers consecutively leads to a segfault.
> >We tired this with the timer_msg test reducing the intervals to around
> >150ms.
> >>>> 
> >>>> A second problem showed up when setting multiple timers at once,
> >e.g., from different threads. After a short time the "timer is already
> >due” warning from schedule timer in hwtimer_cpu.c flashed and soon
> >after the timers simply stopped.
> >>>> 
> >>>> So, I am not sure if these problems originate in our own
> >implementation or the native port. In order to test the short timers,
> >we executed the same program on the iot-lab_M3 board, where it worked
> >even with much shorter timers. 
> >>>> 
> >>>> Anything I should know?
> >>> 
> >>> There is some problem I didn't get around to fixing, yes.
> >>> I guess your issue it is related to this:
> >>> https://github.com/RIOT-OS/RIOT/issues/715
> >> 
> >> Could you try if/how this changes the effect you are seeing in
> >native?
> >> 
> >> https://github.com/RIOT-OS/RIOT/pull/2071
> >> 
> >> I am still able to freeze the timer (especially in Valgrind), but it
> >> does so less often.
> >> 
> >> Cheers, Ludwig
> >> ___
> >> 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 list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] vtimer in native port

[Ludwig Ortmann]

Hi,

Thanks, I'll send a notification when there is further progress.

Cheers, Ludwig

Am 24. November 2014 14:06:52 MEZ, schrieb "Hiesgen, Raphael" 
:
>Hello Ludwig,
>
>looks better. Some of the tests that did not work before, work fine
>now, e.g. using multiple timers.
>Setting a consecutive timer around 1 milliseconds still seem to end up
>in a freeze.
>Most often with the error: "schedule_timer(): timer is already due (3),
>mitigating.”.
>
>Thanks,
>Raphael
>
>> On Nov 22, 2014, at 4:08 PM, Ludwig Ortmann
> wrote:
>> 
>> Hi Raphael,
>> 
>> On Wed, Nov 19, 2014 at 06:51:25PM +0100, Ludwig Ortmann wrote:
>>> On Wed, Nov 19, 2014 at 05:12:42PM +, Hiesgen, Raphael wrote:
>>>> Hey there,
>>>> 
>>>> more questions! We encountered some problems using vtimer.  For
>once, setting multiple short timers consecutively leads to a segfault.
>We tired this with the timer_msg test reducing the intervals to around
>150ms.
>>>> 
>>>> A second problem showed up when setting multiple timers at once,
>e.g., from different threads. After a short time the "timer is already
>due” warning from schedule timer in hwtimer_cpu.c flashed and soon
>after the timers simply stopped.
>>>> 
>>>> So, I am not sure if these problems originate in our own
>implementation or the native port. In order to test the short timers,
>we executed the same program on the iot-lab_M3 board, where it worked
>even with much shorter timers. 
>>>> 
>>>> Anything I should know?
>>> 
>>> There is some problem I didn't get around to fixing, yes.
>>> I guess your issue it is related to this:
>>> https://github.com/RIOT-OS/RIOT/issues/715
>> 
>> Could you try if/how this changes the effect you are seeing in
>native?
>> 
>> https://github.com/RIOT-OS/RIOT/pull/2071
>> 
>> I am still able to freeze the timer (especially in Valgrind), but it
>> does so less often.
>> 
>> Cheers, Ludwig
>> ___
>> 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