Re: [riot-devel] Fwd: Using IEEE802.15.4 on RIOT-OS native

[Ludwig Knüpfer]

Hehe, thank you for the praise :)

If there's interest I think the sources of the thesis are available somewhere 
and could be used to make an updated version.. as far as I recall it was a CC 
licensed document anyways?

Cheers,
Ludwig


Am 15. Juli 2020 14:28:02 MESZ schrieb Linda Fliss :
>Thanks for your explanation!
>Is there any overview documentation on the current state of netdev
>especially in RIOT-OS native? I really like Ludwig Knüpfers diploma
>thesis for its good overview, too bad it's obsolete.
>
>gnrc_sixloenc looks promising. I didn't find it in the docs, thanks for
>pointing that out.
>
>Best Regards,
>Linda / Chamaeleon-
>
>On 15.07.20 11:54, Martine Sophie Lenders wrote:
>> 
>> Accidentally just unicasted.
>> 
>>  Weitergeleitete Nachricht 
>> Betreff: Re: [riot-devel] Using IEEE802.15.4 on RIOT-OS native
>> Datum:   Wed, 15 Jul 2020 11:53:21 +0200
>> Von: Martine Sophie Lenders 
>> An:  Linda Fliss 
>> 
>> 
>> 
>> Hi Linda,
>> 
>> nativenet was more a less a hack to transport radio frames (IIRC not
>> even IEEE 802.15.4, but cc110x-like frames) in Ethernet frames. The
>> support for that was dropped, when `netdev` was introduced the old
>> network stack became obsolete 5 years ago [1], in favor for a pure
>> Ethernet support (`netdev_tap`).
>> 
>> As you already figured out, there are now `socket_zep` for ZEP
>support
>> and `gnrc_sixloenc` for 6LoWPAN encapsulation in Ethernet [2].
>> 
>> Sadly the state of `socket_zep` is not in a good state when it comes
>to
>> simulation. It works well for testing, but not for network
>simulation. I
>> originally intended to add more simulation capabilities either by
>> integrating it with a network simulator (e.g. DESvirt) or by
>improving
>> [3] (where you can find a little doc on using `socket_zep` in a
>mesh).
>> That never happened, sadly.
>> 
>> Best regards,
>> Martine
>> 
>> [1] https://github.com/RIOT-OS/RIOT/pull/3334
>> [2] https://www.rfc-editor.org/rfc/rfc7973.html
>> [3] https://github.com/miri64/zep_mesh
>> 
>> Am 15.07.20 um 09:48 schrieb Linda Fliss:
>>> Hi,
>>>
>>> I'm searching for a way to use IEEE802.15.4 in RIOT-OS native
>between
>>> tap-interfaces to simulate a net with RIOT-OS nodes locally. I found
>>> some information about the native network stack (nativenet) in
>Ludwig
>>> Knüpfers diploma thesis but it seems outdated? The current RIOT-OS
>>> native version only supports Ethernet over tap-interface and some
>>> zep_sockets. Was there a major rework of the native network stack in
>the
>>> last couple of years?
>>>
>>> The zep_sockets could be exactly what I'm looking for but I couldn't
>>> find any documentation how to use them and what they are capable of.
>Has
>>> anyone hints where to find documentation/blog posts/examples how to
>use
>>> zep_sockets?
>>>
>>> Best regards,
>>>
>>> Linda / Chamaeleon-
>>>
>>> ___
>>> 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] FreeRTOS comparison in the website

[Ludwig Knüpfer]

PS:

When I look at that page/table it seems to say that riot is caught in the past. 
Not only is freertos/the flavor of freertos that Amazon is cooking missing, all 
the others that came out after riot aren't there either. Zephyr, mbed, and 
mynewt come to my mind. Those are the ones I would actually care about seeing 
in a comparison today.

The timeline/history also skips to "future" 6 years ago.

Cheers,
Ludwig

Am 12. März 2019 18:16:52 MEZ schrieb "Ludwig Knüpfer" 
:
>Hi,
>
>I've been using FreeRTOS for a while now.
>I've not been using their network stack.
>
>It's a bit hard to compare, as freertos doesn't have the "cover all
>bases centrally" approach RIOT has. NXP for example will let you choose
>from several software components (TCP/IP among others) to include in a
>freertos bundle for their MCUs. Downloading such a bundle will then
>also include drivers for peripherals. Some of these drivers are
>available in freertos flavors that use freertos primitives to e.g.
>transfer data in an interrupt driven manner.
>
>Freertos itself only uses a dedicated hardware timer (much like the
>riot core) that is configured as part of the port. The freertos people
>maintain ports for some architectures. They also maintain their TCP/IP
>dtack. It's decidedly not Linux-like though, so much is clear.
>
>As far as the table goes freertos seems to check all the boxes. It
>probably fares comparably for the RAM/ROM metrics (just a gut feeling).
>
>Cheers,
>Ludwig
>
>
>Am 12. März 2019 17:12:36 MEZ schrieb Juan Ignacio Carrano
>:
>>Hi RIOT developers,
>>
>>In many of the meetings/events I have been with the RAPStore team we
>>had 
>>quite a few people asking us how does RIOT relate to FreeRTOS. The 
>>"official" response up to now has been that we don't do that
>comparison
>>
>>because FreeRTOS does not include all the things that RIOT has, mainly
>
>>networking (and drivers too.)
>>
>>Still, people ask the question and I'd like to give them an answer. 
>>Also, I don't know how accurate is the "no network" answer, especially
>
>>since FreeRTOS was acquired by Amazon. I've never used FreeRTOS so I'd
>
>>be grateful if anybody who knows could explain what's going on.
>>
>>Looking at http://riot-os.org/ I don't see any comparison to FreeRTOS 
>>either. It would be great to have it so we can point people to our 
>>website when they ask.
>>
>>Regards,
>>
>>Juan.
>>___
>>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] FreeRTOS comparison in the website

[Ludwig Knüpfer]

Hi,

I've been using FreeRTOS for a while now.
I've not been using their network stack.

It's a bit hard to compare, as freertos doesn't have the "cover all bases 
centrally" approach RIOT has. NXP for example will let you choose from several 
software components (TCP/IP among others) to include in a freertos bundle for 
their MCUs. Downloading such a bundle will then also include drivers for 
peripherals. Some of these drivers are available in freertos flavors that use 
freertos primitives to e.g. transfer data in an interrupt driven manner.

Freertos itself only uses a dedicated hardware timer (much like the riot core) 
that is configured as part of the port. The freertos people maintain ports for 
some architectures. They also maintain their TCP/IP dtack. It's decidedly not 
Linux-like though, so much is clear.

As far as the table goes freertos seems to check all the boxes. It probably 
fares comparably for the RAM/ROM metrics (just a gut feeling).

Cheers,
Ludwig


Am 12. März 2019 17:12:36 MEZ schrieb Juan Ignacio Carrano 
:
>Hi RIOT developers,
>
>In many of the meetings/events I have been with the RAPStore team we
>had 
>quite a few people asking us how does RIOT relate to FreeRTOS. The 
>"official" response up to now has been that we don't do that comparison
>
>because FreeRTOS does not include all the things that RIOT has, mainly 
>networking (and drivers too.)
>
>Still, people ask the question and I'd like to give them an answer. 
>Also, I don't know how accurate is the "no network" answer, especially 
>since FreeRTOS was acquired by Amazon. I've never used FreeRTOS so I'd 
>be grateful if anybody who knows could explain what's going on.
>
>Looking at http://riot-os.org/ I don't see any comparison to FreeRTOS 
>either. It would be great to have it so we can point people to our 
>website when they ask.
>
>Regards,
>
>Juan.
>___
>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] Host Name

[Ludwig Knüpfer]

Hello Jana,

If you're looking for a way to distinguish nodes based on their hardware, this 
might be what you want:
http://riot-os.org/api/group__drivers__periph__cpuid.html

Cheers,
Ludwig

