Re: [riot-devel] RIOT developers monthly meeting

[Thomas Eichinger]

Hi,

I forgot, but was there a particular reason having these on Mondays? 

For me personally it would be easier to tune in any other day of the week. I’m 
just generally asking since my actual RIOT development availability is very 
limited anyways. 

Best, Thomas 

> On Nov 28, 2017, at 4:59 AM, Francisco Javier Acosta Padilla 
>  wrote:
> 
> +1 on my side too.
> 
> -- 
> Francisco Javier Acosta Padilla
> Research Engineer at INRIA Saclay
> INFINE Team
> 
>> On 28 November 2017 at 12:24:00, Alexandre Abadie 
>> (alexandre.aba...@inria.fr) wrote:
>> 
>> Hi,
>> 
>> Hi,
>> 
>> as hinted yesterday, I usually need to go around 5:30pm. So I was wondering 
>> if we can move the meeting to 4pm.
>> 
>> +1
>> 
>> 
>> Cheers,
>> Martine 
>> 
>> 2017-11-27 16:33 GMT+01:00 Francisco Javier Acosta Padilla 
>> :
>>> 
>>> RIOT developers monthly meeting
>>> Scheduled: 27 Nov 2017 17:00 to 18:00
>>> Location: https://zoom.us/j/235153205
>>> Invitees: devel@riot-os.org, Francisco Javier Acosta Padilla
>>> Hi there, 
>>> 
>>> Francisco Acosta is inviting you to a scheduled Zoom meeting. 
>>> 
>>> Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/235153205
>>> 
>>> Or iPhone one-tap :
>>> US: +16699006833,,235153205#  or +16465588656,,235153205# 
>>> Or Telephone:
>>> Dial(for higher quality, dial a number based on your current location)：
>>> US: +1 669 900 6833  or +1 646 558 8656
>>> Meeting ID: 235 153 205
>>> International numbers available: 
>>> https://zoom.us/zoomconference?m=3QuTkS0wteDtL_3pyOjFM0KBPZ_220mB
>>> 
>>> 
>>> -- 
>>> Francisco Javier Acosta Padilla
>>> Research Engineer at INRIA Saclay
>>> INFINE Team
>>> 
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>> 
>> 
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>> 
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] [riot-maintainer] Monthly meetings for organisation purposes

[Thomas Eichinger]

Hi Paco,

Thanks for the initiative!

I will try to tune in. 

Without wanting to start a tools discussion, I had very good experiences with 
larger groups using zoom.us. 

Best, Thomas 

> On Nov 3, 2017, at 4:29 PM, Francisco Javier Acosta Padilla 
>  wrote:
> 
> Hi again!
> 
> A kind reminder to let us now who’s willing to attend the meeting on Monday, 
> November 6th at 17:00 CET (UTC +1).
> 
> I don’t have an agenda yet but if we can establish it before it would speed 
> up the meeting. So far I propose:
> 
> 1. Sort the most urgent bugs-issues by priority
> 2. Assign (more/new) people to the bugs-issues
> 3. Mark the related issues/PRs to be solved as “in progress”
> 
> The goal is to have the selected issues solved before the next meeting, if it 
> happens before, be free to assign new ones and move them to the “in progress” 
> column.
> 
> Please don’t hesitate to propose your ideas for the topics of the meeting!
> 
> Cheers!
> 
> -- 
> Francisco Javier Acosta Padilla
> Research Engineer at INRIA Saclay
> INFINE Team
> 
>> On 1 November 2017 at 12:25:51, Martine Lenders (m...@martine-lenders.eu) 
>> wrote:
>> 
>> Hi Cenk,
>> 
>> 2017-11-01 11:05 GMT+01:00 Cenk Gündoğan :
>>> > > On 17-10-31 18:03:01, Francisco Javier Acosta Padilla wrote:
>>> > > […]
>>> > > > P.S: @Martine, can you set up the next Hack&ACK meeting? Thanks
>>> > >
>>> >
>>> > Anything different to do than the usual ad-hoc placecam set-up?
>>> >
>>> 
>>> Jup, provide a working mic for the FU's PlaceCam laptop this time (:
>> 
>> We had... the problem was that the machine we ran placecam on was so slow 
>> and old that ALSA wasn't able to stream that audio including video ^^ 
>> (that's definitely a problem we need to solve until next week).
>> 
>> Cheers,
>> Martine 
>> ___
>> Maintainer mailing list
>> maintai...@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/maintainer
> ___
> Maintainer mailing list
> maintai...@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/maintainer
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] rfq commercial additions to riot-os

[Thomas Eichinger]

Hi Richard,

Yes, a node could for example have an ethernet and a 802.15.4 network interface
and communicate over both.

Asking on this list is the right way to go as most people offering any service
like this I know should be listening here.

Generally I think if the functionality I outlined before fits your use case this
would most certainly be of broader interest. Anyways, it'd be great if you could
keep this list updated.

Best, Thomas

On 31 Oct 2017, at 15:41 PDT(-0700), Richard Klingler wrote:

> Hello Thomas
>
> So you're saying a node can participate even with two networks at the same 
> time?
> Anyway...
>
> But what we a re mainly looking is to external manpower with a deeper
> riot-os knowledge to implement our needed features
>
> Either sponsoring to the project if a feature is of everyones interest
> or to a company doing specific features which is applicable mostly to our 
> needs.
>
> Do you know of any company having knowledge/time/ doing such stuff?
>
>
>
> thanks in advance
> richard
>
>
>
> On Tue, 31 Oct 2017 15:35:52 -0700, Thomas Eichinger wrote:
>> Hi Richard,
>>
>> On 31 Oct 2017, at 14:42 PDT(-0700), Richard Klingler wrote:
>>>
>>> Hmm.. I see you sometimes joining/leaving #riot-os (o;
>> That might be me, different Thomas. ;)
>>
>>> Yes the different networks is very interesting...and definitively a
>>> need
>>> not sure if it is easily done like adding a second interface on UNIX
>>> with a simple ifconfig (o;
>>
>> Having two network interfaces is already possible with RIOT as well
>> as RIOT provides
>> a ifconfig command for configuration.
>>
>>> The button thing...don't have to be a button..and is also not always
>>> possible...
>>>
>>> Let's say you want to deploy a new network
>>>
>>> Idea is like all nodes have a default PAN as the firmware is all the
>>> same (more or less).
>>>
>>> You start deploying the network from the border router away by
>>> pressing a button
>>> which tells it to start a join procedurefor example by
>>> broadcasting on that PAN
>>> a message like "who ever wants to joing my new network with PAN ID
>>> xxx, you have 5
>>> minutes time"
>>>
>>> Then on the the next node you press also a button, which then
>>> listens on the
>>> default PAN and accepts then the new PAN advertised by the router node...
>>>
>>> A leave would be then like pressing the button for 5
>>> seconds...putting it back
>>> into the default PAN
>>
>> If I understand your scenario correctly, what you are suggesting
>> involves a 802.15.4
>> coordinator announcing PAN or channel changes and/or manages hardware
>> addresses.
>>
>> I started a discussion on this topic recently but for now RIOT is
>> still missing these
>> "runtime" features.
>>
>> Please be aware though that, to the best of my knowledge, nothing in
>> the standard keeps
>> a device from starting to communicate on a certain channel with a
>> certain PAN ID at any
>> point in time.
>>
>> Best,
>> Thomas
>>
>>> On Tue, 31 Oct 2017 22:28:09 +0100, Thomas C. Schmidt wrote:
>>>> Hi Richard,
>>>>
>>>> thanks for sharing your thoughts on the list!
>>>>
>>>> I'm not sure I fully understand your requirements, but believe that
>>>> some are generically interesting for RIOT, e.g., running several/many
>>>> 802.15.4 networks in parallel.
>>>>
>>>> What about this join/leave button?
>>>>
>>>> Best,
>>>>  Thomas
>>>>
>>>> On 31/10/2017 22:14, Richard Klingler wrote:
>>>>> Evnin' from \.ch (o;
>>>>>
>>>>> Some of you from #riot-os already know some backgrounds...
>>>>>
>>>>> I work for a company doing sanitary devices (basically anything
>>>>> controlling water)
>>>>> with IoT capabilities...currently WLAN/Ethernet connection only...
>>>>>
>>>>> To extend our portfolio we would like to switch over to 802.15.4
>>>>> network...
>>>>> Target areas would be for example hospitals with hundres od WSN
>>>>> nodes per building.
>>>>>
>>>>> In the past I tested so far contiki, skipped totally tinyos and ended up
>>>>> wit

Re: [riot-devel] rfq commercial additions to riot-os

[Thomas Eichinger]

Hi Richard,

On 31 Oct 2017, at 14:42 PDT(-0700), Richard Klingler wrote:


Hmm.. I see you sometimes joining/leaving #riot-os (o;

That might be me, different Thomas. ;)

Yes the different networks is very interesting...and definitively a 
need

not sure if it is easily done like adding a second interface on UNIX
with a simple ifconfig (o;


Having two network interfaces is already possible with RIOT as well as 
RIOT provides

a ifconfig command for configuration.

The button thing...don't have to be a button..and is also not always 
possible...


Let's say you want to deploy a new network

Idea is like all nodes have a default PAN as the firmware is all the 
same (more or less).


You start deploying the network from the border router away by 
pressing a button
which tells it to start a join procedurefor example by 
broadcasting on that PAN
a message like "who ever wants to joing my new network with PAN ID 
xxx, you have 5

minutes time"

Then on the the next node you press also a button, which then listens 
on the
default PAN and accepts then the new PAN advertised by the router 
node...


A leave would be then like pressing the button for 5 seconds...putting 
it back

into the default PAN


If I understand your scenario correctly, what you are suggesting 
involves a 802.15.4
coordinator announcing PAN or channel changes and/or manages hardware 
addresses.


I started a discussion on this topic recently but for now RIOT is still 
missing these

"runtime" features.

Please be aware though that, to the best of my knowledge, nothing in the 
standard keeps
a device from starting to communicate on a certain channel with a 
certain PAN ID at any

point in time.

Best,
Thomas


On Tue, 31 Oct 2017 22:28:09 +0100, Thomas C. Schmidt wrote:

Hi Richard,

thanks for sharing your thoughts on the list!

I'm not sure I fully understand your requirements, but believe that
some are generically interesting for RIOT, e.g., running several/many
802.15.4 networks in parallel.

What about this join/leave button?

Best,
 Thomas

On 31/10/2017 22:14, Richard Klingler wrote:

Evnin' from \.ch (o;

Some of you from #riot-os already know some backgrounds...

I work for a company doing sanitary devices (basically anything
controlling water)
with IoT capabilities...currently WLAN/Ethernet connection only...

To extend our portfolio we would like to switch over to 802.15.4 
network...

Target areas would be for example hospitals with hundres od WSN
nodes per building.

In the past I tested so far contiki, skipped totally tinyos and 
ended up

with an easily setup riot-os network at home...which was the base to
present to our CEO...

We have already assigned a local company to do a WSN but they failed
after half year to deliver
anything useful. That's why I always kept a back plan from the
beginning evaluating
open source solutions...

I got the OK today to ask here on this list for external men power
to extend
the already great riot-os capabilities with special features we 
would need

to be successful in commercial/industrial fields, mainly:

- run independant wsn side by side with not interfering each other
- simple joining/leaving a node to/from a PAN with simple button 
press



We would like early as possible..speaking...within two weeks (o;


thanks in advance for listening and
for the already great riot-os (o;

davorin@#riot-os
richard

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



--

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] On the State of RIOT's IEEE 802.15.4 Support

[Thomas Eichinger]

Hi Joakim,

That was what I pretty much meant before I'm sorry for not expressing
this clear enough.

Seems we reached common ground here.

Best,
Thomas

On 20 Sep 2017, at 13:51 PDT(-0700), Joakim Nohlgård wrote:


Hi again,
Perhaps it would make sense to split it in two? One low level part
which manages the duty cycling and wake scheduling, while the PAN
management part (I think it is called MAC services in the 802.15.4
standard) would run as a higher layer on top of it.

/Joakim

On Wed, Sep 20, 2017 at 10:37 PM, Thomas Eichinger 
 wrote:

Hi Joakim,

Thanks for sharing your point of view.

Personally I think it complicates MAC protocol implementations when 
they

somehow have to accommodate 802.15.4 functionality and deal with e.g.
starting and maintaining the PAN and I'd expect we will have to use 
more

#ifdefs.

In my opinion runtime functionality as described in 6.3 and following 
of
the standard also doesn't need to run with the same priority as the 
actual

MAC protocol.

Your approach would however benefit upper layers I think as the 
interface

wouldn't have to change.

In the end I'm fine with whatever works and covers our requirements.

Best, Thomas


On 20 Sep 2017, at 1:11 PDT(-0700), Joakim Nohlgård wrote:


Hi,
I have recently been digging around the gnrc_netdev code as well. I
think that adding support for other frame types and logic for 
sending
these frames will definitely become a mess if the 802.15.4 code is 
not

decoupled from the netdev code. Especially if someone would like to
add advanced features like 802.15.4e TSCH, which requires version 2
framing and a number of special MAC header fields. I don't think the
802.15.4 layer needs to be in its own thread though, it should be
enough to separate the framing functionality from the send/recv code
and let the MAC layer handle it internally, and keep the 802.15.4
layer in the same thread as the netdev driver, like gnrc_netdev does
today.

/Joakim

On Wed, Sep 20, 2017 at 12:16 AM, Thomas Eichinger 


wrote:


Hi Oleg!

On 19 Sep 2017, at 13:24 PDT(-0700), Oleg Hahm wrote:


On Sun, Sep 17, 2017 at 02:37:39PM -0700, Thomas Eichinger wrote:

A while ago I worked on adding support for MAC commands and 
procedures

the
standard describes like channel scanning and automatic 
association of a

device with a coordinator.
Personally I think those are nifty features to provide, the 
reality

check
the last two days showed though that it'd need some non-trivial
refactoring
of the existing 15.4 code to not end up in #ifdef hell.





Can you elaborate a little bit on this part? I would assume that 
being

compatible with other 802.15.4 implementations requires run-time
flexibility,
i.e., react properly to optional features implemented by other 
802.15.4
devices. Or were you proposing to have a minimal 
non-standard-compliant
version _and_ standard-compliant version intermingled, sharing 
commmon

code
through preprocessor directives?




Admittedly the "#ifdef hell" was a bit polemic and I didn't intend 
to

propose
offering a non-standard-compliant version. ;)

Right now RIOT is very much streamlined to send and receive 
802.15.4 data

and
ACK frames. The nontrivial refactoring I referred to would have to 
break

this.

On the receiving side I see the possibility to introduce an other 
nettype

like
GNRC_NETTYPE_802154 set by the corresponding frame type and the 
actual

runtime
logic would basically be in parallel of sixlowpan threads,
hierarchically.
(changing channels and hardware addresses, actively/passively 
scanning

for
coordinators...)
That'd be at least my approach.

On the sending side, however, the 15.4 header currently gets 
crafted in

the
netdev code and set to data frames. We'd have to take that out and 
let

the
upper layers  define the frame type, or at least overwrite it. 
There will

be
more flags or header fields that will have to get configurable.

Do others see a better approach?

So, instead of having a minimal non-standard-compliant version I'd 
rather
progress to a minimal standard-compliant version with the 
inevitable

increase
in code size. From there we can take it how far we want and make it
configurable
i.e. supporting IEs and use 802.15.9 to support key management etc. 
The

sky
is
the limit.
(Or as a German'd say "With sauce and spicy!")

Does this somehow answer your question? Let me know if I missed it.

Best, Thomas

p.s.: Writing this it seems easier to do actually. Good we talked 
about

it.
:)

___
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] On the State of RIOT's IEEE 802.15.4 Support

[Thomas Eichinger]

Hi Joakim,

Thanks for sharing your point of view.

Personally I think it complicates MAC protocol implementations when they
somehow have to accommodate 802.15.4 functionality and deal with e.g.
starting and maintaining the PAN and I'd expect we will have to use more
#ifdefs.

In my opinion runtime functionality as described in 6.3 and following of
the standard also doesn't need to run with the same priority as the 
actual

MAC protocol.

Your approach would however benefit upper layers I think as the 
interface

wouldn't have to change.

In the end I'm fine with whatever works and covers our requirements.

Best, Thomas

On 20 Sep 2017, at 1:11 PDT(-0700), Joakim Nohlgård wrote:


Hi,
I have recently been digging around the gnrc_netdev code as well. I
think that adding support for other frame types and logic for sending
these frames will definitely become a mess if the 802.15.4 code is not
decoupled from the netdev code. Especially if someone would like to
add advanced features like 802.15.4e TSCH, which requires version 2
framing and a number of special MAC header fields. I don't think the
802.15.4 layer needs to be in its own thread though, it should be
enough to separate the framing functionality from the send/recv code
and let the MAC layer handle it internally, and keep the 802.15.4
layer in the same thread as the netdev driver, like gnrc_netdev does
today.

/Joakim

