Re: [riot-devel] Hack'n'ACK tomorrow
Hi all, the previous link is not working. The Hack'n'ACK is available here: https://haw-hamburg.zoom.us/j/98910128063 Cheers Peter Am 29.06.20 um 20:38 schrieb Martine Sophie Lenders: > Hi, > > Google did not care to remind us about Hack'n'ACK this month, never the > less it will take place. Tomorrow as of 5pm we will meet at > > https://haw-hamburg.zoom.us/j/99810821763 > > As always (I hope this is possible without the host joining?) people who > want to join earlier are invited to as of 3pm. > > Best regards, > Martine > > > ___ > 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 signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] RIOT Summit 2019 - livestream
Folks, you can now follow the RIOT Summit 2019 – Day 1 online: https://www.youtube.com/watch?v=DKKKn8WvI8Q=youtu.be Have fun! Peter ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Notification: Hack'n'ACK @ Tue Dec 18, 2018 5pm - 10pm (CET) (RIOT Events)
The Hack'n'ACK is connected to: https://jitsi.tools.ietf.org/riot-hacknack We are setup and starting at HAW. Cheers Peter Am 17.12.18 um 16:59 schrieb Google Calendar: > more details » > <https://www.google.com/calendar/event?action=VIEW=MzQyZzJ1NjkwdWs0c3E0MHB2N3JoOWdsaGEgazNxbDhzZXR2N2w0OG9mbm9sMHRmdXU2dHNAZw=1> > > > Hack'n'ACK > > https://jitsi.tools.ietf.org/riot-hacknack > <https://www.google.com/url?q=https%3A%2F%2Fjitsi.tools.ietf.org%2Friot-hacknack=D=2=AFQjCNGRLw_oWsexewHFmrgnEmXp-RJoRQ> > /When/ > Tue Dec 18, 2018 5pm – 10pm Central European Time - Berlin > /Where/ > FU Berlin; HAW Hamburg(map > <https://maps.google.com/maps?q=FU+Berlin;+HAW+Hamburg=en>) > /Calendar/ > RIOT Events > /Who/ > > • > Martine Lenders- creator > > Invitation from Google Calendar <https://www.google.com/calendar/> > > You are receiving this email at the account peterschme...@gmail.com > because you are subscribed for notifications on calendar RIOT Events. > > To stop receiving these emails, please log in to > https://www.google.com/calendar/ and change your notification settings > for this calendar. > > Forwarding this invitation could allow any recipient to modify your RSVP > response. Learn More > <https://support.google.com/calendar/answer/37135#forwarding>. > > > _______ > 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
Re: [riot-devel] Benchmarking of Real-Time Operating Systems for Internet of Things Devices
PS: You may want to have a look at this work: https://www.researchgate.net/publication/327561337_System_Architecture_Directions_for_Post-SoC32-bit_Networked_Sensors Cheers Peter On 25/09/2018 23:54, Peter Kietzmann wrote: > Hi guys, > > that sounds awesome! Just some hints inline. > > On 25/09/2018 18:13, Julien Gomez wrote: >> Hello RIOT community ! >> >> We are two students of the Université catholique de Louvain from Belgium >> and we work on our master thesis. The thesis is called "Benchmarking of >> Real-Time Operating Systems for Internet of Things Devices" and is about >> comparing the different implementations of open-source RTOS's currently >> available on the market. >> >> In broad outline, we are planning to analyze the scheduling, switching >> context, memory management and/or any relevant metric dependant of the >> operating system. >> >> Another goal is to compare networking performances or implementations of >> the various stacks available. We have currently no concrete planning for >> this part. >> >> This project will be open source (because we <3 the open source). > > Great, same here :-). > >> >> Here are some questions we have for you: >> - "What would you like to see in this benchmarking project?"; >> - "What RTOS should we benchmark?"; > > Independent from *RT*OS I'd suggest RIOT, contiki-ng, Zephyr, Mynewt. If > you find common ground then FreeRTOS and in case of too much time, add mbed. > >> - "What metric should we consider?". > > Just speaking for the networking part, next to the analysis that you > were pointed to off-list, one might want to see comparable numbers for > the other OSes. Furthermore a more detailed energy analysis is missing. > > Also it would be nice to see how different OSes perform in an "all day" > IoT scenario. For example: x devices in a multi-hop topology communicate > sensor readings each y seconds. What's the energy consumption, what's > the maximum throughput before break-down? And the like ... > > Interoperability, feature sets, and device support are important metrics > next to community agility which is obviously hard to measure but > important when it comes to willingness/speed to migrate bug fixes. > > >> >> We'd love to hear your recommandations or any help you can provide us with. >> >> Also if you are interested about how the project will evolve, we'll be >> glad to update you on our progress. > > I am interested. > > Best > Peter > >> >> If the project gain lot of interests, we will probably create a >> communication channel like Slack or Gitter. >> >> Sincerely, >> Julien Gomez and Trong-Vu Tran >> >> ___ >> 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
Re: [riot-devel] Notification: Hack'n'ACK @ Tue Sep 25, 2018 5pm - 10pm (CEST) (RIOT Events)
Almost forgot: The Hack'n'ACK is connected to https://jitsi.tools.ietf.org/riot-hacknack Cheers Peter On 24/09/2018 17:00, Google Calendar wrote: > more details » > <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxODA5MjVUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=1> > > > Hack'n'ACK > > /When/ > Tue Sep 25, 2018 5pm – 10pm Central European Time - Berlin > /Where/ > FU Berlin; HAW Hamburg(map > <https://maps.google.com/maps?q=FU+Berlin;+HAW+Hamburg=en>) > /Calendar/ > RIOT Events > /Who/ > > • > Martine Lenders- creator > > Invitation from Google Calendar <https://www.google.com/calendar/> > > You are receiving this email at the account peterschme...@gmail.com > because you are subscribed for notifications on calendar RIOT Events. > > To stop receiving these emails, please log in to > https://www.google.com/calendar/ and change your notification settings > for this calendar. > > Forwarding this invitation could allow any recipient to modify your RSVP > response. Learn More > <https://support.google.com/calendar/answer/37135#forwarding>. > > > _______ > 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
Re: [riot-devel] Notification: Hack'n'ACK @ Tue Aug 28, 2018 5pm - 10pm (CEST) (RIOT Events)
Dear RIOTers, due to the lack of participants, we won't setup a conferencing call for today's Hack'n'ACK. However, some people will be on-site at HAW Hamburg as usual. Cheers Peter Am 27.08.2018 um 16:59 schrieb Google Calendar: > more details » > <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxODA4MjhUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=1> > > > Hack'n'ACK > > /When/ > Tue Aug 28, 2018 5pm – 10pm Central European Time - Berlin > /Where/ > FU Berlin; HAW Hamburg(map > <https://maps.google.com/maps?q=FU+Berlin;+HAW+Hamburg=en>) > /Calendar/ > RIOT Events > /Who/ > > • > Martine Lenders- creator > > Invitation from Google Calendar <https://www.google.com/calendar/> > > You are receiving this email at the account peterschme...@gmail.com > because you are subscribed for notifications on calendar RIOT Events. > > To stop receiving these emails, please log in to > https://www.google.com/calendar/ and change your notification settings > for this calendar. > > Forwarding this invitation could allow any recipient to modify your RSVP > response. Learn More > <https://support.google.com/calendar/answer/37135#forwarding>. > > > > _______ > 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
Re: [riot-devel] ESP8266 Port and Networking
Hi Gunar, David, I think implementing against the sock API make most sense: http://riot-os.org/api/group__net__sock.html Have a look at this PR which intends to port the ESP as an AT-based network device: https://github.com/RIOT-OS/RIOT/pull/5898 Best Peter https://github.com/RIOT-OS/RIOT/pull/5898 Am 26.03.2018 um 03:18 schrieb David Lyon: > Hi Gunar, > > Do you have any links to your work ? > > Since I do also work on the ESP8266 I can only say that being able to > send and receive UDP packets might be a place to start? > > I'm not a RIOT expert - so that's where I stand. > > If RIOT supports Sockets or MQTT that might also be worth looking into. > > Regards > > David > > On 2018-03-25 05:33, Gunar Schorcht wrote: > >> Hello, >> >> most parts of my RIOT-OS port to the ESP8266 has been implemented. GPIO, >> SPI, I2C, UART, PWM seem to be ready and most of local applications are >> working. >> >> However, RIOT-OS makes no real sense without networking. Unfortunately, >> ESP8266 doesn't have Zigbee or 802.15.4 radio interface on board. >> >> Sure, one possibility would be to connect a Zigbee module via SPI. But, >> it doesn't seem to be reasonable to connect a 25 EUR Zigbee module to a >> 3 EUR MCU which has a WiFi interface on board. >> >> Therefore, my question is, what is the best way to realize networking on >> a new platform that doesn't have 802.15.4 radio but full TCP/IP stack >> and WiFi on board? >> >> Any suggestion helps. >> >> Regards >> Gunar >> >> ___ >> 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 > -- 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
Re: [riot-devel] networking
Hi Janna, welcome to RIOT! Short answer: Yes and no, but we could need more people working on it :-). Maybe the authors can share further insights. Please have a look at the following efforts: https://github.com/RIOT-OS/RIOT/tree/master/examples/gnrc_networking_mac https://github.com/RIOT-OS/RIOT/pull/6554 https://github.com/RIOT-OS/RIOT/pull/8332 https://github.com/RIOT-OS/RIOT/pull/8570 Best Peter Am 24.02.2018 um 19:57 schrieb Janna Om: > Hello, > i am new in RIOT OS. > I want to write an application that uses different mac protocols. > I would like to know if there already exist CSMA, TDMA and XMAC > implementations in RIOT. > Are there any tutorials or examples available about network > configurations and communication settings? > Thank You in advance! > > > > ___ > 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
Re: [riot-devel] Notification: Hack'n'ACK @ Tue Jan 30, 2018 5pm - 10pm (CET) (RIOT Events)
Dear RIOTers, we changed to tool to participate in the RIOT Hack'n'ACK remotely. Everyone who likes to join, feel free to connect via jitsi https://jitsi.tools.ietf.org/riot-hacknack Cheers Peter Am 29.01.2018 um 17:00 schrieb Google Calendar: > more details » > <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxODAxMzBUMTYwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn> > > > Hack'n'ACK > > /When/ > Tue Jan 30, 2018 5pm – 10pm Berlin > /Where/ > FU Berlin; HAW Hamburg(map > <https://maps.google.com/maps?q=FU+Berlin;+HAW+Hamburg=en>) > /Calendar/ > RIOT Events > /Who/ > > • > Martine Lenders- creator > > Invitation from Google Calendar <https://www.google.com/calendar/> > > You are receiving this email at the account peterschme...@gmail.com > because you are subscribed for notifications on calendar RIOT Events. > > To stop receiving these emails, please log in to > https://www.google.com/calendar/ and change your notification settings > for this calendar. > > Forwarding this invitation could allow any recipient to modify your RSVP > response. Learn More > <https://support.google.com/calendar/answer/37135#forwarding>. > > > > _______ > 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
Re: [riot-devel] Re-transmission, interval 40ms problem
Hi Baptise, which software did you use on BOARD A and B? AFAIK there is not a known problem with this in the stack. The Atmel radio does automatic retransmission and carrier sensing which might take some milli seconds (not 40!). Can you check if the 802.15.4 sequence number of these packets is equal? Cheers Peter Am 26.01.2018 um 10:48 schrieb Baptiste Clenet: > Hi, > Some packet are lost while sending message between two samr21 so I use > the sniffer application to check paquet over the air. > I was surprised to see that sometime paquet are retransmitted without > my consent! > I mean: > I send one paquet from BOARD A to BOARD B > BOARD B does not receive it > BOARD C (sniffer) sees two paquets with 40ms interval > > The interval is almost 40ms every time there is a paquet retransmission. > > Do you know why paquet is retransmitted 40ms after the first one? > Is this a problem (or normal behaviour) in RIOT stack or transceiver? > > Cheers, > -- 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
Re: [riot-devel] 答复: Multi-hop wireless communication based ICN
Hi, have a look at the Tutorials: https://github.com/RIOT-OS/Tutorials . Best Peter Am 15.12.2017 um 10:25 schrieb 侯 宁博: > I have received it and request a account to access FIT IoT-LAB. > > However,Could you tell me how I can install RIOT-OS on my board? I don’t > see it in the website. > > Thanks a lot. > > > > 发送自Windows 10 版邮件 <https://go.microsoft.com/fwlink/?LinkId=550986>应用 > > > > > *From:* devel <devel-boun...@riot-os.org> on behalf of Peter Kietzmann > <peter.kietzm...@haw-hamburg.de> > *Sent:* Thursday, December 14, 2017 3:44:38 PM > *To:* devel@riot-os.org > *Subject:* Re: [riot-devel] Multi-hop wireless communication based ICN > > Hi, > > didn't you receive Emmanuel's response to your mail from 12th December? > Have a look at the archive: > > https://lists.riot-os.org/pipermail/devel/2017-December/005560.html > > Best > Peter > > Am 14.12.2017 um 02:31 schrieb 侯 ?博: >> Hi，I start to learn RIOT just now,I have some questions before working >> on it. >> >> Whether RIOT can support Multi-hop wireless communication based ICN? >> >> Besides,How to install RIOT-OS on my hardware? >> >> Thanks a lot. >> >> >> >> ___ >> 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 > -- 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
Re: [riot-devel] Multi-hop wireless communication based ICN
Hi, didn't you receive Emmanuel's response to your mail from 12th December? Have a look at the archive: https://lists.riot-os.org/pipermail/devel/2017-December/005560.html Best Peter Am 14.12.2017 um 02:31 schrieb 侯 ?博: > Hi，I start to learn RIOT just now,I have some questions before working > on it. > > Whether RIOT can support Multi-hop wireless communication based ICN? > > Besides,How to install RIOT-OS on my hardware? > > Thanks a lot. > > > > ___ > 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
Re: [riot-devel] Open source best practices - Presentation
Hi Dan, looking forward to that talk! It's been a while I read it but this contribution might be interesting:"Experiences from a Decade of TinyOS Development". We'd like to join (remotely) from Hamburg. Usually we use PlaCam as explained in [1] and -as you may know- recently we tried with zoom [2]. Cheers Peter [1] https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation [2] https://zoom.us/ Am 29.11.2017 um 14:42 schrieb Daniel Petry: > Hi all > > I'm doing a presentation next Friday on open source best practices. As a > newcomer in open source development, it was something I was interested > in, and I thought it would help by informing future discussions on the > way we do things as well. > > I was wondering if anyone had any input to make the presentation more > useful? > > Specifically: > > - Can you think of any case studies of prominent open source projects > that are like RIOT, and have either succeeded or failed in a > particularly notable manner? > - Do you know of any particularly prominent studies or other literature > on the subject, maybe which have analysed successes/failures and the > reason for them over a large number of projects? > - Do you have any suggestions for topics/areas of focus that would be > particularly relevant to RIOT, and for what reason would the area of > focus be relevant? > - Is there anyone on other sites who would be interested in this > presentation, and what tech do we usually use for live cross-site > presentations if so? > > Many thanks, > > Dan. > > ___ > 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
Re: [riot-devel] HIL testing
Hi Hauke,
thanks for you efforts! This is great and really useful work. IMO it is
the right direction, even though I always hoped to find a way around
implementing our own I2C slave device. That's why I wanted to take this
opportunity to ask around for other experiences with I2C (slave) test
devices. Anyone, anything?
Best
Peter
Am 27.11.2017 um 18:33 schrieb Hauke Petersen:
> Hi everyone,
>
> in today's developer meeting the discussion passed by the topic of HIL
> testing once again, this time in the context of the upcoming re-modeling
> of the I2C interface. Some weeks ago I had an idea for a simple HIL
> setup for automatically testing perihp/i2c drivers, and I promised to
> share it (although it is in very very early state). So here it is.
>
> So the basic idea is to connect the I2C pins of the 'board-under-test'
> (i2c master for now) to a 2nd board (lets call it 'test peer'), running
> a fully controllable software i2c slave implementation. On the
> device-under-test we simply run the 'tests/periph_i2c' app, that lets us
> control the I2C master using shell commands (init/read/write incl
> parameters). On the 'test peer' we run a programmable soft i2c client,
> that offers shell commands expressing expectations, e.g. "expect 4 byter
> [abcd] written to addr 0x23".
>
> Now for creating an automated I2C test-suite, I imagine something
> similar to our existing pyexpect scripts (testrunner), just with the
> added capability of handling two clients. So the test script could look
> something like this (mostly pseudocode...):
>
> `PORT=/dev/ttyACM0 TESTPEER=/dev/ttyACM1 make hil-test`
>
> triggers:
>
> ```python
> ...
> def testfunc(testie, peer):
> ...
> # tell the 'test peer' to expect something to be written to addr 0x23
> and respond with a NACK
> peer.sendline("expect_addr 0x23")
> # write a random byte the addr 0x23
> testie.sendline("w 0x23 a")
> # the 'test peer' will tell if it sees the expected address
> peer.expect("[SUCCESS]")
> # the 'device-under-test' should recognize the NACK
> testie.expect("error: no device with that address found on bus")
>
> # test writing (expect 4 bytes [affe] written to address 0x42)
> peer.sendline("expect_write 0x42 a f f e")
> testie.sendline("w 0x42 a f f e")
> peer.expect("[SUCCESS]")
> testie.expect("I2C_DEV(0): successfully wrote 4 bytes to the bus\n")
>
> ...
> # many many more test cases here, including simulation of badly
> behaving slaves and bus recovery...
> ```
>
> I have sketched a I2C slave implementation to run on the 'test peer' in
> [1] (under `tests/softi2ccli`). It is in no means production code, but a
> quick prove of concept. But IMHO this would be a very easy and straight
> forward way to have an automatic test-suite that would work on someones
> desk for now.
>
> Integration into the bigger picture would hopefully be easy doable, but
> this not in the scope of this particular proposal here...
> For now my goal would simply be to build a test suite for assisting with
> the upcoming I2C remodeling to get some hands-on experience and speed up
> the testing efforts for that task.
>
> Cheers,
> Hauke
>
> [1] https://github.com/haukepetersen/RIOT/tree/add_softi2cli
> ___
> 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
Re: [riot-devel] Notification: Hack'n'ACK @ Tue Oct 10, 2017 5pm - 10pm (RIOT Events)
Hi all, we're online now: http://placecam.de/call.php?c=kWtmE~M0jTbKGFQSGnUBLtC.xAbWgTythbQbBMVXUvs- You can find information about remote participation here: https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation#videoconferencing Cheers Peter On 09.10.2017 16:59, Google Calendar wrote: > more details » > <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNzA5MjZUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn> > > > Hack'n'ACK > > /When/ > Tue Oct 10, 2017 5pm – 10pm Berlin > /Where/ > FU Berlin; HAW Hamburg(map > <https://maps.google.com/maps?q=FU+Berlin;+HAW+Hamburg=en>) > /Calendar/ > RIOT Events > /Who/ > > • > Martine Lenders- creator > > Invitation from Google Calendar <https://www.google.com/calendar/> > > You are receiving this email at the account peterschme...@gmail.com > because you are subscribed for notifications on calendar RIOT Events. > > To stop receiving these emails, please log in to > https://www.google.com/calendar/ and change your notification settings > for this calendar. > > Forwarding this invitation could allow any recipient to modify your RSVP > response. Learn More > <https://support.google.com/calendar/answer/37135#forwarding>. > > > > _______ > 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
Re: [riot-devel] Notification: Hack'n'ACK @ Tue Aug 29, 2017 5pm - 10pm (RIOT Events)
Hi all, we're online now: http://placecam.de/call.php?c=kWtmE~M0jTbKGFQSGnUBLtC.xAbWgTythbQbBMVXUvs- You can find information about remote participation here: https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation#videoconferencing Cheers Peter On 28.08.2017 16:59, Google Calendar wrote: > more details » > <https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNzA4MjlUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn> > > > Hack'n'ACK > > /When/ > Tue Aug 29, 2017 5pm – 10pm Berlin > /Where/ > FU Berlin; HAW Hamburg(map > <https://maps.google.com/maps?q=FU+Berlin;+HAW+Hamburg=en>) > /Calendar/ > RIOT Events > /Who/ > > • > Martine Lenders- creator > > Invitation from Google Calendar <https://www.google.com/calendar/> > > You are receiving this email at the account peterschme...@gmail.com > because you are subscribed for notifications on calendar RIOT Events. > > To stop receiving these emails, please log in to > https://www.google.com/calendar/ and change your notification settings > for this calendar. > > Forwarding this invitation could allow any recipient to modify your RSVP > response. Learn More > <https://support.google.com/calendar/answer/37135#forwarding>. > > > > _______ > 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
Re: [riot-devel] Dynamic radio power scaling in RIOT
Hi Koen, thanks for your explanations! Are you aware of the FIT IoT-lab testbed? https://www.iot-lab.info/ This should give you access to several hundred iotlab-m3 nodes which are equipped with an at86rf231. There is also one site with some tens of samr21-xpros, equipped with an at86rf233. Would be great if you keep me/us informed about your results :-). Best Peter On 26.06.2017 12:36, Koen wrote: > Hi, > > For now this is all quite proof of concept. I haven't had the time to > measure the actual power saving. > > There are still a few problems that limit the actual power saving. The > way I've implemented it now, only transmit power is limited. Before a > transmission, the radio power is configured, and almost immediately > after, the transmit power is set to full power again. This way L2 ACK > frames are always send at full power and the power scale algorithms of > nodes don't affect each other. Furthermore, if I have to believe the > datasheets, the radio's seem to also consume comparable current when in > RX-mode. For now, until I've confirmed the actual power draw of the > radio, I think the most benefits are in the reduced transmission range > and thus reduced interference between nodes. > > The other limitation is that my implementation depends on the radio > reporting the frame retries. At least the mrf24j40 and the at86rf233 > support this. I don't know about the kw2xrf. The other variants of the > at86rf2xx don't seem to support reporting the frame retries, they only > report whether at least an ACK was received or not. > > I don't have any plans of repeated tests in network topologies at the > moment, mostly because I don't have a large enough network at my > disposal. I'm still trying to get at least repeatable results from my > small setup, but random interference makes this difficult. Any proposals > for this are welcome. I'd love to have some larger tests on node > interaction here. In the future I'd like to try to have RPL minimize > power consumption as a route metric.> > The actual power scaling algorithms I've implemented are based on TCP > congestion control. TCP congestion control also has the goal of > approaching a limit where loss occurs when the limit is passed. Two > algorithm are implemented: A "Reno" style additive increase, > multiplicative decrease and a "Cubic" approach style function. As soon > as I have some results where I can actually compare both algorithm I'll > share them here. > > One of the other ideas for algorithms I've had so far was a PID kind of > control loop where a predefined ETX value is used as a setpoint. This > way a configurable amount of loss versus power saving might be achieved. > If somebody has a different proposal for an algorithm, I'd like to know. > I'm currently trying to use only ETX or other already known values > instead of a negotiating algorithm to keep the implementation compatible > with different nodes and/or operating systems. > > Regards, > Koen > > On 06/23/2017 09:03 AM, Peter Kietzmann wrote: >> Hi Koen, >> >> awesome! IMO this is interesting work and I'd like to push this forward, >> at least to use it myself at some point in time, though I can't promise >> an in-depth review so soon -> let's start polishing "later". >> >> Did you already start measurements of the actual consumption saving of a >> node? Do you plan to evaluate your approach in different network >> topologies? >> >> Cheers >> Peter >> >> On 22.06.2017 22:00, Koen Zandberg wrote: >>> Hello, >>> >>> For a small research project as a part of my study, I did some research >>> on the effectiveness of dynamic radio output scaling. The general idea >>> is that to save power, the radio has to transmit at only the power >>> required to reach the destination. For the research I wanted to build a >>> practical setup instead of a simulation as one of the research goals. >>> >>> The setup I've build works by estimating the minimum required powered >>> and using layer 2 acks (or the lack thereof) as feedback. At this point >>> I have a mostly working power scaling proof of concept implemented in >>> RIOT. For an example measurement: https://bergzand.net/misc/etx5.svg >>> which is a measurement of a number of packets. The blue dots is an ETX >>> estimation measured based on the feedback from the radio module. The Red >>> line is the power configured for that packet. As visible, power is >>> scaled down until a stable level is reached. Power keeps oscillating >>> around this level until a lot of interference is noticed, then the power >>&g
Re: [riot-devel] Dynamic radio power scaling in RIOT
Hi Koen, awesome! IMO this is interesting work and I'd like to push this forward, at least to use it myself at some point in time, though I can't promise an in-depth review so soon -> let's start polishing "later". Did you already start measurements of the actual consumption saving of a node? Do you plan to evaluate your approach in different network topologies? Cheers Peter On 22.06.2017 22:00, Koen Zandberg wrote: > Hello, > > For a small research project as a part of my study, I did some research > on the effectiveness of dynamic radio output scaling. The general idea > is that to save power, the radio has to transmit at only the power > required to reach the destination. For the research I wanted to build a > practical setup instead of a simulation as one of the research goals. > > The setup I've build works by estimating the minimum required powered > and using layer 2 acks (or the lack thereof) as feedback. At this point > I have a mostly working power scaling proof of concept implemented in > RIOT. For an example measurement: https://bergzand.net/misc/etx5.svg > which is a measurement of a number of packets. The blue dots is an ETX > estimation measured based on the feedback from the radio module. The Red > line is the power configured for that packet. As visible, power is > scaled down until a stable level is reached. Power keeps oscillating > around this level until a lot of interference is noticed, then the power > sweeps back up. > > The merit of this whole idea is that it should both save the node power, > but when implemented correctly also improve the total throughput of the > network. This last point because nodes transmit with less power, thus > causing less interference with nodes further away. > > If there is interest in having this feature merged in mainline RIOT-os, > I'm willing to work on this to make sure that the code quality is as > required. The code can be viewed and tracked at > https://github.com/bergzand/RIOT/tree/mwn2 > > Regards, > Koen > > ___ > 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
Re: [riot-devel] lorawan in riot
Hi Arun, as already stated off-list: welcome to RIOT! Happy to see more interest on that topic. There is a WIP PR for LoRaWAN https://github.com/RIOT-OS/RIOT/pull/6645 *but* we still didn't merge the Semtech drivers, even though we are close before IMO. In case you want to contribute it would be great to get more testers for the drivers at first https://github.com/RIOT-OS/RIOT/pull/6797 and then switch to the LoRaWAN development. Regarding hardware I guess SX1276MB1MAS is a good choice. The driver does also support SX1272 devices so the P-NUCLEO-LRWAN1 shield by ST might be a cheaper solution. There are also several custom replica around which are way cheaper. Best Peter On 31.05.2017 11:52, அருண்பிரபு (arunprabhu) wrote: > Dear all, > I'd like to know if the support of lorawan on sx1272/1276 modems in riot > os is already available? > I'd be happy to test it and probably contribute if i can(i'm new to riot > and have some experience with contiki though). > I'm planning to use nucleof476rg as baseboard. I've not selected any > lora shield to use with, would be happy if you recommend one. otherwise > I shall use SX1276MB1MAS*.* > > > thanks in advance, > Arun > > > > ___ > 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
Re: [riot-devel] PWM Driver
Hi Ilias, did you already manage to get your setup working? I would recommend having a deeper look into the reference manual. IIRC it is not possible to configure the same PWM device with different frequencies, as you already indicated. So the question is which hardware PWM device can be configured in which way and run independently from others. This must be reflected in the peripheral configuration. Best regards Peter On 07.04.2017 15:29, Ilias Seitanidis wrote: Hi again :) I am trying to produce two different frequencies on two different pins. When I am trying [1] as it is but only changing the FREQU and STEPS, I get the correct results.(first trial to get 19khz and second trial to get 50khz) However, when I duplicate the method pwm_init(pwm_t dev, pwm_mode_t mode, uint32_t freq, uint16_t res), in order to initialize the two pins with different freq and period at the same time, I got double the freq and half the period. I think that the problem is that for both pins I am using the TCC devices in [2]. I created a duplicate of the pwm_config[] in [2] by only changing the TCC to TC (for the second instance ) but it didn't work. Any suggestions? Thank you in advance! Best regards, Ilias [1] https://github.com/RIOT-OS/RIOT/blob/master/tests/periph_pwm/main.c [2] https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/include/periph_conf.h P.S. When I tried to create at the same time the two different frequencies in the main[1] I erased the for loops and I staticaly used the PWM_DEV(0),PWM_DEV(1) and on the pwm_set(PWM_DEV(Y), X, state), where X is the pin I need, and Y the device number 0 or 1. ___ 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
Re: [riot-devel] Correct way to bring radio module to sleep state
Hi Neo, this should can be done via netapi. Something like this should do: gnrc_netapi_set(dev, NETOPT_STATE_SLEEP, 0, , sizeof(netopt_enable_t) Also check the netapi doc: https://riot-os.org/api/group__net__gnrc__netapi.html#gabc41a5d60228a68daa7ef14b0bbb6ff4 Cheers Peter Am 02.03.2017 um 15:35 schrieb Neo: Dear Riot Developers, has anyone an example how to turn a wireless module into sleep state (including network stack?)? What is here the correct way? Which API functions should be used? Thanks a lot! Regards., Neo ___ 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
[riot-devel] Release 2017.01
Dear RIOTers, we are happy to announce the tenth official release of RIOT: --- * RIOT 2017.01 * --- This release provides a lot of new features, fixes and enhancements. Among others these features contain an initial - still experimental - TCP implementation based on the GNRC network stack, support for reading from and writing to SD cards, a new power management architecture as well additional third party packages such as TweetNaCl, a cryptographic library, and Heatshrink a data compression library optimized for embedded real-time systems. We added support for new platforms including the Calliope mini, Maple mini, and a couple of STMs Nucleo boards. Device support was extended by several new drivers, e.g., for NXP PN532 NFC, Microchip MRF24J40 802.15.4 radio (experimental), or Bosch BME280 pressure/humidity/temperature sensor. We completely refactored the SPI interface, allowing for internally handled hardware or software chip select lines and shared bus usage for multiple devices with different SPI configurations. About 278 pull requests with about 606 commits have been merged since the last release and about 84 issues have been solved. 44 people contributed with code in 87 days. 2230 files have been touched with 220275 insertions and 159840 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! Best regards Peter [1] https://github.com/RIOT-OS/RIOT/releases/tag/2017.01 [2] https://github.com/RIOT-OS/RIOT/archive/2017.01.tar.gz [3] https://github.com/RIOT-OS/RIOT/blob/2017.01-branch/release-notes.txt ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Release 2017.01 status - RC2
Dear Community, due to some backported bugfixes today, I created a new release candidate [1]. Please help testing it [2]! Best Peter [1] https://github.com/RIOT-OS/RIOT/tree/2017.01-RC2 [2] https://github.com/RIOT-OS/Release-Specs/issues/38 Am 26.01.2017 um 20:18 schrieb Peter Kietzmann: > Dear RIOTers, > > Feature Freeze for the imminent 2017.01 release is *now*. I created > a release branch and tagged the first release candidate [1]. Please > start testing it [2]. As some of you might have noticed, I silently > moved the Milestone labels for your PRs and issues. Don't forget that > there are already open bugfixes [3] that will need a backport to the > release branch. So please keep reviewing those! > > We plan to get the Release out by Wednesday, just after the usual > Hack'n'ACK. I will come around with further information at an > appropriate time. > > Best regards > Peter > > [1] https://github.com/RIOT-OS/RIOT/tree/2017.01-RC1 > [2] https://github.com/RIOT-OS/Release-Specs/issues/37 > [3] > https://github.com/RIOT-OS/RIOT/pulls?q=is%3Aopen+is%3Apr+milestone%3A%22Release+2017.01%22 > > > Am 24.01.2017 um 19:39 schrieb Peter Kietzmann: >> Dear Community, >> >> there is still one open feature which is mandatory for this release and >> near completion [1]. Thus, the Feature Freeze will be postponed >> marginally until: >> >> *New Feature Freeze deadline: Thursday, January 26 (afternoon CET). >> >> Still, I'd like to motivate working on bug fixes rather than new features. >> >> Thanks for all the efforts you already put into this Release! >> >> Best regards >> Peter >> >> [1] https://github.com/RIOT-OS/RIOT/pull/4780 >> >> >> Am 20.01.2017 um 18:09 schrieb Peter Kietzmann: >>> Dear RIOTers, >>> >>> Feature Freeze was announced for today and since my last mail on Tuesday >>> there was great progress: >>> >>> *merged 72 pull requests, 53 of which were marked for this milestone >>> *closed 16 issues, 5 of which were marked for this milestone. >>> >>> However, looking at the list of open pull requests it appears that some >>> great features were close before but not merged yet. Thus I'd like to >>> give them a chance and postpone Feature Freeze. >>> >>> *Postponed Feature Freeze: Tuesday, January 24. >>> >>> Even though new features weren't freezed yet, I'd like to motivate >>> working on / reviewing existing issues and pull requests, i.e. anything >>> concerning >>> >>> SPI rework >>> https://github.com/RIOT-OS/RIOT/pull/4780 >>> >>> Storage >>> https://github.com/RIOT-OS/RIOT/pull/6031 >>> https://github.com/RIOT-OS/RIOT/pull/5616 >>> >>> MIPS >>> https://github.com/RIOT-OS/RIOT/pull/6060 >>> https://github.com/RIOT-OS/RIOT/pull/6066 >>> https://github.com/RIOT-OS/RIOT/pull/6092 >>> >>> Sock API >>> https://github.com/RIOT-OS/RIOT/pull/5937 >>> https://github.com/RIOT-OS/RIOT/pull/5938 >>> https://github.com/RIOT-OS/RIOT/pull/6004 >>> https://github.com/RIOT-OS/RIOT/pull/6012 >>> https://github.com/RIOT-OS/RIOT/pull/6117 >>> https://github.com/RIOT-OS/RIOT/pull/6372 >>> >>> ZEP >>> https://github.com/RIOT-OS/RIOT/pull/6121 >>> >>> Topics labeled "bug" >>> https://github.com/RIOT-OS/RIOT/pulls?q=is%3Aopen+is%3Apr+label%3Abug >>> >>> Regards >>> Peter >>> >>> Am 17.01.2017 um 09:59 schrieb Peter Kietzmann: >>>> Dear RIOTers, >>>> >>>> we are actively working for the upcoming 2017.01 release >>>> and since last week we already >>>> >>>> *merged 59 pull requests, 40 of which were marked for this milestone >>>> *closed 31 issues, 13 of which were marked for this milestone. >>>> >>>> This is great progress in my opinion! But we also opened a couple of new >>>> topics. Currently there are still 128 pull requests and 112 open issues >>>> marked for this release. I'd like to motivate all of you developers, >>>> maintainers, authors, and assignees to keep track of pull requests and >>>> issues where you're involved. Please get your code up to date, help >>>> reviewing and testing and move the release milestone for topics that >>>> won't make it this time. Our planned schedule is >>>> >>>> *Feature Freeze: Friday, January 20 >>>> *Expected Release date: Friday, January 27. >>>> >>>> I will silently postpone each pull request/issue that doesn't show any >>>> progress until feature freeze. >>>> >>>> Best regards >>>> Peter >>>> ___ >>>> Maintainer mailing list >>>> maintai...@riot-os.org >>>> https://lists.riot-os.org/mailman/listinfo/maintainer >>>> >>> >> > -- 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
[riot-devel] Release 2017.01 status - Feature Freeze
Dear RIOTers, Feature Freeze for the imminent 2017.01 release is *now*. I created a release branch and tagged the first release candidate [1]. Please start testing it [2]. As some of you might have noticed, I silently moved the Milestone labels for your PRs and issues. Don't forget that there are already open bugfixes [3] that will need a backport to the release branch. So please keep reviewing those! We plan to get the Release out by Wednesday, just after the usual Hack'n'ACK. I will come around with further information at an appropriate time. Best regards Peter [1] https://github.com/RIOT-OS/RIOT/tree/2017.01-RC1 [2] https://github.com/RIOT-OS/Release-Specs/issues/37 [3] https://github.com/RIOT-OS/RIOT/pulls?q=is%3Aopen+is%3Apr+milestone%3A%22Release+2017.01%22 Am 24.01.2017 um 19:39 schrieb Peter Kietzmann: > Dear Community, > > there is still one open feature which is mandatory for this release and > near completion [1]. Thus, the Feature Freeze will be postponed > marginally until: > > *New Feature Freeze deadline: Thursday, January 26 (afternoon CET). > > Still, I'd like to motivate working on bug fixes rather than new features. > > Thanks for all the efforts you already put into this Release! > > Best regards > Peter > > [1] https://github.com/RIOT-OS/RIOT/pull/4780 > > > Am 20.01.2017 um 18:09 schrieb Peter Kietzmann: >> Dear RIOTers, >> >> Feature Freeze was announced for today and since my last mail on Tuesday >> there was great progress: >> >> *merged 72 pull requests, 53 of which were marked for this milestone >> *closed 16 issues, 5 of which were marked for this milestone. >> >> However, looking at the list of open pull requests it appears that some >> great features were close before but not merged yet. Thus I'd like to >> give them a chance and postpone Feature Freeze. >> >> *Postponed Feature Freeze: Tuesday, January 24. >> >> Even though new features weren't freezed yet, I'd like to motivate >> working on / reviewing existing issues and pull requests, i.e. anything >> concerning >> >> SPI rework >> https://github.com/RIOT-OS/RIOT/pull/4780 >> >> Storage >> https://github.com/RIOT-OS/RIOT/pull/6031 >> https://github.com/RIOT-OS/RIOT/pull/5616 >> >> MIPS >> https://github.com/RIOT-OS/RIOT/pull/6060 >> https://github.com/RIOT-OS/RIOT/pull/6066 >> https://github.com/RIOT-OS/RIOT/pull/6092 >> >> Sock API >> https://github.com/RIOT-OS/RIOT/pull/5937 >> https://github.com/RIOT-OS/RIOT/pull/5938 >> https://github.com/RIOT-OS/RIOT/pull/6004 >> https://github.com/RIOT-OS/RIOT/pull/6012 >> https://github.com/RIOT-OS/RIOT/pull/6117 >> https://github.com/RIOT-OS/RIOT/pull/6372 >> >> ZEP >> https://github.com/RIOT-OS/RIOT/pull/6121 >> >> Topics labeled "bug" >> https://github.com/RIOT-OS/RIOT/pulls?q=is%3Aopen+is%3Apr+label%3Abug >> >> Regards >> Peter >> >> Am 17.01.2017 um 09:59 schrieb Peter Kietzmann: >>> Dear RIOTers, >>> >>> we are actively working for the upcoming 2017.01 release >>> and since last week we already >>> >>> *merged 59 pull requests, 40 of which were marked for this milestone >>> *closed 31 issues, 13 of which were marked for this milestone. >>> >>> This is great progress in my opinion! But we also opened a couple of new >>> topics. Currently there are still 128 pull requests and 112 open issues >>> marked for this release. I'd like to motivate all of you developers, >>> maintainers, authors, and assignees to keep track of pull requests and >>> issues where you're involved. Please get your code up to date, help >>> reviewing and testing and move the release milestone for topics that >>> won't make it this time. Our planned schedule is >>> >>> *Feature Freeze: Friday, January 20 >>> *Expected Release date: Friday, January 27. >>> >>> I will silently postpone each pull request/issue that doesn't show any >>> progress until feature freeze. >>> >>> Best regards >>> Peter >>> ___ >>> Maintainer mailing list >>> maintai...@riot-os.org >>> https://lists.riot-os.org/mailman/listinfo/maintainer >>> >> > -- 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
[riot-devel] Release 2017.01 status - not freezed yet
Dear Community, there is still one open feature which is mandatory for this release and near completion [1]. Thus, the Feature Freeze will be postponed marginally until: *New Feature Freeze deadline: Thursday, January 26 (afternoon CET). Still, I'd like to motivate working on bug fixes rather than new features. Thanks for all the efforts you already put into this Release! Best regards Peter [1] https://github.com/RIOT-OS/RIOT/pull/4780 Am 20.01.2017 um 18:09 schrieb Peter Kietzmann: > Dear RIOTers, > > Feature Freeze was announced for today and since my last mail on Tuesday > there was great progress: > > *merged 72 pull requests, 53 of which were marked for this milestone > *closed 16 issues, 5 of which were marked for this milestone. > > However, looking at the list of open pull requests it appears that some > great features were close before but not merged yet. Thus I'd like to > give them a chance and postpone Feature Freeze. > > *Postponed Feature Freeze: Tuesday, January 24. > > Even though new features weren't freezed yet, I'd like to motivate > working on / reviewing existing issues and pull requests, i.e. anything > concerning > > SPI rework > https://github.com/RIOT-OS/RIOT/pull/4780 > > Storage > https://github.com/RIOT-OS/RIOT/pull/6031 > https://github.com/RIOT-OS/RIOT/pull/5616 > > MIPS > https://github.com/RIOT-OS/RIOT/pull/6060 > https://github.com/RIOT-OS/RIOT/pull/6066 > https://github.com/RIOT-OS/RIOT/pull/6092 > > Sock API > https://github.com/RIOT-OS/RIOT/pull/5937 > https://github.com/RIOT-OS/RIOT/pull/5938 > https://github.com/RIOT-OS/RIOT/pull/6004 > https://github.com/RIOT-OS/RIOT/pull/6012 > https://github.com/RIOT-OS/RIOT/pull/6117 > https://github.com/RIOT-OS/RIOT/pull/6372 > > ZEP > https://github.com/RIOT-OS/RIOT/pull/6121 > > Topics labeled "bug" > https://github.com/RIOT-OS/RIOT/pulls?q=is%3Aopen+is%3Apr+label%3Abug > > Regards > Peter > > Am 17.01.2017 um 09:59 schrieb Peter Kietzmann: >> Dear RIOTers, >> >> we are actively working for the upcoming 2017.01 release >> and since last week we already >> >> *merged 59 pull requests, 40 of which were marked for this milestone >> *closed 31 issues, 13 of which were marked for this milestone. >> >> This is great progress in my opinion! But we also opened a couple of new >> topics. Currently there are still 128 pull requests and 112 open issues >> marked for this release. I'd like to motivate all of you developers, >> maintainers, authors, and assignees to keep track of pull requests and >> issues where you're involved. Please get your code up to date, help >> reviewing and testing and move the release milestone for topics that >> won't make it this time. Our planned schedule is >> >> *Feature Freeze: Friday, January 20 >> *Expected Release date: Friday, January 27. >> >> I will silently postpone each pull request/issue that doesn't show any >> progress until feature freeze. >> >> Best regards >> Peter >> ___ >> Maintainer mailing list >> maintai...@riot-os.org >> https://lists.riot-os.org/mailman/listinfo/maintainer >> > -- 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
Re: [riot-devel] PWM Driver
Hi Ilias, it's defined in the CMSIS header and it has the value '2': https://github.com/RIOT-OS/RIOT/blob/2c02520f73efd0b24b535f79414e43a0aa3f3553/cpu/sam0_common/include/cmsis/samr21/include/component/tcc.h#L1312 . There is no further documentation about this single implementation. I guess you've already found the API description?! https://riot-os.org/api/group__drivers__periph__pwm.html In general we try to keep drivers as simple and efficient as possible. If you plan to implement and contribute code it might be worth to ask around if this kind of feature makes sense, before opening a PR that does not gain attraction. What is the problem with GitHub? If you need help getting started with git and you don't know how to contribute code, you can find help by searching 'git' and 'Development procedures' in our wiki. Best regards Peter Am 23.01.2017 um 12:15 schrieb Ilias Seitanidis: > Hi Peter, > Thank you very much for your reply, unfortunatelly I have some problems > with github and cannot create pr. > In my implementation of ([1],i) I use a parameter for the wave type, in the > Atmel documentation, the value for a normal wave is 2, > however I wasn't able to find in RIOT where the #define > TCC_WAVE_WAVEGEN_NPWM expresion for this parameter is, in order to validate > the value. The idea is to implement as many features as possible on the > pwm.c. Do you know any source of documentation for this driver Thank you > for your understanding :) > > Best, > Ilias > > [1]https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/pwm.c#L139 > [i] /* select the waveform generation mode -> normal PWM, wave is an int > variable*/ > _tcc(dev)->WAVE.reg = wave; > > 2017-01-23 8:53 GMT+01:00 Peter Kietzmann <peter.kietzm...@haw-hamburg.de>: > >> Hi Ilias, >> >> the periph_conf.h file should be the only one that you need to adapt. I >> didn't look it up but it might be that you need to make use of different >> PWM devices (TCC0 and TCC1) if you different periods and stuff. There is >> no need to adopt the loop in the driver. If you only want one channel >> per device, you can use this macro >> >> https://github.com/RIOT-OS/RIOT/blob/master/boards/ >> samr21-xpro/include/periph_conf.h#L140 >> >> and simply define one channel. Looking at the driver shows that >> TCC_WAVE_WAVEGEN_NPWM is not configurable: >> >> https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/pwm.c#L139 . >> >> Until now the "normal PWM mode" did suffice our needs. If you want that >> feature you should open a PR for that. >> >> Best >> Peter >> >> >> Am 20.01.2017 um 19:08 schrieb Ilias Seitanidis: >>> Dear all, >>> >>> I am trying to understand Riot by porting examples from Atmel >> Studio(SAMR21 >>> board) to Riot( hopefully when I finish it I will upload it as a full >>> example of Riot with threads, GPIOs, PWM, GNRC and what ever will come up >>> on the way). Currently, I am trying to produce a waveform in an >> oscilosope, >>> I read the [1], [2], [3]. However, I would like to use only pins PA18, >>> PA19, BUT for each pin to set different period, waveform generation mode. >>> The first step I suppose is to define as TCC0 and TCC1 the pin PA18 and >>> PA19 only respectively[3]? or just use it as it is and in [2] instead of >>> having a loop for each channel, to write seperately the configuration for >>> it? I will need every possible help( i.e. where can I find the >>> TCC_WAVE_WAVEGEN_NPWM >>> value). >>> Thank you in advance! >>> >>> Best regards, >>> Ilias >>> >>> [1] https://github.com/RIOT-OS/RIOT/blob/master/tests/periph_pwm/main.c >>> [2] https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/pwm.c >>> [3] >>> https://github.com/RIOT-OS/RIOT/blob/master/boards/ >> samr21-xpro/include/periph_conf.h >>> >>> >>> >>> ___ >>> 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 > -- 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
Re: [riot-devel] PWM Driver
Hi Ilias, the periph_conf.h file should be the only one that you need to adapt. I didn't look it up but it might be that you need to make use of different PWM devices (TCC0 and TCC1) if you different periods and stuff. There is no need to adopt the loop in the driver. If you only want one channel per device, you can use this macro https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/include/periph_conf.h#L140 and simply define one channel. Looking at the driver shows that TCC_WAVE_WAVEGEN_NPWM is not configurable: https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/pwm.c#L139 . Until now the "normal PWM mode" did suffice our needs. If you want that feature you should open a PR for that. Best Peter Am 20.01.2017 um 19:08 schrieb Ilias Seitanidis: > Dear all, > > I am trying to understand Riot by porting examples from Atmel Studio(SAMR21 > board) to Riot( hopefully when I finish it I will upload it as a full > example of Riot with threads, GPIOs, PWM, GNRC and what ever will come up > on the way). Currently, I am trying to produce a waveform in an oscilosope, > I read the [1], [2], [3]. However, I would like to use only pins PA18, > PA19, BUT for each pin to set different period, waveform generation mode. > The first step I suppose is to define as TCC0 and TCC1 the pin PA18 and > PA19 only respectively[3]? or just use it as it is and in [2] instead of > having a loop for each channel, to write seperately the configuration for > it? I will need every possible help( i.e. where can I find the > TCC_WAVE_WAVEGEN_NPWM > value). > Thank you in advance! > > Best regards, > Ilias > > [1] https://github.com/RIOT-OS/RIOT/blob/master/tests/periph_pwm/main.c > [2] https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/pwm.c > [3] > https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/include/periph_conf.h > > > > ___ > 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
Re: [riot-devel] [riot-maintainer] Release 2017.01 status
Dear RIOTers, Feature Freeze was announced for today and since my last mail on Tuesday there was great progress: *merged 72 pull requests, 53 of which were marked for this milestone *closed 16 issues, 5 of which were marked for this milestone. However, looking at the list of open pull requests it appears that some great features were close before but not merged yet. Thus I'd like to give them a chance and postpone Feature Freeze. *Postponed Feature Freeze: Tuesday, January 24. Even though new features weren't freezed yet, I'd like to motivate working on / reviewing existing issues and pull requests, i.e. anything concerning SPI rework https://github.com/RIOT-OS/RIOT/pull/4780 Storage https://github.com/RIOT-OS/RIOT/pull/6031 https://github.com/RIOT-OS/RIOT/pull/5616 MIPS https://github.com/RIOT-OS/RIOT/pull/6060 https://github.com/RIOT-OS/RIOT/pull/6066 https://github.com/RIOT-OS/RIOT/pull/6092 Sock API https://github.com/RIOT-OS/RIOT/pull/5937 https://github.com/RIOT-OS/RIOT/pull/5938 https://github.com/RIOT-OS/RIOT/pull/6004 https://github.com/RIOT-OS/RIOT/pull/6012 https://github.com/RIOT-OS/RIOT/pull/6117 https://github.com/RIOT-OS/RIOT/pull/6372 ZEP https://github.com/RIOT-OS/RIOT/pull/6121 Topics labeled "bug" https://github.com/RIOT-OS/RIOT/pulls?q=is%3Aopen+is%3Apr+label%3Abug Regards Peter Am 17.01.2017 um 09:59 schrieb Peter Kietzmann: > Dear RIOTers, > > we are actively working for the upcoming 2017.01 release > and since last week we already > > *merged 59 pull requests, 40 of which were marked for this milestone > *closed 31 issues, 13 of which were marked for this milestone. > > This is great progress in my opinion! But we also opened a couple of new > topics. Currently there are still 128 pull requests and 112 open issues > marked for this release. I'd like to motivate all of you developers, > maintainers, authors, and assignees to keep track of pull requests and > issues where you're involved. Please get your code up to date, help > reviewing and testing and move the release milestone for topics that > won't make it this time. Our planned schedule is > > *Feature Freeze: Friday, January 20 > *Expected Release date: Friday, January 27. > > I will silently postpone each pull request/issue that doesn't show any > progress until feature freeze. > > Best regards > Peter > ___ > Maintainer mailing list > maintai...@riot-os.org > https://lists.riot-os.org/mailman/listinfo/maintainer > -- 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
[riot-devel] Release 2017.01 status
Dear RIOTers, we are actively working for the upcoming 2017.01 release and since last week we already *merged 59 pull requests, 40 of which were marked for this milestone *closed 31 issues, 13 of which were marked for this milestone. This is great progress in my opinion! But we also opened a couple of new topics. Currently there are still 128 pull requests and 112 open issues marked for this release. I'd like to motivate all of you developers, maintainers, authors, and assignees to keep track of pull requests and issues where you're involved. Please get your code up to date, help reviewing and testing and move the release milestone for topics that won't make it this time. Our planned schedule is *Feature Freeze: Friday, January 20 *Expected Release date: Friday, January 27. I will silently postpone each pull request/issue that doesn't show any progress until feature freeze. Best regards Peter ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] CC1200 Sub-GHz Transceiver
Hi, @Baptiste: How did the CC1350 get into this round :-)? Is it similar to the other mentioned radios? In any way, I would be pretty happy to see support for that radio in RIOT. It would enhance the current SensorTag support significantly. @Anon: I have no idea about the differences between CC1101 and CC1200 (and CC1350). Whenever possible we try to avoid code duplication so if you think it's easily 'possible' so extend the CC1101 driver, you should go that way. If that means `#ifndef CC1200` in every second code line, you should probably avoid it and write a standalone driver. Cheers Peter Am 10.01.2017 um 19:14 schrieb Baptiste Clenet: > Anon, you should try to work on CC1350 which is the last one ;-) > > Cheers, > > 2017-01-10 11:32 GMT+01:00 Anon Mall <anon.m...@gt-arc.com>: >> Dear all, >> >> thanks for the reply >> >> >> >> @Peter: I will then put it into the driver section, as you have suggested. >> >> >> >> @Antonio: Thanks for the offer. I will surely take you up on that. >> >> >> >> Also a small question concerning the location of the driver. The CC1200 uses >> >> the same command strobes on the SPI like the CC1101. As there is already a >> >> CC110X driver implemented, should the CC1200 be added to that implementation >> >> and transceiver specific code just capsuled as defines or would a standalone >> driver >> >> make more sense? >> >> >> >> Cheers, >> >> Anon >> >> >> >>> Hello Anon! >> >>> >> >>> If you need help (as in devices with the CC1200 on board) drop me a line >> >>> >> >>> Cheers, >> >>> >> >>> --Antonio >> >>> >> >>> >> >>>> Hi Anon, >> >>>> >> >>>> it seems no one is working on this driver so please go ahead :-)! As >> >>>> long as the CC1200 is not part of the CC2538 I agree with you the the >> >>>> driver should be implemented stand alone. Compare e.g. the at86rf2xx >> >>>> driver. >> >>>> >> >>>> Best >> >>>> Peter >> >>>> >> >>>> Am 21.12.2016 um 18:41 schrieb Anon Mall: >> >>>>> Hi all, >> >>>>> I wanted to ask if someone is currently working on a driver for the >> >>>> CC1200 transceiver? Otherwise I would try my luck. >> >>>>> Also in the readme of the Remote is noted, that the CC1200 is a >> >>>>> matter >> >>>> of the CC2538 base. As the transceiver is not included in the CC2538, >> >>>> I would think that the driver should rather be implemented stand alone >> >>>> or am I mistaken? >> >>>>> >> >>>>> Cheers and happy Holidays, >> >>>>> Anon >> >>> >> >> >> >> >> ___ >> 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
Re: [riot-devel] RIOT and Peripherals
Hi Ilias, I don't know details about the PWM clock generation on this microcontroller *but* "TCC_CLOCK_PRESCALER_DIV1" means "no division of the source clock". That will be the case when (compare [1]): CLOCK_CORECLOCK / (freq * res) = 1 . Calling the function like this: get_prescaler(1, ), returns 0 (same value as TCC_CTRLA_PRESCALER_DIV1_Val) resulting in no prescaler selection here [2]. That's why I assume the feature you want should be already there, or am I mistaken? In case you convince me of the contrary :-), there's nothing against improving the peripheral driver implementation. Best regards Peter [1] https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/pwm.c#L101 [2] https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/pwm.c#L137 Am 12.12.2016 um 14:41 schrieb Ilias Seitanidis: > Dear all, > > I would like a small explanation of the value > "TCC_CTRLA_PRESCALER_DIV*_VAL" in line 84 in [1], is it possible to add the > equivelant value of the "TC_CLOCK_PRESCALER_DIV1"(as found from the atmel > studio). > > Thank you in advance! > > Best regards, > > Ilias > > [1] https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/pwm.c . > > > > ___ > 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
Re: [riot-devel] Looking for Information about mature RIOT platforms
Hi John, welcome to RIOT! Have a look at these devices: Atmel samr21-xpro https://github.com/RIOT-OS/RIOT/wiki/Board%3A-SAMR21-xpro Phytec phyWAVE https://github.com/RIOT-OS/RIOT/wiki/Board%3A-Phytec-phyWAVE-KW22 Remote Revision B (relatively new in RIOT) https://github.com/Zolertia/Resources/wiki/RE-Mote Also consider the fit iot-lab which consists of custom "iotlab-m3" nodes with default components on it: https://www.iot-lab.info/ As you mentioned the STM32, we support plenty discovery and nucleo boards which you would need to equip with an external transceiver like e.g. the openlabs. Best regards Peter Am 16.11.2016 um 12:46 schrieb John Peter Norair: > Hello: > > I’m trying to find what is the most mature platform/mcu/board for RIOT, so > that I can study it. Then I will build a few apps for this board and > determine the value/benefit of RIOT. I have a lot of IoT hardware, but none > of it seems to be well supported by RIOT at this point. > > Assuming there is value/benefit, I have an IoT stack (OpenTag/DASH7) that > works with STM32L0, L1, and recently TI CC13xx, so then I need to assess the > feasibility of porting RIOT to my stack. > > About me: > haystacktechnologies.com <http://haystacktechnologies.com/> > indigresso.com <http://indigresso.com/> > OpenTag - Wikipedia <https://en.wikipedia.org/wiki/OpenTag> > DASH7 - Wikipedia <https://en.wikipedia.org/wiki/DASH7> > > Best regards, > JPN > > > > ___ > 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
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Nov 2, 2016 2pm - 3pm (RIOT Events)
Hi, I assume it was you who put the topics on the agenda? Simply remove them and most likely the meeting won't take place (in case no on else adds a point). Elsewise I can open a PlaceCam session, even if I'm busy as well and would prefer not to have this meeting. Best Peter Am 01.11.2016 um 15:04 schrieb Martine Lenders: > Hi, > I'm currently deep into release management so can somebody else please take > the reins on this one? > > Cheers, > Martine > > 2016-11-01 14:00 GMT+01:00 Google Calendar <calendar-notificat...@google.com >> : > >> more details » >> <https://www.google.com/calendar/event?action=VIEW=Z2tqN2ZyY3NmdnEzOWFkbDdmMXJkb2hrbzhfMjAxNjExMDJUMTMwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn> >> Biweekly virtual meeting >> Developer discussions that will only happen if a proposed agenda exists. >> Some instructions and a link to the agenda can be found in the RIOT wiki ( >> https://github.com/RIOT-OS/RIOT/wiki/Meetings >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FRIOT-OS%2FRIOT%2Fwiki%2FMeetings=D=2=AFQjCNHYQc4d8bSOfagdkeUWSyK-8tas8Q>). >> Remote participation will be provided. >> *When* >> Wed Nov 2, 2016 2pm – 3pm Berlin >> >> *Calendar* >> RIOT Events >> >> *Who* >> • >> Ludwig Ortmann - creator >> >> Invitation from Google Calendar <https://www.google.com/calendar/> >> >> You are receiving this email at the account peterschme...@gmail.com >> because you are subscribed for notifications on calendar RIOT Events. >> >> To stop receiving these emails, please log in to https://www.google.com/ >> calendar/ and change your notification settings for this calendar. >> >> Forwarding this invitation could allow any recipient to modify your RSVP >> response. Learn More >> <https://support.google.com/calendar/answer/37135#forwarding>. >> >> ___ >> 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 > -- 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
Re: [riot-devel] Soil Moisture Sensor
Hi Alessandro, sorry it's been a while and I don't really remember how we organized branches. However, looking at the tutorial one can see that the "watrli" branch is checked out which is the branch I already pointed to [1]. In there, you actually find "SAMPLE_0_V_OFFSET" and "SAMPLE_REF_V": https://github.com/watr-li/RIOT/blob/watrli/boards/samr21-xpro/include ./periph_conf.h#L273 Best Peter [1] https://github.com/watr-li/RIOT/tree/watrli Am 13.10.2016 um 13:34 schrieb ALESSANDRO NICOLI: > Sorry Peter, i refer to the code used in the tutorial that i linked before, > contained in the "periph_conf.h" file. > > (http://watr.li/Sensing-moisture.html). > > > > *best regards, * > *Alessandro* > > 2016-10-13 13:21 GMT+02:00 <devel-requ...@riot-os.org>: > >> Send devel mailing list submissions to >> devel@riot-os.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.riot-os.org/mailman/listinfo/devel >> or, via email, send a message with subject or body 'help' to >> devel-requ...@riot-os.org >> >> You can reach the person managing the list at >> devel-ow...@riot-os.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of devel digest..." >> >> >> Today's Topics: >> >> 1. Re: Soil Moisture Sensor (Peter Kietzmann) >> >> >> -- >> >> Message: 1 >> Date: Thu, 13 Oct 2016 13:21:16 +0200 >> From: Peter Kietzmann <peter.kietzm...@haw-hamburg.de> >> To: RIOT OS kernel developers <devel@riot-os.org> >> Subject: Re: [riot-devel] Soil Moisture Sensor >> Message-ID: <19466325-a963-85d0-ce11-7a63103bc...@haw-hamburg.de> >> Content-Type: text/plain; charset="utf-8" >> >> Hi, >> >> I don't know what you mean by "this" code but have a look at [1] even if >> it's a bit outdated. >> >> Cheers >> Peter >> >> [1] https://github.com/watr-li/RIOT/tree/watrli >> >> Am 13.10.2016 um 13:06 schrieb ALESSANDRO NICOLI: >>> Yes, indeed i found an ADC implementation in the "Watr.li sensing >> moisture" >>> @ >>> >>> http://watr.li/Sensing-moisture.html >>> >>> I tried to set up the ADC as explained in the guide, but in this code >> there >>> are not these parameters : >>> SAMPLE_0_V_OFFSET >>> SAMPLE_REF_V >>> >>> So, i don't know where i should act to calibrate my ADC. >>> >>> *best regards, * >>> *Alessandro* >>> >>> 2016-10-13 11:47 GMT+02:00 <devel-requ...@riot-os.org>: >>> >>>> Send devel mailing list submissions to >>>> devel@riot-os.org >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://lists.riot-os.org/mailman/listinfo/devel >>>> or, via email, send a message with subject or body 'help' to >>>> devel-requ...@riot-os.org >>>> >>>> You can reach the person managing the list at >>>> devel-ow...@riot-os.org >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of devel digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>>1. Re: Soil Moisture Sensor (Peter Kietzmann) >>>>2. Re: Soil Moisture Sensor (Akshay Mishra) >>>> >>>> >>>> -- >>>> >>>> Message: 1 >>>> Date: Thu, 13 Oct 2016 11:38:24 +0200 >>>> From: Peter Kietzmann <peter.kietzm...@haw-hamburg.de> >>>> To: RIOT OS kernel developers <devel@riot-os.org> >>>> Subject: Re: [riot-devel] Soil Moisture Sensor >>>> Message-ID: <e9a3b231-e2cb-bb08-83eb-9254262a3...@haw-hamburg.de> >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> Hi, >>>> >>>> Am 13.10.2016 um 11:17 schrieb ALESSANDRO NICOLI: >>>>> Hi Peter, >>>>> I've used the default parameters for ADC_0, that are described in the >>>>> attached (RIOT/boards/samr21-xpro/include/periph_conf.h). >>>> >>>> okay but that configuration is not in RIOT master :-) cause there is no >>>> official
Re: [riot-devel] Soil Moisture Sensor
Hi, I don't know what you mean by "this" code but have a look at [1] even if it's a bit outdated. Cheers Peter [1] https://github.com/watr-li/RIOT/tree/watrli Am 13.10.2016 um 13:06 schrieb ALESSANDRO NICOLI: > Yes, indeed i found an ADC implementation in the "Watr.li sensing moisture" > @ > > http://watr.li/Sensing-moisture.html > > I tried to set up the ADC as explained in the guide, but in this code there > are not these parameters : > SAMPLE_0_V_OFFSET > SAMPLE_REF_V > > So, i don't know where i should act to calibrate my ADC. > > *best regards, * > *Alessandro* > > 2016-10-13 11:47 GMT+02:00 <devel-requ...@riot-os.org>: > >> Send devel mailing list submissions to >> devel@riot-os.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.riot-os.org/mailman/listinfo/devel >> or, via email, send a message with subject or body 'help' to >> devel-requ...@riot-os.org >> >> You can reach the person managing the list at >> devel-ow...@riot-os.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of devel digest..." >> >> >> Today's Topics: >> >>1. Re: Soil Moisture Sensor (Peter Kietzmann) >>2. Re: Soil Moisture Sensor (Akshay Mishra) >> >> >> -- >> >> Message: 1 >> Date: Thu, 13 Oct 2016 11:38:24 +0200 >> From: Peter Kietzmann <peter.kietzm...@haw-hamburg.de> >> To: RIOT OS kernel developers <devel@riot-os.org> >> Subject: Re: [riot-devel] Soil Moisture Sensor >> Message-ID: <e9a3b231-e2cb-bb08-83eb-9254262a3...@haw-hamburg.de> >> Content-Type: text/plain; charset="utf-8" >> >> Hi, >> >> Am 13.10.2016 um 11:17 schrieb ALESSANDRO NICOLI: >>> Hi Peter, >>> I've used the default parameters for ADC_0, that are described in the >>> attached (RIOT/boards/samr21-xpro/include/periph_conf.h). >> >> okay but that configuration is not in RIOT master :-) cause there is no >> official ADC driver until now. >> >>> >>> Hi Akshay, >>> Yes, i tried to let the sensor floats in air, with a 10bit precision, and >>> it gives me back a plausible value (less than 40/1024). >>> Than i tried to put it in mineral water, and it replied with a value next >>> to 1000/1024, that it seems to be correct. >> >> It seems the ADC actually works correctly and your issue is about the >> behaviour of the sensor in soil? >> >>> >>> Only in the soil (where it should works correctly) it gives back a >> no-sense >>> value...and i don't know why. >>> >> >> Did you play around with the density of the soil and -of course- water >> level of the plant? >> >> Best >> Peter >> >>> >>> thanks a lot! >>> >>> *best regards, * >>> *Alessandro* >>> >>> 2016-10-12 9:48 GMT+02:00 <devel-requ...@riot-os.org>: >>> >>>> Send devel mailing list submissions to >>>> devel@riot-os.org >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://lists.riot-os.org/mailman/listinfo/devel >>>> or, via email, send a message with subject or body 'help' to >>>> devel-requ...@riot-os.org >>>> >>>> You can reach the person managing the list at >>>> devel-ow...@riot-os.org >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of devel digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>>1. Soil Moisture Sensor (ALESSANDRO NICOLI) >>>>2. Re: Soil Moisture Sensor (Peter Kietzmann) >>>>3. Re: Soil Moisture Sensor (Akshay Mishra) >>>>4. I2C driver function to read a register with 16 bits address >>>> (Kees Bakker) >>>>5. Re: alternative socket-api (Kaspar Schleiser) >>>>6. Re: I2C driver function to read a register with 16 bits >>>> address (Hauke Petersen) >>>>7. Coding conventions amendment (Oleg Hahm) >>>> >>>> >>>> -- >>>> >>>> Message: 1 >>>> Date: Tue, 11 Oct 2016 16:32:22 +0200 &
Re: [riot-devel] Soil Moisture Sensor
Hi, Am 13.10.2016 um 11:17 schrieb ALESSANDRO NICOLI: > Hi Peter, > I've used the default parameters for ADC_0, that are described in the > attached (RIOT/boards/samr21-xpro/include/periph_conf.h). okay but that configuration is not in RIOT master :-) cause there is no official ADC driver until now. > > Hi Akshay, > Yes, i tried to let the sensor floats in air, with a 10bit precision, and > it gives me back a plausible value (less than 40/1024). > Than i tried to put it in mineral water, and it replied with a value next > to 1000/1024, that it seems to be correct. It seems the ADC actually works correctly and your issue is about the behaviour of the sensor in soil? > > Only in the soil (where it should works correctly) it gives back a no-sense > value...and i don't know why. > Did you play around with the density of the soil and -of course- water level of the plant? Best Peter > > thanks a lot! > > *best regards, * > *Alessandro* > > 2016-10-12 9:48 GMT+02:00 <devel-requ...@riot-os.org>: > >> Send devel mailing list submissions to >> devel@riot-os.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.riot-os.org/mailman/listinfo/devel >> or, via email, send a message with subject or body 'help' to >> devel-requ...@riot-os.org >> >> You can reach the person managing the list at >> devel-ow...@riot-os.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of devel digest..." >> >> >> Today's Topics: >> >>1. Soil Moisture Sensor (ALESSANDRO NICOLI) >>2. Re: Soil Moisture Sensor (Peter Kietzmann) >>3. Re: Soil Moisture Sensor (Akshay Mishra) >>4. I2C driver function to read a register with 16 bits address >> (Kees Bakker) >>5. Re: alternative socket-api (Kaspar Schleiser) >>6. Re: I2C driver function to read a register with 16 bits >> address (Hauke Petersen) >>7. Coding conventions amendment (Oleg Hahm) >> >> >> -- >> >> Message: 1 >> Date: Tue, 11 Oct 2016 16:32:22 +0200 >> From: ALESSANDRO NICOLI <alessandro.nic...@studenti.unipr.it> >> To: RIoT Dev List <devel@riot-os.org> >> Subject: [riot-devel] Soil Moisture Sensor >> Message-ID: >> > ftkog6iw...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hi all, >> I'm trying to use a Soil moisture sensor with a Samr21-xpro and RIOT os. >> The sensor used is as follows : >> >> https://www.seeedstudio.com/Grove-Moisture-Sensor-p-955.html >> >> >> I have *4 soil jars (with different moisture concentrations)* that i'm >> gonna use for testing, i've already tried to get moisture values with >> *Arduino >> Uno* and they seem to be acceptable. >> *For both, i used the built in ADC with 10 bits of resolution.* >> >> But when i try to use the samr21, it gets me always 330 as value (10 bits >> ADC). >> For the SAMR21* i used the default parameters for ADC_0*. >> >> There is a way to rectify the readings, or some kind of calibration to do? >> >> >> Thanks a lot, >> *best regards, * >> *Alessandro* >> -- next part -- >> An HTML attachment was scrubbed... >> URL: <http://lists.riot-os.org/pipermail/devel/attachments/ >> 20161011/89c17d33/attachment-0001.html> >> >> -- >> >> Message: 2 >> Date: Tue, 11 Oct 2016 16:46:21 +0200 >> From: Peter Kietzmann <peter.kietzm...@haw-hamburg.de> >> To: RIOT OS kernel developers <devel@riot-os.org> >> Subject: Re: [riot-devel] Soil Moisture Sensor >> Message-ID: <f56b24b5-c67b-fac8-8321-0ced51274...@haw-hamburg.de> >> Content-Type: text/plain; charset="utf-8" >> >> Hi Alessandro, >> >> what are the default values for ADC_0 on the samr21-xpro board and which >> driver did you use? >> >> Best >> Peter >> >> Am 11.10.2016 um 16:32 schrieb ALESSANDRO NICOLI: >>> Hi all, >>> I'm trying to use a Soil moisture sensor with a Samr21-xpro and RIOT os. >>> The sensor used is as follows : >>> >>> https://www.seeedstudio.com/Grove-Moisture-Sensor-p-955.html >>> >>> >>> I have *4 soil jars (with different moisture concentrations)* that i'm >>> gonna use for testing, i've already tried to get moisture values with
Re: [riot-devel] RIOT and Peripherals
Hi, if you are on a samr21-xpro the pwm.c driver implementation can be found here: https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/pwm.c . The pin configurations on an Atmel samr21-xpro board are defined here: https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/include/periph_conf.h#L146 . As Laurent already said, an example lies here: https://github.com/RIOT-OS/RIOT/tree/master/tests/periph_pwm . I didn't really understand the question about the "variable dev" but probably the example will explain everything. There is no *need* to open a separate thread for the PIR but probably you want to. Did you already have a look at the PIR example under "tests": https://github.com/RIOT-OS/RIOT/tree/master/tests/driver_pir ? Best Peter Am 07.10.2016 um 12:58 schrieb Ilias Seitanidis: > Hi, > Thanks Peter, The idea is if the pir detects something, then the speaker > will produce a sound, for example for 2 minutes, then a udp message will be > sent. I have some questions(as a newbie :) ) : > - I didn't find the pwm.c file, maybe someone erased it during a clean up > operation? > -Is there any example of using the pwm lib? (mostly on the sequence of the > function call) > - There is a variable dev that points to the speaker device(as mentioned > this lib was used with virtual devices), is there a specific integer for > one device or it doesn't matter? ( > void pwm_set(pwm_t dev, uint8_t channel, uint16_t value); > ) > > -For the pir Library is it mandatory to register as a thread(?), it will be > my main thread. > > I've seen the project of Mr. Nhat Pham, but the main idea is to use the > RIOT OS as it is. > Thank you in advance! > > Best regards, > Ilias > > > > ___ > 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
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Oct 5, 2016 2pm - 3pm (RIOT Events)
Hi, you can join via PlaceCam (as usual) under: http://placecam.de/call.php?c=kWtmE~M0jTbKGFQSGnUBLtC.xAbWgTythbQbBMVXUvs- Best Peter Am 04.10.2016 um 14:59 schrieb Martine Lenders: > Dear RIOTers, > as the Google Calendar reminds is: tomorrow is our "biweekly" virtual > meeting. I started an agenda at [1]. Feel free to add to it if you think > something needs to be discussed. > > Cheers, > Martine > > [1] http://www.yourpart.eu/p/riot-2016-10-05-virtual-meeting > > 2016-10-04 14:00 GMT+02:00 Google Calendar <calendar-notificat...@google.com >> : > >> more details » >> <https://www.google.com/calendar/event?action=VIEW=Z2tqN2ZyY3NmdnEzOWFkbDdmMXJkb2hrbzhfMjAxNjEwMDVUMTIwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn> >> Biweekly virtual meeting >> Developer discussions that will only happen if a proposed agenda exists. >> Some instructions and a link to the agenda can be found in the RIOT wiki ( >> https://github.com/RIOT-OS/RIOT/wiki/Meetings >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FRIOT-OS%2FRIOT%2Fwiki%2FMeetings=D=2=AFQjCNHYQc4d8bSOfagdkeUWSyK-8tas8Q>). >> Remote participation will be provided. >> *When* >> Wed Oct 5, 2016 2pm – 3pm Berlin >> >> *Calendar* >> RIOT Events >> >> *Who* >> • >> Ludwig Ortmann - creator >> >> Invitation from Google Calendar <https://www.google.com/calendar/> >> >> You are receiving this email at the account peterschme...@gmail.com >> because you are subscribed for notifications on calendar RIOT Events. >> >> To stop receiving these emails, please log in to https://www.google.com/ >> calendar/ and change your notification settings for this calendar. >> >> Forwarding this invitation could allow any recipient to modify your RSVP >> response. Learn More >> <https://support.google.com/calendar/answer/37135#forwarding>. >> >> ___ >> 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 > -- 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
Re: [riot-devel] RIOT and Peripherals
Hi Ilias, what exactly are you looking for? You can find all supported sensors (and actuators) here: https://github.com/RIOT-OS/RIOT/tree/master/drivers . Concerning the speaker you might be interested in the PWM API? https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/periph/pwm.h Best regards Peter Am 30.09.2016 um 15:06 schrieb Ilias Seitanidis: > Hello Rioters, > I am using a samr21 and I want to connect some peripheral devices > (one motion sensor, its connected to the pin_17 and if there is motion I > will get an 1 as input, and a speaker, I will create a frequence with the > osciloscope and then send it to the speaker). Is there any library which > takes care of these staff?? Any example or any help overall will be > appreciated. Thank you in advance! > > Your Faithfully, > Ilias seitanidis > > > > ___ > 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
Re: [riot-devel] Netdev2 State changes
Hi Alex, sorry for the big delay. NETOPT_ACK_REQ, NETOPT_AUTOACK as well as NETOPT_RETRANS, NETOPT_CSMA or NETOPT_CSMA_RETRIES are not meant to be called each time before a frame-transmission but just to set the option on the device/driver. That means -if set- the driver will set the ACK REQ bit automatically for each frame it sends. Best Peter Am 14.09.2016 um 10:25 schrieb Alexander Aring: Hi, On 09/13/2016 11:31 PM, Peter Kietzmann wrote: Hi Alex, It confuses me a little bit here, does such netdev2 option exists to disable auto-acknowledgement or not? For me it should always depends on the acknowledgement-request bit in fc field. have a look at this PR: https://github.com/RIOT-OS/RIOT/pull/5297 . I agree with you that (except in promiscuous sniffer mode) the ACK of a receiver should depend on the ACK request field of the received frame which will be handled by the hardware (in case AACK is not disabled). IIRC "NETOPT_AUTOACK" once was meant to handle the ACK request of a transmitter but the name was a bit misleading. okay, but why does this setting reach the driver layer, or does it not? The driver(or in case of at86rf2xx the hardware) should check if the acknowledgement-request bit is set or not and this _per_ _frame_ and prepare transceiver to do ARET handling if it's set (maybe inside the transmit callback of driver layer). Or will the NETOPT_ACK_REQ option called each time before transmit to signal the fc acknowledgement-request bit? This confuse me then with the at86rf2xx hardware which will do ARET handling or not at hardware side by checking fc acknowledgement-request bit setting in fc. Such setting should only reach the mac layer, which controls then the frame control field generation of 802.15.4 dataframes, in my opinion. The transceiver should has some per frame decision if doing ARET or not ARET handling before transmit, or do nothing e.g. at86rf2xx because the hardware does that check. (sniffer) I think our handling in Linux is to let ARET enabled but disable AACK handling. AACK handling without address filtering will occur that you ack mostly every frame which will arrived. :-) - Alex ___ 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
Re: [riot-devel] Accelerometer on stm32f4-discovery
Hi Joakim, as it seems no one used the this sensor on the stm32f4discovery so far, even if it actually is a popular platform imo. The LIS3DH has been used on the mulle board or via external connections. I don't know about the differences of both sensors, but I assume the driver needs to be adapted. If you have any particular questions about that, just ask! Best regards Peter Am 06.09.2016 um 09:52 schrieb Joakim Borgh: Hello, I am currently looking into reading data from the accelerometer LIS3DSH which is on the board stm32f4-discovery. Since it is such a popular board I was hoping someone else had done this already in RIOT but as far as I can see the "closest" driver is LIS3DH, which is not directly compatible. So my question is: Does anyone have experience with this accelerometer and this board? Did you use the LIS3DH driver which is in RIOT or how did you go about it? Any hints/pointers/ideas are appreciated. Thanks in advance, Joakim Borgh ___ 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
Re: [riot-devel] Netdev2 State changes
Hi Neo, there might be code snippets that actively wait for a state transition, but AFAIK not in the netdev part any more. Then there is interrupt handling which signals tx/rx start/end points to the upper layer. Of course you can't implement anything once it's not available on the device. The great thing about netdev is that it's pretty generic and you don't *need* to implement every function/message/interrupt/state change/whatsoever to get the device running. But looking at the data sheet I stumbled upon the RFSTATE register which signals the following (useful) sates: 111 = RTSEL2 110 = RTSEL1 101 = RX 100 = TX 011 = CALVCO 010 = SLEEP 001 = CALFIL 000 = RESET In addition there is the INTSTAT register which seems somehow similar to the Atmel radio. Where exactly did you stuck? Could you be a more precise? Best Peter Am 11.09.2016 um 17:38 schrieb Neo: Dear radio module driver developers, as far as I have seen, the netdev2 architecture reads several time the state of the radio chip to synchronize with the hardware dependent part of the driver (state changes). This is wonderful if the radio chip has a register which shows the actual state of the radio-modul - like the TRX_STATUS register inside of the Atmel chips. What could be done, if the radio chip doesn't have such a register or shows only rudiment state informations to synchronize/trigger the netdev2 part of the driver. The MRF24J40 from Microchip for example shows only the following useful state information: RX SLEEP RESET Transmission is done in the RX state without any changes, just trigger the transission (TXNCON-Reg./TXNTRIG-Bit). Thanks a lot! Regards, Neo ___ 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
Re: [riot-devel] MRF24J40 radio module driver
Hi Neo, if I see it correctly, the procedure is as follows: gnrc_networking uses the the gnrc_ipv6 module which automatically pulls in it's dependencies. This is, among others, gnrc_ipv6_netif. https://github.com/RIOT-OS/RIOT/blob/master/Makefile.dep#L280 Once this was defined, auto_init will call the "init by netif device" function. https://github.com/RIOT-OS/RIOT/blob/master/sys/auto_init/auto_init.c#L227 This function will set the net option "NETOPT_SRC_LEN" to 8 Byte, which is the length for long hardware addresses. https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/ipv6/netif/gnrc_ipv6_netif.c#L833 The at86rf2xx driver does not implement this option itself and passes it to the netdev2_ieee802154 module. https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L580 In case netopt is "NETOPT_SRC_LEN" and the value is "IEEE802154_LONG_ADDRESS_LEN" (which is defined as 8U), this module sets the "NETDEV2_IEEE802154_SRC_MODE_LONG" flag. https://github.com/RIOT-OS/RIOT/blob/master/drivers/netdev2_ieee802154/netdev2_ieee802154.c#L173 Didn't check it until know. Hope it already helped. Best Peter PS: Independent from upper layers and the flag field, the driver itself sets a short and a long hardware address on initialization. https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx.c#L90 Am 04.09.2016 um 18:10 schrieb Neo: Hello alltogether, I'm using actually the AT86RF2XX driver as a template for the development of the MRF24J40 radio module driver. At the moment I'm comparing the netdev2 flags of the AT86RF2XX driver and the MRF24J40 when using the gnrc_networking example and I see a difference. If I take a look onto the AT86RF2XX setup the flags show me a value of 0x5164 whereas myone shows 0x5160. I can't find the any place where the missing flag 0x0004 is set in the AT86RF2XX driver. In the ../drivers/include/net/netdev2/ieee80154.h file the define for this flag is NETDEV2_IEEE802154_SRC_MODE_LONG meaning the usage of long source addresses. Can anyone tell me where the driver is set up to use long source addresses? Thanks a lot! Best regards, Neo ___ 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
Re: [riot-devel] gnrc_networking packets incoming
Hi Alessandro, gnrc_networking registers the "pkt_dump" module as UDP server. https://github.com/RIOT-OS/RIOT/blob/master/examples/gnrc_networking/udp.c#L108 You can find the implementation here: https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/pktdump/gnrc_pktdump.c . Just write your own minimal server and register its pid instead of the pkt_dump module. You should additionally remove USEMODULE += gnrc_pktdump from the Makefile. Best Peter Am 27.08.2016 um 16:02 schrieb ALESSANDRO NICOLI: Hi all, In case that i could not use CoAP for request messages, i tried to build on a communication using the "gnrc_networking" code. Obviously the communication works, but where and how can i retrive the payload of the incoming packets? My collector node (SAMR21) has to process the content of the incoming packets from DHT sensor node (this is SAMR21 too). thanks all, *best regards, * *Alessandro* ___ 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
Re: [riot-devel] Netdev2 - Events/Flags wich cause netdev2 to transmit
Hi Neo, Am 01.09.2016 um 01:28 schrieb Neo: Hello RIOT radio chip driver developers, my radio module driver (work in progress) transmits Acknowledgement-Frames without forcing it to do anything. Can you rephrase please? 802.15.4 ACK frames are generated by the hardware and not triggered by the network stack (they where sent by the radio after a valid 802.15.4 frame was received in which the ACK request bit is set). You can enable/disable this behaviour in the RXMCR register of the mrf24j40. The netdev2 provides an interface to set options (netopts). The NETOPT_AUTOACK option should be implemented by your driver to set this option on the device (didn't check your driver until now). https://github.com/RIOT-OS/RIOT/blob/master/sys/include/net/netopt.h#L91 There must be a wrong condition (e.g. event or flags) in the interface between netdev2 and the hardware dependent part of the driver which forces the driver to fill the transmit buffer and send it. Which application code did you use? Some time ago you wondered about additional packets sent by layer 3. When exactly do you observe this packet? Do you have a possibility for sniffing the wireless traffic? E.g. A RasPi plus the mrf24j40 should do it. Can anyone give me a hint where to search for the place where netdev2 is triggered to fill the tx-buffer and send the frame ( I guess an Ack-Frame)? As said, there is not ACK frame transmission triggered by netdev. In a usual configuration, there is the gnrc_netdev2 thread which calls the gnrc_netdev2_ieee802154 _send function. https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/link_layer/netdev2/gnrc_netdev2.c#L146 In there, the 802.15.4 header is prepared and the net device (netdev2) _send function is called https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/link_layer/netdev2/gnrc_netdev2_ieee802154.c#L141 This function is implemented by the device driver and usually results in writing the dara to the radio tx buffer as well as triggering the actual transmission. https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L119 So far, for the moment. Best Peter This are the first bytes inside my transmit buffer which were forced to be send: transmitbuf[0]= 0x1f transmitbuf[1]= 0x41 transmitbuf[2]= 0x98 transmitbuf[3]= 0x0 transmitbuf[4]= 0x23 transmitbuf[5]= 0x0 transmitbuf[6]= 0xff transmitbuf[7]= 0xff transmitbuf[8]= 0x2 transmitbuf[9]= 0x30 transmitbuf[a]= 0x7b transmitbuf[b]= 0x3b transmitbuf[c]= 0x3a transmitbuf[d]= 0x2 transmitbuf[e]= 0x85 transmitbuf[f]= 0x0 e.g. Thanks a lot, Regards, Neo ___ 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
Re: [riot-devel] conn f2f (+ remote) meeting
Mi Martine, no objections from my side. I would like to join virtually. Regards Peter Am 16.08.2016 um 14:12 schrieb Martine Lenders: Hi, are there any objections to have the meeting for the Berlin people at FU and let the rest join via Mumble [1]? If not: please state if you like to join the meeting (physically or virtually) so I can plan for a room if need be or expect you in the virtual room. Cheers, Martine [1] https://wiki.mumble.info/wiki/Main_Page 2016-08-15 16:11 GMT+02:00 Martine Lenders <m.lend...@fu-berlin.de>: Hi, as promised: here is the agenda for the meeting next Wednesday: http://yourpart.eu/p/netapp-api-riot Cheers, Martine 2016-08-11 15:33 GMT+02:00 Martine Lenders <m.lend...@fu-berlin.de>: Hi all, we finally want to discuss the overhaul of conn next week. The meeting will be held on Wednesday next week (August 17th) at 1pm (UTC+0200). Remote participation will be possible, we'll try to find a tool that everyone is comfortable with. I'll provide you with an agenda for the meeting until Monday and post it here. For reference until then (if you want to read through it) there is the discussion in PR 5533, with some rough summary of the discussion so far in [1]. For reference here is Kaspar's sock API, which was also discussed and taken as basis for some of the work in the PR. Cheers, Martine [1] https://github.com/RIOT-OS/RIOT/pull/5533#issuecomment-237865337 [2] https://github.com/kaspar030/sock ___ 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
Re: [riot-devel] MRF24J40 Development - mysterious cyclic transmits
Hi Neo, there might be ICMPv6 related packets that were sent from the IP-layer. Also these packets will cause a TX interrupt in the driver (if enabled). This should be independent from the ACK configuration of the radio. Is is possible you meant that? Did you already upload your code somewhere? Best regards Peter Am 10.08.2016 um 12:33 schrieb Neo: Hello everybody, I'm working at the moment with the gnrc_networking example and even if I do nothing I get cyclic transmit interrupts. For my understanding - if I use a configuration with no acknowledgement and no retries there should be no transfer activity at all. Is this correct? Best regards, Neo ___ 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
Re: [riot-devel] Disable 15.4 Acknowledgements
Hi, NETOPT_ACK_REQ is currently not handled by the at86rf2xx driver but IIRC NETOPT_AUTOACK covers both for that device (didn't check that). Best Peter Am 09.08.2016 um 16:44 schrieb Simon Brummer: Hi Oleg, netopt_enable_t opt = NETOPT_DISABLE; gnrc_netif_get(ifs); gnrc_netapi_set(ifs[0], NETOPT_AUTOACK, 0, , sizeof(opt)); gnrc_netapi_set(ifs[0], NETOPT_ACK_REQ, 0, , sizeof(opt)); Did the trick. So there is a way to disable acknowledgements. Cheers, Simon Am Dienstag, den 09.08.2016, 16:40 +0200 schrieb Oleg Hahm: Hi Simon! On Tue, Aug 09, 2016 at 02:33:56PM +0200, simon wrote: Currently I am testing my TCP implementation between two samr21 Boards and a Raspberry Pi as sniffing Probe in between. My measured network dump contains a few unexpected retransmissions and i am unable to distinguish between retransmissions caused by 15.4 and retransmissions caused by TCP. Is there a way to disable the 15.4 acknowledgement and retransmission mechanism? IIRC auto acknowledgement can currently not be disabled with the at86rf2xx driver, but you can set the retransmissions to zero. You can do this either using the shell: ifconfig 7 set retrans 0 or directly via netapi: gnrc_netapi_set(CCNLRIOT_NETIF, NETOPT_CSMA_RETRIES, 0, 0, sizeof(uint8_t)); Cheers, Oleg ___ 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 -- 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
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hey, I asked @Nordzisko for advice. https://github.com/RIOT-OS/RIOT/issues/5407#issuecomment-237543456 As said, I currently won't find time to study the hardware in detail. But I'm pretty convinced that your problems are about configuring the driver or maybe the device itself. About the jumper cables: They do work :-) but I often had loose connections, broken plugs and also confused connections myself. So just be careful ;-). Best Peter Am 04.08.2016 um 14:11 schrieb Adeel Mohammad Malik: Hi Peter, I tried the branch you referred to. I still face the same issue. My guess is that ATZB-X-233-XPRO is a bit different from ATZB-A-233-XPRO in terms of pin configurations. Unfortunately I do not have a logic analyzer. If cheap jumper cables can be a problem, then this can get a bit hard to troubleshoot. /Adeel -Original Message- From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter Kietzmann Sent: Thursday, August 04, 2016 11:44 AM To: RIOT OS kernel developers Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi Adeel, please note that issue #5407 is about the F3 discovery so the pin configuration might differ. I connected an openlabs transceiver http://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio (basically containing an Atmel AT86RF233) to the stm32f4discovery. This is the configuration that I have used https://github.com/PeterKietzmann/RIOT/tree/stm32f4discovery_add_at86 rf233_config examples/gnrc_networking worked as expected. Could you take that branch, connect your device accordingly and try gnrc_networking again? I currently don't find the time to look into the details of that device but the ATZB-A-233-XPRO basically worked for @Nordziski and from what you describe I have the impression it is a peripheral problem. Do you have a logic analyser to see what is on the SPI bus and the additional pins? I experienced the usage of these cheap jumper cables as a big source of trouble pretty often... Best regards Peter Am 04.08.2016 um 10:17 schrieb Adeel Mohammad Malik: Hi again, By the way, I bought the ATZB-X-233-XPRO module (http://www.atmel.com/tools/ATZB-X-233-XPRO.aspx?tab=overview) and not ATZB-A-233-XPRO (http://www.atmel.com/tools/ATZB-A-233- XPRO.aspx?tab=overview). This could possibly be the problem. /Adeel -Original Message- From: Adeel Mohammad Malik Sent: Wednesday, August 03, 2016 7:24 PM To: RIOT OS kernel developers Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi Peter, What PIN configuration do you use with AT86RF233? I went through the thread https://github.com/RIOT-OS/RIOT/issues/5407. You use PA2 for RESET. I want to use PA2 for UART TX. I keep my config same as yours except that I use PE2 for RESET. I still have problems with my SPI connection I presume. I debugged my code and I get a problem here https://github.com/RIOT- OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L85. The part number is 0xff. It does not match with AT86RF233_PARTNUM (0x0b) defined here https://github.com/RIOT- OS/RIOT/blob/master/drivers/at86rf2xx/include/at86rf2xx_registers.h#L38. /Adeel -Original Message- From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter Kietzmann Sent: Wednesday, July 20, 2016 4:48 PM To: RIOT OS kernel developers Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi, just as a side note: @Nordzisko has a pretty similar setup wich worked (except the button issue) https://github.com/RIOT-OS/RIOT/issues/5407 Best Peter Am 20.07.2016 um 16:22 schrieb 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: [
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi Adeel, please note that issue #5407 is about the F3 discovery so the pin configuration might differ. I connected an openlabs transceiver http://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio (basically containing an Atmel AT86RF233) to the stm32f4discovery. This is the configuration that I have used https://github.com/PeterKietzmann/RIOT/tree/stm32f4discovery_add_at86rf233_config examples/gnrc_networking worked as expected. Could you take that branch, connect your device accordingly and try gnrc_networking again? I currently don't find the time to look into the details of that device but the ATZB-A-233-XPRO basically worked for @Nordziski and from what you describe I have the impression it is a peripheral problem. Do you have a logic analyser to see what is on the SPI bus and the additional pins? I experienced the usage of these cheap jumper cables as a big source of trouble pretty often... Best regards Peter Am 04.08.2016 um 10:17 schrieb Adeel Mohammad Malik: Hi again, By the way, I bought the ATZB-X-233-XPRO module (http://www.atmel.com/tools/ATZB-X-233-XPRO.aspx?tab=overview) and not ATZB-A-233-XPRO (http://www.atmel.com/tools/ATZB-A-233-XPRO.aspx?tab=overview). This could possibly be the problem. /Adeel -Original Message- From: Adeel Mohammad Malik Sent: Wednesday, August 03, 2016 7:24 PM To: RIOT OS kernel developers Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi Peter, What PIN configuration do you use with AT86RF233? I went through the thread https://github.com/RIOT-OS/RIOT/issues/5407. You use PA2 for RESET. I want to use PA2 for UART TX. I keep my config same as yours except that I use PE2 for RESET. I still have problems with my SPI connection I presume. I debugged my code and I get a problem here https://github.com/RIOT- OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L85. The part number is 0xff. It does not match with AT86RF233_PARTNUM (0x0b) defined here https://github.com/RIOT- OS/RIOT/blob/master/drivers/at86rf2xx/include/at86rf2xx_registers.h#L38. /Adeel -Original Message- From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter Kietzmann Sent: Wednesday, July 20, 2016 4:48 PM To: RIOT OS kernel developers Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi, just as a side note: @Nordzisko has a pretty similar setup wich worked (except the button issue) https://github.com/RIOT-OS/RIOT/issues/5407 Best Peter Am 20.07.2016 um 16:22 schrieb 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/Atm
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jul 27, 2016 2pm - 3pm (RIOT Events)
Hi all, the link is not static but it needs to permanently point to a fresh etherpad, according to this explanation in the wiki: Minutes from past meetings are listed further below. If a meeting actually took place, the link to the minutes will move downwards to the archive and a new link for the next meeting will be opened and listed here by a maintainer. Best Peter Am 27.07.2016 um 14:14 schrieb Oleg Hahm: Hi Peter! On Wed, Jul 27, 2016 at 02:09:22PM +0200, Peter Kietzmann wrote: as always you can find the link to an etherpad here: https://github.com/RIOT-OS/RIOT/wiki/Meetings Thanks! Didn't know that there was a permanent link. (Or I forgot.) under point "Agenda for the next virtual meeting". There is not topic on the agenda so we skip this meeting. +1 Cheers, Oleg ___ 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
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jul 27, 2016 2pm - 3pm (RIOT Events)
Hi, as always you can find the link to an etherpad here: https://github.com/RIOT-OS/RIOT/wiki/Meetings under point "Agenda for the next virtual meeting". There is not topic on the agenda so we skip this meeting. Best Peter Am 27.07.2016 um 14:01 schrieb Oleg Hahm: Dear release-preparing IOTlers, do we have an Etherpad with an agenda for today's meeting? If not, do we need one? Cheers, Oleg On Tue, Jul 26, 2016 at 12:00:07PM +, Google Calendar wrote: This is a notification for: Title: Biweekly virtual meeting Developer discussions that will only happen if a proposed agenda exists. Some instructions and a link to the agenda can be found in the RIOT wiki (https://github.com/RIOT-OS/RIOT/wiki/Meetings). Remote participation will be provided. When: Wed Jul 27, 2016 2pm – 3pm Berlin Calendar: RIOT Events Who: * Ludwig Ortmann - creator Event details: https://www.google.com/calendar/event?action=VIEW=Z2tqN2ZyY3NmdnEzOWFkbDdmMXJkb2hrbzhfMjAxNjA3MjdUMTIwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this email at the account peterschme...@gmail.com because you are subscribed for notifications on calendar RIOT Events. To stop receiving these emails, please log in to https://www.google.com/calendar/ and change your notification settings for this calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding ___ 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 -- 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
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi,
as said, the radio driver uses the CPUID for hardware address
generation, so yes. See this line and following:
https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx.c#L77
Best
Peter
Am 27.07.2016 um 10:35 schrieb Adeel Mohammad Malik:
Hi again,
I was talking about the HWaddr. I want to run the CCN stack directly over the
radio without any IP stack. Does the CPUID module also configure the hardware
addresses?
/Adeel
-Original Message-
From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter
Kietzmann
Sent: Wednesday, July 27, 2016 10:25 AM
To: RIOT OS kernel developers
Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi Adeel,
not sure I fully understand you previous mail. The driver will generate a
default hardware address which is based on the CPUID.
USEMODULE += at86rf233
AFAIK one of these modules is actually responsible for that
USEMODULE += gnrc_netdev_default
USEMODULE += auto_init_gnrc_netif
You already have this in. Otherwise there won't be any hardware access.
If you try examples/gnrc_networking (maybe at first in native) and type
"ifconfig" you will see that the network interface has some ipv6 addresses.
The local unicast address is based on the hardware address which was
explained previously.
I currently don't know which module attaches these ip addresses, maybe
@miri64 can say more? Anyway, please try to get the transceiver running
with tests/driver_at86rf2xx and examples/gnrc_networking before using it
on a border router.
Best
Peter
Am 27.07.2016 um 09:36 schrieb Adeel Mohammad Malik:
Hi Peter,
Do you mean I should get an address on my interface without having to
configure it manually? If so, which module (USEMODULE) is it exactly that has
this effect?
/Adeel
-Original Message-
From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter
Kietzmann
Sent: Monday, July 25, 2016 8:40 AM
To: RIOT OS kernel developers
Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi Adeel,
generation of the CPUID shouldn't be a problem. I checked it on an
stm32f4discovery board. Can you try it with examples/gnrc_networking?
"ifconfig" works there as well.
The f4 board usually has no network interface and now you're about to
initialize two. I could imagine it's just a configuration problem but
to be sure, please check gnrc_networking first.
Best
Peter
Am 21.07.2016 um 12:11 schrieb Adeel Mohammad Malik:
Hi again,
I think I got the SPI connection right now. I just configured an
address using
ifconfig and was able to change the address. I am still not getting
an address automatically which as Thomas mentioned I should be
getting using the cupid module. Seems like I am missing a module in my
Makefile.
/Adeel
-Original Message-
From: Adeel Mohammad Malik
Sent: Thursday, July 21, 2016 11:29 AM
To: 'RIOT OS kernel developers'
Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi again,
I just used the following pin configuration for the AT86RF233
transceiver
now:-
#define AT86RF2XX_PARAMS_BOARD {
.spi = SPI_0, \
.spi_speed = SPI_SPEED_5MHZ, \
.cs_pin = GPIO_PIN(PORT_E, 0), \
.int_pin = GPIO_PIN(PORT_E, 1), \
.sleep_pin = GPIO_PIN(PORT_E, 2), \
.reset_pin = GPIO_PIN(PORT_E, 3)}
I still have the same problem. I have the following relevant
modules included in my Makefile:-
...
USEMODULE += gnrc_netdev_default
USEMODULE += auto_init_gnrc_netif
GNRC_NETIF_NUMOF := 2
USEMODULE += ethos gnrc_netdev2
CFLAGS += '-DETHOS_UART=UART_DEV(0)' -
DETHOS_BAUDRATE=115200
-
DUSE_ETHOS_FOR_STDIO USEMODULE += at86rf233 ...
Any hints/clues would be appreciated.
/Adeel
-Original Message-
From: Adeel Mohammad Malik
Sent: Wednesday, July 20, 2016 6:33 PM
To: RIOT OS kernel developers
Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi Peter and Thomas,
I was quite skeptical about my pin connections/configurations. I
did realize that the default pin mapping of the Atmel driver could
be a problem so I had already defined my own pin mapping in the
file "/boards/stm32f4discovery/include/board.h" before writing to
the mailing list. I defined it as follows:-
#define AT86RF2XX_PARAMS_BOARD {
.spi = SPI_0, \
.spi_speed = SPI_SPEED_5MHZ, \
.cs_pin = GPIO_PIN(PORT_A, 0), \
.int_pin = GPIO_PIN(PORT_E, 0), \
.sleep_pin = GPIO_PIN(PORT_E, 1), \
.reset_pin = GPIO_PIN(PORT_E, 2)}
After reading the thread that Peter referred to, I checked the
file "/boards/stm32f4discovery/include/board.h" and saw that there
is an overlap on PA0:-
#define BTN_B1_PIN GPIO_PIN(PORT_A, 0)
The reason I defined AT86RF2XX_PARAMS_BOARD as above is the
link
https://github.com/RIOT-OS/RIOT/wiki/Board%3A-STM32F4discovery
where a
picture of the STM32F4DISCOVERY board shows the different pins. I
just assumed that GPIO_0 (PA
Re: [riot-devel] RE - Tutorial "How to port a radio module driver to RIOT OS"
Hi Neo, surprise :-)! Do you reuse code that has already been available in a closed PR?? Regards Peter Am 26.07.2016 um 21:47 schrieb Neo: Hi Peter, yes I'm working on a radio driver and I hope that it will be finished soon - it's a driver for the Microchip MRF24J40. Cheers, Neo Am 26.07.2016 um 20:28 schrieb Peter Kietzmann: Hi Neo, great! Many thanks for the initiative, it might be pretty helpful for others. Just asking: Do you actually intend to write a radio driver? If so, which one is it :-)? Cheers Peter Am 26.07.2016 um 20:22 schrieb Neo: Hello Alessandro, I just started writing the tutorial some minutes ago and my plans are to add parts day by dayso - don't have too big expectations at the moment.it will grow ;-) You can find it starting from here https://github.com/RIOT-OS/RIOT/wiki Best regards, Neo Am 26.07.2016 um 19:30 schrieb ALESSANDRO NICOLI: Hi Neo, I'm really interested to this topic because i need to do it too for the OpenMote board. Where we could find your tutorial? /best regards, / /Alessandro/ ___ 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 -- 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
Re: [riot-devel] RE - Tutorial "How to port a radio module driver to RIOT OS"
Hi Neo, great! Many thanks for the initiative, it might be pretty helpful for others. Just asking: Do you actually intend to write a radio driver? If so, which one is it :-)? Cheers Peter Am 26.07.2016 um 20:22 schrieb Neo: Hello Alessandro, I just started writing the tutorial some minutes ago and my plans are to add parts day by dayso - don't have too big expectations at the moment.it will grow ;-) You can find it starting from here https://github.com/RIOT-OS/RIOT/wiki Best regards, Neo Am 26.07.2016 um 19:30 schrieb ALESSANDRO NICOLI: Hi Neo, I'm really interested to this topic because i need to do it too for the OpenMote board. Where we could find your tutorial? /best regards, / /Alessandro/ ___ 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 -- 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
Re: [riot-devel] Status of the MRF24J40 radio module support
Hi Neo,
thanks for the hint. AFAIK reading/writing at long addresses already
worked in Tobias' implementation, though I don't remember how he handled
it. I will keep it in mind.
Best
Peter
Am 26.07.2016 um 01:28 schrieb Neo:
Hello Peter,
sorry for the mistake - Frederic? I thought about Tobias Fredersdorf.
Here is my hint about the hardware access to the MRF24J40.
The SPI-Interface of the MRF24J40 is a little bit tricky.
If you take a look onto the diagram of the chip datasheet (chapter
2.14.2) you see that the bit which makes the decision between read and
right access is not on a 8bit border but rather in the middle if you
have a SPI-controller which is 8bit oriented.
Therefore you have to introduce a MRF24J40_ACCESS_WRITE_LONG bit to set
the write bit correct.
/**
* @brief SPI access specifiers
*@{
*/
#define MRF24J40_SHORT_ADDR_TRANS (0x00)
#define MRF24J40_LONG_ADDR_TRANS (0x80)
#define MRF24J40_ACCESS_READ (0x00)
#define MRF24J40_ACCESS_WRITE(0x01)
#define MRF24J40_ACCESS_WRITE_LONG (0x10)
#define MRF24J40_ADDR_OFFSET (0x01)
/** @} */
void mrf24j40_reg_write_long(const mrf24j40_t *dev, const uint16_t addr,
const uint8_t value)
{
uint8_t reg1,reg2;
reg1 = MRF24J40_LONG_ADDR_TRANS | (addr>>3);
reg2 = (addr<<5) | MRF24J40_ACCESS_WRITE_LONG;
spi_acquire(dev->params.spi);
GPIOB->BRR = (1 << 12);
spi_transfer_byte(dev->params.spi, reg1, 0);
spi_transfer_byte(dev->params.spi, reg2, 0);
spi_transfer_byte(dev->params.spi, value, 0);
GPIOB->BSRR = (1 << 12);
spi_release(dev->params.spi);
}
Without this bit you will never achieve a working write access.
Best regards,
Neo
Am 22.07.2016 um 19:25 schrieb Peter Kietzmann:
Hi Neo,
the PR was closed because it was outdated but Tobias Fredersdorf
promised to open a new one with more up to date code -> so there is
more code but not available until now. I will meet him f2f in the next
week and report the status, in case there is no PR to await soon.
At the RIOT summit several people stated their interest and we agreed
on blocking that work about two more weeks for Tobias. In case there
is no progress, someone else will take this over (probably me).
Which hints do you have about hardware access?
And who is Frederic? At least I'm not aware to be his follower.
Best regards
Peter
Am 22.07.2016 um 12:54 schrieb Neo:
Hello developers,
in the comments of the Pull-Request 5099 it seems that Tobias
Fredersdorf stops now his efford in implementing the MRF24J40 driver.
What is the status of the MRF24J40 driver development? Is there more
code available as stored in GitHub?
If not - I have some additional important hints about that driver
(depending especially the hardware access of this radio chip).
Who will be the follower of Frederic? Is it Peter Kietzmann?
Best 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
--
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
Re: [riot-devel] Hack'n'ACK July 2016
Hi, yes we will. So let's set up a PlaceCam session as usual. I propose you initiate the call, as it as proven this way. Best Peter Am 25.07.2016 um 15:39 schrieb Martine Lenders: Hi, tomorrow we have our monthly Hack'n'ACK again. Oleg and I will most likely sit together at FU Berlin and are happy about any other dev from Berlin that likes to join. Hamburg & Saclay are you holding a Hack'n'ACK at your location, too? Cheers, Martine ___ 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
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi Adeel,
generation of the CPUID shouldn't be a problem. I checked it on an
stm32f4discovery board. Can you try it with examples/gnrc_networking?
"ifconfig" works there as well.
The f4 board usually has no network interface and now you're about to
initialize two. I could imagine it's just a configuration problem but to
be sure, please check gnrc_networking first.
Best
Peter
Am 21.07.2016 um 12:11 schrieb Adeel Mohammad Malik:
Hi again,
I think I got the SPI connection right now. I just configured an address using
ifconfig and was able to change the address. I am still not getting an address
automatically which as Thomas mentioned I should be getting using the cupid
module. Seems like I am missing a module in my Makefile.
/Adeel
-Original Message-
From: Adeel Mohammad Malik
Sent: Thursday, July 21, 2016 11:29 AM
To: 'RIOT OS kernel developers'
Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi again,
I just used the following pin configuration for the AT86RF233 transceiver
now:-
#define AT86RF2XX_PARAMS_BOARD {
.spi = SPI_0, \
.spi_speed = SPI_SPEED_5MHZ, \
.cs_pin = GPIO_PIN(PORT_E, 0), \
.int_pin = GPIO_PIN(PORT_E, 1), \
.sleep_pin = GPIO_PIN(PORT_E, 2), \
.reset_pin = GPIO_PIN(PORT_E, 3)}
I still have the same problem. I have the following relevant modules included
in my Makefile:-
...
USEMODULE += gnrc_netdev_default
USEMODULE += auto_init_gnrc_netif
GNRC_NETIF_NUMOF := 2
USEMODULE += ethos gnrc_netdev2
CFLAGS += '-DETHOS_UART=UART_DEV(0)' -DETHOS_BAUDRATE=115200 -
DUSE_ETHOS_FOR_STDIO USEMODULE += at86rf233 ...
Any hints/clues would be appreciated.
/Adeel
-Original Message-
From: Adeel Mohammad Malik
Sent: Wednesday, July 20, 2016 6:33 PM
To: RIOT OS kernel developers
Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi Peter and Thomas,
I was quite skeptical about my pin connections/configurations. I did
realize that the default pin mapping of the Atmel driver could be a
problem so I had already defined my own pin mapping in the file
"/boards/stm32f4discovery/include/board.h" before writing to the
mailing list. I defined it as follows:-
#define AT86RF2XX_PARAMS_BOARD {
.spi = SPI_0, \
.spi_speed = SPI_SPEED_5MHZ, \
.cs_pin = GPIO_PIN(PORT_A, 0), \
.int_pin = GPIO_PIN(PORT_E, 0), \
.sleep_pin = GPIO_PIN(PORT_E, 1), \
.reset_pin = GPIO_PIN(PORT_E, 2)}
After reading the thread that Peter referred to, I checked the file
"/boards/stm32f4discovery/include/board.h" and saw that there is an
overlap on PA0:-
#define BTN_B1_PIN GPIO_PIN(PORT_A, 0)
The reason I defined AT86RF2XX_PARAMS_BOARD as above is the link
https://github.com/RIOT-OS/RIOT/wiki/Board%3A-STM32F4discovery
where a
picture of the STM32F4DISCOVERY board shows the different pins. I just
assumed that GPIO_0 (PA0), GPIO_1 (PE0), GPIO_2 (PE1), GPIO_3 (PE2),
as shown in the picture, are not connected to anything and hence free to
use.
My assumption was obviously wrong.
I will fix my pin configuration tomorrow and see if it works for me.
Thanks for your replies. You guys are really helpful.
Regards,
Adeel
-Original Message-
From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter
Kietzmann
Sent: Wednesday, July 20, 2016 4:48 PM
To: RIOT OS kernel developers
Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi,
just as a side note: @Nordzisko has a pretty similar setup wich
worked (except the button issue)
https://github.com/RIOT-OS/RIOT/issues/5407
Best
Peter
Am 20.07.2016 um 16:22 schrieb 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
Tho
Re: [riot-devel] ADC on SAMR21-xpro (Alessandro Nicoli)
Hi Alessandro, you're pretty much welcome! Even though I didn't do that much. Do you think you could open a PR with this ADC driver implementation? Best Peter Am 23.07.2016 um 11:50 schrieb ALESSANDRO NICOLI: Hi all, I've successfully put in work the ADC module on SAMR21-xpro. I'm still trying to set up the offset and gain corrections, i tried to edit the "periph_conf.h" file, but when i compile and run it, it seems that nothing has changed... Anyway i want to say "thanks" to Peter that gave me a huge help! /best regards, / /Alessandro/ ___ 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
Re: [riot-devel] Status of the MRF24J40 radio module support
Hi Neo, the PR was closed because it was outdated but Tobias Fredersdorf promised to open a new one with more up to date code -> so there is more code but not available until now. I will meet him f2f in the next week and report the status, in case there is no PR to await soon. At the RIOT summit several people stated their interest and we agreed on blocking that work about two more weeks for Tobias. In case there is no progress, someone else will take this over (probably me). Which hints do you have about hardware access? And who is Frederic? At least I'm not aware to be his follower. Best regards Peter Am 22.07.2016 um 12:54 schrieb Neo: Hello developers, in the comments of the Pull-Request 5099 it seems that Tobias Fredersdorf stops now his efford in implementing the MRF24J40 driver. What is the status of the MRF24J40 driver development? Is there more code available as stored in GitHub? If not - I have some additional important hints about that driver (depending especially the hardware access of this radio chip). Who will be the follower of Frederic? Is it Peter Kietzmann? Best regards Neo ___ 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
Re: [riot-devel] ADC on SAMR21-xpro
Hi Alessandro, what is your code base? If you have adapted this PR (as I proposed some time ago) https://github.com/RIOT-OS/RIOT/pull/4162/ it should be PA6, PA7, PA8, PA9, PB2, PB3 according to the ADC channel. Compare this configuration: https://github.com/RIOT-OS/RIOT/pull/4162/files#diff-134bda29ded96fa4abaa9f99216a6116R325 Best regards Peter Am 22.07.2016 um 11:46 schrieb ALESSANDRO NICOLI: Hi Rioters, I've some troubles about using the ADC on the SAMR21-XPRO board. At now, i've added the libraries and required features for it, it compiles and i can use the "periph_adc" test, but i'm not able to find which GPIO are used for the ADC. In less words, i need an help to start using the ADC lines for a moisture sensor. I've found the watr-li tutorial (http://watr.li/Sensing-moisture.html), but is deprecated. There is someone who can drive me about it? Thanks a lot, /best regards, / /Alessandro/ ___ 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
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi, just as a side note: @Nordzisko has a pretty similar setup wich worked (except the button issue) https://github.com/RIOT-OS/RIOT/issues/5407 Best Peter Am 20.07.2016 um 16:22 schrieb 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 -- 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
Re: [riot-devel] Organizing device drivers
Hi Martin, thanks for your feedback. Am 12.07.2016 um 14:28 schrieb Martin: Hi Perter, all, > this approach prohibits to use both devices simultaneously. I think this is a blocking issue for merging akin device drivers. IMHO If this situation happens the drivers should be separated back, even if bloating/doubling the code. > For similar CPUs we maintain a "common" folder ... Considering the mentioned "blocking issue" I would go for a "common" folder for solely collecting utility functions, i.e. functions not using global/static variables or buffers. > Another solution would be to handle common and individual functions in one file (without #ifdef). ... You mean putting all required functions in each driver without considering similarities? That approach is about to maintain one folder/file for a shared implementation. That file consists of individual functions *and* shared functions. That prohibits from bloating the file structure and enables simultaneous usage but enlarges code size.. At least this would be safe, since every driver then truly operates in defined bounds. But obviously this would most probably introduce a lot developing/debugging repetition. Best regards, Martin Best Peter Am 07/12/2016 um 10:49 AM schrieb Peter Kietzmann: Hi devs, on several occasions the question about how to merge similar device drivers occurred. That means covering different derivatives of a device with one device driver, to avoid code duplication. Compare discussions in these PRs: https://github.com/RIOT-OS/RIOT/pull/5604 https://github.com/RIOT-OS/RIOT/pull/5484 https://github.com/RIOT-OS/RIOT/pull/5433 For the dht11/22 or at86rf212b/232/233 we already merged drivers by putting #ifdef around different code parts. This does not affect code readability as long as differences are small (which is not guaranteed). On the other hand, this approach prohibits to use both devices simultaneously. Furthermore, naming schemes might get confusing. E.g. merging "MPU6000", "MPU6050" and "MPU9150" might lead to "MPUXXX0". I've no idea about further and future version names. For similar CPUs we maintain a "common" folder next to the dedicated CPU version. Different code parts were maintained separately in individual folders. The question is, if this approach is reasonable for pretty simple device drivers where multiple derivatives might exist. Another solution would be to handle common and individual functions in one file (without #ifdef). This might bloat code size but allows usage of different versions in parallel. Also, it does not bloat the file structure. The problem about naming schemes is still present here. I'd like to have a general principle for this. What is your opinion about the above described procedures? Are there other/better ideas? Best Peter ___ 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
[riot-devel] Organizing device drivers
Hi devs, on several occasions the question about how to merge similar device drivers occurred. That means covering different derivatives of a device with one device driver, to avoid code duplication. Compare discussions in these PRs: https://github.com/RIOT-OS/RIOT/pull/5604 https://github.com/RIOT-OS/RIOT/pull/5484 https://github.com/RIOT-OS/RIOT/pull/5433 For the dht11/22 or at86rf212b/232/233 we already merged drivers by putting #ifdef around different code parts. This does not affect code readability as long as differences are small (which is not guaranteed). On the other hand, this approach prohibits to use both devices simultaneously. Furthermore, naming schemes might get confusing. E.g. merging "MPU6000", "MPU6050" and "MPU9150" might lead to "MPUXXX0". I've no idea about further and future version names. For similar CPUs we maintain a "common" folder next to the dedicated CPU version. Different code parts were maintained separately in individual folders. The question is, if this approach is reasonable for pretty simple device drivers where multiple derivatives might exist. Another solution would be to handle common and individual functions in one file (without #ifdef). This might bloat code size but allows usage of different versions in parallel. Also, it does not bloat the file structure. The problem about naming schemes is still present here. I'd like to have a general principle for this. What is your opinion about the above described procedures? Are there other/better ideas? Best Peter -- 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
Re: [riot-devel] samr21-xpro ADC I/O lines
Hi Alessandro, there have been several efforts to write the ADC driver but unfortunately we never finished because of discrepancies in terms of configuration. Have a loot at this PR which basically works but needs rebase: https://github.com/RIOT-OS/RIOT/pull/4162 It is somewhere on my ToDo list to update that PR but I can not estimate when it will be. We would be *really* happy about this feature, so would you probably find some time to take over? Best regards Peter Am 11.07.2016 um 15:22 schrieb ALESSANDRO NICOLI: Hi Rioters, I was looking for any example about ADC lines on the SAMR21-xpro, because i have to manage analog signals. I saw that there is nothing about it in the official release of RIOT, so, there is someone that has already use it? Can he give me some tip about it? Thanks a lot! :) /best regards, / /Alessandro/ ___ 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
Re: [riot-devel] Is samr21-xpro SPI working
Hi Kees, stupid question: How do you know SPI is not working? "GPIO_1090536471" was a formatting bug, compare: https://github.com/RIOT-OS/RIOT/pull/5619 Would you try to initialize an other pin as CS line? If I see it correctly you decided for PA23. Maybe just try it with PB2 (in case you don't use it for other things). Best Peter Am 08.07.2016 um 20:16 schrieb Kees Bakker: This very same setup works perfectly with Arduino. It is a SAMD21 on a Autonomo (very much like Arduine Zero). It has a 16Mb "serial flash" chip on it. I started with the code from cpu/samd21 that was developed for the samr21-xpro board. The "only" thing I had to change is the pins for the SPI. And with the pins I also had to change the SERCOM, the PADs and the pin MUX. And yes, I checked the SS pin (and all other pins) over and over. So far I was able to get UART and I2C working. But for more than a week now I am stuck at SPI. I use the tests/periph_spi test program. �main(): This is RIOT! (Version: 2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo) RIOT low-level SPI driver test This application enables you to test a platforms SPI driver implementation. Enter 'help' to get started > �main(): This is RIOT! (Version: 2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo) RIOT low-level SPI driver test This application enables you to test a platforms SPI driver implementation. Enter 'help' to get started > help Command Description --- init_master Initialize node as SPI master init_slave Initialize node as SPI slave send Transfer string to slave (only in master mode) print_rx Print the received string (only in slave mode) reboot Reboot the node > > init_master 0 0 23 SPI_0 successfully initialized as master, cs: GPIO_1090536471, mode: 0, speed: 2 > > send Transfered 5 bytes: MOSI 01234 0x9f 0x00 0x00 0x00 0x00 ?? ?? ?? ?? ?? MISO 01234 0xff 0xff 0xff 0xff 0xff ?? ?? ?? ?? ?? It drives me nuts. Any hint is greatly appreciated. -- Kees On 08-07-16 19:03, Baptiste Clenet wrote: Autonomo uses samd21 CPU? You use same driver as samr21? What's your problem? Are you sure your SPI Slave chip is working correctly? 2016-07-07 21:01 GMT+02:00 Kees Bakker <k...@sodaq.com>: Ah, _now_ it makes sense. :-) Thanks for letting me know. That leaves me with my own SPI problem. On my Autonomo I can't get it to work. It is working with Arduino, but with RIOT (under construction) it's not :-( On 06-07-16 22:53, Baptiste Clenet wrote: Yes I know, I changed it to make it work :) (SPI1) 2016-07-06 22:48 GMT+02:00 Kees Bakker <k...@sodaq.com>: OK thanks. However, your remark about SPI1 puzzles me a bit, because it was using an incorrect PAD setting. PR #5609 fixed today. On 05-07-16 23:21, Baptiste Clenet wrote: I can confirm that it works properly. SPI is used to communicate with the transceiver on samr21-xpro and communication works so SPI works, I used SPI1 also with no problem 2016-07-05 21:50 GMT+02:00 Kees Bakker <k...@sodaq.com>: Hey, Can someone confirm that SPI is working on the samr21-xpro board? I'm trying to make SPI work on my Autonomo board, but I haven't succeeded yet. FYI, I'm also reorganizing the code so there are a lot of parameters that can be of influence. I can't use the current code because the pins and the SERCOMs are different. It would help me to know that it works on samr21-xpro. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ 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 -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ 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
Re: [riot-devel] Question regarding CCN-lite and RIOT supported platforms
Hi Adeel, Am 30.06.2016 um 09:42 schrieb Oleg Hahm: Hi Adeel, On Wed, Jun 29, 2016 at 07:04:43PM +, Adeel Mohammad Malik wrote: Thank you for your reply. It was really helpful. I actually posted another question on the mailing list about STM32F4Discovery and the possibility to run CCN-lite over it with 802.15.4. You have answered that question too. I just have a follow up question about how the setup would look like if I use the Atmel at86rf23x transceiver with STM32F4Discovery. Does the transceiver hook up directly to the STM32F4Discovery board? For this first question, I'm probably not the best person to answer, so maybe others (Peter, Paco, Kaspar?) can help, but AFAIK a viable way could be to buy an Openlabs adapter [1] that can be connected over SPI and plug it on the Discovery Board. as Oleg already said, the easiest (and cheapest) solution would be an openlabs transceiver. Unfortunately the connector configuration is not compatible with the STM discovery boards but you could use cables instead. The default pin configuration of the RIOT driver can be found here: https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/include/at86rf2xx_params.h#L53 There also exist extension boards by Atmel which should work with RIOT, but I assume the problem of incompatible connectors is the same with STM boards (cables needed): http://www.atmel.com/tools/ATZB-A-233-XPRO.aspx Unfortunately the Microchip MRF24J20 driver is still not in shape but this might be a cheap solution in future. Assuming I run CCN-lite directly on 802.15.4, how would I connect the STM32F4Discovery board to a computer that acts as a gateway to the CCN network? That's indeed an interesting question. I think the easiest solution would be to either plug an Ethernet module to the Discovery Board or use ethos (ETHernet Over Serial) [2] to connect to the Gateway that run a CCN-lite client with two interfaces (one with an Ethernet socket pointing to the RIOT node and one with an IP/UDP socket pointing to the rest of the world). In fact, this kind of bridge functionality to translate between different transports for CCN could be also done directly on a RIOT node, assuming that (i) the node would have enough resources and (ii) the adaptation to IP addresses in RIOT's CCN-lite package is there. Cheers, Oleg [1] http://openlabs.co/store/Raspberry-Pi-802.15.4-radio [2] https://github.com/RIOT-OS/RIOT/tree/master/dist/tools/ethos ___ 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
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jun 29, 2016 2pm - 3pm (RIOT Events)
Hi Folks, because of a lack of participants we won't set up the Placecam session for today’s Hack'n'ACK. However, if anyone has an urgent topic that needs to be discussed, we can still initialize a "private" session. In that case, just contact me. Otherwise, I recommend to use the normal communication channels (github, mailing lists, biweekly agenda, etc) or visit us hat the HAW Hamburg :-). Greetings Peter Am 28.06.2016 um 14:00 schrieb Google Calendar: more details » <https://www.google.com/calendar/event?action=VIEW=Z2tqN2ZyY3NmdnEzOWFkbDdmMXJkb2hrbzhfMjAxNjA2MjlUMTIwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn> Biweekly virtual meeting Developer discussions that will only happen if a proposed agenda exists. Some instructions and a link to the agenda can be found in the RIOT wiki (https://github.com/RIOT-OS/RIOT/wiki/Meetings <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FRIOT-OS%2FRIOT%2Fwiki%2FMeetings=D=2=AFQjCNHYQc4d8bSOfagdkeUWSyK-8tas8Q>). Remote participation will be provided. /When/ Wed Jun 29, 2016 2pm – 3pm Berlin /Calendar/ RIOT Events /Who/ • Ludwig Ortmann- creator Invitation from Google Calendar <https://www.google.com/calendar/> You are receiving this email at the account peterschme...@gmail.com because you are subscribed for notifications on calendar RIOT Events. To stop receiving these emails, please log in to https://www.google.com/calendar/ and change your notification settings for this calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More <https://support.google.com/calendar/answer/37135#forwarding>. ___ 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
Re: [riot-devel] LoRaWAN implementation under RIOT
Hi anonymous, great :-)! I assume you're using a development board, dev kit or something. Would you disclose which one it is (in case...)? Best Peter Am 20.06.2016 um 16:25 schrieb Kaspar Schleiser: Hey anonymous, On 06/20/2016 03:20 PM, Anon Anonymous wrote: After a couple of months I've finished a Semtech's SX1276 LoRa transceiver driver (physical level, RX and TX) under RIOT (pull request coming soon!) and the next step is a LoRaWAN MAC level implementation. Awesome! looking forward. My question is: Which RIOT interfaces should I choose to implement next to introduce LoRaWAN MAC level as seamlessly as possible into existing RIOT's networking stacks? If the MAC is mostly stateless (doesn't need dynamic buffering), it might make sense to model it as a netdev2 layer on top of raw LoRa. Is there a use case for using LoRa without the MAC? Kaspar ___ 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
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
Hi Kees, Am 15.06.2016 um 22:07 schrieb Kees Bakker: On 15-06-16 09:32, Peter Kietzmann wrote: Hi Kees, if you volunteer you could start with moving code to samd21_common and open PR(s) for that :-). Well, OK. I'll give it a try. Seems like a step in the right direction. I personally won't find time for that unfortunately. On our side we could test your PR(s) with the samr21-xpro board and AFAIK Kaspar has a saml21-xpro board. Do you have a "build farm" of some sorts? Or do you run tests manually? We have static build tests (tool named "Murdock") which can be enabled by maintainers in a PR. The rest is done manually with review and local testing. Regarding the UART issue, could you give some more insights about the pad you want to add to uart_conf_t? I just gave it a quick look into the reference manual http://www.atmel.com/images/atmel-42181-sam-d21_datasheet.pdf but on the first sight I didn't see a difference to http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf My UART changes have nothing to do with samd21 versus samr21. It's about selecting a pin for RX, TX. For example, on Autonomo use pin PA10 for TX. PA10 is PAD2 of SERCOM0, with MUX C. The samr21_xpro has PA4 as TX, PA4 is PAD0 of SERCOM0 (ALT) with MUX D. Ok I got it. Agree that it makes sense to expand the configuration type. But as I'm probably biased, do others feel that the folder scheme should more reflect a vendor's scheme? I'd like to have the most generic abstraction (e.g. samd21, saml21 and probably samr21) and better no separate folders for each CPU variant. However, I can't estimate the feasibility of that in order to allow support for all these variants. Let's move this discussion to your PR. Best Peter -- 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
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jun 15, 2016 2pm - 3pm (RIOT Events)
Hi, probably todays problems were caused by my computer... Best Peter Am 15.06.2016 um 14:35 schrieb Martine Lenders: Hi, Should we rathe change to skype & co? Cheers, Martine 2016-06-15 14:25 GMT+02:00 Peter Kietzmann <peter.kietzm...@haw-hamburg.de>: Sorry, PC hung up. Session available under link as before: http://placecam.de/call.php?c=kWtmE~M0jTbKGFQSGnUBLtC.xAbWgTythbQbBMVXUvs- Am 15.06.2016 um 14:06 schrieb Peter Kietzmann: Forgot to attach the Padlink for the agenda: http://www.yourpart.eu/p/riot-2016-05-17-virtual-meeting Am 15.06.2016 um 14:04 schrieb Peter Kietzmann: Hi, session should be available under: http://placecam.de/call.php?c=kWtmE~M0jTbKGFQSGnUBLtC.xAbWgTythbQbBMVXUvs- Please note that it might be a different link as usul. Cheers Peter Am 15.06.2016 um 13:21 schrieb Peter Kietzmann: Hi all, there is a point on the agenda for todays virtual meeting, so it will take place. The proposed topic concerns the network stack architecture. In that regards it would be great if someone of the main authors could participate :-). Hear your later! Peter Am 14.06.2016 um 14:00 schrieb Google Calendar: more details » <https://www.google.com/calendar/event?action=VIEW=Z2tqN2ZyY3NmdnEzOWFkbDdmMXJkb2hrbzhfMjAxNjA2MTVUMTIwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn> Biweekly virtual meeting Developer discussions that will only happen if a proposed agenda exists. Some instructions and a link to the agenda can be found in the RIOT wiki (https://github.com/RIOT-OS/RIOT/wiki/Meetings <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FRIOT-OS%2FRIOT%2Fwiki%2FMeetings=D=2=AFQjCNHYQc4d8bSOfagdkeUWSyK-8tas8Q>). Remote participation will be provided. /When/ Wed Jun 15, 2016 2pm – 3pm Berlin /Calendar/ RIOT Events /Who/ • Ludwig Ortmann- creator Invitation from Google Calendar <https://www.google.com/calendar/> You are receiving this email at the account peterschme...@gmail.com because you are subscribed for notifications on calendar RIOT Events. To stop receiving these emails, please log in to https://www.google.com/calendar/ and change your notification settings for this calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More <https://support.google.com/calendar/answer/37135#forwarding>. ___ 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 -- 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
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jun 15, 2016 2pm - 3pm (RIOT Events)
Hi, session should be available under: http://placecam.de/call.php?c=kWtmE~M0jTbKGFQSGnUBLtC.xAbWgTythbQbBMVXUvs- Please note that it might be a different link as usul. Cheers Peter Am 15.06.2016 um 13:21 schrieb Peter Kietzmann: Hi all, there is a point on the agenda for todays virtual meeting, so it will take place. The proposed topic concerns the network stack architecture. In that regards it would be great if someone of the main authors could participate :-). Hear your later! Peter Am 14.06.2016 um 14:00 schrieb Google Calendar: more details » <https://www.google.com/calendar/event?action=VIEW=Z2tqN2ZyY3NmdnEzOWFkbDdmMXJkb2hrbzhfMjAxNjA2MTVUMTIwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn> Biweekly virtual meeting Developer discussions that will only happen if a proposed agenda exists. Some instructions and a link to the agenda can be found in the RIOT wiki (https://github.com/RIOT-OS/RIOT/wiki/Meetings <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FRIOT-OS%2FRIOT%2Fwiki%2FMeetings=D=2=AFQjCNHYQc4d8bSOfagdkeUWSyK-8tas8Q>). Remote participation will be provided. /When/ Wed Jun 15, 2016 2pm – 3pm Berlin /Calendar/ RIOT Events /Who/ • Ludwig Ortmann- creator Invitation from Google Calendar <https://www.google.com/calendar/> You are receiving this email at the account peterschme...@gmail.com because you are subscribed for notifications on calendar RIOT Events. To stop receiving these emails, please log in to https://www.google.com/calendar/ and change your notification settings for this calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More <https://support.google.com/calendar/answer/37135#forwarding>. ___ 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
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
Hi Kees, if you volunteer you could start with moving code to samd21_common and open PR(s) for that :-). Seems like a step in the right direction. I personally won't find time for that unfortunately. On our side we could test your PR(s) with the samr21-xpro board and AFAIK Kaspar has a saml21-xpro board. Regarding the UART issue, could you give some more insights about the pad you want to add to uart_conf_t? I just gave it a quick look into the reference manual http://www.atmel.com/images/atmel-42181-sam-d21_datasheet.pdf but on the first sight I didn't see a difference to http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf Best Peter Am 14.06.2016 um 20:30 schrieb Kees Bakker: On 13-06-16 22:39, Peter Kietzmann wrote: Hi Kees, honestly just now I got your actual problem and I remember what I stumbled upon this morning: # define the cpu used by SAMR21 Xplained Pro board export CPU = samd21 export CPU_MODEL = samr21x18a https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/Makefile.include However, I won't say "for RIOT that's good enough". To summarize: The main questions are (i) how to split different CPUs/MCUs with rather small differences and (ii) how to reuse most of the code. Right? Correct. For (ii) it would obviously be the best way to have drivers and stuff in the common folder. Personally I have no idea if this is possible or not, it depends on the differences. If these are too big, one needs to stay with a separate CPU folder for each "family". Yes, that is certainly possible. All these SAM devices can be handled with a common code base. Someone already started such a common place: cpu/sam21_common. We should continue with that. If you ask me, I'd say that already a lot of files from cpu/samd21/periph can be moved to cpu/sam21_common. For (i) won't it be enough to export the CPU_MODEL by the board and adjust the include paths properly, as done e.g. here? Yes, that is the right thing to do. For Atmel there is one more thing: CFLAGS must have a define like -D__SAMD21J18A__, otherwise the correct include files aren't selected. https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32f3/include/cpu_conf.h#L27 One other question is the need for changing the CPU name of the Atmel samr21-xpro board from "samd21" to "samr21". In your regards I think it could make sense but with a solution as described in (i) above, there won't be a need for that. Do I see that correctly? I don't care too much how the CPU is called. But maybe it is useful to know which CPU variant it is, like SAMD21J18A. Generally I'm not too much into Atmels product series and I would like to hear Kaspar's opinion as he knows RIOTs architecture much better than me. I'd be interested to know what Kaspar thinks about it. ___ 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
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
Hi Kees, nice to see your interest in RIOT! Find some comments inline. Am 12.06.2016 um 21:14 schrieb Kees Bakker: Hi, This is a heads up to let you know I'm working on a port of RIOT to SODAQ Autonomo, which has an Atmel samd21 (like Arduino Zero). 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? https://github.com/RIOT-OS/RIOT/tree/master/cpu/samd21/include In the process I learned how to use the Atmel-ICE and how to debug via openocd. Nice :-) Yepp :-) At the moment I can step through the hello world example. But I have no idea where the output is going. That's my next challenge. By default the STDIO is mapped to UART_DEV(0) which will generally be the first device defined in the periph_conf.h file of the board. E.g.: https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/include/periph_conf.h#L108 The driver used should be common for samX21 MCUs but is currently not. https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/uart.c For Kinetis there already is a great code reusability: https://github.com/RIOT-OS/RIOT/tree/master/cpu/kinetis_common/periph However, you could try to set up a different STDIO UART device and connect an external UART/USB converter to see if it's about conflicting pins. Meanwhile the changes and additions are available in my fork at g...@github.com:keestux/RIOT-OS Branch sodaq-autonomo. Best Peter -- 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
Re: [riot-devel] UDP datagram sending
Hi Mateusz, nice! I was just about to start looking into it. For the next time I recommend to work in branches. (i) It is the "RIOT-way" and (ii) it makes reviewing your changes a lot easier. Cheers Peter Am 10.06.2016 um 11:17 schrieb Mateusz Kubaszek: Problem solved, It was caused by netreg registering. The msg queue initialization is performed inside the thread, so if it has lower priority or the scheduler is not called after thread creation the gnrc_netreg_register() fails. The solution was to register this thread after message queue initialization. So after i placed the gnrc_netreg_register() inside the thread function all works fine. Many thanks :) ___ 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
Re: [riot-devel] UDP datagram sending
Hi Mateusz, hard to figure out from afar. Do you have your code available on github? Regarding 1): I don't know how this should be related to you memory violation issue. Regarding 2): AFAIK your thread will have the priority that you give on initialization, no matter from where it is created. Best Peter Am 07.06.2016 um 11:26 schrieb Mateusz Kubaszek: Hi, > can you elaborate on how it "doesn't work"? After the message is sent, the reading thread doesn't receive it. I have been watching what is going on in "gnrc_netapi_dispatch" function. The destination pid is correct and there wasn't a problem with message sending. Destination PID is 6 which is the udp thread (I put there a printf statement indicating any incoming message). I finally resolved the problem yesterday's night. I was certain about it, but now I repeated a couple of tests and I don't know why it is working properly... The UDP thread's priority equals 5, the same priority has my sending thread. After I lowered my thread's priority to be lesser than udp's (lets say 6) all began to work properly. Today I retried the test and all seems to work no matter what my thread priority is. So maybe there was another bug in my code. Sorry to bother you. But I have two more things that puzzles me. Why the program is aborting as a result of memory access violation after my thread has been: 1) Initialized with flag THREAD_CREATE_WOUT_YIELD 2) Has lower or the same priority as main thread from which it was created. The platform I am running my program on is native (Linux). ___ 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
Re: [riot-devel] Questions on Semtech SX1276 radio device driver
Hi Anon, and once again, welcome to RIOT :-)! Am 12.04.2016 um 12:17 schrieb Anon Anonymous: Hi everyone! I'm new to RIOT and I want to implement LoRa network with using existing RIOT OS networking tools. My transceiver is Semtech SX1276. It's famous LoRa modem for IoT. I want to use it as physical layer for my network. I come up with questions: 1. Where I can get information about all steps that I should perform to implement networking based on this transceiver? I mean from messing with SPI up to network connection. I'm not aware of such kind of porting guide. My proposal would be to read some RIOT code, try to adapt it and open a PR in which you can probably get more concrete help. 2. As far I can see there's two good examples: theCC1101 device driver and AT86RF2xx driver. They're implementing a netdev2 interface, it's good choice for SX1276 radio? netdev2 is the interface of choice, yes. 3. Which IEEE specification or network type fits to the my transceiver as upper layers? It might be the IEEE 802.15.4? I've no experience with LoRa but probably 802.15.4 is not an upper layer for LoRa cause it is a PHY/MAC standardization as well. Isn't 6LowPAN + IPv6 compatible?! 4. Maybe I missing something and there's an already existing port of SX1276 to the RIOT somewhere? Nope, there's no port. Thanks in advance and best regards, Cr0s Best Peter 2016-04-10 20:22 GMT+03:00 Anon Anonymous <anon1644...@gmail.com <mailto:anon1644...@gmail.com>>: Hi everyone! I'm new to RIOT and I want to implement LoRa network with using existing RIOT OS networking tools. My transceiver is Semtech SX1276. It's famous LoRa modem for IoT. I want to use it as physical layer for my network. I come up with questions: 1. Where I can get information about all steps that I should perform to implement networking based on this transceiver? I mean from messing with SPI up to network connection. 2. As far I can see there's two good examples: theCC1101 device driver and AT86RF2xx driver. They're implementing a netdev2 interface, it's good choice for SX1276 radio? 3. Which IEEE specification or network type fits to the my transceiver as upper layers? 4. Maybe I missing something and there's an already existing port of SX1276 to the RIOT somewhere? Thanks in advance and best regards, Cr0s ___ 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
Re: [riot-devel] ReSupport for Microchip MRF24J40 Radio Module
Hi Adika, here is the currently pretty much WIP pull request for the MRF24J40 transceiver: https://github.com/RIOT-OS/RIOT/pull/5099 Any help in reviewing and testing is welcome ;-)! It will take me some days to start the review. Best Peter Am 15.03.2016 um 08:55 schrieb Peter Kietzmann: Hi Adika, it is as usual: took longer than expected. A WIP pull request should be opened soon. I'll force @TobiasFredersdorf ;-) to open it. If you have some experience with that device you can speed up development by (reviewing and) testing then. Best Peter Am 14.03.2016 um 20:59 schrieb Adika Bintang Sulaeman: Hallo Bernhard, I'm trying to use STM32F4 Discovery with MRF24J40 transceiver, but I didn't find the driver for this transceiver. It's a relief to see in this mailing list that you and Tobias are working on this driver and I hope the code will be merged soon. By the way, can I see the code you are working on? Maybe if it is possible I can fork the code through Github. Thank you Hello Malo, thanks a lot for your hint about the atzb-a-233-xpro module. I guess RIOT should support this module out of the box (as a reference for debugging). Best regards, Bernhard --- Hello Peter, shure - you are right - Tobias is working on it and I stay in contact with him. Thanks also a lot for your help! Best regards Bernhard ___ 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
Re: [riot-devel] ReSupport for Microchip MRF24J40 Radio Module
Hi Stefan, thanks for the report! Could save hours of debugging :-). We'll keep that hint in mind. Best Peter Am 18.03.2016 um 10:59 schrieb Stefan Schmidt: Hello. On 18/03/16 10:41, Peter Kietzmann wrote: Hi Adika, here is the currently pretty much WIP pull request for the MRF24J40 transceiver: https://github.com/RIOT-OS/RIOT/pull/5099 Any help in reviewing and testing is welcome ;-)! It will take me some days to start the review. No review comment or testing but some remark from a pitfall we recently fixed in the linux driver for the MRF24J40 With link layer security enabled one can run into trouble if not handling the SECIF interrupt. The situation we had was that it looks like the device stopped receiving frames after a frame with llsec enabled was received. http://www.spinics.net/lists/linux-wpan/msg03556.html http://www.spinics.net/lists/linux-wpan/msg03557.html http://www.spinics.net/lists/linux-wpan/msg03558.html Might be useful for you to know. :) regards Stefan Schmidt ___ 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
Re: [riot-devel] Networking Module does not appear in process list
Hi Bernhard, without looking into details of your problem, just a quick hint from my side: The mac layer (nomac) and the device driver are running in the same thread which should be automatically initialized in our networking examples. I don't remember the name of the thread out of my head... Did that already help a bit? Best Peter Am 02.03.2016 um 22:57 schrieb Bernhard Nägele: Hello everybody, today I tried to get the at86rf2xx working with my board. I have the following statement in the board's Makefile: ifneq (,$(filter gnrc_netif_default,$(USEMODULE))) USEMODULE += at86rf233 USEMODULE += gnrc_nomac endif I tried all the networking examples but no example shows the at86rf2xx networking module when I list the threads. I see all networking threads but not the driver. I tried to include (USEMODULE) the Module in the project makefile and then i tried to invoke the auto_init mechanism on serveral places -> no success. Can you please tell me what I have to do to load the radio module driver? I think it would be a good idea to write down how it should go in a tutorial. It's not very nice for newbies to grep through the source code to find out how it should work and what might go wrong (it a little bit like beeing Sherlock Holmes but without having fun). Question 2 - ifconfig: ifconfig help usage: ifconfig [] From where do I get the if_id ? I think you will get it if you invoke ifconfig without parameters (when you have a network module thread running). Is this true? Thanks a lot! Regards, Bernhard ___ 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
Re: [riot-devel] Support for Microchip MRF24J40 Radio Module
Hi Bernhard, I'm a bit confused. Just some days ago @TobiasFredersdorf stated to work on this. Did you synchronize each others? Regarding the module initialization: Honestly I don't quite understand your doubts. Yes it is a signed 16 bit integer in dBm. The quantization to valid values is done inside the function. It makes things easier for the netdev(2) abstraction. You won't get an OpenLabs transceiver within days. By experience not even within two weeks. If you want to cross-test drivers you could a) get an Atmel samr21-xpro (same transceiver as OpenLaps on board) and run RIOT b) get a Phytec evaluation kit. There you can cross-test with kinetis kw2x transceivers on either RIOT or Linux c) use the MRF24J40 with the Linux driver on a RasPi d) work together with @TobiasFredersdorf. He hast the hardware available. Cheers Peter Am 29.02.2016 um 00:58 schrieb Bernhard Nägele: Hello everybody, today I started to port the AT86RF2XX driver for the MRF24J40 radio module. Hier I have 2 question: 1. At the module initialization I found the following comment: /** * @brief Set the transmission power of the given device [in dBm] * * If the device does not support the exact dBm value given, it will set a value * as close as possible to the given value. If the given value is larger or * lower then the maximal or minimal possible value, the min or max value is * set, respectively. * * @param[in] dev device to write to * @param[in] txpower transmission power in dBm */ void at86rf2xx_set_txpower(at86rf2xx_t *dev, int16_t txpower); How should the txpower be coded? A int16 value in dBm ??? I don't understand this. The Atmel AT86RF231 has a tx-power range from -17dBm to +3dBm and the MRF24J40 has a range from -30 to 0dBm. How fits this together with that comment above? 2. From where could I get as fast as possible some OpenLabs 802.15.4 modules (delivery should be in 2-3 days, prefered in Germany)? At the store of OpenLabs there is mentioned a delivery time from about 2 weeksthis is to long for my purpose. Best regards Bernhard ___ 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
Re: [riot-devel] netdev2 - some hints about the relationships between the 6lowpan protocol
Hi, AFAIK the nrf24l01+ actually is the radio and it does not support netdev2, neither netdev. That proprietary transceiver has just the lowlevel support currently. There are plans to adapt it to netdev2 "soon" but that device is kind of special. Thus it will be a bit tinkered I guess. Even if it's fun to find a way it won't be my first choice to transmit 6LoWPAN packets over it. Best Peter Am 26.02.2016 um 12:50 schrieb Martine Lenders: Hi, what radio is the nrf24l01p using? The only radio in master currently implementing netdev2 is the cc11xx driver (all others are either Ethernet drivers or not merged yet). As stated before: there is a move to port the IEEE 802.15.4 devices (which are currently implementing the older GNRC-specific interface gnrc_netdev), starting with PR 4646 [1] (with the at86rf2xx radio). Cheers, Martine [1] https://github.com/RIOT-OS/RIOT/pull/4646 2016-02-26 12:43 GMT+01:00 Bernhard Nägele <bernh...@naegele-privat.de <mailto:bernh...@naegele-privat.de>>: Hello everyone, today I compiled the example/gnrc_minimal with the nrf24l01p module included in the boards Makefile.dep file (Riot Release package RIOT-2015.12) . The compile process was successful and the compiler output show the the driver for the radio module was compiled. But when I searched with the debugger for driver subroutines, it seems that they are not really linked into the result. Is there anyone who can explain me where I have to include the driver in the makefile-structure (USEMODULES +=) that it will be involked by the example-application? In the board makefiles? In the application makefiles? Auto-Init? Wherelse? Thank you very much! Best regards, Bernhard ___ devel mailing list devel@riot-os.org <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 -- 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
Re: [riot-devel] Implementing rng
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
Re: [riot-devel] USB BLE HCI protocol
Hi Phanindra, as my previous speakers already mentioned there are several references to start with. Usually when I start work on a new project I begin with google, just to get an overview of the whole thing. Searching for "BLE" will give you several interesting references. One hint besides: There are also some relevant books available, e.g. "Bluetooth Low Energy: The Developer's Handbook". Are you explicitly interested in USB HCI or do I suggest correctly that you are more interested in BLE in general? Anyway, you need to find out where you actually want spend your time and get an understanding of the respective technique. To get familiar with RIOT in general I recommend reading through our wiki (https://github.com/RIOT-OS/RIOT/wiki) that provides some guidelines, tutorials, explanations (etc..) and execute some of our examples and tests. As Johann mentioned, we have some newcomer tasks that usually act as a training for your first contribution to RIOT. Best Peter Am 08.02.2016 um 11:37 schrieb Johann Fischer: Hello Phanindra, Am 08.02.2016 um 11:03 schrieb PHANINDRA SURA: Hello, I would like to work on the above issue, related to Bluetooth low Energy,a topic of my interest. Please tell me the pre-requisites to be learnt for contributing to this task. You need the following hardware: - a Bluetooth compatible transceiver connected to a NXP Kinetis or Atmel SAM[R,D]21 MCU (for these both exist the usb device driver for RIOT). You need the following software support: - a Bluetooth compatible protocol stack (there is no one mainline) Where can I find relevant material to build my knowledge on these protocols. See [1...3], but based on the questions that you ask, I do not think it is an appropriate project for you, maybe one of [4]? [1] https://www.bluetooth.com/specifications [2] http://www.usb.org/developers/docs/ [3] http://lxr.free-electrons.com/source/drivers/bluetooth/btusb.c [4] https://github.com/RIOT-OS/RIOT/labels/Newbie-Task-Candidate -- 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
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jan 13, 2016 2pm - 3pm (RIOT Events)
Hi all, sorry I was in a meeting until now that took longer than expected. Is there still some urgent need for the Biweekly today? Best Peter Am 13.01.2016 um 14:24 schrieb Oleg Hahm: Hi! On Wed, Jan 13, 2016 at 02:16:02PM +0100, Lotte Steenbrink wrote: Martine has added a point to the list but there's no invitation yet, are we waiting or is the meeting cancelled nonetheless? :) I would say - if it's not too late - please, go ahead and start. Any of the maintainer team should have the credentials for the RIOT placecam account to initiate the meeting. Cheers, Oleg ___ 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
Re: [riot-devel] Hack'n'ACK October '15
Hi Haoyang, I'm not quite sure if I got your question. But I can try to solve some confusion. Se me comments inline! Am 29.10.2015 um 05:18 schrieb Haoyang Yu: Thanks Peter, I encountered an question about DEFAULT program. the _netif_send is the underlying function for txtsnd, it use genre_netapi_send(dev, pkt) to send the packet. But in pkt_dump process running background, I notice the _eventloop(void *arg), is the codes in charge of printing. The question is: - The command "txtsnd" in the default example *sends* plain data over an interface, without using other protocols - netapi is an IPC mechanism to communicate between modules/threads in the network-stack - pkd_dump you can understand as a *receiver* thread. You register it for some kind of protocol and if this kind is received, pkt_dum just prints the packets contents to the console gnrc_netapi_send is sending GNRC_NETAPI_MSG_TYPE_SND, but in _eventloop, it is the GNRC_NETAPI_MSG_TYPE_RCV type, because the stdout result shows “PKTDUMP: data received:”. Is there any problem? - GNRC_NETAPI_MSG_TYPE_SND and GNRC_NETAPI_MSG_TYPE_RCV are two types of the communication mechanism netapi. Like the names already say, one type is used when there is data to send (network-stack from top to bottom) and the other is used when there is data received (network-stack bottom to top). If you are still confused, could you explain your scenario and the existing problem in a bit more detail? Thanks, Haoyang Cheers, Peter On Oct 28, 2015, at 05:12, Peter Kietzmann <peter.kietzm...@haw-hamburg.de <mailto:peter.kietzm...@haw-hamburg.de>> wrote: Hi Haoyang, yesterday it was too late for joining the session. We've already closed the conference at that time. Usually we start the Hack'n'ACK about 17:30 p.m. CET. If you want to join discussions you can also follow the virtual meetings that take place on wednesdays at 2 p.m. CET *if* someone put content in a prepared pad. If I see it correctly this pad should be the one for the next potential conference: http://riot.pad.spline.de/23? Alternatively you can use this list to discuss anything :-). Best, Peter Am 27.10.2015 um 22:32 schrieb Haoyang Yu: Hi Martine, What is the actual time for the Hack’n’ACK meeting, I want to join to discuss with RIOTers. Thanks, Haoyang On Oct 27, 2015, at 12:02, Martine Lenders <mlend...@inf.fu-berlin.de <mailto:mlend...@inf.fu-berlin.de>> wrote: Hello fellow RIOTers, Cenk and I are holding the castle for tonight's Hack'n'ACK at FU Berlin. You can join via your favorite PlaceCam link: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- If you never used PlaceCam before, please refer to [1] Lots of fun and merges tonight, Martine [1] https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation ___ devel mailing list devel@riot-os.org <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 -- 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 <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 -- 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
Re: [riot-devel] Hack'n'ACK October '15
Hi Haoyang, yesterday it was too late for joining the session. We've already closed the conference at that time. Usually we start the Hack'n'ACK about 17:30 p.m. CET. If you want to join discussions you can also follow the virtual meetings that take place on wednesdays at 2 p.m. CET *if* someone put content in a prepared pad. If I see it correctly this pad should be the one for the next potential conference: http://riot.pad.spline.de/23? Alternatively you can use this list to discuss anything :-). Best, Peter Am 27.10.2015 um 22:32 schrieb Haoyang Yu: Hi Martine, What is the actual time for the Hack’n’ACK meeting, I want to join to discuss with RIOTers. Thanks, Haoyang On Oct 27, 2015, at 12:02, Martine Lenders <mlend...@inf.fu-berlin.de <mailto:mlend...@inf.fu-berlin.de>> wrote: Hello fellow RIOTers, Cenk and I are holding the castle for tonight's Hack'n'ACK at FU Berlin. You can join via your favorite PlaceCam link: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- If you never used PlaceCam before, please refer to [1] Lots of fun and merges tonight, Martine [1] https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation ___ devel mailing list devel@riot-os.org <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 -- 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
Re: [riot-devel] Energy Consumption on samr21_xpro
Hi Ilias,
I'd love to have such possibility, but from my knowledge there is no
coulomb counter (or similar) on that board or on any common hardware. If
you find a way, please let me know :-) !
Cheers,
Peter
Am 23.10.2015 um 11:31 schrieb Ilias Seitanidis:
Hi Peter,
First of all I want to thank you for your fast reply.I want to measure
the energy consumption from the board using software without external
tools as an ammeter.
Thank you.
Best ,
Ilias
2015-10-23 11:22 GMT+02:00 Peter Kietzmann
<peter.kietzm...@haw-hamburg.de <mailto:peter.kietzm...@haw-hamburg.de>>:
Hi Ilias,
and welcome to RIOT! This board has a jumper on it's current
monitor header pins (next to the user programmable button). You
can replace the jumper by an ammeter and measure the current.
Compare the boards user guide
http://www.atmel.com/Images/Atmel-42243-SAMR21-Xplained-Pro_User-Guide.pdf
Best,
Peter
Am 23.10.2015 um 11:07 schrieb Ilias Seitanidis:
Hi , I am new to wsn and I am wondering if there is a way to
measure the energy consumption of the atmel samr21_xpro .Thank
you in advance!
___
devel mailing list
devel@riot-os.org <mailto: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 <tel:%2B49-40-42875-8426>
Web:http://www.haw-hamburg.de/inet
___
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
--
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
Re: [riot-devel] Newcomer Query: Feature list/TODO items
T/blob/master/drivers/include/nvram.h https://github.com/RIOT-OS/RIOT/blob/master/boards/mulle/include/mulle-nvram.h https://github.com/RIOT-OS/RIOT/blob/master/boards/mulle/board.c 3: I've interest in Networking aspects too, however, I do not have any practical exposure to lower layers such as 802.15.4, 6loWPAN and have limited experience with IPv6. Thanks, Amit Best, Peter ___ 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
Re: [riot-devel] Blink Led
Hi Toza, there are macros for LED usage. Compare https://github.com/RIOT-OS/RIOT/blob/master/boards/ek-lm4f120xl/include/board.h#L49. You just need to include the board.h from you application and call these macros to turn the on board LEDs on, off or toggle them. If you want blinking, you could periodically use "toggle" in a loop, with a delay (use xtimer) between two calls. Best, Peter Am 30.09.2015 um 05:33 schrieb mtz kbb: Hello Could you please give an example on how to blink led in RIOT, if you can help me translate some arduino examples to RIOT, that would be wonderful. I want to migrate my code to RIOT. I am using ti launchpad ek-lm4f120xl <https://github.com/RIOT-OS/RIOT/tree/master/boards/ek-lm4f120xl> Best regards toza ___ 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
Re: [riot-devel] Support for Nordic nRF2401 RF Transceivers.
Hi Rakendra, and welcome to RIOT! I think no one used the nRF2401A. We only have (low-level) support for the nRF24L01+. Also note Nordics recommendation: " This product is not recommended for new designs. Nordic recommends the nRF24L01+ or for a System-on-Chip solution either the Nordic nRF24LE1 or nRF24LU1+." Why do you need the "A" version? What's the benefit? Best, Peter Am 29.09.2015 um 11:28 schrieb rakendra thapa: Hello Everyone, Has anyone been using nRF2401A already in their project ? I don' t see it currently supported in RIOT. I am starting to work with it and if any one else is already working on it, do let me know. A head start will be great :) *https://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF2401A* Thanks and Regards, Rakendra ___ 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
Re: [riot-devel] Support for Nordic nRF2401 RF Transceivers.
Hi Rakendra, I didn't find informations about "nRF120 transceiver boards", could you provide a link? Anyway, we don't have support for that board. Regarding the nRF24L01+ you can find the driver here: https://github.com/RIOT-OS/RIOT/tree/master/drivers/nrf24l01p and a small test here: https://github.com/RIOT-OS/RIOT/tree/master/tests/driver_nrf24l01p_lowlevel Note that it is currently just low-level support. Did you check if there is other hardware support in RIOT that might fulfil your requirements? Best, Peter Am 29.09.2015 um 20:29 schrieb rakendra thapa: Hello Peter, Thanks for your reply and pointing out the difference. Will take care of this detail while buying these. (I don't think nRF2401A will even be available now) So, RIOT-OS does have low level support for nRF120 transceiver boards. Is it ? That will be helpful to get started. Thanks and Regards, Rakendra On Tue, Sep 29, 2015 at 3:04 PM, Peter Kietzmann <peter.kietzm...@haw-hamburg.de <mailto:peter.kietzm...@haw-hamburg.de>> wrote: Hi Rakendra, and welcome to RIOT! I think no one used the nRF2401A. We only have (low-level) support for the nRF24L01+. Also note Nordics recommendation: " This product is not recommended for new designs. Nordic recommends the nRF24L01+ or for a System-on-Chip solution either the Nordic nRF24LE1 or nRF24LU1+." Why do you need the "A" version? What's the benefit? Best, Peter Am 29.09.2015 um 11:28 schrieb rakendra thapa: Hello Everyone, Has anyone been using nRF2401A already in their project ? I don' t see it currently supported in RIOT. I am starting to work with it and if any one else is already working on it, do let me know. A head start will be great :) *https://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF2401A* Thanks and Regards, Rakendra ___ devel mailing list devel@riot-os.org <mailto: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 <tel:%2B49-40-42875-8426> Web:http://www.haw-hamburg.de/inet ___ 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 -- 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
Re: [riot-devel] RIOT preview for TI cc3200
Hi Attilio,
nice! Looking forward to see you PR ;-) .
Best,
Peter
Am 25.09.2015 um 14:27 schrieb Attilio Dona:
Ok,
just for sharing a little roadmap I'm starting to work on the wifi
module integration.
I need a little bit of time for this task, I think some weeks.
Could make sense create a PR after the completion of this task?
Let me know!
greetings
Attilio
ps. For shell echoing I needed to apply the following patch to
shell/shell.c (I think this affect all systems that use newlib)
@@ -256,6 +256,9 @@ static int readline(char *buf, size_t size)
else {
*line_buf_ptr++ = c;
_putchar(c);
+#ifdef MODULE_NEWLIB
+fflush(stdout);
+#endif
}
}
}
On Thu, Sep 24, 2015 at 1:29 PM, Hauke Petersen
<hauke.peter...@fu-berlin.de <mailto:hauke.peter...@fu-berlin.de>> wrote:
Hej,
On 03.09.2015 23:22, Attilio Dona wrote:
Ciao Kaspar,
I agree with RIOT philosophy, so a rewrite could be a nice thing,
but I also think that this is not a top priority now, at least
for me ...
If someone else wants to contribute it would be great!
One more thing to consider is that cc3200 has:
* 256 Kb of RAM
* an external SD serial flash card memory where to flash the image
* an internal ROM memory burned into the chip that hosts the
bootloader and the driverlib "ROM version" (directly from
factory)
So from version ES1.33 it seems possible to link to the ROM
version of driverlib for resource optimizations (so could be a
waste to throw away the driverlib API?)
IMHO that is exactly what we do!
@kaspar: in this particular case (as for the LM4F120 launchpad
board) it makes very much sense to use the provided hardware
abstraction to implement RIOTs periph interfaces, as the code used
by this HAL layer is burned into read-only ROM directly on the CPU
and thus does not use any additional memory...
Cheers,
Hauke
I have not tested this setup yet, but I think could be a trail to do.
Attilio
On Wed, Sep 2, 2015 at 9:36 AM, Kaspar Schleiser
<kas...@schleiser.de <mailto:kas...@schleiser.de>> wrote:
Hey Attilio,
Thanks a lot for your effort on getting this board supported!
On 09/01/15 21:32, Attilio Dona wrote:
> I need just some confirmation, the most important is
> that driverlib from TI is license compatible with RIOT
> (cpu/cc32000/driverlib and cpu/cc3200/inc files used as HAL
for the
> drivers).
I just took a quick look, but it seems like "driverlib" is
TI's own
hardware abstraction C code.
Our philosphy here was always to not use vendor-supplied HAL
code and
instead rewrite hardware support from scratch.
While that requires a little more effort for a new port in the
beginning, we usually end up with a lot cleaner, smaller,
more-to-the
point code that can more easily be shared between platforms.
(The license used by driverlib looks fine actually.)
Kaspar
___
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 <mailto:devel@riot-os.org>
https://lists.riot-os.org/mailman/listinfo/devel
___
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
--
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
Re: [riot-devel] Suopported platform
Hi Rupesh, and welcome to RIOT! The supposed platform looks quite interesting, but as far as I see it, we currently don't have support for that MCU. If you are interested and have some capacities, you could try to port the platform for RIOT, according to our porting guide [1]. I think there will be some people (including me), that will help you. Also you could cheat a bit by comparing to the 8Bit Atmega2560 or several other 32Bit platforms. Regarding the on-chip receiver, you should fulfill the netdev interface [2] (attention! this may change slightly during the next weeks) and with that, be able to run our gnrc network-stack. For the transceiver driver you may also cheat a bit by comparing other 802.15.4. drivers, e.g. for the AT86RFxx family. Best, Peter [1] https://github.com/RIOT-OS/RIOT/wiki/Porting-Guide [2] https://github.com/RIOT-OS/RIOT/blob/master/sys/include/net/gnrc/netdev.h Am 24.08.2015 um 09:39 schrieb Rupesh Basnet: Hello people, I want to use RIOT in avr-zigduino platform. The development board is zigduino r2. It has ATmega128RFa1 processor and on chip low power 2.4GHz radio for zigbee and IEEE 802.15.4. The link to the board manual is here: http://wiki.logos-electro.com/zigduino-r2-manual ___ 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
Re: [riot-devel] New Bie at RIOT - For Initial Guidance
Hi Sherry, and welcome to RIOT! Yes, this is the right place for your concern. Nice to hear that you'd like to contribute. Honestly I didn't get what exactly you want to do. But here are some interesting links: Open issues in RIOT, nice if they were fixed :-) : https://github.com/RIOT-OS/RIOT/issues Here is a list of supported platforms. If you are about to buy a board, I'd recommend one of the arm cortex-m platforms. E.g. the STM-boards are cheap. The Ateml board has an on-board 802.15.4. transceiver. https://github.com/RIOT-OS/RIOT/wiki/RIOT-Platforms This are our development procedures and coding conventions: https://github.com/RIOT-OS/RIOT/wiki/Development-procedures https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions I hope that helped at least a bit. If not, just ask again! Best, Peter Am 11.07.2015 um 13:30 schrieb sherry samuel: Hello All, I am newcomer at RIOT. I am a Software Devoper working for IOT. Sorry for spamming your boxes, for I am not sure whether this is the right place to send this query. I would like to contribute to the RIOT. I have already downloaded the source from GITHUB. I have joined the mailing list and commits. I also have gone through the initial guide for new comers. Currently I don't have a Development Board. But for the past few week I was debugging through gdb for native target for example program. Can any one of you guide me , what to be done for next steps and for target board fixes how the development and testing to be done ? Regards Sherry ___ 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
Re: [riot-devel] Using Code composer studio to compile RIOT
Hi Balaji, there is support for the MSP430. AFAIK nobody tried configuring Code Composer Studio. In general we are focused on open software. There is a tutorial [1] about using Eclipse, if this is also interestiong for you. @all please correct me if I'm wrong! Best, Peter [1] https://github.com/RIOT-OS/RIOT/wiki/Using-the-Eclipse-IDE-for-C-and-CPP-Developers,-Howto Am 06.06.2015 um 09:48 schrieb Balaji Dhayabaran: Hi, I am using Wireless Sensor Node which uses MSP430 microcontroller. From your website I learnt that RIOT has been ported for MSP 430 already. Now I have a question. Can I use code composer studio to compile and develop projects in RIOT? If it is possible can you please give me the procedures about how to do it? Regards, Balaji Dhayabaran ___ 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
Re: [riot-devel] samr21-xpro / watr.li ADC
Hi Ludwig, in general I would do so. As part of watrli I already worked with this PR and improved some things locally (which I mostly commented inside the PR). IIRC @wiredsource stated several times that he wants to finish the implementation. @wiredsource are you reading this? What's the status from your side? Best, Peter Am 06.06.2015 um 17:31 schrieb Ludwig Ortmann: Hi, I just noticed that the samr21-xpro still has no ADC support and was wondering if maybe someone from the watr.li team could upstream their implementation..? Or take over the existing PR https://github.com/RIOT-OS/RIOT/pull/2063 ? Cheers, Ludwig ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- 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
[riot-devel] Hack'n'ACK tonight
Hi everyone, here is the link for tonight's Hack'n'ACK. http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- As always, see here [1] for more information on how to join. Cheers, Peter [1] https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation -- 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
[riot-devel] Biweekly virtual meeting
Hi everyone, here is the link for the biweekly meeting: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- This is the first time that I started this conference, hope it works. For instructions of joining see: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- Cheers, Peter -- 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
Re: [riot-devel] Measuring power on the iot-lab testbed
Hi Gaëtan, I tested the RIOT hello-world- and also your simple_idle example on different nodes that are noted as ok in [1] (1, 9, 35, 40, 41 45). The spurious peaks were existent in all experiments. Regarding the sawtooth-problem for me it still seems to be RIOT-dependant because the sawtooth does not apply to your simple_idle example. This questions addresses all RIOTers. Looking forward to get helpful feedback by anyone :-)! Cheers, Peter [1] https://github.com/iot-lab/iot-lab/issues/148 Am 26.04.2015 um 11:03 schrieb Gaëtan Harter: Hi Peter, don't worry, I think it's an IoT-Lab problem. Some nodes have this unstable consumption graph, it's tracked on the following issue: https://github.com/iot-lab/iot-lab/issues/148 Can you try with one good node: like Grenoble 1+9+12 and see if the problem remains? I added iot-lab admin as CC to let us follow the discussions. Regards, Gaëtan - IoT-Lab team On 04/25/2015 05:13 PM, Peter Kietzmann wrote: Hi devs, after measuring the consumption of an iot-lab_M3 node (on the iot-lab testbed) I can't explain myself the graph of the measured power over time in [1] (please note that I zoomed the plot to better visualize the problem). It is just the normal example in RIOT/examples/hello-word. You can find my measuring profile which I used on the testbed in [2]. (i) There is a sawtooth-signal where one tooth lasts approx. 30 seconds (ii) There is some kind of cycle which pulses each 1.5 seconds (This seems to be a known problem of the measurement unit) Any ideas what this is or where it comes from? Best, Peter [1] https://drive.google.com/file/d/0B2ig4jIQ4JbHSWpvaTZyOGRCb00/view?usp=sharing [2] https://drive.google.com/file/d/0B2ig4jIQ4JbHS3FVdTc0TnZ5eDA/view?usp=sharing ___ 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