Am 19. April 2018 21:18:30 MESZ schrieb Janna Om :
>Hello!
>Is it possible with RIOT OS to get access to the host name?
>I'm working with iot-lab m3 nodes and trying to get their ids or host
>names.
>I'm trying to make the node m3-id running my application to be aware
>that its hostname is m3-id or that its ID = id.
>Is there any possibility to  achieve this goal.
>Thank You in advance!
>
>Kind regards,
>Jana
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT integration options for Whitefield

[Ludwig Knüpfer]

Hi Rahul,

Regarding implementation proposal 2:
As I don't know anything about Whitefield: what would that implementation look 
like in detail? In particular: how would RIOT communicate with Whitefield? 
(Unix) socket/thread messages/other IPC?

Cheers,
Ludwig

Am 30. Juli 2017 17:13:51 MESZ schrieb Rahul Jadhav :
>Hello team RIOT,
>
>I m trying to integrate RIOT with a simulation framework called as
>Whitefield (which i m developing for interop testing) ... For details:
>https://github.com/whitefield-framework/whitefield
>
>I ll use RIOT in native mode. Whitefield will provide for 802.15.4
>phy/mac
>and RIOT will provide for 6lo/ipv6/udp/blah.
>
>As far as possible i wanted to check integration options which do not
>involve changing RIOT.
>
>For integration i ve thought of foll options:
>1. using tapX interface (but without tapbrX intf) ... i.e. RIOT will
>send
>packets on tap and whitefield will sniff in promiscous mode on tap and
>then
>redirect the packets to the whitefield RF layer ... similarly sending
>pkts
>to the RIOT node by using raw sockets and then injecting on tap
>interface.
>**The problem here is that with netdev_tap, 6lo adaptation is not
>included** ... I saw an option to use gnrc_zep + gnrc_nomac which could
>ve
>enabled 6lo for tap (
>https://github.com/RIOT-OS/RIOT/wiki/Testing-6LoWPAN-on-Ethernet-based-devices)
>but seems these two modules are no more part of RIOT.
>
>2. writing a driver for whitefield in RIOT ... This would be a
>clean/easy
>solution (and this is what i did for contiki integration) ...  But this
>would mean changes to RIOT, and i m not sure if RIOT team would be
>interested in such PR.
>
>3. Another option is to use fakelb, which simulates a 802.15.4 phy intf
>on
>linux. Thus i assume RIOT 6lo will work on this phy device. Then i go
>about
>the same way with integration, the way i planned for tap interface as
>in 1.
>Problem here is, fakelb is not available by default, thus there are
>clumsy
>(kernel module compilation) setup steps and i m still not sure if this
>is
>the right way to go.
>
>Wanted to seek advise from RIOT team regarding which option to use.
>
>Thanks,
>Rahul
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] flash command without compiling

[Ludwig Knüpfer]

Hi,

In general this should not be the case. I'd imagine one of the packages messes 
up the build system's dependencies. Hard to say without seeing the project.

Cheers,
Ludwig

Am 17. April 2017 16:47:12 MESZ schrieb Jose Alamos :
>Dear RIOTers,
>
>I noticed the 'make flash' recompiles everything before flashing.
>What's
>the reason behind this?
>
>I'm working with some packages that require some time to
>configure/compile,
>and everytime I run 'flash' I have to wait the whole process to finish.
>I
>cannot even flash 2 boards at the same time because the compile process
>is
>concurrent.
>
>As always, any ideas would be appreciated :)
>
>Cheers!
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] To global seed or not to global seed

[Ludwig Knüpfer]

Hi,

Am 8. März 2017 10:21:15 MEZ schrieb Oleg Hahm :
>Is testing and simulation the only use case you can imagine? I'm
>somewhat
>reluctant to add code just for non-production purposes.

Since we outspokenly target researchers with RIOT this is a production feature.

However we might want to move this feature into a dedicated implementation of 
the same interface.

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

Re: [riot-devel] To global seed or not to global seed

[Ludwig Knüpfer]

Hi,

Am 8. März 2017 10:06:17 MEZ schrieb "Cenk Gündoğan" :
>On 17-03-08 09:09:34, Kaspar Schleiser wrote: 
>> That way we'd have:
>> 
>> - user controlled state
>> - the ability to overload (e.g., combine hwrng, collected entropy,
>prng
>> but with the same interface)
>
>Looks good at first sight. We also would need some sort of
>synchronization for concurrent access, e.g. a mutex in the `rnd_t`
>struct, if two threads should use the same local state.

Just as a remark (might make sense to copy and paste to upcoming documentation):
If two threads are using the same local state they will probably not get 
deterministic numbers.

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

Re: [riot-devel] Github Issue

[Ludwig Knüpfer]

Hi,

Of your base bench (6541) contains content your work branch depends, on there 
is no way open a PR against master without including that content.
What you could do is open a PR of your work branch against your base branch and 
rebase on master once the base branch is merged.

Cheers,
Ludwig

Am 25. Februar 2017 19:02:13 MEZ schrieb Simon Brummer 
:
>Hi Everyone,
>
>I have a small issue with github and need some help.
>I would like to create a PR, that depends on another PR of mine.
>
>The currently existing PR (#6541) is not merged jet, the new PR is a 
>branch based on the branch in #6541.
>If I try to open a new PR, the PR contains all commits from the new 
>branch and those of #6541.
>
>This is what I don't want. I have seem before that commiters have based
>
>a new PR on a existing PR without
>the commits of the base PR in the new PR.
>
>How do I do that? Googling didn't help much.
>
>Cheers Simon
>
>___
>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] Low-Power-Management - LPM_arch

[Ludwig Knüpfer]

Hi neo,

Please compare:
https://github.com/RIOT-OS/RIOT/releases/tag/2017.01
and:
http://api.riot-os.org/group__drivers__periph__pm.html

Apropos:
Our documentation does have a search function in the upper right corner of the 
site ;-)

Cheers,
Ludwig

Am 14. Februar 2017 23:44:27 MEZ schrieb Neo :
>Hello alltogether,
>
>as far as I have seen there is no LPM_arch anymore in the RIOT Release 
>2017.1.
>
>What about the low-power state management in this release? Is it gone?
>
>Regards,
>
>Neo
>
>___
>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] MIPS Support of RIOT RTOS

[Ludwig Knüpfer]

Hi,

Please have a look at the open pull requests:
https://github.com/RIOT-OS/RIOT/pulls?utf8=✓=is%3Apr%20is%3Aopen%20mips

For further information, please also have a look at the mailing list archives:
https://www.mail-archive.com/search?q=Mips=devel%40riot-os.org

If that does not answer your questions don't hesitate to ask here again :)

Cheers,
Ludwig


Am 7. Dezember 2016 15:36:14 MEZ, schrieb Mehul  Hirpara 
:
>Hello RIOT Developers,
>
>
>I am from Ineda Systems, India. We found RIOT as much suitable OS for
>SDK development of Ineda platforms, which follow MIPS architecture.
>
>
>Latest RIOT code does not have any reference code for MIPS architecture
>and so I am looking for more info on support for MIPS architecture. It
>would be great help if someone can give us correct direction.
>
>
>Thanks,
>
>Mehul Hirpara
>
>
>
>
>___
>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] Απ: BSc Thesis

[Ludwig Knüpfer]

Hi,

Please keep messages to the mailing list in English.

Cheers,
Ludwig