On Wed, Sep 20, 2017 at 12:16 AM, Thomas Eichinger 
 wrote:

Hi Oleg!

On 19 Sep 2017, at 13:24 PDT(-0700), Oleg Hahm wrote:


On Sun, Sep 17, 2017 at 02:37:39PM -0700, Thomas Eichinger wrote:

A while ago I worked on adding support for MAC commands and 
procedures

the
standard describes like channel scanning and automatic association 
of a

device with a coordinator.
Personally I think those are nifty features to provide, the reality 
check

the last two days showed though that it'd need some non-trivial
refactoring
of the existing 15.4 code to not end up in #ifdef hell.




Can you elaborate a little bit on this part? I would assume that 
being

compatible with other 802.15.4 implementations requires run-time
flexibility,
i.e., react properly to optional features implemented by other 
802.15.4
devices. Or were you proposing to have a minimal 
non-standard-compliant
version _and_ standard-compliant version intermingled, sharing 
commmon

code
through preprocessor directives?



Admittedly the "#ifdef hell" was a bit polemic and I didn't intend to
propose
offering a non-standard-compliant version. ;)

Right now RIOT is very much streamlined to send and receive 802.15.4 
data

and
ACK frames. The nontrivial refactoring I referred to would have to 
break

this.

On the receiving side I see the possibility to introduce an other 
nettype

like
GNRC_NETTYPE_802154 set by the corresponding frame type and the 
actual

runtime
logic would basically be in parallel of sixlowpan threads, 
hierarchically.
(changing channels and hardware addresses, actively/passively 
scanning for

coordinators...)
That'd be at least my approach.

On the sending side, however, the 15.4 header currently gets crafted 
in the
netdev code and set to data frames. We'd have to take that out and 
let the
upper layers  define the frame type, or at least overwrite it. There 
will be

more flags or header fields that will have to get configurable.

Do others see a better approach?

So, instead of having a minimal non-standard-compliant version I'd 
rather

progress to a minimal standard-compliant version with the inevitable
increase
in code size. From there we can take it how far we want and make it
configurable
i.e. supporting IEs and use 802.15.9 to support key management etc. 
The sky

is
the limit.
(Or as a German'd say "With sauce and spicy!")

Does this somehow answer your question? Let me know if I missed it.

Best, Thomas

p.s.: Writing this it seems easier to do actually. Good we talked 
about it.

:)

___
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] On the State of RIOT's IEEE 802.15.4 Support

[Thomas Eichinger]

Hi Oleg!

On 19 Sep 2017, at 13:24 PDT(-0700), Oleg Hahm wrote:


On Sun, Sep 17, 2017 at 02:37:39PM -0700, Thomas Eichinger wrote:

A while ago I worked on adding support for MAC commands and 
procedures the
standard describes like channel scanning and automatic association of 
a

device with a coordinator.
Personally I think those are nifty features to provide, the reality 
check
the last two days showed though that it'd need some non-trivial 
refactoring

of the existing 15.4 code to not end up in #ifdef hell.



Can you elaborate a little bit on this part? I would assume that being
compatible with other 802.15.4 implementations requires run-time 
flexibility,
i.e., react properly to optional features implemented by other 
802.15.4
devices. Or were you proposing to have a minimal 
non-standard-compliant
version _and_ standard-compliant version intermingled, sharing commmon 
code

through preprocessor directives?


Admittedly the "#ifdef hell" was a bit polemic and I didn't intend to 
propose

offering a non-standard-compliant version. ;)

Right now RIOT is very much streamlined to send and receive 802.15.4 
data and
ACK frames. The nontrivial refactoring I referred to would have to break 
this.


On the receiving side I see the possibility to introduce an other 
nettype like
GNRC_NETTYPE_802154 set by the corresponding frame type and the actual 
runtime
logic would basically be in parallel of sixlowpan threads, 
hierarchically.
(changing channels and hardware addresses, actively/passively scanning 
for

coordinators...)
That'd be at least my approach.

On the sending side, however, the 15.4 header currently gets crafted in 
the
netdev code and set to data frames. We'd have to take that out and let 
the
upper layers  define the frame type, or at least overwrite it. There 
will be

more flags or header fields that will have to get configurable.

Do others see a better approach?

So, instead of having a minimal non-standard-compliant version I'd 
rather
progress to a minimal standard-compliant version with the inevitable 
increase
in code size. From there we can take it how far we want and make it 
configurable
i.e. supporting IEs and use 802.15.9 to support key management etc. The 
sky is

the limit.
(Or as a German'd say "With sauce and spicy!")

Does this somehow answer your question? Let me know if I missed it.

Best, Thomas

p.s.: Writing this it seems easier to do actually. Good we talked about 
it. :)

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

[riot-devel] On the State of RIOT's IEEE 802.15.4 Support

[Thomas Eichinger]

Dear fellow RIOTers,

tl;dr: Do we see the need to be IEEE 802.15.4 compliant?

RIOT so far does not support anything other than beacon, data, and ack 
frames while the standard says that also reduced-function devices have 
to support certain command frames [IEEE802.15.4-2015 7.5.1]. Basically, 
"RIOT does not support IEEE 802.15.4".


A while ago I worked on adding support for MAC commands and procedures 
the standard describes like channel scanning and automatic association 
of a device with a coordinator.
Personally I think those are nifty features to provide, the reality 
check the last two days showed though that it'd need some non-trivial 
refactoring of the existing 15.4 code to not end up in #ifdef hell.
(I see work on netif2 but I am not in the position to evaluate if above 
mentioned will benefit from it.)


On the other side, scanning through Zephyr's 1.9.0 release notes I 
noticed their support for IEEE 802.15.4 MAC commands, at least the most 
basic ones. So we'd have an other project to actually test against. 
(They also claim support for basic 802.15.4 security.)


Thus my questions,
do people consider adding support for MAC commands worth the effort?

Does anybody know about cases these are actually used?

Can we add those when approaching 802.15.4 security?

It'd be great to hear peoples' take on this.

Thanks,
Thomas

[IEEE802.15.4-2015] 
http://ieeexplore.ieee.org/servlet/opac?punumber=7460873

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

Re: [riot-devel] Mailserver issues

[Thomas Eichinger]

Oleg,

Thank you for handling this!

Best, Thomas

On 8 Aug 2017, at 7:53 PDT(-0700), Oleg Hahm wrote:

> Dear RIOTers,
>
> due to an immense load of requests on the mailing lists, ten thousands of
> mails got queued over the last days. This lead to a delay for mail delivery up
> to several days. After some throttling and performance tuning on the mail
> server everything should be back to normal and most of the mails should have
> been delivered by now.
>
> Sorry for the inconvenience and please let me know if you encounter further
> problems.
>
> Cheers,
> Oleg
> -- 
> The best thing about script jokes is that they start with a bang.
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel


smime.p7s
Description: S/MIME digital signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT port to RISC-V?

[Thomas Eichinger]

Hi Craig,

That's great news and I am stoked to see support for RISC-V in RIOT.

To my knowledge nobody put real effort into that yet. (I'm happy to be 
corrected!)
If you need help or guidance on porting please don't hesitate to ask on 
this list.


Thanks and good luck for your funding proposal,

Thomas

On 15 Jun 2017, at 2:53 PDT(-0700), Craig S. Steele wrote:

I am preparing a funding proposal in the U.S., and am contemplating a 
port of RIOT to the 32-bit RISC-V architecture.  We have HiFive 
development boards from SiFive.com, as well as FPGA platforms, to work 
on a project trying to provide hardware security support for 32-bit 
RISC-V MCU variants.


It is helpful for the proposal process to know if anyone else is 
working on such a port to RISC-V.  I have seen a question about that 
last year on the developers' email list, but have seen no indication 
that anyone is actually working on this port.  If anyone is aware of 
any such effort at present, I'd appreciate that information.


Thanks in advance,

Craig Steele
___
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] At86rf2xx ACK frame

[Thomas Eichinger]

Hi Baptiste,

you could try reading out the frame buffer after that
although I am not sure the current mode of operation actually
updates the frame buffer with the ACK frame.
(The data sheet is also kind of unspecific on this.)

Other than that I don't see an easy solution, only porting
the driver to basic operation mode.

Best, Thomas

On 14 Jun 2017, at 23:17 PDT(-0700), Baptiste Clenet wrote:


Which mean that automated ACK by the transceiver is fine.
1 - RIOT sends a frame
2 - Transceiver receives an ACK and transmit a 
AT86RF2XX_TRX_STATE__TRAC_SUCCESS

3 - Here I want to get the ACK frame content
4 - Use it with openthread (Have a look here [1] to understand why we 
need it)


[1] 
https://github.com/openthread/openthread/blob/master/include/openthread/platform/radio.h#L404


Cheers,

2017-06-13 15:46 GMT+02:00 Baptiste Clenet :

2017-06-13 14:45 GMT+02:00 Oleg :

Hi Baptiste!

On 2017-06-13 12:30, Baptiste Clenet wrote:


On netdev event: NETDEV_EVENT_TX_COMPLETE (after
AT86RF2XX_TRX_STATE__TRAC_SUCCESS state), how may I get the ACK 
frame

received by at86rf2xx?



The ACK frame is processed automatically by the transceiver. There 
is no way
to access it using the extended mode. If you use the base mode, you 
will

have to send and process the ACK yourself.



Ok I don't want to process the ACK myself, I only want to get the
frame on AT86RF2XX_TRX_STATE__TRAC_SUCCESS state. Is the ACK frame
store in a register/frame buffer? Or do we must use base mode to get
the ACK frame.



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




--
Baptiste




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

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

Re: [riot-devel] Netdev events questions

[Thomas Eichinger]

Hi Joakim,

I'm very excited to see the KW41Z supported in 802.15.4 mode.

As for your questions regarding NETDEV_EVENT_RX_COMPLETE:
To my knowledge it is not strictly formalized if it should be sent
before or after transmitting the ACK. Generally I think this depends
on the capabilities of the hardware but as there are also 802.15.4
frames that don't require ACKs I think triggering RX_COMPLETE after
successful reception of a valid frame is reasonable. Also this should
be doable on most hardware to have as consistent behavior as possible.
(The at86rf2xx transceiver line for example doesn't offer a way to
configure this, at least when using auto-ACKs.)

Would you be ok with this approach?

Best, Thomas

On 21 May 2017, at 7:13 PDT(-0700), Joakim Nohlgård wrote:

> Dear developers,
> I'm working on a radio driver for the Kinetis KW41Z 802.15.4 radio and
> I have run into some questions regarding when to send the different
> netdev events from my device driver.
>
> Should NETDEV_EVENT_RX_COMPLETE be sent before, or after TX of ACK
> packet is finished?
> Should NETDEV_EVENT_RX_COMPLETE be sent even when the radio detects a
> CRC failure?
>
> My device is using hardware auto-ACK, but I can enable interrupts for
> both the end of RX and at the end of TX ACK. It seem like it would be
> more robust to always wait for TX ACK to be performed, but it may add
> delays if the medium is very busy. It is possible to abort the TX ACK
> after an RX if the CPU issues a new command quickly enough.
>
> Best regards,
> Joakim
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] at86rf2xx: packet too large -> FCS check

[Thomas Eichinger]

Hi Baptiste,

On 17 May 2017, at 23:22 PDT(-0700), Baptiste Clenet wrote:


I re-do my example again started at 0:
Example:
at86rf2xx_tx_load(dev, ptr->iov_base, length=5, 0);
FCS is calculated on bytes 0, 1 and 2 and bytes 3 and 4 are replaced 
by FCS


at86rf2xx_tx_load(dev, ptr->iov_base, length=126, 0);
FCS is calculated on bytes 0, to 123 and bytes 124 and 125 are 
replaced by FCS


Just ran a test using the txtsnd command in the default example which 
sends raw 802.15.4 frames and I didn't see any of my payload overwritten 
by FCS bytes




In your example Alexandre:

I think when the transmitter starts sending the FRAME -> going into
BUSY. The transceiver will make some:

init_fcs();
for (b:each_bytes_to_tx) { <--- 127 - 2
   send(b);
   calc_fcs(b);
}
send_fcs(); <--- 2 bytes

then you need to be sure you send 127 - 2 bytes out


You send to the radio driver N bytes, then the transceiver calculates
FCS on this N bytes and after sending these N bytes, send the
calculated FCS. So you say that transmitter appends FCS to the given
frame.


This is the expected behavior with AUTO_CRC on, yes.


Now, I'm helping to port OpenThread on RIOT and OpenThread stack gives
sometimes to the radio driver a frame of 126 bytes. My team asks them
how is it possible:
Their answer:
The IEEE 802.15.4 frame length includes the FCS bytes at the end of 
the frame.  The radio driver should simply update the last two bytes 
of the frame rather than extending it.


If I understand well, RIOT stack does not include FCS in its
ieee802154 layer and OpenThread stack includes it?

Am I right?


You are right.

For using OpenThread with RIOT the quick fix would be giving the OT 
buffer to RIOT with the buffer length - 2.


Best, Thomas




2017-05-17 21:26 GMT+02:00 Alexander Aring :

Hi,

On Wed, May 17, 2017 at 07:56:05PM +0200, Baptiste Clenet wrote:

2017-05-17 17:47 GMT+02:00 Thomas Eichinger :

Hi Baptiste,

On 17 May 2017, at 1:14 PDT(-0700), Baptiste Clenet wrote:


According to their example:
Example:
A frame transmission of length five with TX_AUTO_CRC_ON set, is
started with a Frame Buffer write access of five bytes (the last 
two

bytes can be omitted). The first three bytes are used for FCS
generation; the last two bytes are replaced by the internally
calculated FCS.

Even a five bytes frame would have its last two bytes overwritten. 
Is

my understanding correct?
So I don't understand why the driver limits the frame length to 
127-2?



The at86rf2xx driver doesn't limit the *frame length* to 127-2 
octets

because the
FCS is part of the frame sent out. The driver just makes sure that 
no

payload
data is overwritten by the FCS.

Every 802.15.4 frame has two bytes of FCS. So if we didn't use
TX_AUTO_CRC_ON
we would have to calculate the checksum in software and write it 
into the
frame buffer, appended to the header, sequence number, addresses 
and payload

we
want to send. All together (FCF + seq_num + addrs + payload + FCS) 
this can

be 127 bytes max.

Now RIOT's at86rf2xx driver uses TX_AUTO_CRC_ON thus we don't have 
to

calculate
the FCS, it's appended to the rest of the frame.


I don't think it is appended to the frame but it really replace the
last two bytes of the frame
Example:
at86rf2xx_tx_load(dev, ptr->iov_base, 5, 0);
FCS is calculated on bytes 1, 2 and 3 and bytes 4 and 5 are replaced 
by FCS




starting here at 0 or 1? :S

Replaced by FCS? I suppose this function loads frame into 
framebuffer,

the FCS isn't calculated there. See below.


at86rf2xx_tx_load(dev, ptr->iov_base, 126, 0);
FCS is calculated on bytes 1, to 124 and bytes 125 and 126 are 
replaced by FCS


So the stack which give the frame should give a frame  2bytes longer
to let the transceiver calculate the FCS.
This is why IMO this check is useless.

After reading more the datasheet, it's not clear because it is 
written:

On transmission the radio transceiver generates and appends the FCS
bytes during the frame transmission. This
behavior can be disabled by setting register bit TX_AUTO_CRC_ON = 0
(register 0x04, TRX_CTRL_1).



I think when the transmitter starts sending the FRAME -> going into
BUSY. The transceiver will make some:

init_fcs();
for (b:each_bytes_to_tx) { <--- 127 - 2
send(b);
calc_fcs(b);
}
send_fcs(); <--- 2 bytes

then you need to be sure you send 127 - 2 bytes out. If you disable

---

now if you disable AUTO_CRC then you can load 127 bytes into 
framebuffer
and hopefully last 2 bytes are FCS (or doesn't need to be, but then 
you

running out-of-spec).

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




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

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

Re: [riot-devel] at86rf2xx: packet too large -> FCS check

[Thomas Eichinger]

Hi Baptiste,

On 17 May 2017, at 1:14 PDT(-0700), Baptiste Clenet wrote:


According to their example:
Example:
A frame transmission of length five with TX_AUTO_CRC_ON set, is
started with a Frame Buffer write access of five bytes (the last two
bytes can be omitted). The first three bytes are used for FCS
generation; the last two bytes are replaced by the internally
calculated FCS.

Even a five bytes frame would have its last two bytes overwritten. Is
my understanding correct?
So I don't understand why the driver limits the frame length to 127-2?


The at86rf2xx driver doesn't limit the *frame length* to 127-2 octets 
because the
FCS is part of the frame sent out. The driver just makes sure that no 
payload

data is overwritten by the FCS.

Every 802.15.4 frame has two bytes of FCS. So if we didn't use 
TX_AUTO_CRC_ON
we would have to calculate the checksum in software and write it into 
the
frame buffer, appended to the header, sequence number, addresses and 
payload we
want to send. All together (FCF + seq_num + addrs + payload + FCS) this 
can

