I forgot, but was there a particular reason having these on Mondays?
For me personally it would be easier to tune in any other day of the week. I’m
just generally asking since my actual RIOT development availability is very
> On Nov 28, 2017, at 4:59 AM,
Thanks for the initiative!
I will try to tune in.
Without wanting to start a tools discussion, I had very good experiences with
larger groups using zoom.us.
> On Nov 3, 2017, at 4:29 PM, Francisco Javier Acosta Padilla
atures which is applicable mostly to our
> Do you know of any company having knowledge/time/ doing such stuff?
> thanks in advance
> On Tue, 31 Oct 2017 15:35:52 -0700, Thomas Eichinger wrote:
>> Hi Richard,
On 31 Oct 2017, at 14:42 PDT(-0700), Richard Klingler wrote:
Hmm.. I see you sometimes joining/leaving #riot-os (o;
That might be me, different Thomas. ;)
Yes the different networks is very interesting...and definitively a
not sure if it is easily done like adding a
which manages the duty cycling and wake scheduling, while the PAN
management part (I think it is called MAC services in the 802.15.4
standard) would run as a higher layer on top of it.
On Wed, Sep 20, 2017 at 10:37 PM, Thomas Eichinger
the framing functionality from the send/recv code
and let the MAC layer handle it internally, and keep the 802.15.4
layer in the same thread as the netdev driver, like gnrc_netdev does
On Wed, Sep 20, 2017 at 12:16 AM, Thomas Eichinger
On 19 Sep 2017, at 13:24 PDT(-0700), Oleg Hahm wrote:
On Sun, Sep 17, 2017 at 02:37:39PM -0700, Thomas Eichinger wrote:
A while ago I worked on adding support for MAC commands and
standard describes like channel scanning and automatic association of
Dear fellow RIOTers,
tl;dr: Do we see the need to be IEEE 802.15.4 compliant?
RIOT so far does not support anything other than beacon, data, and ack
frames while the standard says that also reduced-function devices have
to support certain command frames [IEEE802.15.4-2015 7.5.1]. Basically,
Thank you for handling this!
On 8 Aug 2017, at 7:53 PDT(-0700), Oleg Hahm wrote:
> Dear RIOTers,
> due to an immense load of requests on the mailing lists, ten thousands of
> mails got queued over the last days. This lead to a delay for mail delivery up
> to several days.
That's great news and I am stoked to see support for RISC-V in RIOT.
To my knowledge nobody put real effort into that yet. (I'm happy to be
If you need help or guidance on porting please don't hesitate to ask on
Thanks and good luck for your funding
you could try reading out the frame buffer after that
although I am not sure the current mode of operation actually
updates the frame buffer with the ACK frame.
(The data sheet is also kind of unspecific on this.)
Other than that I don't see an easy solution, only porting
I'm very excited to see the KW41Z supported in 802.15.4 mode.
As for your questions regarding NETDEV_EVENT_RX_COMPLETE:
To my knowledge it is not strictly formalized if it should be sent
before or after transmitting the ACK. Generally I think this depends
on the capabilities of the
Alexander Aring <alex.ar...@gmail.com>:
On Wed, May 17, 2017 at 07:56:05PM +0200, Baptiste Clenet wrote:
2017-05-17 17:47 GMT+02:00 Thomas Eichinger <tho...@riot-os.org>:
On 17 May 2017, at 1:14 PDT(-0700), Baptiste Clenet wrote:
According to their example:
2017-05-16 16:42 GMT+02:00 Thomas Eichinger <tho...@riot-os.org>:
If you take a look at figures 37-1 and 37-2 in the data sheet you
linked you can see that IEEE 802.15.4 allows up to 127 bytes for the
MPDU and this includes the FCS.
So if the driver would allow writing 127
If you take a look at figures 37-1 and 37-2 in the data sheet you linked you
can see that IEEE 802.15.4 allows up to 127 bytes for the MPDU and this
includes the FCS.
So if the driver would allow writing 127 bytes into the frame buffer the last
two bytes would indeed be
Great job everybody! And special thanks to Kaspar for handling it this time!
On 10 May 2017, at 4:04 PDT(-0700), Kaspar Schleiser wrote:
> Dear RIOTers,
> we are happy to announce the 11th official release of RIOT:
> --- * RIOT 2017.04 *
Thanks for your feedback. I think there is no such thing as an official
trial period so I understand correctly that this trial period would be a
As far as I get it nobody objects the idea of RIOT as a project joining
People who would
As some of you might have noticed there exists a new initiative hosted
by Linux Foundation called EdgeX Foundry . From their website:
"EdgeX FoundryTM is a vendor-neutral open source project hosted by the
Linux Foundation building a common open framework for Industrial IoT
thank you for sharing the results and thanks a lot to everyone involved
for their contributions to finally reduce the increasingly confusing
"Checks" section in github PRs.
Reading the document provided it seems to me that Jenkins actually
got a better score than Murdock 2. (Please
On 18 Jan 2017, at 11:57 PST(-0800), Oleg Hahm wrote:
On Wed, Jan 18, 2017 at 02:49:37PM -0500, Anthony Merlino wrote:
Here is an example https://gitter.im/Microsoft/vscode
Thanks. Seems rather slow/resource-hungry. Is there a non-Web (or even
a non-GUI) version?
Personally I would be very much stoked to see a port of wolfSSL to RIOT
and I think many others think the same.
Let us know how we can help with it and I'm sure we will figure
On 30 Nov 2016, at 13:09 PST(-0800), kaleb himes wrote:
On 18 Nov 2016, at 1:58 PST(-0800), Oleg Hahm wrote:
This seems to be some real low-cost device, but I wonder how much IoT
Does anybody know if this Wi-Fi chip is capable of 802.11 ad-hoc mode
Well it's a cheap device, that's already something. ;-)
2016-11-18 6:20 GMT+01:00 Thomas Eichinger <tho...@riot-os.org>:
Just got some of these PADI IoT Stamps  into my hands. Did anybody
on this list start working on RIOT support for a R
you could try to add a printf() in the `spi_transfer_byte` function in
stm32f4/periph/spi.c for the `in` pointer and see if there are
reasonable values shown
- to make sure SPI communication is working.
On 3 Aug 2016, at 19:24 CEST(+0200), Adeel Mohammad Malik wrote:
we're happy to help and please keep us posted about your progress.
On 20 Jul 2016, at 18:33 CEST(+0200), Adeel Mohammad Malik wrote:
I will fix my pin configuration tomorrow and see if it works for me.
Thanks for your replies. You guys are really helpful.
please see my answers inline. I hope this helps, let us know if there is
On 20 Jul 2016, at 13:46 CEST(+0200), Adeel Mohammad Malik wrote:
I am struggling a bit to understand how to connect my STM32F4Discovery
board with my AT86RF233
I am a little concerned the coding conventions getting too pedantic
While I agree magic numbers should be avoided, I disagree to introduce
for every single one of them as I do with introducing a static check for
(Using a #define for a number only used once in HW
On 13 Jun 2016, at 9:56 CEST(+0200), Peter Kietzmann wrote:
First I moved the existing cpu/samd21 tree to cpu/samr21. Then
Why? Well *if* there is a need to change the current RIOT code base,
you should open a separate PR for that.
This is a question to all: How comes the Atmel
Congratulations to everybody for their awesome work!
> On Apr 22, 2016, at 4:33 PM, Hauke Petersen
> Dear RIOT developers and users,
> we are happy to announce the seventh official release of the RIOT:
surveys on IoT seem to be en vogue nowadays, here  is a OMA IoT open
source survey which's results could also be interesting.
On 15 Mar 2016, at 6:15 ART(-0300), Emmanuel Baccelli wrote:
our friends from
thanks for pointing out and letting us know about a possible
vulnerability related to the length field. It rose attention to the fact
that we checked it in past versions of the driver but missed it at some
point in transition. With  we should respect this again.
the mbed-lpc1768 according to  doesn't have any network interfaces
as far as I see. Because of this there are no network drivers
implemented and ifconfig doesn't have anything to show. Do you use it
with any kind of extension board?
Woohoo, congratulations to everyone!
> On 10 Jan 2016, at 16:28, Cenk Gündogan wrote:
> Dear RIOT developers and users,
> I am glad to announce the sixth official release of the RIOT operating system:
> --- * RIOT
thank you very much to point us to your work. I didn't find time yet to
but will do for sure. From what you shared with us by now I think this
useful informations we definitely should consider for our driver.
I have to admit when I once started it, the promises
Did you try the following?
DIRS += thingA thingB
INCLUDES += -I$(CURDIR)/include -I$(CURDIR)/thingA -I$(CURDIR)/thingB
module = $(APPLICATION)
This way all code in `app`
I wanted to share my findings regarding flashing an iotlab-m3 board from
OS X 10.11.
The good thing, the 3rd party FTDI driver is not needed anymore. Apple
a FTDI kernel extension for some releases already but I didn't find them
until this release. So, when
great to hear from you and about your interest in RIOT. First of all
I am really sorry for the delayed reply.
In our current approach we pull in the network stack part of OpenWSN
and apply patches with an adaption layer to map OpenWSN's hardware
abstraction to RIOT's driver model.
I got me some NXP pn532 modules some time ago as I heard there is work
on specifying 6LoWPAN over ISO 14443 (which NFC is part of). Beside this
there are a lot of interesting applications you could build in combination
with constraint networks.
Sadly, I didn’t come too far with
On 19 Mar 2015, at 10:54, Oleg Hahm oliver.h...@inria.fr wrote:
Sadly, I didn’t come too far with the driver, as it includes a (more) complex
communication with the module, at least for the pn532, and it was kind of a
private side project. My initial work can be found in .
I can remember having the same problem with the telosb. I traced it down
to the fact, that there are no interrupts triggered. Which is strange
as the same code is working on an other msp430/cc2420 platform (Zolertia Z1).
Maybe a misconfiguration somehow sneaked into the radio driver
source neither as I focused on the driver refactoring.
Looking forward for your review and testing.
On 17 Mar 2015, at 12:42, Joakim Gebart joakim.geb...@eistec.se wrote:
On Fri, Feb 20, 2015 at 10:53 AM, Thomas Eichinger
for helping you with your problem, could share a link to your
code with us? Or/and could you run `make` with command line option
`QUIET=0` and paste the output to pastepin  or a gist ?
On 24 Feb 2015, at 15:19 CET(+0100),
will keep you updated on my findings.
On 18 Feb 2015, at 14:54, Ralph Droms (rdroms) rdr...@cisco.com wrote:
On Feb 18, 2015, at 4:18 AM 2/18/15, Thomas Eichinger
first of all also welcome from my side.
Regarding the RIOT
On 06 Feb 2015, at 09:36, Ludwig Ortmann ludwig.ortm...@fu-berlin.de wrote:
On Fri, Feb 06, 2015 at 09:03:31AM +0100, Oleg Hahm wrote:
Am Thu, Feb 05, 2015 at 02:09:52PM -0800 schrieb Adam Hunt:
There's already a driver for for Atmel's AT86RF231 in the tree and while
maybe you already saw this but github provides a guide to its workflow. 
Its well illustrated, hope it helps.
On 04 Feb 2015, at 19:58, Jan Wagner m...@jwagner.eu wrote:
I was playing with the openocd configuration a bit, mainly
`adapter_speed`, back when support for this was added without
any significant outcome.
Problem is, the EDBG chip, on the bottom of the board, handling
communication with the MCU is specified to run on 1MHz and the
On 30 Dec 2014, at 12:04, shishir tiwari sumit.tiwari1...@gmail.com wrote:
Is Porting for ARC600/ ARC700 (Synopsys) has been done. Any idea?
As far as I know nobody started to port RIOT to Synopsys processors although
seem quite interesting to me. Although, I don’t know how
Thank you all for an amazing year with RIOT!
Looking forward to an exciting year 2015.
Best wishes to you all.
On 24 Dec 2014, at 12:12, Oleg Hahm oliver.h...@inria.fr wrote:
Dear romantic IoTlers,
for those of you not using Twitter (regularly), let me point to
On 15 Dec 2014, at 11:10, Ludwig Ortmann ludwig.ortm...@fu-berlin.de wrote:
As for the general topic of relicensing:
Personally speaking I’m rather pragmatic on this topic and either license is
me *but* I tend to advocate for MIT.
ad contributing back”: Apart from
Mail list logo