Am 15. November 2016 14:42:28 MEZ, schrieb Dimitris Kazantzas 
:
>Ναι, σκέφτηκα να ρωτήσω και την κοινότητα, αν και τελικά πήρα
>ανακατευθυνση για εσάς ξανα.
>
>
>Καμιά ιδέα;
>
>
>Από: devel  εκ μέρους του Nikos Fotiou
>
>Στάλθηκε: Τρίτη, 15 Νοεμβρίου 2016 3:04:38 μμ
>Προς: RIOT OS kernel developers
>Θέμα: Re: [riot-devel] BSc Thesis
>
>έξυπνη κίνηση ;)
>On 13/11/2016 11:49 πμ, Dimitris Kazantzas wrote:
>
>Hi I am a student of the CS department of the Athens University of
>Economics and Business. I am currently in the process of conducting
>research for my BSc Thesis.
>
>
>What I would like to do is a project in OS and I think that RIOT would
>be a great choice of OS for that thing.
>
>
>However I don't really know what I want to develop. Maybe a network
>stack or a network protocol?
>
>
>I would be grateful for any ideas and help I get from you, thanks!!!
>
>
>
>
>
>___
>devel mailing list
>devel@riot-os.org
>https://lists.riot-os.org/mailman/listinfo/devel
>
>
>
>
>
>
>___
>devel mailing list
>devel@riot-os.org
>https://lists.riot-os.org/mailman/listinfo/devel

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

Re: [riot-devel] RIOT OS Student Research

[Ludwig Knüpfer]

Hi,


On Sat, Nov 12, 2016 at 01:23:03AM -0500, Dominic Massoni wrote:
> To whom it may concern:

This is a fairly good place to ask.

> We are hoping to ask for some helpful information in regards to the
> security policies and practices ...

Thanks for giving us a heads up ;)

I would suggest you take a look at the wiki where our processes are
documented.
https://github.com/RIOT-OS/RIOT/wiki/RIOT-Community-Processes

In case you are interested in the concrete technical measurements, our
the CI tests live here:
https://github.com/RIOT-OS/RIOT/tree/master/dist/tools

With that as a starting point, feel free to ask specific questions
here :)

> ... implemented in the standard opensource version of Riot OS, ...

There is no other version.

> ... with the ultimate goal of contributing to the Riot OS community
> the results of our research and suggestions for improvement.

So you assume there is room for improvement, eh? (just kidding)

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

Re: [riot-devel] Coding conventions amendment

[Ludwig Knüpfer]

Hi,

Am 14. Oktober 2016 10:04:07 MESZ, schrieb Oleg Hahm <oliver.h...@inria.fr>:
>Hi Ludwig!
>
>On Fri, Oct 14, 2016 at 09:13:50AM +0200, Ludwig Knüpfer wrote:
>> In general it is safer to explicate the integer width. As RIOT is
>targeted
>> at 32 bit architectures,
>
>I object!

With what exactly?

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

Re: [riot-devel] Coding conventions amendment

[Ludwig Knüpfer]

Hi,

Am 14. Oktober 2016 08:05:51 MESZ, schrieb Kees Bakker :
>But I believe the question was more, in case of an unsigned type,
>should we use "unsigned int" or size_t. In that case I would go for
>size_t.

BTW: there is also the signed type `ssize_t`.

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

Re: [riot-devel] Coding conventions amendment

[Ludwig Knüpfer]

Hi,

Am 13. Oktober 2016 22:42:11 MESZ, schrieb Kaspar Schleiser 
:
>Hi,
>
>On 10/13/2016 09:43 PM, Kees Bakker wrote:
 Does anybody object to adding this to the coding
 >> conventions explicitly?
>>> > What about `size_t`?
>> +1 for size_t
>
>Well, any convention would need careful wording.
>
>```
>for (uint32_t timeout = 1; timeout < (10LU*1000*1000); timeout *= 2) {
>   if(try()) break;
>}
>```
>
>... cannot blindly by convention converted to size_t as loop variable.
>
>IMHO this example also answers Oleg's initial concern: sometimes int or
>unsigned int or size_t just don't work.

Of course there are cases where this default can or should not be applied for 
various (e.g. type safety, numeric, or optimization) reasons.

In general it is safer to explicate the integer width. As RIOT is targeted at 
32 bit architectures, I can also see a rationale for `*int32_t` as the default 
per convention.

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

Re: [riot-devel] BIN FILES

[Ludwig Knüpfer]

Hi,

I guess you need glasses ;)

If you have your target exported, then 'make' creates a binary image.
'make flash' flashes this image onto your board.

Cheers,
Ludwig

Am 7. Oktober 2016 15:29:38 MESZ, schrieb Ilias Seitanidis 
:
>Dear all,
>Is it possible to create a bin file, which includes everything and then
>flash the .bin file
>on the board? (From what I've seen RIOT OS doesn't support this,
>right)
>
>Thank you in advance!
>
>Best,
>Ilias
>
>
>
>
>___
>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] Sensors with STM32F4Discovery

[Ludwig Knüpfer]

Hi,

I would take a look at the existing drivers in RIOT. The drivers say what 
connection type the support (most often SPI/I2C). Then you go on eBay and look 
for "Arduino" + the sensor you are interested in. Usually that leads you to a 
cheap board with the sensor and all the infrastructure electronics it needs 
(resistors, capacitors, ...).

Cheers,
Ludwig

Am 22. August 2016 17:39:02 MESZ, schrieb Adeel Mohammad Malik 
:
>Hi all,
>
>I wanted to attach some sensors to my STM32F4Discovery board and
>thought I should ask people on the mailing list for recommendations.
>The basic question I have is, what is the easiest way to connect a
>sensor to this board with RIOT running on it? What is the interface
>that I should use (ADC, GPIO, I2C?). What interfaces does RIOT support?
>
>Regards,
>Adeel
>
>
>
>
>___
>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] FW: Missing Libraries

[Ludwig Knüpfer]

Hi,

ncurses is not supported in RIOT, neither is MS DOS (conio.h and dos.h).
It is possible to link native against libraries on your host OS, but that is 
because it ends up running as a process.

You need to understand that you can not just pull libraries from your desktop 
OS and use them on an embedded system.

If you need some external libraries, you need to integrate them with RIOT first.

Cheers,
Ludwig