be 127 bytes max.

Now RIOT's at86rf2xx driver uses TX_AUTO_CRC_ON thus we don't have to 
calculate

the FCS, it's appended to the rest of the frame.

Personally, I never tried what happens if you remove this check for 
127-2 and
fully fill the frame buffer but I would imagine that exactly that 
happens, the
last two bytes are overwritten by the FCS and thus lost, unless it 
already was

the exact same checksum.

Best, Thomas




2017-05-16 16:42 GMT+02:00 Thomas Eichinger :

Hi Baptiste,

If you take a look at figures 37-1 and 37-2 in the data sheet you 
linked you can see that IEEE 802.15.4 allows up to 127 bytes for the 
MPDU and this includes the FCS.
So if the driver would allow writing 127 bytes into the frame buffer 
the last two bytes would indeed be overwritten which is undesired I 
guess.


I hope I understood you correctly and this helps.

Best, Thomas

On May 16, 2017, at 6:09 AM, Baptiste Clenet  
wrote:


Thomas, Hauke, Martine, Kaspar what do you think about it?

My last question: how do I send a packet with length 127 octets with
at86rf2xx transceiver?

2017-05-15 14:59 GMT+02:00 Baptiste Clenet :

Hi,

When I want to send a pkt which is 126 Octet long, I get a message
from [at86rf2xx]:
[at86rf2xx] error: packet too large (2 byte) to be send

IEE802.15.4 MAX length is 127 so it should be sent.
#define IEEE802154_FRAME_LEN_MAX(127U)  /**< maximum frame 
length */


I checked source code of at86rf2xx driver and I think I understand 
the

magic number +2 in the if condition but I don't know why this is
checked.

at86rf2xx_netdev.c:110:

   /* current packet data + FCS too long */
   if ((len + ptr->iov_len + 2) > AT86RF2XX_MAX_PKT_LENGTH) {
   DEBUG("[at86rf2xx] error: packet too large (%u byte) to 
be

send (iov_len %d, i %d, count %d)\n",
 (unsigned)len + 2, ptr->iov_len, i, count);
   return -EOVERFLOW;
   }

+2 mean two FCS octets?
In the samr21 datasheet, 37.3 Frame Check Sequence (FCS) [1]:

For a frame with a frame length specified as N (3 ≤ N ≤ 127), 
the FCS

is calculated on the first N-2 octets in the Frame Buffer, and the
resulting FCS field is transmitted in place of the last two octets
from the Frame Buffer.
Example:
A frame transmission of length five with TX_AUTO_CRC_ON set, is
started with a Frame Buffer write access of five bytes (the last 
two

bytes can be omitted). The first three bytes are used for FCS
generation; the last two bytes are replaced by the internally
calculated FCS.

So while I think we should remove the +2 test and let the 
possibility

to send packet up to 127 octets and I don't understand the part in
datasheet: "the last two bytes are replaced by the internally
calculated FCS". This mean that a part of data is erased? (for 5
octets or 127)

Cheers,

[1] 
http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf



--
Baptiste




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


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




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

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

Re: [riot-devel] at86rf2xx: packet too large -> FCS check

[Thomas Eichinger]

Hi Baptiste,

If you take a look at figures 37-1 and 37-2 in the data sheet you linked you 
can see that IEEE 802.15.4 allows up to 127 bytes for the MPDU and this 
includes the FCS. 
So if the driver would allow writing 127 bytes into the frame buffer the last 
two bytes would indeed be overwritten which is undesired I guess. 

I hope I understood you correctly and this helps. 

Best, Thomas 

> On May 16, 2017, at 6:09 AM, Baptiste Clenet  wrote:
> 
> Thomas, Hauke, Martine, Kaspar what do you think about it?
> 
> My last question: how do I send a packet with length 127 octets with
> at86rf2xx transceiver?
> 
> 2017-05-15 14:59 GMT+02:00 Baptiste Clenet :
>> Hi,
>> 
>> When I want to send a pkt which is 126 Octet long, I get a message
>> from [at86rf2xx]:
>> [at86rf2xx] error: packet too large (2 byte) to be send
>> 
>> IEE802.15.4 MAX length is 127 so it should be sent.
>> #define IEEE802154_FRAME_LEN_MAX(127U)  /**< maximum frame length */
>> 
>> I checked source code of at86rf2xx driver and I think I understand the
>> magic number +2 in the if condition but I don't know why this is
>> checked.
>> 
>> at86rf2xx_netdev.c:110:
>> 
>>/* current packet data + FCS too long */
>>if ((len + ptr->iov_len + 2) > AT86RF2XX_MAX_PKT_LENGTH) {
>>DEBUG("[at86rf2xx] error: packet too large (%u byte) to be
>> send (iov_len %d, i %d, count %d)\n",
>>  (unsigned)len + 2, ptr->iov_len, i, count);
>>return -EOVERFLOW;
>>}
>> 
>> +2 mean two FCS octets?
>> In the samr21 datasheet, 37.3 Frame Check Sequence (FCS) [1]:
>> 
>> For a frame with a frame length specified as N (3 ≤ N ≤ 127), the FCS
>> is calculated on the first N-2 octets in the Frame Buffer, and the
>> resulting FCS field is transmitted in place of the last two octets
>> from the Frame Buffer.
>> Example:
>> A frame transmission of length five with TX_AUTO_CRC_ON set, is
>> started with a Frame Buffer write access of five bytes (the last two
>> bytes can be omitted). The first three bytes are used for FCS
>> generation; the last two bytes are replaced by the internally
>> calculated FCS.
>> 
>> So while I think we should remove the +2 test and let the possibility
>> to send packet up to 127 octets and I don't understand the part in
>> datasheet: "the last two bytes are replaced by the internally
>> calculated FCS". This mean that a part of data is erased? (for 5
>> octets or 127)
>> 
>> Cheers,
>> 
>> [1] http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf
>> 
>> 
>> --
>> Baptiste
> 
> 
> 
> -- 
> Baptiste
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

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

Re: [riot-devel] [riot-maintainer] Release 2017.04

[Thomas Eichinger]

Great job everybody! And special thanks to Kaspar for handling it this time!

Best, Thomas

On 10 May 2017, at 4:04 PDT(-0700), Kaspar Schleiser wrote:

> Dear RIOTers,
>
> we are happy to announce the 11th official release of RIOT:
>
> --- * RIOT 2017.04 * ---
>
> This release provides a lot of new features, fixes and enhancements.
> Among these has been a huge cleanup regarding cppcheck and
> documentation, and we're pleased to announce that all remaining doxygen
> and cppcheck warnings have been fixed.
> We're also proud to present a Virtual File System layer and integration
> of the SPIFFS file system.
> A lot of work has gone into support for STMicroelectronics's Nucleo
> family, with RIOT now supporting 28 (up from 13) Nucleo boards. And as
> always, there was a lot of under-the-hood cleanup, bug fixing and
> documentation work.
>
> About 200 pull requests with about 562 commits have been merged since
> the last release and about 23 issues have been solved. 32 people
> contributed with code in 91 days. 2697 files have been touched with
> 716950 insertions and 492623 deletions.
>
> You can download the RIOT release from Github by cloning the repository
> [1] or by downloading the tarball [2], and look up the release notes for
> further details [3].
>
> Thanks everyone for your contributions, discussions, testing efforts,
> and keep RIOTing!
>
> Happy hacking,
> Kaspar
>
> [1] https://github.com/RIOT-OS/RIOT/releases/tag/2017.04
> [2] https://github.com/RIOT-OS/RIOT/archive/2017.04.tar.gz
> [3] https://github.com/RIOT-OS/RIOT/blob/2017.04-branch/release-notes.txt
> ___
> Maintainer mailing list
> maintai...@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/maintainer
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Regarding RIOT joining EdgeX Foundry

[Thomas Eichinger]

Hi Oleg,

Thanks for your feedback. I think there is no such thing as an official 
trial
trial period so I understand correctly that this trial period would be a 
RIOT

internal thing?

As far as I get it nobody objects the idea of RIOT as a project joining 
EdgeX

in general.

People who would be interested in participating in this endeavor please 
contact

me off list to start organizing the upcoming administrational steps.

Best, Thomas

On 28 Apr 2017, at 23:41 PDT(-0700), Oleg Hahm wrote:


Hi Aaron, hi Thomas!

Thanks for sparking this discussion and sharing your thoughts about 
this

topic!

On Sat, Apr 29, 2017 at 11:03:03AM +1200, Aaron Sowry wrote:

I think this is a good idea, forming a special interest group a.k.a 
task
force gathering people having time to spare to invest in EdgeX, 
reporting

back to the community as we used to do for technical topics.


I think a task force would at least fulfill the desire to "keep an 
eye

on the results" as you say, and would probably be a positive thing to
have regardless of how much involvement RIOT decides to have in 
EdgeX.


I very much like the idea of joining the EdgeX Foundry with some kind 
of trial
period in mind having a group of people committed to monitor this 
period and
the general alignment between RIOT's goals and the direction EdgeX is 
taking.


Cheers,
Oleg
--
Unix is user friendly... its just selective about who its friends are.
___
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] Regarding RIOT joining EdgeX Foundry

[Thomas Eichinger]

Hi Aaron,

Thanks for your input, I very much appreciate it. Please see my comments 
inline.


On 28 Apr 2017, at 13:18 PDT(-0700), Aaron Sowry wrote:

I'm generally sceptical of anything the Linux Foundation does these 
days. I
know the word "Foundation" has a nice community vibe to it, but 
ultimately

LF are an industry association working in the best interests of their
paying members (some of whom pay a lot, and therefore quite 
understandably
expect to see results). Potentially, these interests may not be 
compatible

with the goals of RIOT.


Potentially it does turn out that EdgeX is moving into a direction that 
is not
desired by the community or incompatible with RIOT's goals. From my 
point of
view however the only way to have at least a little bit of an influence 
on this
is to actually participate and try. If the point should be reached at 
which
there is a conflict of interests, there is always the option to drop 
out.


I understand that being an associate member doesn't incur any 
obligations,
and the exposure may be good for the RIOT project. My main concern is 
that
development focus will be misdirected towards Edge X rather than 
continuing

the excellent work done in RIOT so far, if Edge X certification was to
become an "official" goal of RIOT.


As a project we can't make any contributor work on EdgeX other than 
they,
or their employers, want to. How far the involvement will go will also 
depend
on how open this group is for our input. In general I can rather see 
people
somehow involved in RIOT providing technical input and keeping an eye on 
the
results than actually contributing huge junks to an Apache 2 licensed 
code base.


Perhaps an alternative would be to set up a special interest group 
within
the RIOT project, to monitor the progression of Edge X as it matures. 
It's

still a young initiative and may not even end up gaining traction.


I think this is a good idea, forming a special interest group a.k.a task 
force
gathering people having time to spare to invest in EdgeX, reporting back 
to the

community as we used to do for technical topics.

I hope I understood you right, does this the above make sense?

Best, Thomas



On 29/04/2017 6:28 AM, "Thomas Eichinger"  wrote:


Dear RIOTers,

As some of you might have noticed there exists a new initiative 
hosted by

Linux Foundation called EdgeX Foundry [1]. From their website:

"EdgeX FoundryTM is a vendor-neutral open source project hosted by 
the
Linux Foundation building a common open framework for Industrial IoT 
edge

computing. ... The initiative is aligned around a common goal: the
simplification and standardization of the foundation for tiered edge
computing architectures in the Industrial IoT market while still 
enabling

the ecosystem to provide significant value-added differentiation."

Some central people in the RIOT community consider this as an 
interesting
project to join as it holds the possibility to expose RIOT to a 
broader

audience and might also attract future contributions.
RIOT would join as an open source project and thus become an 
Associated

Member which does not imply joining the Linux Foundation.

Before taking any further actions we wanted to know if anybody in the
community feels uncomfortable or has any objections to RIOT 
participating?


Please let us know in a timely manner about your concerns. General
feedback is very much welcome as usual.

Cheers,
Thomas

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





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

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

[riot-devel] Regarding RIOT joining EdgeX Foundry

[Thomas Eichinger]

Dear RIOTers,

As some of you might have noticed there exists a new initiative hosted 
by Linux Foundation called EdgeX Foundry [1]. From their website:


"EdgeX FoundryTM is a vendor-neutral open source project hosted by the 
Linux Foundation building a common open framework for Industrial IoT 
edge computing. ... The initiative is aligned around a common goal: the 
simplification and standardization of the foundation for tiered edge 
computing architectures in the Industrial IoT market while still 
enabling the ecosystem to provide significant value-added 
differentiation."


Some central people in the RIOT community consider this as an 
interesting project to join as it holds the possibility to expose RIOT 
to a broader audience and might also attract future contributions.
RIOT would join as an open source project and thus become an Associated 
Member which does not imply joining the Linux Foundation.


Before taking any further actions we wanted to know if anybody in the 
community feels uncomfortable or has any objections to RIOT 
participating?


Please let us know in a timely manner about your concerns. General 
feedback is very much welcome as usual.


Cheers,
Thomas

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

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

[Thomas Eichinger]

Hi Oleg,

thank you for sharing the results and thanks a lot to everyone involved
for their contributions to finally reduce the increasingly confusing
"Checks" section in github PRs.

Reading the document provided it seems to me that Jenkins actually
got a better score than Murdock 2. (Please tell me if I am mistaken
and misinterpret the table.)

Because of this I'd very much appreciate a little bit more of 
information

on why this group came to the conclusion Murdock 2 is still better
fitting RIOT than Jenkins.

I do not intend to bash the task force results just try to better
understand the reasoning.

Thanks,
Thomas

On 20 Mar 2017, at 10:13 PDT(-0700), Oleg Hahm wrote:


Dear robust IOTlers,

as you probably know we're currently running three CI systems in 
parallel:
Murdock, Jenkins and Murdock 2, where the first one is the 
authoritative CI
system and the other two are under test. Since these two last systems 
support
distributed deployment - a must-have feature for us - we need to 
replace

Murdock with one of it.

In order to decide whether we should use Jenkins or Murdock 2, a task 
force
was formed to deploy and thoroughly evaluate both systems. This task 
force

finally defined 34 criteria categorized into Web UI, GitHub Interface,
Performance, Operation, Maintenance, Security, and Extensibility for 
the
evaluation. The outcome was that both tools seem to fulfill the 
criteria

satisfactorily well. You can find the result of the evaluation at [1].

Hence, it was a close call, but eventually, we (the members of the 
task force)
agreed that we want to switch to Murdock 2 as the default CI system. 
Murdock 2

is currently developed by Kaspar particular for the needs of RIOT and
therefore simplifies configuration. It is also seems to scale better 
and

outperform Jenkins.

Please let us know if you disagree with our assessment and object 
switching to

Murdock 2 as the authoritative CI.

Cheers,
Oleg

[1] 
https://docs.google.com/spreadsheets/d/1_KxHZmuDb-j4IfNZt-XSTW711NESWTxfMX46YppoTic/edit?usp=sharing

--
printk("ip6t_hook: happy cracking.\n");
linux-2.6.6/net/ipv6/netfilter/ip6table_filter.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

Re: [riot-devel] Proposal: Use Gitter to allow users and developers easier and simpler chat functionality

[Thomas Eichinger]

Hi Oleg,

On 18 Jan 2017, at 11:57 PST(-0800), Oleg Hahm wrote:


On Wed, Jan 18, 2017 at 02:49:37PM -0500, Anthony Merlino wrote:


Here is an example https://gitter.im/Microsoft/vscode 


Thanks. Seems rather slow/resource-hungry. Is there a non-Web (or even 
better:

a non-GUI) version?


Apparently gitter offers an IRC bridge [1].

Best, Thomas

[1] https://irc.gitter.im
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] wolfSSL port to RIOT OS

[Thomas Eichinger]

Hi Kaleb,

Personally I would be very much stoked to see a port of wolfSSL to RIOT 
and I think many others think the same.


Let us know how we can help with it and I'm sure we will figure 
something out!


Best, Thomas

On 30 Nov 2016, at 13:09 PST(-0800), kaleb himes wrote:


Hi @RIOT_OS developers,

@wolfSSL is considering doing a port to the Revolutionary Internet of 
Things Operating System. We wanted to reach out to the RIOT_OS 
developers group to see if this is something that interests you.


Please let us know your thoughts, we look forward to hearing from you!

i...@wolfssl.com 
supp...@wolfssl.com 

Regards,

Kaleb and the wolfSSL Team




___
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 on Realtek RTL8710AF

[Thomas Eichinger]

Hi Oleg!

On 18 Nov 2016, at 1:58 PST(-0800), Oleg Hahm wrote:

This seems to be some real low-cost device, but I wonder how much IoT 
it is.
Does anybody know if this Wi-Fi chip is capable of 802.11 ad-hoc mode 
and

IPv6?


Well it's a cheap device, that's already something. ;-)

But after working on it last night my enthusiasm about this device is 
pretty
much gone already again for now. I was definitely blinded by the amount 
of

