Mrf24j40 #5792

Nenaco · 2016-08-31T15:03:16Z

Work in progress - Support for radio module MRF24J40. Please feel free to make changes and help to make this radio work together with netdev2.

OlegHahm · 2016-08-31T15:55:44Z

Cool!

OlegHahm · 2016-09-02T18:42:56Z

@PeterKietzmann, you have the device available at HAW?

miri64 · 2016-09-09T07:44:42Z

drivers/mrf24j40/mrf24j40_getset.c

+                                         0x78, 0x70, 0x68, 0x60, 0x58, 0x50, 0x48, 0x40,
+                                         0x38, 0x30, 0x28, 0x20, 0x18, 0x10, 0x08, 0x00 };
+
+


That's a lot of empty space o___o

Hello miri64,
thanks a lot for the hint - I 'll make a correction tomorrow.

Regards,
Neo

I have a small hint why the mrf24j40 doesn't send data up to now.
The MRF24J40 seem to expect a different FIFO format for Receive FIFO and Transmit-Normal-FIFO. If I interpret the figure 3-11 inside the datasheet it seems that the TX FIFO needs the "Header Length" inserted at address 0.
Has anyone an idea where/how to get the header length?

Regards,
Neo

If I understand the figure 3-11 of the datasheet right and if netdev2 is configured to use long-address mode - then the "Header Length" is 23 - is this correct?

Regards,
Neo

…-FIFO -> Header-Length

PeterKietzmann · 2016-10-05T06:37:04Z

Hi @Nenaco! Is this PR still WIP? Where are you at?

Nenaco · 2016-10-09T20:22:59Z

Hello Peter,
yes, it is still WIP. The code which is at the moment in the PR is able
to send data without retries. I have also a version which is able to
handle retries (not yet checked in).
This works for me at the moment. Therefore I don't force the development
at the moment.
I hoped that someone else could help to bring the driver to a higher level.

Regards,
Neo

Am 05.10.2016 um 08:37 schrieb Peter Kietzmann:

Hi @Nenaco https://github.com/Nenaco! Is this PR still WIP? Where
are you at?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5792 (comment), or
mute the thread
https://github.com/notifications/unsubscribe-auth/ATsbrONAPGRDxwyACSVH5NxtZ9ccYk26ks5qw0WXgaJpZM4Jxtzc.

miri64

Please use the default values provided in #5977

miri64 · 2016-10-22T12:50:37Z

drivers/include/mrf24j40.h

+/**
+ * @brief   Maximum possible packet size in byte
+ */
+#define MRF24J40_MAX_PKT_LENGTH        (127)


Please consider using the values provided in #5977 instead

miri64 · 2016-10-22T12:50:44Z

drivers/include/mrf24j40.h

+ */
+#define MRF24J40_MIN_CHANNEL           (11U)
+#define MRF24J40_MAX_CHANNEL           (26U)
+#define MRF24J40_DEFAULT_CHANNEL       (26U)


In addition, you should set this channel during initialization.
EDIT: After startup, ifconfig showls channel 0 but 802.15.4 has no channel 0.

miri64 · 2016-10-22T12:50:50Z

drivers/include/mrf24j40.h

+ *
+ * @todo    Read some global network stack specific configuration value
+ */
+#define MRF24J40_DEFAULT_PANID         (0x0023)


miri64 · 2016-10-22T12:51:02Z

drivers/include/mrf24j40.h

+ *  31 -> -0dB
+ */
+
+#define MRF24J40_DEFAULT_TXPOWER       (31U)


phectori · 2016-11-08T14:30:35Z

drivers/include/mrf24j40.h