Am 10. August 2016 12:31:30 MESZ, schrieb MiTsArAs Jimaras 
:
>In addition to the previous, I want someone to help me with this:
>
>(it has to do with ncurses.h)
>
>
>Building application "c_stopwatch" for "native" with MCU "native".
>
>"make" -C /home/d/RIOT/boards/native
>"make" -C /home/d/RIOT/boards/native/drivers
>"make" -C /home/d/RIOT/core
>"make" -C /home/d/RIOT/cpu/native
>"make" -C /home/d/RIOT/cpu/native/periph
>"make" -C /home/d/RIOT/drivers
>"make" -C /home/d/RIOT/sys
>"make" -C /home/d/RIOT/sys/auto_init
>/home/d/RIOT/examples/c_stopwatch/bin/native/c_stopwatch.a(main.o): In
>function `main':
>main.c:(.text.main+0x136): undefined reference to `stdscr'
>main.c:(.text.main+0x13f): undefined reference to `wgetch'
>main.c:(.text.main+0x17e): undefined reference to `stdscr'
>main.c:(.text.main+0x187): undefined reference to `wgetch'
>collect2: error: ld returned 1 exit status
>make: ***
>[/home/d/RIOT/examples/c_stopwatch/../../Makefile.include:260: all]
>Error 1
>
>
>
>
>Από: devel  εκ μέρους του MiTsArAs Jimaras
>
>Στάλθηκε: Τετάρτη, 10 Αυγούστου 2016 11:17 πμ
>Προς: devel@riot-os.org
>Θέμα: [riot-devel] Missing Libraries
>
>Good Morning again from Greece!
>I managed to compile the project to Arduino Uno. I assume that my
>problem is at the shell script, neither arduino nor qemu (even if it
>seems broken) can run the script.
>
>So I decided to build it again on C.
>When I do that, some libraries such as  and  are
>missing from RIOT.
>What do I have to do to import them?
>
>
>
>
>___
>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] qemu-i386 port

[Ludwig Knüpfer]

All of them?

Am 9. August 2016 14:11:12 MESZ, schrieb Martine Lenders 
<m...@martine-lenders.eu>:
>Hi Ludwig,
>well at least the FU boards are now "obtainable" through the IoT-Lab
>testbed. ;-)
>
>Cheers,
>Martine
>
>2016-08-09 14:06 GMT+02:00 Ludwig Knüpfer
><ludwig.knuep...@fu-berlin.de>:
>> Hi,
>>
>> I'm all for cleaning up stale boards, especially I'd they are as hard
>to obtain as for example the FU boards.
>> If I'm not mistaken this would also enable the removal of at least
>one legacy driver interface (I have some GPIO API in mind).
>>
>> Cheers,
>> Ludwig
>>
>> Am 9. August 2016 13:52:56 MESZ, schrieb "Joakim Nohlgård"
><joakim.nohlg...@eistec.se>:
>>>I agree with dropping qemu-i386
>>>
>>>On the same subject, would it make sense to clean up some other
>boards
>>>with less than ideal support?
>>>chronos is one board which I frequently run into trouble with because
>>>it is never up to date with the other platform implementations,
>>>especially the stdio is very hacky on that board.
>>>
>>>/Joakim
>>>
>>>On Aug 9, 2016 12:51, "Martine Lenders" <m.lend...@fu-berlin.de>
>wrote:
>>>>
>>>> Hi,
>>>> we now have the third person wondering about the qemu-i386 port.
>Fact
>>>> is, it doesn't work (we do not even have the unittests activated
>>>> anymore). Is there a reason why we did not drop it yet (except
>making
>>>> all the good work by René void)? Or are we planning to provide
>better
>>>> support for it in the future?
>>>>
>>>> Cheers,
>>>> Martine
>>>> ___
>>>> 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] qemu-i386 port

[Ludwig Knüpfer]

Hi,

I'm all for cleaning up stale boards, especially I'd they are as hard to obtain 
as for example the FU boards.
If I'm not mistaken this would also enable the removal of at least one legacy 
driver interface (I have some GPIO API in mind).

Cheers,
Ludwig

Am 9. August 2016 13:52:56 MESZ, schrieb "Joakim Nohlgård" 
:
>I agree with dropping qemu-i386
>
>On the same subject, would it make sense to clean up some other boards
>with less than ideal support?
>chronos is one board which I frequently run into trouble with because
>it is never up to date with the other platform implementations,
>especially the stdio is very hacky on that board.
>
>/Joakim
>
>On Aug 9, 2016 12:51, "Martine Lenders"  wrote:
>>
>> Hi,
>> we now have the third person wondering about the qemu-i386 port. Fact
>> is, it doesn't work (we do not even have the unittests activated
>> anymore). Is there a reason why we did not drop it yet (except making
>> all the good work by René void)? Or are we planning to provide better
>> support for it in the future?
>>
>> Cheers,
>> Martine
>> ___
>> 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] Απ: Απ: Απ: Problem with "make" -lm missing.

[Ludwig Knüpfer]

Hi,

If you have been told to write an application that runs on a VM without using 
an OS, RIOT is not the answer because it is an OS, so your application is using 
an OS.

Apart from that there is no difference between running on native and running on 
QEMU from the application point of view.

As René already said: you probably should clarify the intention of the task 
with your teachers.

Cheers,
Ludwig



Am 9. August 2016 12:21:51 MESZ, schrieb MiTsArAs Jimaras 
:
>Hahahahaha it's that WHY again!
>
>
>Because I have told to do so from my university!
>
>I can't explain further because I DON'T KNOW WHY!
>
>
>
>
>Από: devel  εκ μέρους του Ludwig Knupfer
>
>Στάλθηκε: Τρίτη, 9 Αυγούστου 2016 1:02 μμ
>Προς: RIOT OS kernel developers
>Θέμα: Re: [riot-devel] Απ: Απ: Problem with "make" -lm missing.
>
>Hi,
>
>Yes, you said that you want do that before but you never explained:
>*WHY* do you want to do that?
>Also: RIOT is an OS!
>
>Cheers,
>Ludwig
>
>Am 9. August 2016 11:15:26 MESZ, schrieb MiTsArAs Jimaras
>:
>>I made trouble once, speaking about this project, but I am going at it
>>again!!
>>
>>
>>I want my app to run on a bare VM. Meaning that I want my VM to boot
>to
>>my app without an OS been installed in the VM emulator. Any solutions
>>would be very helpful!
>>
>>
>>P.S: On the other hand, I have a raspberry pi on my hands and an
>>arduino uno for some days. My project aims on that purpose too.
>>
>>
>>
>>Από: devel  εκ μέρους του Oleg Hahm
>>
>>Στάλθηκε: Τρίτη, 9 Αυγούστου 2016 12:04 μμ
>>Προς: RIOT OS kernel developers
>>Θέμα: Re: [riot-devel] Απ: Problem with "make" -lm missing.
>>
>>Hi!
>>
>>On Tue, Aug 09, 2016 at 08:27:04AM +, MiTsArAs Jimaras wrote:
>>> Now I have another problem!
>>>
>>> I compile on native board, and everything is alright.
>>>
>>> When I am trying to compile on qemu-i386, it seems to start, but I
>>get no
>>> results.
>>
>>Please note that support for i386 is rather rudimentary. Any
>particular
>>reason
>>you want to use this platform?
>>
>>Cheers,
>>Oleg
>>--
>>panic("Aarggh: attempting to free lock with active wait queue - shoot
>>Andy");
>>linux-2.0.38/fs/locks.c
>>
>>
>>
>>
>>___
>>devel mailing list
>>devel@riot-os.org
>>https://lists.riot-os.org/mailman/listinfo/devel
>devel -- RIOT OS kernel
>developers
>lists.riot-os.org
>This is the mailing list for kernel developers of RIOT OS - the
>friendly Internet Of Things Operating System. To see the collection of
>prior postings to the list ...
>
>
>
>
>___
>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] Απ: Απ: Problem with "make" -lm missing.

[Ludwig Knüpfer]

Hi,

Yes, you said that you want do that before but you never explained: *WHY* do 
you want to do that?
Also: RIOT is an OS!

Cheers,
Ludwig

Am 9. August 2016 11:15:26 MESZ, schrieb MiTsArAs Jimaras 
:
>I made trouble once, speaking about this project, but I am going at it
>again!!
>
>
>I want my app to run on a bare VM. Meaning that I want my VM to boot to
>my app without an OS been installed in the VM emulator. Any solutions
>would be very helpful!
>
>
>P.S: On the other hand, I have a raspberry pi on my hands and an
>arduino uno for some days. My project aims on that purpose too.
>
>
>
>Από: devel  εκ μέρους του Oleg Hahm
>
>Στάλθηκε: Τρίτη, 9 Αυγούστου 2016 12:04 μμ
>Προς: RIOT OS kernel developers
>Θέμα: Re: [riot-devel] Απ: Problem with "make" -lm missing.
>
>Hi!
>
>On Tue, Aug 09, 2016 at 08:27:04AM +, MiTsArAs Jimaras wrote:
>> Now I have another problem!
>>
>> I compile on native board, and everything is alright.
>>
>> When I am trying to compile on qemu-i386, it seems to start, but I
>get no
>> results.
>
>Please note that support for i386 is rather rudimentary. Any particular
>reason
>you want to use this platform?
>
>Cheers,
>Oleg
>--
>panic("Aarggh: attempting to free lock with active wait queue - shoot
>Andy");
>linux-2.0.38/fs/locks.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] Απ: Problem with "make" -lm missing.

[Ludwig Knüpfer]

Hi,

It's difficult to say anything about this without seeing the actual source code.

Cheers,
Ludwig

Am 9. August 2016 10:27:04 MESZ, schrieb MiTsArAs Jimaras 
:
>Problem solved.
>
>Now I have another problem!
>
>I compile on native board, and everything is alright.
>
>When I am trying to compile on qemu-i386, it seems to start, but I get
>no results. All I get is:
>
>Building application "time" for "qemu-i386" with MCU "x86".
>
>"make" -C /home/d/RIOT/pkg/tlsf
>rm -rf /home/d/RIOT/examples/time/bin/pkg/qemu-i386/tlsf/src
>mkdir -p /home/d/RIOT/examples/time/bin/pkg/qemu-i386/tlsf/src
>patching file Makefile
>patching file tlsf-malloc.c
>patching file tlsf-malloc.h
>patching file tlsf.c
>patching file tlsf.h
>"make" -C /home/d/RIOT/boards/qemu-i386
>"make" -C /home/d/RIOT/boards/x86-multiboot-common
>"make" -C /home/d/RIOT/core
>"make" -C /home/d/RIOT/cpu/x86
>"make" -C /home/d/RIOT/drivers
>"make" -C /home/d/RIOT/sys
>"make" -C /home/d/RIOT/sys/auto_init
>"make" -C /home/d/RIOT/sys/quad_math
>   text   databssdechex filename
>123739   2392  68228 194359  2f737
>/home/d/RIOT/examples/time/bin/qemu-i386/time.elf
>true
>exec /home/d/RIOT/boards/qemu-i386/dist/term.py qemu-system-i386
>/home//RIOT/examples/time/bin
>/home/d/RIOT/examples/time/bin/qemu-i386/time.hex
>Type 'exit' to exit.
>Starting QEMU: qemu-system-i386 -serial tcp:0.0.0.0:55893 -nographic
>-monitor /dev/null -kernel
>/home/d/RIOT/examples/time/bin/qemu-i386/time.hex -m size=512
>
>2016-08-09 11:19:44.436878: Interrupt handling initialized
>2016-08-09 11:19:44.437139: PIC initialized
>2016-08-09 11:19:44.437568: Warning: Your hardware does not support the
>NX bit!
>2016-08-09 11:19:44.437834:  Setting PT_XD = 0.
>2016-08-09 11:19:44.438586: Kernel memory: 0x10 - 0x132000
>2016-08-09 11:19:44.438882:   .text:   0x100060 - 0x1172ef
>2016-08-09 11:19:44.439173:   .rodata: 0x118000 - 0x11ae08
>2016-08-09 11:19:44.439451:   .data:   0x12 - 0x1208e8
>2016-08-09 11:19:44.439737:   .bss:0x121000 - 0x131a84
>2016-08-09 11:19:44.440049: Unmapped memory: 0x132000 - 0x14
>2016-08-09 11:19:44.440254: Heap start: 0x14
>2016-08-09 11:19:44.440625:    - 0009fc00
>(usable)
>2016-08-09 11:19:44.441091:   0009fc00 - 000a
>(unusable: reseved)
>2016-08-09 11:19:44.441545:   000f - 0010
>(unusable: reseved)
>2016-08-09 11:19:44.441919:   0010 - 1ffe
>(usable)
>2016-08-09 11:19:44.674721:   1ffe - 2000
>(unusable: reseved)
>2016-08-09 11:19:44.675258:   fffc - 0001
>(unusable: reseved)
>2016-08-09 11:19:44.676789: There are 130734 free pages (510.680 MB)
>available for the heap.
>2016-08-09 11:19:44.677060: Virtual memory initialized
>2016-08-09 11:19:44.677378: RTC initialized [08:19:44, 2016-08-09]
>2016-08-09 11:19:44.677551: PIT initialized
>2016-08-09 11:19:44.677769: Looking up PCI devices
>2016-08-09 11:19:44.678502:   00:00.0 "Intel Corporation": "440FX -
>82441FX PMC [Natoma]" (Bridge device: Host bridge, rev: 02)
>2016-08-09 11:19:44.679282:   00:01.0 "Intel Corporation": "82371SB
>PIIX3 ISA [Natoma/Triton II]" (Bridge device: ISA bridge, rev: 00)
>2016-08-09 11:19:44.680175:   00:01.1 "Intel Corporation": "82371SB
>PIIX3 IDE [Natoma/Triton II]" (Mass storage controller: IDE controller,
>rev: 00)
>2016-08-09 11:19:44.680531: BAR 4: I/O space, ports 0xc040-0xc04f
>2016-08-09 11:19:44.681289:   00:01.3 "Intel Corporation":
>"82371AB/EB/MB PIIX4 ACPI" (Bridge device: Other bridge device, rev:
>03)
>2016-08-09 11:19:44.681535: IRQ: new = 10, old = 9
>2016-08-09 11:19:44.682184:   00:02.0 "0x1234": "0x" (Display
>controller: VGA-compatible controller, rev: 02)
>2016-08-09 11:19:44.695092: BAR 0: memory, physical =
>0xfd00-0xfdff, virtual = 0x0023d000-0x0123cfff
>2016-08-09 11:19:44.695797: BAR 2: memory, physical =
>0xfebf-0xfebf0fff, virtual = 0x1fff7000-0x1fff7fff
>2016-08-09 11:19:44.696827:   00:03.0 "Intel Corporation": "82540EM
>Gigabit Ethernet Controller" (Network controller: Ethernet controller,
>rev: 03)
>2016-08-09 11:19:44.697108: IRQ: new = 10, old = 11
>2016-08-09 11:19:44.697756: BAR 0: memory, physical =
>0xfebc-0xfebd, virtual = 0x1fff9000-0x20018fff
>2016-08-09 11:19:44.698100: BAR 1: I/O space, ports 0xc000-0xc03f
>2016-08-09 11:19:44.698438: RIOT x86 hardware initialization complete.
>2016-08-09 11:19:44.698729: RIOT board initialization complete.
>2016-08-09 11:19:44.699216: main(): This is RIOT! (Version:
>2016.10-devel-21-gcf11a-D)
>
>
>After this, it just don't run. It was supposed to show a clock to me.
>
>
>Από: devel  εκ μέρους του Martine Lenders
>
>Στάλθηκε: Τρίτη, 9 Αυγούστου 2016 10:22 πμ
>Προς: RIOT OS kernel developers
>Θέμα: Re: [riot-devel] Problem with "make" -lm missing.
>
>Oops, forgot to 

Re: [riot-devel] Απ: Make bootable .elf file!

[Ludwig Knüpfer]

Hi,

On Thu, Jul 28, 2016 at 10:25:14PM +0200, astralien3000 wrote:
> Ah, ok I understood MiTsArAs was trying to run the native
> implementation on qemu-i385, which is not possible, right ?

It is not possible to run a 'native' binary directly on 'qemu-i386',
correct.

> But I did not know this target existed, anyway.

To get an up-to-date overview of supported (to what degree varies a
lot) boards:
https://github.com/RIOT-OS/RIOT/tree/master/boards

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

[riot-devel] Booting RIOT

[Ludwig Knüpfer]

Hi,

first of all:

Both of you turned up at about the same time with about the same
question .. Are you the same person/working together? Can I ask where
and how you learned about RIOT?

Regarding booting RIOT:
- RIOT is generally targeting microcontroller IoT hardware, not PC
  hardware
- when compiling RIOT you have various target choices, among them are
  two virtual platforms, namely 'native' and 'qemu-i386'
- 'native' is a virtual platform meant for testing and debugging of RIOT
  and RIOT applications, 'qemu-i386' is more or less a proof of concept
- you can run RIOT on QEMU (see below) when compiling for the
  'qemu-i386' target, but there is no way to run the binary compiled
  for 'native' on 'qemu-i386'

Two things to keep in mind:
- support for QEMU is rather rudimentary, for example there is no
  network
- running RIOT as an OS on a desktop PC (instead of OSX, Windows or
  Linux) is not intended, nor is it possible at the moment

The big question:
- Why do you want to run the application on QEMU? What are you trying
  to achieve by running it on that platform?

Cheers,
Ludwig

Compiling and running on 'qemu-i386':
BOARD=qemu-i386 make clean all flash term

The same applies for all other platforms.
To compile for, flash to, and test on real hardware like the
'samr21-xpro':
BOARD=samr21-xpro make clean all flash term
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Booting my App from USB.

[Ludwig Knüpfer]

Hi,

I am uncertain what you mean by "boot to a VM" and "from a USB".

Currently RIOT is meant neither for running virtual machines nor for
running on virtual machines.
Booting from USB is generally not supported by any of the target
platforms of RIOT.

What are you trying to achieve?
What hardware do you intend to run your application on, and what
purpose does it have?

Cheers,
Ludwig

PS:
Technically, RIOT does have a target platform that enables you to run
RIOT on a VM, namely x86/QEMU. If you want to run your application
on that platform you just type `BOARD=qemu-i386 make clean all term`
and off it goes. But as I wrote above, I have the vague impression
this is not what you want.

On Sat, Jul 23, 2016 at 01:54:14AM +0300, Dimitrios Sotirakis wrote:
> Hello from Greece.
> I just finished my app on RIOT RTOS, and all I want now is to make a binary
> file with the .elf file that I created, in order to be able to boot
> directly to a VM or from a USB.
> How can I do that? It is of much importance.
> Thanks!

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

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

Re: [riot-devel] [eeprom] [stm32l151] Driver for internal EEPROM

[Ludwig Knüpfer]

Dear Anon,

On Thu, Jul 21, 2016 at 05:32:19PM +0300, Anon Anonymous wrote:
> I have a task to read/write the internal EEPROM block on the
> STM32L151 MCU and as I can see there's no driver or interface
> implemeted yet for this kind of task.
> 
> My question is how can I add the EEPROM features support into the
> RIOT OS?
> 
> Should I use NVRAM interface?

Yes, the NVRAM interface is the right choice for EEPROM.

> Could I use the ST's SPL code at the RIOT driver level?

I think usage of the ST standard peripheral library has been discussed
before, I have no time to search for the outcome right now. Please
search the mailing list archives and the issue tracker/pull requests.

Maybe you could link to the results you find from the FAQ in the RIOT
Wiki if you find it.

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

[riot-devel] Compatibility matrix

[Ludwig Knüpfer]

Hi,

One idea for improving understanding of the meaning of "supported platform":
We could provide a matrix showing which test application runs on which platform.
Opinions?

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

Re: [riot-devel] Byte array should be uint8_t, not char

[Ludwig Knüpfer]

Hi Kees,

I assume there are more violations than the ones in the SPI drivers... But of 
course every step forward is great!

Testing can be done by the community. We have plans to create a distributed 
test system with actual hardware attached, but sadly that has not become 
reality yet.

Compilation can be tested automatically by running `make buildtest` for the 
respective test application (tests/periph_spi).

Cheers,
Ludwig

Am 5. Juli 2016 21:31:49 MESZ, schrieb Kees Bakker <k...@sodaq.com>:
>Hi Ludwig,
>
>Well, it will be a challenge to smootly correct this.
>There are 16 CPU's that use spi_transfer_byte(s) and 6 drivers.
>
>I won't mind creating a PR, but of course I can only test it by
>building
>examples for all boards that support SPI. And look at compile errors.
>Or are
>there other procedures?
>
>On 04-07-16 07:23, Ludwig Knüpfer wrote:
>> Hi Kees,
>>
>> Unless there is a good reason to deviate from this guideline all
>violations should be corrected. This particular rule was added
>relatively recently, so it would not surprise me if not all occurrences
>in RIOT have been adapted yet.
>>
>> Cheers,
>> Ludwig
>>
>> Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker <k...@sodaq.com>:
>>> Hi,
>>>
>>> The Coding Convention is clear about it.
>>>
>>> "Guidelines for pointer types (as long as it is reasonable):
>>>
>>>   * use |char *| for strings and only for strings
>>> * use |uint8_t[]| as type for arbitrary byte buffers, but use |void
>*|
>>> to pass them around. |uint8_t[]| because we're dealing with
>bytes
>>> and not characters, |void *| to avoid unnecessary casting shall
>the
>>> need arise to have their content to have a certain type
>>>   * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer
>>> addresses, where it avoids unnecessary temporary variable
>>>   * use |void *| for generic typing"
>>>
>>>
>>> In the SPI driver however the transfer functions use char *
>parameters,
>>>
>>> but SPI is usually dealing with binary
>>> information (bytes), not strings. This leads to unnecessary casts in
>>> other parts of the code. (E.g. nvram_spi).
>>>
>>> What is our policy about this? Are we going to correct this at some
>>> point? Is it too late already (I hope not)?
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>
>
>-- 
>Kees Bakker
>Founder
>SODAQ
>M. 0031617737165
>www.sodaq.com
>
>___
>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] Byte array should be uint8_t, not char

[Ludwig Knüpfer]

Hi,

gebart is Joakim ;)

Cheers,
Ludwig

Am 5. Juli 2016 21:11:44 MESZ, schrieb Kees Bakker <k...@sodaq.com>:
>Thank you for the info. It seems that gebart noticed it too :-) There
>is 
>a fresh reply in #4780.
>
>
>On 04-07-16 19:49, Joakim Nohlgård wrote:
>> Hi Kees,
>> Like Ludwig wrote, there are some places which haven't followed the 
>> coding conventions because the CC weren't as clear before as they are
>
>> now with regards to this. Since RIOT is relying on its community for 
>> code contributions, these kinds of clean ups may take a long time 
>> after the documentation has been updated until someone decides to fix
>
>> them.
>>
>> The SPI periph driver is going through some rework, see 
>> https://github.com/RIOT-OS/RIOT/pull/4780 and 
>> https://github.com/RIOT-OS/RIOT/issues/4758, but it has not yet been 
>> merged because of various other things getting in the way.
>>
>> Best regards,
>> Joakimr
>>
>> On Mon, Jul 4, 2016 at 7:23 AM, Ludwig Knüpfer 
>> <ludwig.knuep...@fu-berlin.de <mailto:ludwig.knuep...@fu-berlin.de>> 
>> wrote:
>>
>> Hi Kees,
>>
>> Unless there is a good reason to deviate from this guideline all
>> violations should be corrected. This particular rule was added
>> relatively recently, so it would not surprise me if not all
>> occurrences in RIOT have been adapted yet.
>>
>> Cheers,
>> Ludwig
>>
>> Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker
><k...@sodaq.com
>> <mailto:k...@sodaq.com>>:
>> >Hi,
>> >
>> >The Coding Convention is clear about it.
>> >
>> >"Guidelines for pointer types (as long as it is reasonable):
>> >
>> >  * use |char *| for strings and only for strings
>> > * use |uint8_t[]| as type for arbitrary byte buffers, but use
>> |void *|
>> >to pass them around. |uint8_t[]| because we're dealing with
>bytes
>> >and not characters, |void *| to avoid unnecessary casting
>> shall the
>> >need arise to have their content to have a certain type
>> >  * use |uint8_t *| to pass "typed" byte buffers, e.g.,
>link-layer
>> >addresses, where it avoids unnecessary temporary variable
>> >  * use |void *| for generic typing"
>> >
>> >
>> >In the SPI driver however the transfer functions use char *
>> parameters,
>> >
>> >but SPI is usually dealing with binary
>> >information (bytes), not strings. This leads to unnecessary
>casts in
>> >other parts of the code. (E.g. nvram_spi).
>> >
>> >What is our policy about this? Are we going to correct this at
>some
>> >point? Is it too late already (I hope not)?
>>
>> ___
>> devel mailing list
>> devel@riot-os.org <mailto: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] Progress of port to SODAQ Autonomo

[Ludwig Knüpfer]

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 <k...@sodaq.com>:
> >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

Re: [riot-devel] Byte array should be uint8_t, not char

[Ludwig Knüpfer]

Hi Kees,

Unless there is a good reason to deviate from this guideline all violations 
should be corrected. This particular rule was added relatively recently, so it 
would not surprise me if not all occurrences in RIOT have been adapted yet.

Cheers,
Ludwig

Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker :
>Hi,
>
>The Coding Convention is clear about it.
>
>"Guidelines for pointer types (as long as it is reasonable):
>
>  * use |char *| for strings and only for strings
> * use |uint8_t[]| as type for arbitrary byte buffers, but use |void *|
>to pass them around. |uint8_t[]| because we're dealing with bytes
>and not characters, |void *| to avoid unnecessary casting shall the
>need arise to have their content to have a certain type
>  * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer
>addresses, where it avoids unnecessary temporary variable
>  * use |void *| for generic typing"
>
>
>In the SPI driver however the transfer functions use char * parameters,
>
>but SPI is usually dealing with binary
>information (bytes), not strings. This leads to unnecessary casts in 
>other parts of the code. (E.g. nvram_spi).
>
>What is our policy about this? Are we going to correct this at some 
>point? Is it too late already (I hope not)?

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

Re: [riot-devel] RIOT, Windows, and Code Composer Studio

[Ludwig Knüpfer]

Hi Clark,

I am not aware of anyone using CCS.
In my perception most of us are Linux based and don't even use Eclipse.

Cheers,
Ludwig

Am 20. Juni 2016 15:59:29 MESZ, schrieb Clark Leach :
>Nothing? Really?
>
>On Tue, Jun 14, 2016 at 2:43 PM, Clark Leach 
>wrote:
>
>> I am intersted in developing with RIOT for a few different TI targets
>and
>> have Code Composer Studio installed on Windoze 8.1 which I have used
>for
>> several projects.  Since CCS already has all the tool chains and
>debugger
>> interfaces, it seems like it would make sense to use it for these
>projects
>> as well.
>>
>> Is there any hope of making such a configuration work?  Is there any
>> guidance available?  I have read the howto on using Eclipse and found
>the
>> information lacking and, at times, incomprehensible (what is a
>"speaking
>> Variable Name", anyways).
>>
>> Any feedback would be appreciated.
>>
>>
>
>
>
>
>___
>devel mailing list
>devel@riot-os.org
>https://lists.riot-os.org/mailman/listinfo/devel

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

Re: [riot-devel] Bridge border router and 6LowPan interfaces

[Ludwig Knüpfer]

Hi,

Am 4. März 2016 18:05:14 MEZ, schrieb "Bernhard Nägele" 
:
>Hello everyone,
>just one thought about border-routers from a newbie: Why not using 
>embedded boards like Raspberry Pi for this purpose. Everything from the
>
>software stack side is available (bridging in every direction) and if 
>you use a Pi Zero it will not cost much more than 20$.

The Pi is a great platform for prototyping primarily because of the wide usage 
and therefore comparably good documentation/support, but not a good production 
system in my opinion.
I for one would not base a production system on a device which uses an SD card 
for its primary memory.

>Wouldn't the development resources be better invested in supporting
>more 
>platforms and drivers?

Since RIOT is a community driven free software project people will mostly do 
whatever they want/need at that point in time ;)

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

Re: [riot-devel] Sample applications

[Ludwig Knüpfer]

Hi,

Based on a quick scan this looks very good indeed and think we should 
incorporate it into the RIOT project space. Not sure where exactly though.

Cheers,
Ludwig

Am 1. März 2016 11:48:19 MEZ, schrieb Alexandre Abadie 
:
>Dear Rioters,
>
>I started to use riot-os a few weeks ago now and I'd like to tell you
>that your project is totally awesome and quite well documented.
>
>I first began to write some sample applications with in mind the idea
>of providing some easy to use/understand starter tutorials showing the
>possibilities offered by riot-os (UART, GPIO, NET, etc). I tried to
>have the examples as much documented as possible (but we all know that
>this can always be improved).
>The code is already available on GitHub [1]. By the way I noticed that
>you already have a repo targeting the same idea [2]. 
>
>What do you think of merging both or maybe create another repository
>called "riot-tutorials" where "aabadie/riot-apps" could be moved ? Are
>you interested in such a contribution ?
>
>Cheers,
>
>Alex
>
>[1] https://github.com/aabadie/riot-apps
>[2] https://github.com/RIOT-OS/applications
>___
>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] Interim Hack'n'ACK

[Ludwig Knüpfer]

Hi,

On Tue, Mar 01, 2016 at 07:49:42PM +0100, Oleg Hahm wrote:
> Hi!
> 
> On Tue, Mar 01, 2016 at 07:23:26PM +0100, Ludwig Ortmann wrote:
> > apparently there was a copy/paste error, the correct URL is:
> > http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE-
> 
> Actually, I had to switch to a different machine and different user, correct
> URL is now
> http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xX-

Sorry, it's not working. The debug output says:
"qml: The user whom this link belongs to could not be found."

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

Re: [riot-devel] Issue in mailing list

[Ludwig Knüpfer]

Hi,

There are two mails from you and two answers.
Maybe the problem confused you so much you overlooked and/or forgot the answers 
;)

https://lists.riot-os.org/pipermail/devel/2016-February/003488.html

There is a link labeled "next message" you can use to click through the thread 
to find the answers.
Gmail also has a search function that might be of help in case you struggle 
with the invalid certificate of the archives page.

On a general note: RIOT does not have commercial service as of now, so even if 
you receive no answers within a certain period that is no reason to think 
something is broken.
There is no "our side"/"your side", we're all just people interested in this 
project.

Cheers,
Ludwig

Am 28. Februar 2016 04:43:38 MEZ, schrieb Giri Sugu :
>Hi posted my question in ur mailing list before 4 days.
>But still now i didn,t get any response from your side.May i know where
>is
>the problem.
>
>
>
>
>___
>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] Happy 10k!

[Ludwig Knüpfer]

Hoorah!

BTW:
what's the current SLoC count?

Cheers,
Ludwig

Am 22. Februar 2016 00:56:13 MEZ, schrieb Kaspar Schleiser 
:
>Hey fellow RIOTers,
>
>we've passed 1 commits...
>
>Congratulations to everyone!
>
>Kaspar
>___
>devel mailing list
>devel@riot-os.org
>https://lists.riot-os.org/mailman/listinfo/devel

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

Re: [riot-devel] Make error: SPI Driver test program

[Ludwig Knüpfer]

Hi,

It seems you are not building for your target board but for native. Native has 
no SPI support (as indicated by the error message).
If you export BOARD for your target hardware (which has to support SPI), things 
should go better.

Cheers,
Ludwig

Am 21. Februar 2016 22:55:13 MEZ, schrieb amit mehta :
>Hi All,
>
>As a beginner's level task, I'm working on Spansion NOR flash memory
>(S25FL127S) interfacing with STM32F072 (ARM Cortex M0 based SOC).
>I've a custom board which has Spansion Flash memory connected to
>STM32F072 over SPI bus.
>
>I've a work-in-progress driver under: ~/RIOT/drivers/s25127s/s25127s.c
>driver header: ~/RIOT/drivers/include/s25fl127s.h
>and the driver test program: ~/RIOT/tests/driver_s25fl127s/main.c
>
>However, As of now an attempt to build the test program failed. So
>I tried to build driver test program for nvram-spi (since, this is the
>driver
>that I'm referring to) instead and that too failed.
>
>
>[amit@discworld driver_nvram_spi]$ make
>There are unsatisfied feature requirements: periph_gpio periph_spi
>
>
>EXPECT ERRORS!
>
>
>Building application "driver_nvram_spi" for "native" with MCU "native".
>
>In file included from main.c:28:0:
>../../drivers/include/nvram-spi.h:40:5: error: unknown type name
>‘spi_t’
> spi_t spi;
> ^
>main.c: In function ‘main’:
>main.c:116:16: error: ‘SPI_0’ undeclared (first use in this function)
> .spi = TEST_NVRAM_SPI_DEV,
>^
>main.c:116:16: note: each undeclared identifier is reported only once
>for each function it appears in
>main.c:125:9: error: implicit declaration of function
>‘spi_init_master’ [-Werror=implicit-function-declaration]
>if (spi_init_master(TEST_NVRAM_SPI_DEV, SPI_CONF, SPI_SPEED_10MHZ) ==
>0) {
> ^
>main.c:125:33: error: ‘SPI_CONF_FIRST_RISING’ undeclared (first use in
>this function)
>if (spi_init_master(TEST_NVRAM_SPI_DEV, SPI_CONF, SPI_SPEED_10MHZ) ==
>0) {
> ^
>main.c:125:57: error: ‘SPI_SPEED_10MHZ’ undeclared (first use in this
>function)
>if (spi_init_master(TEST_NVRAM_SPI_DEV, SPI_CONF, SPI_SPEED_10MHZ) ==
>0) {
> ^
>cc1: all warnings being treated as errors
>/home/amit/Documents/tut/sem4/sem5/projects/riot-os/RIOT/Makefile.base:60:
>recipe for target
>'/home/amit/Documents/tut/sem4/sem5/projects/riot-os/RIOT/tests/driver_nvram_spi/bin/native/driver_nvram_spi/main.o'
>failed
>make[1]: ***
>[/home/amit/Documents/tut/sem4/sem5/projects/riot-os/RIOT/tests/driver_nvram_spi/bin/native/driver_nvram_spi/main.o]
>Error 1
>/home/amit/Documents/tut/sem4/sem5/projects/riot-os/RIOT/tests/driver_nvram_spi/../../Makefile.include:215:
>recipe for target 'all' failed
>make: *** [all] Error 2
>
>
>Seems that, I may have to export some environment variables or update
>some
>Makefiles for building my driver test application. I'm wondering, if
>there is
>any document on writing and testing drivers for RIOT ?
>
>My setup environment:
>Host: Linux, x86_64
>
>Thanks,
>#!/Kumar/Amit/Mehta
>___
>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] Implementing rng

[Ludwig Knüpfer]

Hi,

The Makefile.features defines the features of a board, that's why it lives in 
the boards directory. So yes, it is intended to declare the RNG in there even 
if it is not part of the CPU/SoC.

It would be architecturally nicer to have such files in various places (eg CPU, 
radio, board) and let them be included, but that has not been done for any 
board as far as I know. Also, I can't remember if there was a discussion about 
this possibility.

Cheers,
Ludwig

Am 21. Februar 2016 20:56:51 MEZ, schrieb Mathias Tausig 
:
>Unfortunately, it doesn't. My problems are:
>
>a) In the case of my board, the hardware RNG is not part of the CPU but
>instead of the radio chip, which is accessed by the code in
>driver/at86rf2xx.
>
>b) If I implement the hwrng interface in the at86rf2xx code, how does
>the samr21-xpro board learn of this? I couldn't find the
>code/configuration, where the at86rf2xx driver is attached to that
>board.
>
>c) Can I simply put the periph_hwrng feature in the board's
>Makefile.features if I know that that interface is implemented in some
>of its parts?
>
>Thanks a lot for your assistance, I just want to create a good patch
>for this, which can easily be integrated with the upstream code.
>
>cheers
>Mathias
>
>Am 21.02.2016 7:29 nachm. schrieb Peter Kietzmann
>:
>>
>> Hi Mathias,
>>
>> [1] is the interface that should be implemented by your driver. The
>driver is CPU specific and should be placed in
>RIOT/cpu/*/periph/hwrng.c like e.g. here [2].
>>
>> Does that reduce your confusion or did I get you wrong :-) ?
>>
>> Best
>> Peter
>>
>> [1]
>https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/periph/hwrng.h
>> [2]
>https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32f4/periph/hwrng.c
>>
>> Am 18.02.2016 um 13:46 schrieb Tausig Mathias:
>>>
>>> I am a bit confused, where to put that code. As far as I can tell,
>all current
>>>
>>> implementations of the hwrng functions are implemented on the cpu
>and not on the
>>>
>>> board level. While my rng is on the at86rf2xx chip, which is a
>driver. Can I put
>>>
>>> the feature in the driver?
>>>
>>>
>>>
>>>
>>>
>>> Am Mittwoch, den 17.02.2016, 17:22 +0100 schrieb Hauke Petersen:
>>>
 Hi Mathias,



 I think the way to go here is to implement the

 `drivers/include/periph/hwrng.h` interface. For this I think it
>makes sense to

 add a function that reads the random data from the radio to the
>at86rf2xx

 driver and call this function from the hwrng driver.



 Cheers,

 Hauke











 On 16.02.2016 17:14, Tausig Mathias wrote:

> Hy!
>
>
>
> I would like to use the hardware RNG from my samr1-xpro board. It
>should be
>
> available by reading out a certain register, according to the
>AT86RF233
>
> documentation.
>
> My problem is, that I don't how to do that (I am pretty new to
>this stuff).
>
> Is there some documentation available for this kind of task, or
>could you
>
> point me in the right
>
> direction?
>
>
>
> cheers
>
> Mathias
>
>
>
> ___
>
> devel mailing list
>
> devel@riot-os.org
>
> https://lists.riot-os.org/mailman/listinfo/devel
>
>>
>> -- 
>>
>> Peter Kietzmann
>>
>>
>>
>> Hamburg University of Applied Sciences
>>
>> Dept. Informatik, Internet Technologies Group
>>
>> Berliner Tor 7, 20099 Hamburg, Germany
>>
>> Fon: +49-40-42875-8426 
>>
>> Web: http://www.haw-hamburg.de/inet
>>
>___
>devel mailing list
>devel@riot-os.org
>https://lists.riot-os.org/mailman/listinfo/devel

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

Re: [riot-devel] Fwd: tapsetup problem

[Ludwig Knüpfer]

Hi,

Apparently your project is not configured to use a transceiver.

Cheers,
Ludwig

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

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

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

[Ludwig Knüpfer]

Hi,

I bow my head to everyone who contributed :)

Cheers,
Ludwig

Am 17. September 2015 18:31:21 MESZ, schrieb Oleg Hahm :
>Ladies and gentlemen!
>
>I'm more than proud to announce that just a couple of minutes ago I
>sent the
>first successful ping from an iotlab-m3 node over a RIOT powered border
>router
>(running on a samr21-xpro) to my desktop PC and received its response!
>
>Let's celebrate this tonight!
>
>Cheers,
>Oleg
>
>P.S. Everything you need is included in my pre-release branch:
>https://github.com/OlegHahm/RIOT/tree/2015.09-RC0

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

Re: [riot-devel] one wire communication

[Ludwig Knüpfer]

Hi,

The DHT devices use a protocol similar to 1-wire. See pull request #2990 for 
reference.

Cheers,
Ludwig

Am 18. August 2015 09:51:21 MESZ, schrieb shishir tiwari 
sumit.tiwari1...@gmail.com:
Hello RIOTers,

we are trying to communicating with  DS2430A IC which support is one
wire protocol.

if anyone having some basic example of one wire
protocol(reading/writing).

please share with us.

Thanks
Shishir Tiwari
___
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] MQTT + RIOT

[Ludwig Knüpfer]

Hi,

I can't report any progress either.

Cheers,
Ludwig

Am 4. August 2015 14:43:58 MESZ, schrieb Cenk Gündogan 
cenk.guendo...@fu-berlin.de:
Hey,

As far as I'm concerned the mqtt-sn implementation
that Ludwig and me started a while back can be labled as Work In 
No-Progress.
We never went beyond some header definitions, because the gnrc network 
stack was still transitioning. So feel free to port mqtt-sn or adopt 
Ludwig's branch.

Ludwig, anything to add?

cheers,
Cenk

On 04.08.2015 11:17, Michael Frey wrote:
 Hi,

 Am Di, 4.08.2015, 10:14, schrieb Joakim Gebart:

 I was only yesterday reading up on Paho and MQTT SN for use in RIOT.
I
 will
 I was also looking into an MQTT client for RIOT and found a couple of
days
 ago this discussion:

 https://github.com/RIOT-OS/RIOT/issues/2224

 tl;dr Ludwig points out that there is a work in progress MQTT-SN
client
 over here:

 https://github.com/LudwigOrtmann/RIOT/tree/mqtt-sn

 However, I don't know the exact status of MQTT-SN in RIOT?

 Best,
   Michael

___
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