documents provided but should have gotten suspicious when the SDK hat a
"without NDA" in it's name. I think this device is great for makers and 
the
arduino scene but due to the lack of documentation of low level specs 
(no docs
on the vector table and they make you use their peripheral library) 
renders

it basically useless for RIOT.

Maybe realtek will change their mind on that and release a full data 
sheet

without NDA at some point, one can hope.

Best, Thomas

ps.: AFAI saw, it supports p2p mode but AT commands are limited to IPv4
communication so far.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT on Realtek RTL8710AF

[Thomas Eichinger]

Hi Bas,

That's great to hear, I will definitely check out your branch! Thank for 
the link.


On first sight the PADI SDK is in very good shape, header files, 
openocd.cfgs, extensive pdf documentation. We will see how it turns out.


Best, Thomas

On 17 Nov 2016, at 22:09 PST(-0800), Bas Stottelaar wrote:


Hi Thomas,

I have started a port (or PoC) of RIOT-OS for the general purpose 
RTL7810:

[1]. Back then, the PADI IoT Stamp was not yet released.

Some of the sources (and flash script) is based on the work of [2]. 
Due to

the lack of a decent SDK, I quit.

Kind regards,

Bas Stottelaar

[1]: https://github.com/basilfx/RIOT/tree/feature/rtl8710
[2]: https://bitbucket.org/rebane/


2016-11-18 6:20 GMT+01:00 Thomas Eichinger :


All,

Just got some of these PADI IoT Stamps [1] into my hands. Did anybody
on this list start working on RIOT support for a Realtek RTL8710AF
already?

Best, Thomas

[1] https://www.pine64.org/?page_id=917
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel





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

[riot-devel] RIOT on Realtek RTL8710AF

[Thomas Eichinger]

All,

Just got some of these PADI IoT Stamps [1] into my hands. Did anybody
on this list start working on RIOT support for a Realtek RTL8710AF
already?

Best, Thomas

[1] https://www.pine64.org/?page_id=917
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233

[Thomas Eichinger]

Hi Adeel,

you could try to add a printf() in the `spi_transfer_byte` function in 
stm32f4/periph/spi.c for the `in` pointer and see if there are 
reasonable values shown

- to make sure SPI communication is working.

Best, Thomas

On 3 Aug 2016, at 19:24 CEST(+0200), Adeel Mohammad Malik wrote:

The part number is 0xff. It does not match with AT86RF233_PARTNUM 
(0x0b) defined here

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

Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233

[Thomas Eichinger]

Adeel,

we're happy to help and please keep us posted about your progress.

Best, Thomas

On 20 Jul 2016, at 18:33 CEST(+0200), Adeel Mohammad Malik wrote:

I will fix my pin configuration tomorrow and see if it works for me. 
Thanks for your replies. You guys are really helpful.

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

Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233

[Thomas Eichinger]

Hi Adeel,

the transceiver uses the cpuid module to generate hwaddr. If your port 
is based on the stm32f4discovery board it should be configured already 
which makes me think there might still be some nit in your SPI 
connection.


You could try to issue `ifconfig set addr `. If you then do 
`ifconfig` again and nothing changed I guess it would be the SPI 
connection. Else you might miss some configuration still.


Best, Thomas

On 20 Jul 2016, at 15:16 CEST(+0200), Adeel Mohammad Malik wrote:


Hi Thomas,

I did as you said. I have 9 wires connected between my 
STM32F4Discovery board and the AT86RF233 ZigBit Xplained Pro Extension 
board. 4 SPI wires, 3 GPIO wires and 2 for power (+3.3V and GND).


Now doing an "ifconfig" gives me the following result:-

ifconfig
Iface  3   HWaddr: 00:00  Channel: 0  Page: 0  NID: 0x0
   Long HWaddr: 00:00:00:00:00:00:00:00
   TX-Power: -17dBm  State: IDLE  max. Retrans.: 15

   Source address length: 2

Iface  4   HWaddr: 00:15:01:00:40:e4

   Source address length: 6

I was expecting to see a valid HWaddr but this doesn't look right. 
Should I be able to see a HWaddr if the connection is alright?


/Adeel


-Original Message-
From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Thomas
Eichinger
Sent: Wednesday, July 20, 2016 2:17 PM
To: RIOT OS kernel developers
Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233

Hi Adeel,

please see my answers inline. I hope this helps, let us know if there 
is further

open questions.

Best, Thomas

On 20 Jul 2016, at 13:46 CEST(+0200), Adeel Mohammad Malik wrote:


Hi all,

I am struggling a bit to understand how to connect my 
STM32F4Discovery

board with my AT86RF233 ZigBit Xplained Pro Extension board
(http://www.atmel.com/tools/ATZB-X-233-XPRO.aspx).  I have a few
questions that I list as follows:-


* When connecting the SPI interface, is it enough to connect
SCK, MISO and MOSI? Or should I also connect SS?
What you refer to as SS (Slave Select) is called CS (Chip Select) in 
RIOT. So
yes, you have to connect this pin too to actually activate the 
slave's SPI

interface.



* I see that the file
https://github.com/RIOT-

OS/RIOT/blob/master/drivers/at86rf2xx/include/at86rf2xx_params.h

has some PIN configuration parameters. What is AT86RF2XX_PARAM_CS?
Looking at the manual for my AT86RF233 board
(http://www.atmel.com/Images/Atmel-Wireless-ATZB-X-233-

XPRO_design_documentation.PDF),

on page 3 I see the RESET (AT86RF2XX_PARAM_RESET), SLP_TR
(AT86RF2XX_PARAM_SLEEP) and the IRQ (AT86RF2XX_PARAM_INT) pins. I

do

not seem to find the corresponding pin for AT86RF2XX_PARAM_CS. Any
clues?

See above.



* Should I include anything besides USEMODULE += at86rf2xx 
to

be able to use the transceiver?

In your particular case you will want to include `USEMODULE +=
at86rf233`.
___
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] Connecting STM32F4Discovery & AT86RF233

[Thomas Eichinger]

Hi Adeel,

please see my answers inline. I hope this helps, let us know if there is 
further

open questions.

Best, Thomas

On 20 Jul 2016, at 13:46 CEST(+0200), Adeel Mohammad Malik wrote:


Hi all,

I am struggling a bit to understand how to connect my STM32F4Discovery 
board with my AT86RF233 ZigBit Xplained Pro Extension board 
(http://www.atmel.com/tools/ATZB-X-233-XPRO.aspx).  I have a few 
questions that I list as follows:-



* When connecting the SPI interface, is it enough to connect 
SCK, MISO and MOSI? Or should I also connect SS?
What you refer to as SS (Slave Select) is called CS (Chip Select) in 
RIOT. So yes, you have to connect this pin too to actually activate the 
slave's SPI interface.




* I see that the file 
https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/include/at86rf2xx_params.h 
has some PIN configuration parameters. What is AT86RF2XX_PARAM_CS? 
Looking at the manual for my AT86RF233 board 
(http://www.atmel.com/Images/Atmel-Wireless-ATZB-X-233-XPRO_design_documentation.PDF), 
on page 3 I see the RESET (AT86RF2XX_PARAM_RESET), SLP_TR 
(AT86RF2XX_PARAM_SLEEP) and the IRQ (AT86RF2XX_PARAM_INT) pins. I do 
not seem to find the corresponding pin for AT86RF2XX_PARAM_CS. Any 
clues?

See above.



* Should I include anything besides USEMODULE += at86rf2xx to 
be able to use the transceiver?
In your particular case you will want to include `USEMODULE += 
at86rf233`.

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

Re: [riot-devel] Progress of port to SODAQ Autonomo

[Thomas Eichinger]

All,

I am a little concerned the coding conventions getting too pedantic 
lately.


While I agree magic numbers should be avoided, I disagree to introduce 
#defines
for every single one of them as I do with introducing a static check for 
it.
(Using a #define for a number only used once in HW initialization for 
example

seems too much to me.)

I agree however with putting a comment with an explanation or data sheet 
reference

to each occurrence.
(Register initializations should use or'ed bit defines from vendor 
headers anyways.)
To me it is the duty of the maintainer reviewing the code to decide if 
it makes
sense to use a #define or a comment is enough. Thus I'd prefer a best 
practice

instead of a rule.

Best, Thomas

On 4 Jul 2016, at 9:20 CEST(+0200), Ludwig Knüpfer wrote:


On Mon, Jul 04, 2016 at 07:44:21AM +0200, Ludwig Knüpfer wrote:

Am 2. Juli 2016 13:21:19 MESZ, schrieb Kees Bakker :
While going through the code I notice that there are too many 
"magic"

constants. Hard coded numbers that are obvious for some, but not
obvious
for others. My advise: always try to use defines and add a comment
about
what constants mean. Or point to datasheet sections explaining the
constants.


Thank you for bringing this up.

I am uncertain if there is something that can be done about it in the 
existing code base, but at least we should find a way to prevent such 
issues in the future:


There is an "immediately" missing in the sentence above... I guess
there's quite a few of these ;)

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

Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)

[Thomas Eichinger]

Hi!

On 13 Jun 2016, at 9:56 CEST(+0200), Peter Kietzmann wrote:


First I moved the existing cpu/samd21 tree to cpu/samr21. Then


Why? Well *if* there is a need to change the current RIOT code base, 
you should open a separate PR for that.


This is a question to all: How comes the Atmel samr21-xplained pro 
board has "samd21" CPU in RIOT?



I added the samd21 CMSIS files from Arduino and the board files
for the SODAQ Autonomo. For that, I copied several files from
samr21-xpro.


What was wrong with current CMSIS headers?


The problem is, the Atmel data sheet calls the samr21-xpro board CPU 
samd21 but then again Atmel maintains separate header file trees.


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

Re: [riot-devel] RIOT Release 2016.04

[Thomas Eichinger]

Congratulations to everybody for their awesome work! 

Best, Thomas 

> On Apr 22, 2016, at 4:33 PM, Hauke Petersen  
> wrote:
> 
> Dear RIOT developers and users,
> 
> we are happy to announce the seventh official release of the RIOT:
> 
> --- * RIOT 2016.04 * 
> ---
> 
> This release adds support for two additional network stacks: lwIP and emb6.
> A bunch of additional protocols are now available, P2P-RPL in the GNRC
> network stack, Ethernet-over-Serial (ethos). Murdock, the new, blazing fast
> RIOT CI is now available to significantly speed up code merging procedures.
> 
> This release also adds support for a number of new boards and sensors and a 
> new
> tool for automated border router setup is now provided which greatly 
> simplifies
> that setup for newbies as well as for old-timers. Last but not least: this
> release includes a number of bug fixes, mostly about stabilizing and enhancing
> the networking capabilities of RIOT.
> 
> About 470 pull requests with about 1196 commits have been merged since the 
> last
> release and 127 additional issues have been solved. 55 people contributed code
> in 124 days. 1521 files have been touched with ~91700 insertions and ~42200
> deletions.
> 
> You can download the RIOT release from Github by cloning the repository [1] 
> or by
> downloading the tarball [2], and look up the release notes for further 
> details [3].
> 
> Thanks everyone for your contributions, discussions, testing efforts, and 
> keep RIOTing!
> 
> Cheers,
> Hauke
> 
> [1] https://github.com/RIOT-OS/RIOT/releases/tag/2016.04
> [2] https://github.com/RIOT-OS/RIOT/archive/2016.04.tar.gz
> [3] https://github.com/RIOT-OS/RIOT/blob/master/release-notes.txt
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

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

Re: [riot-devel] IoT technology survey

[Thomas Eichinger]

All,

surveys on IoT seem to be en vogue nowadays, here [1] is a OMA IoT open 
source survey which's results could also be interesting.


Best, Thomas

[1] https://www.surveymonkey.com/r/OSSPublic

On 15 Mar 2016, at 6:15 ART(-0300), Emmanuel Baccelli wrote:


Hi everyone,

our friends from Eclipse Foundation are conducting a survey about IoT
technologies currently in use or aimed at in various contexts. Maybe 
you
can consider filling it in (and maybe the results will be of some 
interest).


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

Best,

Emmanuel
___
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] at86rf2xx and PHR filtering

[Thomas Eichinger]

Hi Alex,

thanks for pointing out and letting us know about a possible 
vulnerability related to the length field. It rose attention to the fact 
that we checked it in past versions of the driver but missed it at some 
point in transition. With [1] we should respect this again.


Regarding your example on state transition below, for the driver getting 
stuck in the assertion loop the transceiver would already have to be in 
RX_AACK_ON state before to change into RX_AACK_BUSY. The MCU's call of 
at86rf2xx_set_state(foo, RX_AACK_ON) would then already return in the 
fourth line of this function [2].
As far as I can see the situation pointed out by you should be avoided 
with this for most situations.


Looking at the code now we might should exchange the order of this check 
with the loop waiting for busy states though to catch the case the 
transceiver is busy receiving and a call of at86rf2xx_set_state(foo, 
RX_AACK_ON).


Best, Thomas

[1] https://github.com/RIOT-OS/RIOT/pull/5234
[2] 
https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_getset.c#L429


On 1 Apr 2016, at 7:24 ART(-0300), Alexander Aring wrote:

I looked now in RIOT code [0].

So they will call at86rf2xx_set_state(at86rf2xx_t *dev, uint8_t state)
with state as RX_AACK_ON, but at the end they call:

_set_state(at86rf2xx_t *dev, uint8_t state)

with RX_AACK_ON, so it could be that RIOT has this behaviour:

MCU   -> at86rf2xx_set_state(foo, RX_AACK_ON)
at86rf2xx -> going into RX_AACK_ON
at86rf2xx -> detected SFD, going into RX_AACK_BUSY
  MCU   -> _set_state(foo, RX_AACK_ON)
MCU   ->  while (at86rf2xx_get_status(dev) != state) -> stucks 
inside this loop

at86rf2xx -> receiving done, going into RX_AACK_ON
MCU   ->  while (at86rf2xx_get_status(dev) != state) -> loop 
ends



The stucking inside the loop for assertion is here a possible case 
which

is bad. But okay it's unlikely I also get such issues only when I make
really big traffic.

- Alex

[0] 
https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_getset.c#L420

___
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] Question regarding MBED-LPC1768 network drivers support.

[Thomas Eichinger]

Hi Fernando,

as Hauke pointed out already, RIOT supports Ethernet devices in general but 
still needs support for the specific hardware used. For your device this would 
mean implementing the interfaces defined in netdev2.h [1] and netdev2_eth.h 
[2]. 
If you are willing to take on this task we're happy to support you with any 
questions arising and you can take a look how it is done for other existing 
Ethernet devices like the enc28j60 [3]. 

Best, Thomas 

[1] https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/net/netdev2.h
[2] 
https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/net/netdev2_eth.h
[3] https://github.com/RIOT-OS/RIOT/tree/master/drivers/enc28j60

> On Mar 21, 2016, at 10:49 AM, Hauke Petersen  
> wrote:
> 
> Hi,
> 
> we do have support for ethernet, but we don't have a device driver for the 
> lpc1768 phy, yet. Feel free to write one :-)
> 
> Cheers,
> Hauke
> 
> 
> On 18.03.2016 20:50, Fernando Alberione wrote:
>>> On 2016-03-18 13:05, Thomas Eichinger wrote:
>>> Hi Fernando,
>>> 
>>>the mbed-lpc1768 according to [1] doesn't have any network interfaces
>>> as far as I see. Because of this there are no network drivers
>>> implemented and ifconfig doesn't have anything to show. Do you use it
>>> with any kind of extension board?
>> Hi Thomas,
>> 
>>  Thanks for answering.
>> 
>> I wanted to run the example using the mbed-lpc1768 ethernet device. It 
>> already has an integrated phy, so we just connected an rj-45 jack.
>> 
>> Do you have support for ethernet devices in your stack?
>> 
>> Regards,
>> 
>> 
>> ___
>> 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] Question regarding MBED-LPC1768 netwok drivers support.

[Thomas Eichinger]

Hi Fernando,

  the mbed-lpc1768 according to [1] doesn't have any network interfaces 
as far as I see. Because of this there are no network drivers 
implemented and ifconfig doesn't have anything to show. Do you use it 
with any kind of extension board?


Best, Thomas

[1] https://developer.mbed.org/platforms/mbed-LPC1768/

On 16 Mar 2016, at 15:48 CET(+0100), Fernando Alberione wrote:


Hi,
I tried executing an example of gnrc_networking (gnrc_networking) 
on

Mbed-lpc1768 and it runs fine. But, the network was not configured
correctly (e.g. ifconfig doesn't show anything).

My question is:
What is the status of network drivers for LPC1768?

Fernando Alberione
Software Engineer

Taller Technologies - Argentina
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

*Mobile:* [+54 358 4827823 (ARG)]
*Skype:* falberione
___
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-users] RIOT Release 2015.12

[Thomas Eichinger]

Woohoo, congratulations to everyone! 

Best, Thomas 