+/**
+ * @brief   Device descriptor for MRF24J40 radio devices
+ */
+typedef struct {


Shouldn't there be a "uint8_t header_len" in this struct? As used in mrf24j40.c, line 202.

I think @phectori is right. @Nenaco I'm wondering how you even compiled this way, or was removal by accident?

phectori · 2016-11-13T14:02:51Z

The driver works for me with some minor changes, see: mrf24j40-test

My test setup consists of two nucleo-f401 boards and two mrf24j40 modules.

The branch in the link above also has a driver test in the tests folder. This is an adaptation of the at86rf2xx test, it sends raw 802.15.4 messages.

I have also tested the "gnrc_networking" and "gnrc_border_router" examples, they both work.

Thank you for this driver!

PeterKietzmann · 2016-11-14T08:55:12Z

drivers/mrf24j40/mrf24j40_getset.c

+     * 24 -> Value = 0xD3
+     * 25 -> Value = 0xE3
+     * 26 -> Value = 0xF3
+     */


Instead of the upper block, just mentino the page where to find this mapping.

PeterKietzmann · 2016-11-14T08:56:25Z

drivers/mrf24j40/mrf24j40_getset.c

+                tmp = mrf24j40_reg_read_short(dev, MRF24J40_REG_TXMCR);
+                tmp &= 0b11100000;
+                tmp |= 0b00011000;
+                tmp |= 0b00000100;


Are there not macros for this usage? It would be cool to see what's gonging on here.

PeterKietzmann · 2016-11-14T15:09:47Z

drivers/mrf24j40/mrf24j40.c

+    mrf24j40_reg_write_short(dev, MRF24J40_REG_WAKECON, MRF24J40_WAKECON_MASK__IMMWAKE);            /* enable Immediate Wake-up mode */
+
+    /* set default options */
+    mrf24j40_set_option(dev, NETDEV2_IEEE802154_PAN_COMP, true);


Option has been removed within #5897

PeterKietzmann · 2016-11-15T14:27:56Z

@phectori what exactly was needed to get gnrc_networking running? Did you try to communicate with an other device than mrf24j40? Are you in charge of a sniffer (e.g. RasPi + 802.15.4 radio)?

phectori · 2016-11-15T14:46:47Z

@PeterKietzmann Alle the changes are in the branch I referred to before. The changes are also listed in this commit: commit

In summary:

For some reason I needed to comment the if-statement at this line: line
I changed the argument types of some of the the functions in the "netdev2_driver_t" structure.
And I added the uint8_t header_len to the mrf24j40_t struct.

I don't quite understand why the first change is necessary, maybe you have an idea?

I only tested the mrf24j40 with another mrf24j40, both on the same board (nucleo-f401). I do not have a raspberry pi + 802.15.4 radio setup right now.

PeterKietzmann · 2016-11-15T15:11:57Z

Thanks for your quick answer! Yes, I already used your branch and it is really helpful. However, you must have added the mrf24j40 module to your application Makefile or the board Makefile in order to use gnrc_networking with a STM board + external transceiver as network interface, I guess? However, that's not my main point. More looking for the information weather you can be sure about the RF channel in use.

phectori · 2016-11-15T15:27:30Z

Yes, I have added the module to the application Makefile, like in this branch.

Hmm, I'm not sure about the channel. The driver should use channel 26 as defined in mrf24j40_internal.c. The four first bits of that register define the channel, but I have no way to check this actually happens.

Nenaco · 2016-11-15T22:40:58Z

Hello Peter,
that's nice - it seems that there is getting life into the work on that
driver!
What is the further work? Shall I include the inputs into my branch? Or
do you include the
driver into the RIOT-master branch doing the work there ?

Regards
Neo

P.S. sorry for the delay - I was outside for some days

Am 15.11.2016 um 16:12 schrieb Peter Kietzmann:

Thanks for your quick answer! Yes, I already used your branch and it
is really helpful. However, you must have added the |mrf24j40| module
to your application Makefile or the board Makefile in order to use
|gnrc_networking| with a STM board + external transceiver as network
interface, I guess? However, that's not my main point. More looking
for the information weather you can be sure about the RF channel in use.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5792 (comment), or
mute the thread
https://github.com/notifications/unsubscribe-auth/ATsbrCZdfj5N9fUIGFmnq4EZvZjAHayNks5q-cvAgaJpZM4Jxtzc.

PeterKietzmann · 2016-11-16T07:56:38Z

@Nenaco you should definitely address all comments and take care of the code until it fits our coding conventions and works as expected (see our Developement Procedures and Contribution Guidlines). A rebase on the latest RIOT master would be great. In the end (still not defined when this will be) I will merge your code into RIOT master, but not integrate it by myself.
Did you test this device+driver against other 802.15.4 devices? Until now I just set up one stm32f4disco+mrf radio and a sniffer (RasPi + openlabs transceiver). Then I adapted your PR, mainly likein @phectori's branch. Did not see any 15.4 packets in the air. Is there maybe a special frame format or a bug in the channel selection? For example, using ifconfig shows channel 0 (which does not exist in 802.15.4) until a new channel was set. Might also be that the value isn't stored in netdev during initialization. I don't know, I'm asking for some input :-)!