> On 10 Jan 2016, at 16:28, Cenk Gündogan  wrote:
> 
> Dear RIOT developers and users,
> 
> I am glad to announce the sixth official release of the RIOT operating system:
> 
> --- * RIOT 2015.12 * 
> ---
> 
> This release is packed with nearly 150 enhancements to the codebase and 
> bugfixes
> for several known issues. It also contains a lot of new documentation as well 
> as
> improvements to existing ones, which can be found in http://doc.riot-os.org/.
> 
> In addition to the above, this new release re-enables the support for ICN
> by integrating CCN-lite as a package and provides example applications
> to showcase its functionality.
> 
> Developers can now make use of a Vagrant file that ships with
> this release in order to manage a RIOT supported guest machine.
> This reduces the set-up time by delivering a system with all
> necessary toolchains installed without the need to touch the host system.
> 
> With a partial support of the Arduino API, RIOT becomes more accessible
> to a wide range of Arduino specialized developers. Although this new feature 
> is
> still rudimentary, it already enables simple Arduino sketches to be compiled
> into RIOT.
> 
> A further highlight of this release is the introduction of SAUL,
> the [S]ensor [A]ctuator [U]ber [L]ayer. SAUL enables a portable approach
> to interact with different types of sensors and actuators on RIOT supported
> hardware by offering a unified API to the developer.
> 
> Several new platforms and device drivers found their way into this release.
> RIOT 2015.12 supports the WeIO board, the Silicon Labs Wireless Eval Kit
> (SLWSTK6220A) and the STM32 Nucleo-F401. With the new device driver for the
> enc28j60 ethernet chip it is now possible to use wired connections with RIOT.
> 
> Since the last release about 222 new pull requests with about 631 commits
> were merged and 48 additional issues have been solved. 37 people generated
> a total of ~59779 insertions and ~12115 deletions in 980 files.
> 
> You can download the RIOT release from Github by cloning the repositoryor by
> downloading the tarball:https://github.com/RIOT-OS/RIOT/archive/2015.12.tar.gz
> 
> Keep RIOTing!
> 
> - Cenk
> ___
> users mailing list
> us...@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/users
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Is RIOT right?

[Thomas Eichinger]

Hi Patrick,

On 23 Nov 2015, at 12:07 CET(+0100), Hauke Petersen wrote:

On 20.11.2015 20:48, Patrick Rota - Swissponic Sagl wrote:
SAMR21 is pretty capable, but with 32kB RAM would it be able to 
coordinate hundreds of nodes? Somebody ever tried with a large number 
of nodes? The original reasoning behind putting the coordinator on 
the A13 side was for managing a large number of notes.


You might have a point here, but I am probably the wrong person to 
ask.


Could you elaborate how you want to use 802.15.4 PAN coordinator role 
and for what?
Do you want to use it combined with a network management protocol? 
Please note that

none of existing or PR'ed MAC protocols for RIOT utilises this role yet.

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

Re: [riot-devel] at86rf2xx radio driver -- potential severe performance issues for multi-hop communication

[Thomas Eichinger]

Hi Andreas,

thank you very much to point us to your work. I didn't find time yet to 
read it
but will do for sure. From what you shared with us by now I think this 
are very

useful informations we definitely should consider for our driver.

I have to admit when I once started it, the promises extended operating 
mode made
were too auspicious to not use it, and I never came to run actual multi 
hop tests

on it yet.

At least with the possibility of disabling CSMA-CA chances are we don't 
have to

rewrite it again.

Taken from your description below, the main problem is that the 
transceiver drops

any packets, right? Does IEEE802.15.4 specify anything on this?

Anyhow, I will try to get your article tomorrow and thanks again for 
sharing this

with us.

Best,
Thomas

On 15 Oct 2015, at 14:38 CEST(+0200), Andreas Weigel wrote:


Hi again,

indeed this should solve the issue -- I have to admit, that I hadn't 
considered this possibility for our driver, because I adapted the 
TinyOS MAC layer (using the basic operating mode) and had everything 
there already, including a handling of the ACKs in software, which 
works reasonably well.


You will obviously still have to implement the CSMA-CA mechanism then 
if you need it. Is there already usable (for the at86rf2xx) code 
available for a CSMA-CA in Riot? Then probably combining it with the 
existing driver (with deactivated CSMA-CA) would be a good solution.


Regards,
Andreas

On 10/15/2015 02:13 PM, Alexander Aring wrote:

Hi,

On Thu, Oct 15, 2015 at 01:57:03PM +0200, Andreas Weigel wrote:

Hi everyone,

I've recently executed some experiments on the performance of 
Atmel's
extended operating mode on the ATmega256RFR2 (which afaik is 
basically the

same as the AT82RF2xx transceivers) in multihop collection traffic
scenarios, with unslotted CSMA/CA. For those, we used our own 
framework for
WSNs (CometOS). Result is, that the extended operating mode can 
severely
impact performance (in terms of PRR) in the presence of large 
fragmented
datagrams sent over 6LoWPAN. However, I expect that there will be an 
impact
in any traffic scenario with "enough" traffic to get some node's 
queue
filled to some extent (resulting in repeated transmissions towards 
the same

node).

Problem is the property of the TX_ARET mode to discard any incoming
transmissions during the backoff phase of the CSMA mechanism. This 
leads to
a large number of lost frames on longer paths (4 hops are enough to 
produce
a large number of losses), even with rather high backoff exponents 
and the
maximum number of retries. This problem caused me to reimplement our 
mac

driver for the ATmega256RFR2 using the basic operating mode.

As far as I can see, the at86rf2xx driver in the riot repo uses the 
same
extended operating mode and therefore will very likely have the very 
same
weakness. If the time is available, it would probably be a good idea 
to
change the driver to use the basic operating mode or alternatively 
include a
note for users explaining the impact of the extended operating mode 
for said
traffic scenarios. The frame solely caused by the extended operating 
mode
can render results of experiments virtually useless (speaking from 
my own,

sad experience ;-/  )


I am not a riot-dev but did you try to turn off CSMA-CA handling?

You can do that and I think all (except at86rf230) supports it by
setting MAX_CSMA_RETRIES to 7 which means no CSMA-CA handling.

I would _not_ use TX_ON mode only, because in this mode the ack
request bit in 802.15.4 MAC will be ignored always and sometimes you
need to the result of tx trac status if ACK was received or not. 
(like

in possible mlme-ops)

TX_ARET_ON will automatic wait for an ACK if ack request bit is set 
and

not if it isn't set.

Possible solution (maybe also in linux, because I am do a lot of
802.15.4 linux stuff) would be to insert a no CSMA-CA setting which
performs no CSMA-CA handling, but still supports ack handling stuff 
then.


I was thinking about that already about something like that (in 
linux) for
such case, because several transceivers supports for disable CSMA-CA 
handling.


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



--

Hamburg University of Technologyandreas.wei...@tuhh.de
Institute of Telematics (E-17)   Tel.: (+49) 40 42878-3746
Am Schwarzenbergcampus 3 Fax:  (+49) 40 42878-2581
21073 Hamburg, Germany   http://www.ti5.tu-harburg.de/staff/weigel


___
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] Include in Makefile

[Thomas Eichinger]

Baptist,

Did you try the following?

app/Makefile:
```
...
DIRS += thingA thingB
INCLUDES += -I$(CURDIR)/include -I$(CURDIR)/thingA -I$(CURDIR)/thingB
...
```

app/thingA/Makefile, app/thingB/Makefile
```
module = $(APPLICATION)

include $(RIOTBASE)/Makefile.base
```

This way all code in `app` should form one module.
Let me know if this helps.

Best,
Thomas

On 14 Oct 2015, at 9:05 CEST(+0200), Baptiste Clenet wrote:

> Anyone? @OlegHahm , @daniel-k ?
>
> 2015-10-09 16:50 GMT+02:00 Baptiste Clenet :
>> Hi all,
>>
>> I'm building an example (let's called it "app") for RIOT with the
>> following structure:
>> app/*.c
>> app/include/*.h
>> app/thingA/*.c
>> app/thingA/include*.h
>> app/thingB/*.c
>> app/thingB/include*.h
>>
>> How to add the required path in the Makefile? Should I add
>> Makefile.base in each folder or is there another way to do it with
>> RIOT Makefile ? I couldn't find any example of this structure.
>>
>> Cheers,
>>
>>
>> --
>> Baptiste
>
>
>
> -- 
> Baptiste
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] iotlab-m3 and recent OS X update

[Thomas Eichinger]

Dear list,

I wanted to share my findings regarding flashing an iotlab-m3 board from
OS X 10.11.

The good thing, the 3rd party FTDI driver is not needed anymore. Apple 
delivered
a FTDI kernel extension for some releases already but I didn't find them 
working
until this release. So, when connecting an iotlab-m3 board to your Mac 
without
having the old FTDI driver loaded you should already be able to connect 
to the

/dev/tty.usbserial-xB device with by executing

`BOARD=iotlab-m3 PORT=/dev/tty.usbserial-xB make term`

The bad thing, flashing fails as the Apple driver also assigns 
/dev/tty.usbserial-xA
to the first serial device on the board and openocd can't claim it. I 
could

successfully prevent it from doing so by these steps:

DISCLAIMER: backup first and you do this on your own reliability.

1. `sudo nvram boot-args=kext-dev-mode=1`
We will change the kext's Info.plist so the signature will not be valid 
anymore.


2. Boot into recovery mode by holding cmd + r during start up

3. In recovery mode open a terminal and execute
`csrutil disable`
to turn off System Integrity Protection.

4. Restart into normal mode an use your editor of choice to edit the 
file

/System/Library/Extensions/AppleUSBFTDI.kext/Contents/Info.plist
and comment out the  and  entries for "AppleUSBEFTDI-6010-0" 
with 

See the snip below.

5. Restart into recovery mode again and enable System Integrity 
Protection again by

`csrutil enable`

6. Restart into normal mode and you should only see one remaining 
/dev/tty.usbserial-xxxB

device. Flashing the board should work now.

If somebody found an easier approach, please let me know, else, good 
luck.


Best, Thomas


The snip:
```

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

Re: [riot-devel] Open WSN

[Thomas Eichinger]

Hi Ben,

great to hear from you and about your interest in RIOT. First of all
I am really sorry for the delayed reply.

In our current approach we pull in the network stack part of OpenWSN
and apply patches with an adaption layer to map OpenWSN's hardware
abstraction to RIOT's driver model. Unfortunately the current version
used in RIOT master is quite outdated but we plan to change this and
address problems we found during the last plug test soon.
Right now we are kept busy getting a new RIOT release ready but it
improvements to OpenWSN support have a very high priority for the time
after the release is out.
(This should happen in the next couple of days)

There are also plans to improve interaction between RIOT applications
and the OpenWSN network stack. If you could imply what your specific
requirements are we can take these into account of future planning.

I hope this gives you an overview, for any further questions don't
hesitate to ask.

Best, Thomas


On 17 Sep 2015, at 8:35 CEST(+0200), b...@vpt-systems.co.za wrote:


Hi All

Not sure if this is the correct channel to start , but will never know 
unless I try.


Currently I'm running Contiki OS for my applications with all the 
problems (biggest is debugging the OS)
My applications are relying heavily on Open WSN that Contiki provide 
for the mesh network.


What are the status of OpenWSN on RIOT?

My solutions needs
1) Low power consumption
2) Wireless Mesh

Any input will be appreciated.

Kind regards
Ben Duvenage
VPT-SYSTEMS
Development Engineer

On 2015-09-14 03:25 PM, Evan Dietz wrote:


Hi Oleg,

I would be happy to give the new feature a try. When you create the 
issue, could you point to some similar implementations as references? 
This will help me implement the "riot" way.


I imagine getting the periph_uart* unit tests working on native would 
be a good start?


Thanks for the help.

Evan

On Sep 14, 2015 3:20 AM, "Oleg Hahm" > wrote:


Hi Evan!

> This is a first time post to the forum so please excuse any newbie
> language/etiquette.

Welcome to the RIOT community and no worries about any RIOT
specific language
or etiquette.

> I'd like to test some uart-related code using native before
flashing to a
> specific board.  However it doesn't look like native cpu
supports uart.
>
> Am I missing something or is this the correct assessment?

Nope, you are correct. We just recently switched to periph/uart
support for
all boards, but since the native getchar/putchar implementation
are mapped to
the host's implementation of these functions there was no urgent
need for a
periph/uart implementation on native.

> Is there any work being done on adding uart emulation to
native?  Is this
> an issue already being tracked (i tried to check but didn't see
anything)

I guess you're right here, too: there is indeed no issue for this.
I'll open
one. Do you have interest in working on this by any chance?

Cheers,
Oleg
--
printk(KERN_CRIT "Whee.. Swapped out page in kernel page table\n");
linux-2.6.6/mm/vmalloc.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] NFC & Atmel AT86RF232B

[Thomas Eichinger]

Hi,

> On 19 Mar 2015, at 10:54, Oleg Hahm  wrote:
> 
>> 
>> Sadly, I didn’t come too far with the driver, as it includes a (more) complex
>> communication with the module, at least for the pn532, and it was kind of a
>> private side project. My initial work can be found in [1].
> 
> Link was missing. ;)

Of course, sorry about that.

[1] https://github.com/thomaseichinger/RIOT/tree/pn532

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

Re: [riot-devel] NFC & Atmel AT86RF232B

[Thomas Eichinger]

Hi Joël,

ad NFC:
I got me some NXP pn532 modules some time ago as I heard there is work
on specifying 6LoWPAN over ISO 14443 (which NFC is part of). Beside this
there are a lot of interesting applications you could build in combination
with constraint networks.
Sadly, I didn’t come too far with the driver, as it includes a (more) complex
communication with the module, at least for the pn532, and it was kind of a
private side project. My initial work can be found in [1].

ad rf212b:
As Joakim stated, the existing at86rf231 driver supports the rf212b as the 
main functionality is the same for all current Atmel radio devices.
I’m also currently refactoring the driver, providing the ability to extend
the common functionality by very device specific features without writing
it from scratch. I have it running for the rf231 already but need some more
time to debug and entangle it correctly with all the other new network stack
work. I will open a WIP PR for this today.

Best, Thomas


> On 18 Mar 2015, at 22:04, Joël Chotard  wrote:
> 
> Hi all,
> 
> Does somebody is working on a RIOT NFC device driver ? and the ATMEL sub-G 
> AT86RF212B driver ?
> 
> Joël
> ___
> 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] NSTF radio driver

[Thomas Eichinger]

Hi Joakim,

sorry for the silence on this. The driver is almost ready I’ll open a
PR for it by Thursday at latest. I was discussing with Hauke the initialisation
process for the network stack and also initialisation in general.

I saw these memory corruptions too, but didn’t manage to identify the
source neither as I focused on the driver refactoring.

Looking forward for your review and testing.

Best, Thomas

> On 17 Mar 2015, at 12:42, Joakim Gebart  wrote:
> 
> Hi Thomas,
> 
> On Fri, Feb 20, 2015 at 10:53 AM, Thomas Eichinger
>  wrote:
>> Hi Joakim,
>> 
>> On 20 Feb 2015, at 9:31 CET(+0100), Joakim Gebart wrote:
>> 
>>> Thank you for the prompt response. I will start reading the existing
>>> drivers but I think I will wait at least until there is a PR for the rf231
>>> before I begin my implementation work.
>> 
>> As Peter mentioned I'm working hard on refactoring the rf2xx driver. As we
>> want to use it on EmbeddedWorld on Tuesday you can expect a PR for this
>> soonish. :-)
> 
> How is the new rf2xx driver coming along?
> 
> I have been seeing some memory corruption problems on my platform and
> I think it originates somewhere in the radio stack, but I have not
> managed to pinpoint it further. I would like to test the new driver
> before I spend more time chasing down a bug that might have already
> been fixed in the refactoring process.
> 
> Is there any WIP branch we can look at?
> Do you have any ETA for a PR?
> 
> 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] Need help about RIOT radio communicate example

[Thomas Eichinger]

Hi Chen,

I can remember having the same problem with the telosb. I traced it down 
to the fact, that there are no interrupts triggered. Which is strange
as the same code is working on an other msp430/cc2420 platform (Zolertia Z1).
Maybe a misconfiguration somehow sneaked into the radio driver setup.

As I don’t have a TelosB anymore I can’t debug it in more detail right now,
but maybe this gives you a hint.

Best, Thomas

> On 16 Mar 2015, at 19:11, Oleg Hahm  wrote:
> 
> Hi Chen!
> 
>> I connect 2 telosb to 2 USB port and used 2 terminal to "make term" to each
>> telosb board.
> 
> I guess you're using the default example, right?
> 
>> Then I use one board to txtsnd to other board address. But there is no
>> reaction from the other board. (For native mode, the other should show
>> received packets).
> 
> Do you have the possibility to use a sniffer somehow? This could be helpful to
> check if it is a sender or a receiver problem. You could also try to use "make
> debug" or set ENABLE_DEBUG to 1 in drivers/cc2420/cc2420_rx.c (cc2420_tx.c
> respectively), to figure out what fails. The last time I checked the driver
> was working, but I cannot verify right now, because I don't have any
> cc2420-based hardware here.
> 
> Thomas, Kévin, could one of you verify the problem?
> 
>> I also use the .elf file in cooja simulation tool, there is no reaction for
>> receiving node also.
>> And I think the #1442 bug is not a matter about shell(explanation from 2014
>> dec version), I think it's a cc2420 driver related bug.
> 
> Have you tried without setting the channel and PAN?
> 
> Cheers,
> Oleg
> -- 
> The problem UDP jokes
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel

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

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

[Thomas Eichinger]

Hi Tararaina,

for helping you with your problem, could share a link to your 
code with us? Or/and could you run `make` with command line option
`QUIET=0` and paste the output to pastepin [1] or a gist [2]?

Best, Thomas

[1] pastebin.com
[2] gist.github.com


On 24 Feb 2015, at 15:19 CET(+0100), Tararaina Klipffel wrote:

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

Re: [riot-devel] NSTF radio driver

[Thomas Eichinger]

Hi Joakim,

On 20 Feb 2015, at 9:31 CET(+0100), Joakim Gebart wrote:

> Thank you for the prompt response. I will start reading the existing
> drivers but I think I will wait at least until there is a PR for the rf231
> before I begin my implementation work.

As Peter mentioned I'm working hard on refactoring the rf2xx driver. As we
want to use it on EmbeddedWorld on Tuesday you can expect a PR for this
soonish. :-)

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

Re: [riot-devel] redbee-econotag board

[Thomas Eichinger]

Hi Ralph,

a short update:
I spent most of today’s afternoon to set up toolchain and additional tools 
again which
didn’t left much time for testing.

I can confirm the latter problem the app yielding. I will continue 
investigation tomorrow.
The first issue I couldn’t reproduce though. 

I will keep you updated on my findings.

Best, Thomas

> On 18 Feb 2015, at 14:54, Ralph Droms (rdroms)  wrote:
> 
>> 
>> On Feb 18, 2015, at 4:18 AM 2/18/15, Thomas Eichinger 
>>  wrote:
>> 
>> Hi Ralph,
>> 
>> first of all also welcome from my side.
>> 
>> Regarding the RIOT support for the redbee-econotag I can remember similar
>> problems which resulted from the compiler used. For this board it is 
>> important
>> to note that only the CodeSourcery GCC 2008q3 is supported. Could you 
>> check for this?
> 
> $ arm-none-eabi-gcc -v
> Using built-in specs.
> Target: arm-none-eabi
> Configured with: /scratch/julian/lite-respin/eabi/src/gcc-4.3/configure 
> --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi 
> --enable-threads --disable-libmudflap --disable-libssp 
> --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ 
> --disable-shared --with-newlib --with-pkgversion='Sourcery G++ Lite 
> 2008q3-66' --with-bugurl=https://support.codesourcery.com/GNUToolchain/ 
> --disable-nls --prefix=/opt/codesourcery --with-headers=yes 
> --with-sysroot=/opt/codesourcery/arm-none-eabi 
> --with-build-sysroot=/scratch/julian/lite-respin/eabi/install/arm-none-eabi 
> --with-gmp=/scratch/julian/lite-respin/eabi/obj/host-libs-2008q3-66-arm-none-eabi-i686-pc-linux-gnu/usr
>  
> --with-mpfr=/scratch/julian/lite-respin/eabi/obj/host-libs-2008q3-66-arm-none-eabi-i686-pc-linux-gnu/usr
>  --disable-libgomp --enable-poison-system-directories 
> --with-build-time-tools=/scratch/julian/lite-respin/eabi/install/arm-none-eabi/bin
>  --with-build-time-tools=/scratch/julian/lite-respin/
> eabi/install/arm-none-eabi/bin
> Thread model: single
> gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) 
> 
> Regarding the conditional assembly problem - this code snippet doesn't seem 
> to correctly recognize "(CPU != mc1322x)" (where "CPU = mc1322x" is set in 
> boards/redbee-econotag/Makefile.include):
> 
> .if (CPU != mc1322x)
>/* jump into vic interrupt */
>movr0, #0xff00/* lpc23xx */
>ldrr0, [r0]
>addlr,pc,#4
> .else
>/* mc1322x seems to lack a VIC, distinction of IRQ has to be done in SW */
>ldrr0, =isr   /* mc1322x */
> .endif
> 
> Running the code as distributed yields:
> 
> Board initialized.
> kernel_init(): This is RIOT! (Version: 2014.12-415-g1e6e-instant-contiki)
> kernel_init(): jumping into first task...
> #!undef abort at 0x1c00a0 (0x6809490E) originating from 0x400fe8
> 
> If I force assembly of the .else code, the code doesn't abort but only yields:
> 
> Board initialized.
> kernel_init(): This is RIOT! (Version: 2014.12-415-g1e6e-instant-contiki)
> kernel_init(): jumping into first task...
> 
> - Ralph
> 
>> 
>> I will have a more in depth look on your reported problem in the afternoon.
>> 
>> Kind regards,
>> Thomas
>> 
>>> On 17 Feb 2015, at 22:41, Ralph Droms (rdroms)  wrote:
>>> 
>>> 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
> 
> ___
> 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] Regarding Hardware Timer

[Thomas Eichinger]

Hi Shisir,

the log posted by Ludwig shows a hwtimer implementation with 4 timer slots.
(In most cases these refer to channels on the silicon timer which can be spread
over several silicon modules)
Each slot has its own callback getting executed when the below running timer
matches the set compare value. In combination the interrupt for this slot has
to be disabled.
For illustration I note the output of a hardware platform with only two timer
slots.

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

All timers set.

callback  1
hwtimer set.
```
After `hwtimer set.` you should not receive any more output from the board.

I hope this helps somehow. If got you wrong or there are any open questions 
don’t hesitate to contact this list.

Best, Thomas


> On 17 Feb 2015, at 20:10, shishir tiwari  wrote:
> 
> hi,
> 
> thanks for reply,
> 
> Still we have not disable timer interrupt?? so we will get interrupt
> every timer expire??
> 
> this "callback  1" print continues??
> 
> 
> please tell me what need tobe done??
> 
> thanks
> shishir
> 
> 
> On Tue, Feb 17, 2015 at 9:36 PM, Ludwig Ortmann
>  wrote:
>> 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
> ___
> 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

[Thomas Eichinger]

Hi Ralph,

first of all also welcome from my side.

Regarding the RIOT support for the redbee-econotag I can remember similar
problems which resulted from the compiler used. For this board it is important
to note that only the CodeSourcery GCC 2008q3 is supported. Could you 
check for this?

I will have a more in depth look on your reported problem in the afternoon.

Kind regards,
Thomas

> On 17 Feb 2015, at 22:41, Ralph Droms (rdroms)  wrote:
> 
> 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] Flashing the Samr21 xpro

[Thomas Eichinger]

Hi Baptiste,

these lines are copied from openocd’s shell output when executing `make flash`.

Best, Thomas

> On 10 Feb 2015, at 13:41, Baptiste Clenet  wrote:
> 
> Hi,
> 
> I tried the patch Thomas mentioned, it works great! Much faster.
> I only wonder how you get this:
> wrote 32768 bytes from file hello-world.hex in 5.071708s (6.310 KiB/s)
> │
> verified 16600 bytes in 1.374114s (11.797 KiB/s)
> I mean, how do you print those values?
> 
> Cheers,
> 
> 2015-01-27 14:54 GMT+01:00 Thomas Eichinger  <mailto:thomas.eichin...@fu-berlin.de>>:
> HI again,
> 
> with this patch [1] time needed to flash the samr21 gets divided
> by factor 3. (numbers below) For someone doing it very often this
> could be very interesting. It is still worked on but I tested it
> without error for now.
> Please provide feedback if you use this, as openocd guys are desperately
> looking for EDBG testers.
> 
> Best, Thomas
> 
> with patch:
> wrote 32768 bytes from file hello-world.hex in 5.071708s (6.310 KiB/s)
> │
> verified 16600 bytes in 1.374114s (11.797 KiB/s)
> 
> without patch
> wrote 32768 bytes from file hello-world.hex in 16.532793s (1.936 KiB/s)
> verified 16600 bytes in 1.432996s (11.313 KiB/s)
> 
> [1] http://openocd.zylin.com/#/c/2356/ <http://openocd.zylin.com/#/c/2356/>
> 
> > On 27 Jan 2015, at 13:48, Thomas Eichinger  > <mailto:thomas.eichin...@fu-berlin.de>> wrote:
> >
> > Hi again,
> >
> > after some research I found this post [1] on the openocd mailing list
> > explaining why flashing the samr21-xpro is unbearably slow.
> >
> > tl;dr
> > The openocd cmsis-dap driver operates in synchronous operation
> > and is not ported to a new asynchronous API yet.
> > Fingers crossed they port it soon.
> >
> > Best, Thomas
> >
> > [1] http://sourceforge.net/p/openocd/mailman/message/32496519/ 
> > <http://sourceforge.net/p/openocd/mailman/message/32496519/>
> >
> >> On 14 Jan 2015, at 15:46, Lucas Jenß  >> <mailto:li...@x3ro.de>> wrote:
> >>
> >> Hi again,
> >>
> >> so it seems that the slowness was caused by virtualization after all. My 
> >> previous VM was an Ubuntu 13.10 running inside an older version of VMware 
> >> Fusion, which resulted in the ~0.5KiB/s speed. After installing an Ubuntu 
> >> 14.10 that went up to ~1.5KiB/s and running OpenOCD directly on the host 
> >> gets me close to 2KiB/s when flashing.
> >>
> >> On OS X 10.9:
> >>
> >> wrote 32768 bytes from file hello-world.hex in 16.164614s (1.980 KiB/s)
> >> verified 16892 bytes in 1.463347s (11.273 KiB/s)
> >>
> >> On Ubuntu 14.10:
> >>
> >> wrote 32768 bytes from file 
> >> /home/lucas/RIOT/examples/hello-world/bin/samr21-xpro/hello-world.hex in 
> >> 22.042933s (1.452 KiB/s)
> >> verified 16892 bytes in 1.505869s (10.955 KiB/s)
> >>
> >> Cheers,
> >> Lucas
> >>
> >> On 13 Jan 2015, at 11:18, Martin  >> <mailto:martin.landsm...@haw-hamburg.de>> wrote:
> >>
> >>> Hi,
> >>>
> >>> my flashing speed is roughly equal to Thomas' for the Samr21-xpro:
> >>>
> >>> ```
> >>> wrote 65536 bytes from file RIOT/tests/pnet/bin/samr21-xpro/pnet.hex in 
> >>> 32.083557s (1.995 KiB/s)
> >>> verified 49688 bytes in 4.114729s (11.793 KiB/s)
> >>> ```
> >>>
> >>> My openocd version:
> >>> `Open On-Chip Debugger 0.9.0-dev-00186-g30203b3 (2014-11-12-11:49)`
> >>>
> >>> Best regards,
> >>> Martin
> >>> On 12.01.2015 21:07, Baptiste Clenet wrote:
> >>>> Flashing is slow for us too, how do you get the speed?
> >>>>
> >>>> 2015-01-12 11:13 GMT+01:00 Lucas Jenß  >>>> <mailto:li...@x3ro.de>>:
> >>>> Hi Thomas,
> >>>>
> >>>> verification was much faster as 0.4KiB/s, I think around 10 or so for me.
> >>>> I checked out OpenOCD on the 9th. I’m also running Linux inside VMware
> >>>> though, so maybe it’s just caused by the virtualization. I’ll see how 
> >>>> fast
> >>>> it is on the host.
> >>>>
> >>>> Cheers,
> >>>> Lucas
> >>>>
> >>>> A couple of days ago.
> >>>>
> >>>> On 12 Jan 2015, at 11:00, Thomas Eichinger 
>

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

[Thomas Eichinger]

Hi Kévin,

just checked with RIOT’s master and default example works for me.
When you run `make term` is the yellow status LED on the board on?

Best, Thomas

> On 06 Feb 2015, at 11:57, Ludwig Ortmann  wrote:
> 
> 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

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

Re: [riot-devel] How low can you go?

[Thomas Eichinger]

Hi,

> On 06 Feb 2015, at 09:36, Ludwig Ortmann  wrote:
> 
> 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).
Yes, I will take up work on this again next week, as we have a stable netdev
interface by today.

Best, Thomas

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

[riot-devel] Bypassing hardware vendors' unlicensed header files

[Thomas Eichinger]

Dear list,

tl;dr: Does anybody have experience with SVD files?

Since it happened at least two times that ports of RIOT to new hardware was put 
on halt because of unclear or no license statements in hardware manufacturers 
header files I did some research into this direction.

What I found yet are SVD (System View Definition) files, specified by ARM and 
somehow
distributed I was thinking about generating missing header files directly from 
this
definitions.

Would it make sense to generate our own header files from these files?

Does anybody have any experience with those files and license implications with 
those?
(When searching the ARM page there are a couple of EULAs to accept and so forth)

Any input on this topic is welcome.

Best, Thomas

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

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

[Thomas Eichinger]

Hi Jan,

maybe you already saw this but github provides a guide to its workflow. [1]
Its well illustrated, hope it helps.

Best, Thomas

[1] https://guides.github.com/introduction/flow/ 


> On 04 Feb 2015, at 19:58, Jan Wagner  wrote:
> 
> hi devs,
>  
> i still had some troubles with git, and create correctly branched pulls. this 
> is the best command line based
> tutorial  I found - and now even I seem to understand :)
>  
> https://www.atlassian.com/git/tutorials/making-a-pull-request/example 
> 
>  
> i still did not find the correct way to add TAGS to pulls - can anyone give 
> me a hint on that ?
>  
> have fun
> ___
> 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] [i...@meetup.com: Invitation: Internet of Things Meetup 12 – Intel Edison]

[Thomas Eichinger]

See you there!

Best, Thomas

> On 29 Jan 2015, at 13:43, Emmanuel Baccelli  
> wrote:
> 
> Hi all,
> I will probably join too.
> Cheers
> Emmanuel
> 
> On Thu, Jan 29, 2015 at 1:31 PM, Frank Holtz  > wrote:
> Hi,
> 
> i have joined this meeting.
> 
> Frank
> 
> Am 29.01.2015 11:48, schrieb Hauke Petersen:
> Hi,
> 
>  sounds interesting, I think I will go. Anyone joining in?
> 
>  Cheers,
>  Hauke
> 
> On 28.01.2015 13:28, Oleg Hahm wrote:
> 
> Dear rhyming IoTlers (from the Berlin region),
> 
> this might be interesting for folks with an interest in Intels IoT
> stuff.
> 
> Cheers,
> Oleg
> 
> ___
> devel mailing list
> devel@riot-os.org 
> http://lists.riot-os.org/mailman/listinfo/devel 
>  [1]
> 
> 
> 
> Links:
> --
> [1] 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] Porting RIOT for PSoC 5LP Development Kit (CY8CKIT-050)

[Thomas Eichinger]

Of course I missed the link. Sorry.

[1] https://github.com/RIOT-OS/RIOT/wiki/Porting-Guide 
<https://github.com/RIOT-OS/RIOT/wiki/Porting-Guide>

> On 27 Jan 2015, at 20:12, Thomas Eichinger  
> wrote:
> 
> Hi Murat,
> 
> welcome also from my side.
> In the wiki there exists a porting guide [1] describing the basic steps 
> needed.
> Looking forward to your port.
> 
> Best, Thomas
> 
>> On 27 Jan 2015, at 19:57, Murat CAKMAK > <mailto:m...@muratcakmak.net>> wrote:
>> 
>> Hi all, 
>>  
>> I want to port RIOT (If there is nobody working on it) to CY8CKIT-050 
>> development kit to use RIOT on Cypress PSoC 5LP processor. 
>> I have created a wiki page : Board: CY8CKIT 050 PSoC® 5LP 
>> <https://github.com/RIOT-OS/RIOT/wiki/Board%3A-CY8CKIT-050-PSoC%C2%AE-5LP>
>> I will provide more information in wiki page.
>>  
>> It is my first activity in this group so does RIOT community need any 
>> additional information? 
>>  
>> Regards.
>>  
>> Murat CAKMAK
>> Senior SW Engineer at Cypress Semiconductor
>> ___
>> devel mailing list
>> devel@riot-os.org <mailto:devel@riot-os.org>
>> http://lists.riot-os.org/mailman/listinfo/devel 
>> <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] Porting RIOT for PSoC 5LP Development Kit (CY8CKIT-050)

[Thomas Eichinger]

Hi Murat,

welcome also from my side.
In the wiki there exists a porting guide [1] describing the basic steps needed.
Looking forward to your port.

Best, Thomas

> On 27 Jan 2015, at 19:57, Murat CAKMAK  wrote:
> 
> Hi all, 
>  
> I want to port RIOT (If there is nobody working on it) to CY8CKIT-050 
> development kit to use RIOT on Cypress PSoC 5LP processor. 
> I have created a wiki page : Board: CY8CKIT 050 PSoC® 5LP 
> 
> I will provide more information in wiki page.
>  
> It is my first activity in this group so does RIOT community need any 
> additional information? 
>  
> Regards.
>  
> Murat CAKMAK
> Senior SW Engineer at Cypress Semiconductor
> ___
> 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

[Thomas Eichinger]

HI again,

with this patch [1] time needed to flash the samr21 gets divided 
by factor 3. (numbers below) For someone doing it very often this
could be very interesting. It is still worked on but I tested it 
without error for now. 
Please provide feedback if you use this, as openocd guys are desperately
looking for EDBG testers.

Best, Thomas

with patch:
wrote 32768 bytes from file hello-world.hex in 5.071708s (6.310 KiB/s)  
  │
verified 16600 bytes in 1.374114s (11.797 KiB/s)

without patch
wrote 32768 bytes from file hello-world.hex in 16.532793s (1.936 KiB/s) 
  
verified 16600 bytes in 1.432996s (11.313 KiB/s)

[1] http://openocd.zylin.com/#/c/2356/

> On 27 Jan 2015, at 13:48, Thomas Eichinger  
> wrote:
> 
> Hi again,
> 
> after some research I found this post [1] on the openocd mailing list
> explaining why flashing the samr21-xpro is unbearably slow.
> 
> tl;dr 
> The openocd cmsis-dap driver operates in synchronous operation
> and is not ported to a new asynchronous API yet. 
> Fingers crossed they port it soon.
> 
> Best, Thomas
> 
> [1] http://sourceforge.net/p/openocd/mailman/message/32496519/
> 
>> On 14 Jan 2015, at 15:46, Lucas Jenß  wrote:
>> 
>> Hi again,
>> 
>> so it seems that the slowness was caused by virtualization after all. My 
>> previous VM was an Ubuntu 13.10 running inside an older version of VMware 
>> Fusion, which resulted in the ~0.5KiB/s speed. After installing an Ubuntu 
>> 14.10 that went up to ~1.5KiB/s and running OpenOCD directly on the host 
>> gets me close to 2KiB/s when flashing. 
>> 
>> On OS X 10.9:
>> 
>> wrote 32768 bytes from file hello-world.hex in 16.164614s (1.980 KiB/s)
>> verified 16892 bytes in 1.463347s (11.273 KiB/s)
>> 
>> On Ubuntu 14.10:
>> 
>> wrote 32768 bytes from file 
>> /home/lucas/RIOT/examples/hello-world/bin/samr21-xpro/hello-world.hex in 
>> 22.042933s (1.452 KiB/s)
>> verified 16892 bytes in 1.505869s (10.955 KiB/s)
>> 
>> Cheers,
>> Lucas
>> 
>> On 13 Jan 2015, at 11:18, Martin  wrote:
>> 
>>> Hi,
>>> 
>>> my flashing speed is roughly equal to Thomas' for the Samr21-xpro:
>>> 
>>> ```
>>> wrote 65536 bytes from file RIOT/tests/pnet/bin/samr21-xpro/pnet.hex in 
>>> 32.083557s (1.995 KiB/s)
>>> verified 49688 bytes in 4.114729s (11.793 KiB/s)
>>> ```
>>> 
>>> My openocd version:
>>> `Open On-Chip Debugger 0.9.0-dev-00186-g30203b3 (2014-11-12-11:49)`
>>> 
>>> Best regards,
>>> Martin
>>> On 12.01.2015 21:07, Baptiste Clenet wrote:
>>>> Flashing is slow for us too, how do you get the speed?
>>>> 
>>>> 2015-01-12 11:13 GMT+01:00 Lucas Jenß :
>>>> Hi Thomas,
>>>> 
>>>> verification was much faster as 0.4KiB/s, I think around 10 or so for me.
>>>> I checked out OpenOCD on the 9th. I’m also running Linux inside VMware
>>>> though, so maybe it’s just caused by the virtualization. I’ll see how fast
>>>> it is on the host.
>>>> 
>>>> Cheers,
>>>> Lucas
>>>> 
>>>> A couple of days ago.
>>>> 
>>>> On 12 Jan 2015, at 11:00, Thomas Eichinger  
>>>> wrote:
>>>> 
>>>>> Hi Lucas,
>>>>> 
>>>>> I was playing with the openocd configuration a bit, mainly
>>>>> `adapter_speed`, back when support for this was added without
>>>>> any significant outcome.
>>>>> Problem is, the EDBG chip, on the bottom of the board, handling
>>>>> communication with the MCU is specified to run on 1MHz and the
>>>>> openocd docs mention, for CMSIS-DAP, it is not advised to let
>>>>> signal frequency exceed half of the operating frequency.
>>>>> (I’d guess Nyquist-Shannon applies)
>>>>> 
>>>>> That said, 0.481KiB/s still seems slow for this. I’m at least
>>>>> reaching 1.787KiB/s for flashing and 11.190KiB/s for verification.
>>>>> When did you check out the OpenOCD code?
>>>>> 
>>>>> Best, Thomas
>>>>> 
>>>>>> On 10 Jan 2015, at 14:25, Lucas Jenß  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 t

Re: [riot-devel] Flashing the Samr21 xpro

[Thomas Eichinger]

Hi again,

after some research I found this post [1] on the openocd mailing list
explaining why flashing the samr21-xpro is unbearably slow.

tl;dr 
The openocd cmsis-dap driver operates in synchronous operation
and is not ported to a new asynchronous API yet. 
Fingers crossed they port it soon.

Best, Thomas

[1] http://sourceforge.net/p/openocd/mailman/message/32496519/

> On 14 Jan 2015, at 15:46, Lucas Jenß  wrote:
> 
> Hi again,
> 
> so it seems that the slowness was caused by virtualization after all. My 
> previous VM was an Ubuntu 13.10 running inside an older version of VMware 
> Fusion, which resulted in the ~0.5KiB/s speed. After installing an Ubuntu 
> 14.10 that went up to ~1.5KiB/s and running OpenOCD directly on the host gets 
> me close to 2KiB/s when flashing. 
> 
> On OS X 10.9:
> 
> wrote 32768 bytes from file hello-world.hex in 16.164614s (1.980 KiB/s)
> verified 16892 bytes in 1.463347s (11.273 KiB/s)
> 
> On Ubuntu 14.10:
> 
> wrote 32768 bytes from file 
> /home/lucas/RIOT/examples/hello-world/bin/samr21-xpro/hello-world.hex in 
> 22.042933s (1.452 KiB/s)
> verified 16892 bytes in 1.505869s (10.955 KiB/s)
> 
> Cheers,
> Lucas
> 
> On 13 Jan 2015, at 11:18, Martin  wrote:
> 
>> Hi,
>> 
>> my flashing speed is roughly equal to Thomas' for the Samr21-xpro:
>> 
>> ```
>> wrote 65536 bytes from file RIOT/tests/pnet/bin/samr21-xpro/pnet.hex in 
>> 32.083557s (1.995 KiB/s)
>> verified 49688 bytes in 4.114729s (11.793 KiB/s)
>> ```
>> 
>> My openocd version:
>> `Open On-Chip Debugger 0.9.0-dev-00186-g30203b3 (2014-11-12-11:49)`
>> 
>> Best regards,
>> Martin
>> On 12.01.2015 21:07, Baptiste Clenet wrote:
>>> Flashing is slow for us too, how do you get the speed?
>>> 
>>> 2015-01-12 11:13 GMT+01:00 Lucas Jenß :
>>> Hi Thomas,
>>> 
>>> verification was much faster as 0.4KiB/s, I think around 10 or so for me.
>>> I checked out OpenOCD on the 9th. I’m also running Linux inside VMware
>>> though, so maybe it’s just caused by the virtualization. I’ll see how fast
>>> it is on the host.
>>> 
>>> Cheers,
>>> Lucas
>>> 
>>> A couple of days ago.
>>> 
>>> On 12 Jan 2015, at 11:00, Thomas Eichinger  
>>> wrote:
>>> 
>>>> Hi Lucas,
>>>> 
>>>> I was playing with the openocd configuration a bit, mainly
>>>> `adapter_speed`, back when support for this was added without
>>>> any significant outcome.
>>>> Problem is, the EDBG chip, on the bottom of the board, handling
>>>> communication with the MCU is specified to run on 1MHz and the
>>>> openocd docs mention, for CMSIS-DAP, it is not advised to let
>>>> signal frequency exceed half of the operating frequency.
>>>> (I’d guess Nyquist-Shannon applies)
>>>> 
>>>> That said, 0.481KiB/s still seems slow for this. I’m at least
>>>> reaching 1.787KiB/s for flashing and 11.190KiB/s for verification.
>>>> When did you check out the OpenOCD code?
>>>> 
>>>> Best, Thomas
>>>> 
>>>>> On 10 Jan 2015, at 14:25, Lucas Jenß  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
>>>> 
>>> 
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> http://lists.riot-os.org/mailman/listinfo/devel
>>> 
>>> 
>>> 
>>> -- 
>>> Clenet Baptiste
>>> FR: +33 6 29 73 05 39
>>> Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte 
>>> système temps réél embarqué
>>> Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014
>>> 
>>> 
>>> 
>>> ___
>>> devel mailing list
>>> 
>>> devel@riot-os.org
>>> http://lists.riot-os.org/mailman/listinfo/devel
>> 
>> ___
>> devel mailing list
>> devel@riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
> 
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel

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

Re: [riot-devel] Network Stack Task Force

[Thomas Eichinger]

Hi,

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

Best, Thomas

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

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

Re: [riot-devel] RFDuino Board -> add to Wiki please (and more)

[Thomas Eichinger]

Hi Jan,

> On 13 Jan 2015, at 11:13, Jan Wagner  wrote:
> 
> https://github.com/RIOT-OS/RIOT/blob/master/boards/yunjia-nrf51822/include/periph_conf.h
> 
> #define GPIO_0_PIN 7
> #define GPIO_1_PIN 8
> #define GPIO_2_PIN 9
> etc.
> 
> I dont get why its starting at 7. i dont own a yunia board.
> 
> (http://forum.rfduino.com/index.php?topic=377.0 - Pin assignment nRF51822 ->
> RFD22301)

I’m not the expert for these nrf MCUs/boards but these mappings work on MCU pin
numbering. So `GPIO_0_PIN` which is MCU’s pin 7 could be mapped to the boards’s
pin with the label “P1.1000” (I’m making these up).
So you’ll need the boards data sheet to get the MCU’s pin connected to which 
board
pin.

Best, Thomas

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

Re: [riot-devel] Flashing the Samr21 xpro

[Thomas Eichinger]

Hi Lucas,

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

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

Best, Thomas

> On 10 Jan 2015, at 14:25, Lucas Jenß  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

Re: [riot-devel] Merry Christmas and a Happy New Year

[Thomas Eichinger]

Thank you all for an amazing year with RIOT! 
Looking forward to an exciting year 2015.

Best wishes to you all.

Thomas

> On 24 Dec 2014, at 12:12, Oleg Hahm  wrote:
> 
> Dear romantic IoTlers,
> 
> for those of you not using Twitter (regularly), let me point to
> https://twitter.com/RIOT_OS/status/547442255456649217
> 
> Thanks for a very successful year, great work and fruitful discussions in an
> awesome community. Let's hope for another amazing year with RIOT in 2015. Have
> some relaxing days and enjoy the holidays!
> 
> Cheers,
> Oleg
> -- 
> /* When we have more time, we can teach the penguin to say 
> * "By your command" or "Activating turbo boost, Michael".
> */
>linux-2.2.16/arch/sparc/prom/sun4prom.c
> ___
> devel mailing list
> devel@riot-os.org
> 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

[Thomas Eichinger]

Hi Shishir,

> On 30 Dec 2014, at 12:04, shishir tiwari  wrote:
> 
> Is Porting for ARC600/ ARC700 (Synopsys) has been done. Any idea?

As far as I know nobody started to port RIOT to Synopsys processors although 
they
seem quite interesting to me. Although, I don’t know how to get them samples/DKs
without of industrial context. If you have any plans into this direction please 
share them on this list and we’d be happy to support you as much as possible.

Best, Thomas

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

Re: [riot-devel] Switch to BSD?

[Thomas Eichinger]

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

I read a lot of strong words and claims like “ethical correct decision” and 
similar in this debate (I had them on my mind too) which are by definition 
highly political and philosophical and I for my self question the metrics I
use to support these.

But yes, this list is not the right place to discuss this.

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

Re: [riot-devel] Switch to BSD?

[Thomas Eichinger]

Hi,

> On 15 Dec 2014, at 15:34, Kaspar Schleiser  wrote:
> 
> On 12/15/2014 03:03 PM, Thomas Eichinger wrote:
>> Philosophical question: If we take open source software as an altruistic 
>> approach
>> to publish software for the greater good wouldn’t it be contradictory to tell
>> others to give something in return and exclusionary to those who simply 
>> can’t?
> Not in a world which is mostly ruled by the interests of companies which 
> don't have the greater good in their priorities.
> 
> Giving away source code which strenghtens those is contraproductive to the 
> common good.
Right, but giving away source code which isn’t used by those doesn’t serve the 
common good neither as it is only used by the initiated elite and not delivered 
to the broad public. IMHO.

Thomas

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

Re: [riot-devel] Switch to BSD?

[Thomas Eichinger]

Dear all,


> On 15 Dec 2014, at 11:10, Ludwig Ortmann  wrote:
> 
> As for the general topic of relicensing:

Personally speaking I’m rather pragmatic on this topic and either license is 
fine for
me *but* I tend to advocate for MIT.

ad "contributing back”: Apart from companies practicing an open source culture
forcing those others to open their changes doesn’t imply for me RIOT will 
actually 
benefit from these. Opening their changes doesn’t mean these will be opened
in a way RIOT maintainers know about it. They simply have to put them
somewhere publicly accessible. While with a non-restrictive license we could get
the contributions (maybe also in a better shape in terms of coding style and 
quality)
from those who’d do it with LGPL and maybe broaden the basis and convince others
(by improvements and further development on RIOT’s master) to consider opening
their changes to not get left behind. *
As Emmanuel put it, it is a bet we will have to place.

ad “mimic Linux’s story“: Looking into Linux’s story is and was very unique and 
GPL is no guarantee against patent trolls. Additionally I think today we are 
embedded in an even faster moving/developing environment with a big challenge
arising next October in form of mbed OS.

The biggest blocker implied by LGPL I see is that someone providing RIOT driven
hardware has to provide means to re-flash the devices with self compiled 
binaries.
At least that’s what I understood in past discussions and what I simply can’t 
imagine to become widely adopted.


IMHO I think in the short and mid term it is greatly beneficial at least one 
big 
player taking up on RIOT providing resources to maintain and improve it and the 
whole surrounding quite changed since Linux emerged.
Also as most “bigger” open source projects are in some sort backed by a company 
to
ensure development, we are dealing with companies (I’m mainly referring to HW
aspect here) who are not used to deal with open source by now. Taking this into
account I don’t believe RIOT’s technical advantages can prevail the concerns for
many companies. **

To sum up, I would like to see RIOT as wide spread as possible and thereby 
promote
(at least) open networking standards and I think RIOT licensed under MIT has the
highest chance to succeed in this. ***

Best, Thomas


*   Philosophical question: If we take open source software as an altruistic 
approach
to publish software for the greater good wouldn’t it be contradictory to tell 
others to give something in return and exclusionary to those who simply can’t?

**  My (limited) experience from working for HW manufacturers is more like 
“don’t even
mention these three evil letters”. This matches Emmanuel’s and Matthias’ 
experiences
quite well.

*** In my personal Utopia we wouldn’t have to discuss this but would be 
consensus to
open all code for the greater good but the above thoughts come to my mind when
reality hits me.

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

Re: [riot-devel] RPL_UDP problem for Samr21

[Thomas Eichinger]

Hi Maxence,

started the debugger for the samr21 a minute ago and it seems for the rpl_udp 
example it crashes
when calling printf in `kernel_init`. Could you verify this by setting a 
breakpoint for kernel_init?
It should then go into hard fault for the second line. 
This said I didn’t investigate any further by now and probably won’t find time 
today but it might
provide you and others with an additional hint. Could you also open an issue on 
github for this?

Best, Thomas 

> On 10 Dec 2014, at 10:08, Maxence Chotard  wrote:
> 
> Hi !
>  
> I am trying to make rpl_udp example work for samr21. I am quite surprised 
> that every time I want to debug the code on the board it goes to « 
> isr_hard_fault » even if the program didn’t enter in my main and execute 
> possible wrong code. So I am wondering if somebody could explain me how the 
> system starts and why I am facing such problems ?
>  
> Cheers ,
> Maxence
> ___
> 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] Separating module drivers from physical pin configuration

[Thomas Eichinger]

Dear Joakim,

> On 30 Nov 2014, at 18:02, Joakim Gebart  wrote:
> I would like to have a separate driver for setting up the CPU pin mux.
> That is, separate the CPU logic module drivers (such as SPI, I2C, UART
> etc.) from the actual hardware ports and pins. 

You mean introducing a central point to handle all the PIN initialisation for
the other peripherals? “Mux-driver, initialise pins for UART3!”

> By improving the separation/abstraction it may make it easier use the
> same board directory for multiple variations of the same board, where
> the on board peripherals are the same, or almost the same, and only
> some minor additions.

I see your point here, but couldn’t it be realised by using some different
configuration in periph_conf.h separated by preprocessor guards? Like:

```C
#ifdef MULLE_v1
  #define SPI0_MISO_PIN PA12
  ...