Nenaco · 2016-11-16T18:23:13Z

Hello Peter,
I tested the device against my sniffer (beaglebone green + mrf24j40-cape

promiscous mode + tcpdump) and also against a full custom design
equiped with a stm32-l0 and a at86rf233 radio modul.
I'm using also the beaglebone + mrf24j40 as border router and UDP
traffic runs as expected.
About your problem - In my application code base I have sometimes
controlled the MCU pins directly by MCU-registers accesses.....I have
also used my own pin and interface configuration.
Maybe I have forgotten something or removed something accidetally.
Phecotri's board seams to work with the code - therefore I think it
could not be too worse.
I wanted to clean-up a little bit more with the Realese 2016.10.
On which SPI interface (AF?)/GPIOs have you connected the MRF24J40?
Maybe I can also connect a MRF24J40 module onto the stm32f4discovery
board.....I have also one.......
Have you got register-access to all registers? 8-bit/16-bit registers?
Do you see interrupts comming from the MRF?
Best regards

Neo

Am 16.11.2016 um 08:56 schrieb Peter Kietzmann:

@Nenaco https://github.com/Nenaco you should definitely address all
comments and take care of the code until it fits our coding
conventions and works as expected (see our Developement Procedures
https://github.com/RIOT-OS/RIOT/wiki/Development-procedures and
Contribution Guidlines
https://github.com/RIOT-OS/RIOT/wiki/Contributing-to-RIOT). A rebase
on the latest RIOT master would be great. In the end (still not
defined when this will be) I will merge your code into RIOT master,
but not integrate it by myself.
Did you test this device+driver against other 802.15.4 devices? Until
now I just set up one stm32f4disco+mrf radio and a sniffer (RasPi +
openlabs transceiver). Then I adapted your PR, mainly likein @phectori
https://github.com/phectori's branch. Did not see any 15.4 packets
in the air. Is there maybe a special frame format or a bug in the
channel selection? For example, using |ifconfig| shows channel |0|
(which does not exist in 802.15.4) until a new channel was set. Might
also be that the value isn't stored in netdev during initialization. I
don't know, I'm asking for some input :-)!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5792 (comment), or
mute the thread
https://github.com/notifications/unsubscribe-auth/ATsbrNxfmUjcZr2CW6CP376GCLrr6GBVks5q-rc5gaJpZM4Jxtzc.

phectori · 2016-12-08T19:23:22Z

Any progress here?

@Nenaco If you have no time to finish the driver, I have no problem starting a new PR and making the changes suggested here.

PeterKietzmann · 2017-01-20T09:56:28Z

@Nenaco would you mind if we continue in #6277 and close this PR? I just gave it a shot with the other PR and it works pretty great at a first sight. And it also contains your work and your commits. By the way, thanks a lot for your pioneer work!

PeterKietzmann · 2017-01-20T13:20:45Z

Ok, there is progress in #6277, let's continue there. @Nenaco would be great if you 'd scan over the code there.

Nenaco added 2 commits August 31, 2016 16:44

Support for radio chip MRF24J40 - Work In Progress

72e370a