#elif MULLE_v1.2
  #define SPI0_MISO_PIN PB09
  ...
#endif
```

> Because of the hardware function muxing capabilities in advanced MCUs
> is usually in a separate module it is only logical that the driver for
> a CPU module does not need to know anything about which pin numbers on
> the IC is connected to its signals, the driver should only control the
> logic within its own module.

The peripheral interface currently tries to exploit the greatest possible
common set of functionality while minimising overhead. Since such a mux-driver
would mainly be used in the other peripheral drivers it could be optional.
Also it would need evaluation of the impact on more constraint platforms
(cortex-M0 etc.) in terms of memory and clock rate.

I like the idea in general but could you elaborate a little bit more on the
concrete use case and implementation so we can discuss this in more detail.

Best, Thomas



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

Re: [riot-devel] [quentin.lam...@orange.com: [iot-lab-users] OpenOCD and M3 nodes : configuration file using the FTDI interface driver pushed upstream]

[Thomas Eichinger]

Hi,

> On 27 Nov 2014, at 17:34, Oliver Hahm  wrote:
> 
> P.S. Haven't compared with our version, nor tested yet.
Tested it a minute ago. It has some slightly different configurations, couldn’t 
make out any differences in behaviour nor performance though.
But we don’t have to maintain it our selfs anymore! \o/

Best, Thomas

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

Re: [riot-devel] At86rf231 for samr21

[Thomas Eichinger]

Hi Maxence,


> On 24 Nov 2014, at 21:00, Maxence Chotard  wrote:
> I am facing a problem with the at86rf231 implementation for samr21-xpro. Is
> there somebody who could explain me how to add a module in RIOT in order to
> use it?
You are already on the right path. With USEMODULE you can specify which modules
to include into your build.

> I'm trying to add USEMODULE at86rf231 in default exemple Makefile but I
> can't make it work. My main.c can't access to transceiver.h so if somebody
> has any idea how to solve this problem I would be grateful !
The dependency works the other way around. When you specify

USEMODULE += transceiver

in you Makefile, the build system knows which radio driver to include (at86rf231
for the samr21-xpro). You can then send messages to the transceiver to control
the radio interface.
You should be able to play with example/default out of the box if including 
Troels’
PR [1]. The default example then provides shell commands to set the node’s
address, channel, PAN and also the txtsnd command you can use to send data 
between
two nodes.
To get a feeling how to interact with the transceiver module in your own code
you can also take a look at sys/shell/commands/sc_transceiver.c.

Hope this somehow provides you the information to get started. Else don’t 
hesitate
to ask on this list.

Best, Thomas

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

Re: [riot-devel] iot-lab_M3

[Thomas Eichinger]

Hi Martin,

below the configuration options I use to build for OS X

```
./configure —disable-dependency-tracking —prefix= 
—enable-dummy —enable-buspirate —enable-jtag_vpi —enable-remote-bitbang 
—enable-usb_blaster_libftdi —enable-presto_libftdi —enable-openjtag_ftdi 
—enable-legacy-ft2232_libftdi
```
Let me know if this helps, I’d update the wiki accordingly.

Best, Thomas


> On 12 Nov 2014, at 11:13, Martin  wrote:
> 
> Hi Oleg,
> 
> tried it, but still no luck.
> I also tried it together with @PeterKietzmann on a different linux 
> distribution but all the same results for all steps.
> 
> Best regards,
> Martin
> 
> On 11.11.2014 17:39, Oleg Hahm wrote:
>> Hi Martin!
>> 
>>> sorry for bothering.
>> No problem.
>>  
>>> invoking `make BOARD=iot-lab_M3 flash` results in
>>> ```
>>> ...
>>> DEPRECATED! use 'adapter_khz' not 'jtag_khz'
>>> adapter speed: 1000 kHz
>>> Error: The specified debug interface was not found (ft2232)
>>> ...
>>> ```
>> If you have built OpenOCD yourself, make sure to run the configure script 
>> with
>>  --enable-legacy-ft2232_ftd2xx
>> to enable the legacy interface (IIRC). Thomas might correct me if I'm wrong.
>> 
>> Cheers,
>> Oleg
>> 
>> 
>> ___
>> devel mailing list
>> devel@riot-os.org 
>> http://lists.riot-os.org/mailman/listinfo/devel 
>> 
> 
> ___
> devel mailing list
> devel@riot-os.org
> 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-OS on telosb, issue with default example

[Thomas Eichinger]

Hi Ivano,

sorry we couldn’t solve this problem in the meanwhile. We have a demo in 
beginning
of November and most core devs are currently very busy preparing for this.
Coming to your question, I’ll first cite Oleg’s answer to a similar question on 
the users
mailing list:

> Actually, in the past it turned out to be difficult finding widely available
> and not too expensive Cortex driven platforms with a radio chip. Fortunately,
> it seems that the situation is slowly improving with some new boards popping
> up on the market to fill this gap.
> 
> Currently we're mostly focusing on support for the IoT-Lab M3 nodes [1][2]
> which are used in the FIT IoT-LAB [3]. Although these nodes are only available
> as part of the testbed, the IoT-Lab provides open remote access. Otherwise,
> you might consider using the HikoB Fox [4] which is very similar to the
> IoT-Lab hardware. If you work for some company, you can purchase these boards
> from HikoB. 
> 
> We have also preliminary support for the Atmel SAM R21 [5] which also features
> the same radio transceiver. A more functional support for this platform may
> become available in December.

Additionally there is the Zolertia Z1 [6] somehow a successor to the TelosB with
very similar hardware. The RIOT port for this works (yes even receiving :)) and
got a lot of attention lately.

Also there are new ports emerging for boards running a TI CC2538 (OpenMote [8] 
and
cc2538dk [7]) while currently in an early stage these got some traction lately.

I can’t give you an explicit recommendation because I don’t know your project
needs and timeframe. If you want we could also discuss this off-list.

Hope this helps somehow.

Best, Thomas

[1] https://www.iot-lab.info/hardware/m3/ 
<https://www.iot-lab.info/hardware/m3/>
[2] https://github.com/RIOT-OS/RIOT/wiki/Board%3A-IoT-LAB_M3 
<https://github.com/RIOT-OS/RIOT/wiki/Board%3A-IoT-LAB_M3>
[3] https://www.iot-lab.info/ <https://www.iot-lab.info/>
[4] http://www.hikob.com/assets/uploads/2014/07/HIKOB_FOX_ProductSheet_EN.pdf 
<http://www.hikob.com/assets/uploads/2014/07/HIKOB_FOX_ProductSheet_EN.pdf>
[5] http://www.atmel.com/tools/atsamr21-xpro.aspx 
<http://www.atmel.com/tools/atsamr21-xpro.aspx>
[6] http://www.zolertia.com/ti <http://www.zolertia.com/ti>
[7] http://www.ti.com/tool/cc2538dk <http://www.ti.com/tool/cc2538dk>
[8] http://www.openmote.com/openmote-cc2538/ 
<http://www.openmote.com/openmote-cc2538/>

> On 22 Oct 2014, at 17:30, Ivano Calabrese  wrote:
> 
> Hi Thomas, hi folks.
> it seems I don't find a solution to this issue. Since I believe that RIOT-OS 
> is a good OS and I need a board with 802.15.4 link layer, can you suggest me 
> which board is really compatible with RIOT-OS. Of sure I'll come back on this 
> issue but now I need to go along on my project.
> 
> Thanks a lot guys.
> 
> 
> 
> 
> 
>  
> 
> 
> Ivano Calabrese, MSc.
> http://www.dei.unipd.it/~icalabre/ <http://www.dei.unipd.it/~icalabre/>
> https://www.linkedin.com/in/ivanocalabrese 
> <https://www.linkedin.com/in/ivanocalabrese>
> 
> On 22 October 2014 12:18, Ivano Calabrese  <mailto:alphaem...@gmail.com>> wrote:
> Hi Thomas,
> I tried to set monitor 1(on telosb_A) but I didn't obtain success. After you 
> remind me to use monitor 1 command, I tried again. Now having some print 
> debugs I can look that if I set monitor to 1 (on telosb_A), the msp430 
> doesn't receive interrupt signal. Come back to monitor 0, the telosb_A 
> restart to receive only after a new transmission (from telosb_A to telosb_B).
> 
> the same happen if I change A with B.
> 
> Best
> 
> ________
> Ivano Calabrese, MSc.
> http://www.dei.unipd.it/~icalabre/ <http://www.dei.unipd.it/~icalabre/>
> https://www.linkedin.com/in/ivanocalabrese 
> <https://www.linkedin.com/in/ivanocalabrese>
> 
> On 22 October 2014 11:25, Thomas Eichinger  <mailto:thomas.eichin...@fu-berlin.de>> wrote:
> Hi Ivano,
> 
> could you check if it is the same situation if you set the receiving node into
> promiscuous mode using the shell command
> 
> monitor 1
> 
> Reading the cc2420 spec FIFOP should rise independently of the threshold if a 
> valid packet is received.
> 
> cc2420 data sheet p. 33
> > When address recognition is enabled the FIFOP pin will remain inactive 
> > until the incoming frame passes address recognition, even if the number 
> > of bytes in the RXFIFO exceeds the programmed threshold. 
> 
> Maybe the address encoding in the default example does not match the
> cc2420’s decoding rules.
> 
> Best, Thomas
>   
>> On 21 Oct 2014, at 18:17, Ivano Calabrese > &

Re: [riot-devel] Port of RIOT on Samr21

[Thomas Eichinger]

Hi Baptiste,

> On 22 Oct 2014, at 15:08, Baptiste Clenet  wrote:
> Thomas, I'm looking at the uart.c that you wrote. Why did you only develop 
> one UART?
The intention was to get preliminary support for this board fast. For this I 
chose to implement
one UART using one SERCOM. It can be seen as prototype and be applied to 
additional 
SERCOMs if needed.

> After reading the datasheet, I see that the samd21 has got 5 SERCOM which can 
> be used by USART, I2C, SPI and LIN slave. 
> With RIOT, we can set 4 USART and 4 I2C. How do we proceed with the 5 SERCOM? 
I’d suggest we take one SERCOM for SPI (needed for the radio device) and one 
for I2C to provide
an example implementation for someone interested into this board. How many of 
each of them 
(SPI,I2C,USART) one would actually use later could then be configured via 
periph_conf.h by adopting
to individual needs. One could say I don’t need an USART I’ll take the spare 
SERCOM to physically
connect another SPI device or similar.

> You chose PIN_PA04 and PIN_PA05 for UART 0. Which one should I use for UART 
> 1,2,3? 
> And Atmel chose to define I2C on PIN_PA16  and PIN_PA17, on which pin will be 
> the following I2C?
For this we’d have to consult the multiplexing table in the Atmel data sheet p. 
12. There are not
too many possible combinations.

Currently I’m busy developing sensor drivers for the iot-lab_M3 for a demo we 
give beginning 
of November. When these are done the samr21 will get some more love again. :)

Best, Thomas

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

Re: [riot-devel] RIOT-OS on telosb, issue with default example

[Thomas Eichinger]

Hi Ivano,

could you check if it is the same situation if you set the receiving node into
promiscuous mode using the shell command

monitor 1

Reading the cc2420 spec FIFOP should rise independently of the threshold if a 
valid packet is received.

cc2420 data sheet p. 33
> When address recognition is enabled the FIFOP pin will remain inactive 
> until the incoming frame passes address recognition, even if the number 
> of bytes in the RXFIFO exceeds the programmed threshold. 

Maybe the address encoding in the default example does not match the
cc2420’s decoding rules.

Best, Thomas

> On 21 Oct 2014, at 18:17, Ivano Calabrese  wrote:
> 
> Hi Thomas,
> debugging the .../RIOT/boards/telosb/driver_cc2420.c  file, I have in void 
> cc2420_init_interrupts(void) the following values:
> 2014-10-21 17:02:55,338 - INFO # P1IN: x10
> 2014-10-21 17:02:55,340 - INFO # P1IFG: x10
> 2014-10-21 17:02:55,341 - INFO # P1IES: x29
> 2014-10-21 17:02:55,343 - INFO # P1IE: x09
> 2014-10-21 17:02:55,344 - INFO # P1SEL: x02
> 2014-10-21 17:02:55,347 - INFO # CC2420_FIFOP: x00
> 2014-10-21 17:02:55,349 - INFO # CC2420_GIO0: x00
> 2014-10-21 17:02:55,351 - INFO # CC2420_GIO1: x10
> 2014-10-21 17:02:55,354 - INFO # CC2420_SFD: x00
> 
> and these ones in interrupt(PORT1_VECTOR) __attribute__((naked)) 
> cc2420_isr(void)
> 2014-10-21 17:04:06,609 - INFO # P1IN: x00
> 2014-10-21 17:04:06,610 - INFO # P1IFG: x18
> 2014-10-21 17:04:06,612 - INFO # P1IES: x29
> 2014-10-21 17:04:06,614 - INFO # P1IE: x09
> 2014-10-21 17:04:06,615 - INFO # P1SEL: x02
> 
> To receive a pkt, the msp430 needs a P1IFG= xxx1, didn't it?
> I hope you have some suggestion :)
> 
> I also tried to change the FIFOP threshold from 127(max) to 20(cc2420 default 
> value), but nothing. 
> 
> 
> 
> Ivano Calabrese, MSc.
> http://www.dei.unipd.it/~icalabre/ <http://www.dei.unipd.it/~icalabre/>
> https://www.linkedin.com/in/ivanocalabrese 
> <https://www.linkedin.com/in/ivanocalabrese>
> 
> On 21 October 2014 10:08, Ivano Calabrese  <mailto:alphaem...@gmail.com>> wrote:
> Hi Thomas,
> I'm using the linked toolchain in the RIOT-OS wiki 
> (http://sourceforge.net/projects/mspgcc/ 
> <http://sourceforge.net/projects/mspgcc/>) [LTS-20120406].
> 
> I don't know if this issue is related to the toolchain. Yesterday evening 
> debugging the .../RIOT/boards/telosb/driver_cc2420.c  file, I notice that 
> when a radio interrupt happens the if/else check hooks the the following code 
> snippet:
> [...]
> /* GIO0 is falling => check if FIFOP is high, indicating an RXFIFO overflow */
> else if ((P1IFG & CC2420_GIO0_PIN) != 0) {
> P1IFG &= ~CC2420_GIO0_PIN;
> if (cc2420_get_fifop()) {
> cc2420_rxoverflow_irq();
> DEBUG("[CC2420] rxfifo overflow");
> }
> }
> [...]
> but this is strange. Today I'm debugging this issue and if I find the 
> solution I'll inform you.
> 
> thanks a lot for the support.
> 
> ____
> Ivano Calabrese, MSc.
> http://www.dei.unipd.it/~icalabre/ <http://www.dei.unipd.it/~icalabre/>
> https://www.linkedin.com/in/ivanocalabrese 
> <https://www.linkedin.com/in/ivanocalabrese>
> 
> On 20 October 2014 18:03, Thomas Eichinger  <mailto:thomas.eichin...@fu-berlin.de>> wrote:
> Hi Ivano,
> 
> just checked, my TelosB doesn't receive anything neither. As you mentioned 
> the ISR doesn't get triggered correctly. 
> I'm wondering what's the source of this as there were no recent changes to 
> this code. 
> As a start could you tell me your toolchain version you are using?
> Will investigate this more in detail tomorrow and let you know of my 
> findings. 
> 
> Best, Thomas 
> 
> 
> 
> On 20 Oct 2014, at 15:54, Ivano Calabrese  <mailto:alphaem...@gmail.com>> wrote:
> 
>> Hi Thomas, hi folks.
>> currently seems the sent packages from a telosb (A) don't arrive to telosb 
>> (B).
>> Using a sniffer 802.15.4 I can look the packets are correct but, although I 
>> set the same pan id and the telosb (B) as monitor, I don't receive pkt.
>> 
>> I tried to monitor the interrupt (PORT1_VECTOR) __attribute__ ((naked)) 
>> cc2420_isr(void) in .../RIOT/boards/telosb/driver_cc2420.c, but seems the 
>> cc2420_isr(void) is never called.
>> 
>> Do you have some hint to debug this issue?
>> 
>> thanks a lot in advance
>> 
>> 
>> Ivano Calabrese, MSc.
>> http://www.dei.unipd.it/~icalabre/ <http://www.dei.unipd.it/~icalabre/>
>> https://www.linkedin.com/in