added new files to project

3303541

PeterKietzmann added State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Area: drivers Area: Device drivers labels Aug 31, 2016

Nenaco added 2 commits August 31, 2016 22:23

doing some cosmetic

9026b0c

cosmetics2

a9452c8

miri64 assigned OlegHahm Sep 2, 2016

OlegHahm assigned PeterKietzmann and unassigned OlegHahm Sep 2, 2016

Introduced PSEUDO-State to get near to the states of the AT86RF2XX

2c301f9

miri64 reviewed Sep 9, 2016
View reviewed changes

Nenaco added 2 commits September 9, 2016 22:06

removed empty lines in mrf24j40_getset.c

a8d451b

first successful transmit. Added one Byte at start of Transmit-Normal…

364bfd2

…-FIFO -> Header-Length

Nenaco added 2 commits October 26, 2016 20:31

receiving is now working

b7d8cee

again doing some clean-up

567d9f3

miri64 reviewed Nov 1, 2016

View reviewed changes

phectori reviewed Nov 8, 2016

View reviewed changes

PeterKietzmann reviewed Nov 14, 2016

View reviewed changes

bergzand mentioned this pull request Dec 31, 2016

drivers/mrf24j40: Add mrf24j40 radio support #6277

Merged

PeterKietzmann closed this Jan 20, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Mrf24j40 #5792

Mrf24j40 #5792

Nenaco commented Aug 31, 2016

OlegHahm commented Aug 31, 2016

OlegHahm commented Sep 2, 2016

miri64 Sep 9, 2016

Nenaco Sep 9, 2016

Nenaco Sep 9, 2016

Nenaco Sep 9, 2016

PeterKietzmann commented Oct 5, 2016

Nenaco commented Oct 9, 2016

miri64 left a comment

miri64 Oct 22, 2016

miri64 Oct 22, 2016

PeterKietzmann Nov 15, 2016 •

edited

Loading

miri64 Oct 22, 2016

miri64 Oct 22, 2016

phectori Nov 8, 2016

PeterKietzmann Nov 14, 2016

phectori commented Nov 13, 2016

PeterKietzmann Nov 14, 2016

PeterKietzmann Nov 14, 2016

PeterKietzmann Nov 14, 2016

PeterKietzmann commented Nov 15, 2016

phectori commented Nov 15, 2016 •

edited

Loading

PeterKietzmann commented Nov 15, 2016

phectori commented Nov 15, 2016 •

edited

Loading

Nenaco commented Nov 15, 2016

PeterKietzmann commented Nov 16, 2016

Nenaco commented Nov 16, 2016

phectori commented Dec 8, 2016

PeterKietzmann commented Jan 20, 2017

PeterKietzmann commented Jan 20, 2017

		0x78, 0x70, 0x68, 0x60, 0x58, 0x50, 0x48, 0x40,
		0x38, 0x30, 0x28, 0x20, 0x18, 0x10, 0x08, 0x00 };

Mrf24j40 #5792

Mrf24j40 #5792

Conversation

Nenaco commented Aug 31, 2016

OlegHahm commented Aug 31, 2016

OlegHahm commented Sep 2, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PeterKietzmann commented Oct 5, 2016

Nenaco commented Oct 9, 2016

miri64 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PeterKietzmann Nov 15, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

phectori commented Nov 13, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PeterKietzmann commented Nov 15, 2016

phectori commented Nov 15, 2016 • edited Loading

PeterKietzmann commented Nov 15, 2016

phectori commented Nov 15, 2016 • edited Loading

Nenaco commented Nov 15, 2016

PeterKietzmann commented Nov 16, 2016

Nenaco commented Nov 16, 2016

phectori commented Dec 8, 2016

PeterKietzmann commented Jan 20, 2017

PeterKietzmann commented Jan 20, 2017

PeterKietzmann Nov 15, 2016 •

edited

Loading

phectori commented Nov 15, 2016 •

edited

Loading

phectori commented Nov 15, 2016 •

edited

Loading