Linux IEEE 802.15.4 and 6LoWPAN development
 help / color / mirror / Atom feed
* extending driver mrf24j40
@ 2016-02-20 21:20 smlng
  2016-02-21 12:29 ` Alexander Aring
  0 siblings, 1 reply; 5+ messages in thread
From: smlng @ 2016-02-20 21:20 UTC (permalink / raw)
  To: linux-wpan

Hi all,

I'm using 2 lowpan transceivers on a Raspberry Pi namely openlabs at86rf233 and microchip mrf24j40ma. I found that the latter one seams to be somewhat _incomplete_, that is it doesn't support handles for _reset_ and _wake/sleep_ gpio-pin configuration. Further, this makes connecting the mrf24j40ma to the RasPi pinout inconvenient (IMHO). On the other hand the atmel driver (at86rf230)[1] does support these functions, so I'd like to _port_ the reset and sleep functionality into the mrf24j40 driver[2]. 

Is anybody working on this, and if not: do you think it is useful/worth while doing so? I'm willing to work on that and implement these extension, maybe also restructure/clean up the driver code a little bit in this process.

So any thoughts on this and/or hints, comments ...

Thanks, best
  Sebastian

[1]: http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/drivers/net/ieee802154/at86rf230.c
[2]: http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/drivers/net/ieee802154/mrf24j40.c

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: extending driver mrf24j40
  2016-02-20 21:20 extending driver mrf24j40 smlng
@ 2016-02-21 12:29 ` Alexander Aring
  2016-02-21 12:44   ` Koen
  0 siblings, 1 reply; 5+ messages in thread
From: Alexander Aring @ 2016-02-21 12:29 UTC (permalink / raw)
  To: smlng; +Cc: linux-wpan, Alan Ott, Koen Zandberg

Hi,

Am 02/20/2016 um 10:20 PM schrieb smlng:
> Hi all,
>
> I'm using 2 lowpan transceivers on a Raspberry Pi namely openlabs at86rf233 and microchip mrf24j40ma. I found that the latter one seams to be somewhat _incomplete_, that is it doesn't support handles for _reset_ and _wake/sleep_ gpio-pin configuration. Further, this makes connecting the mrf24j40ma to the RasPi pinout inconvenient (IMHO). On the other hand the atmel driver (at86rf230)[1] does support these functions, so I'd like to _port_ the reset and sleep functionality into the mrf24j40 driver[2]. 

Yes, hard-reset functionality would be nice.

Remember the wake/sleep functionalty is limited only, if the subsystem doesn't use the
transceiver then it will go into sleep mode. Nothing more is supported for powersaving
currently.

> Is anybody working on this, and if not: do you think it is useful/worth while doing so? I'm willing to work on that and implement these extension, maybe also restructure/clean up the driver code a little bit in this process.

ok. Great!

If I remember correctly Koen Zandberg (I cc him here) said something about the
hard-reset functionality @irc, that he plans to implement it.

Koen, do you already working on this or still try to bring mac802154 led-trigger
functionality mainline? :-)

Also I cc "Alan Ott" the maintainer of mrf24j40 driver.

- Alex

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: extending driver mrf24j40
  2016-02-21 12:29 ` Alexander Aring
@ 2016-02-21 12:44   ` Koen
  2016-02-22  9:09     ` smlng
  0 siblings, 1 reply; 5+ messages in thread
From: Koen @ 2016-02-21 12:44 UTC (permalink / raw)
  To: Alexander Aring, smlng; +Cc: linux-wpan, Alan Ott

On 02/21/2016 01:29 PM, Alexander Aring wrote:
> Hi,
>
> Am 02/20/2016 um 10:20 PM schrieb smlng:
>> Hi all,
>>
>> I'm using 2 lowpan transceivers on a Raspberry Pi namely openlabs at86rf233 and microchip mrf24j40ma. I found that the latter one seams to be somewhat _incomplete_, that is it doesn't support handles for _reset_ and _wake/sleep_ gpio-pin configuration. Further, this makes connecting the mrf24j40ma to the RasPi pinout inconvenient (IMHO). On the other hand the atmel driver (at86rf230)[1] does support these functions, so I'd like to _port_ the reset and sleep functionality into the mrf24j40 driver[2]. 
> Yes, hard-reset functionality would be nice.
>
> Remember the wake/sleep functionalty is limited only, if the subsystem doesn't use the
> transceiver then it will go into sleep mode. Nothing more is supported for powersaving
> currently.
>
>> Is anybody working on this, and if not: do you think it is useful/worth while doing so? I'm willing to work on that and implement these extension, maybe also restructure/clean up the driver code a little bit in this process.
> ok. Great!
>
> If I remember correctly Koen Zandberg (I cc him here) said something about the
> hard-reset functionality @irc, that he plans to implement it.
>
> Koen, do you already working on this or still try to bring mac802154 led-trigger
> functionality mainline? :-)
Real life gave me a kick in the nuts, but I haven't forgotten the led
triggers.
>
> Also I cc "Alan Ott" the maintainer of mrf24j40 driver.
>
> - Alex
Hello,

I'm using multiple mrf24j40ma radio's in my setup. I've had some plans
too to extend the driver. Maybe we could collaborate with this since we
seem to have the same ideas. As Alexander said, I've got the reset
functionality on my to-do list, but haven't found time to implement it
yet. I also had the idea to implement some sanity checks in the
interrupt code. Furthermore it might be nice to have some kind of check
in the hw_init code to probe the device somehow and error if the radio
does not respond (correctly).

It would be great if you have time to implement some of these functions.
When I find the time to start working on these things I'll notify you so
we don't do the same work twice :)

Koen



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: extending driver mrf24j40
  2016-02-21 12:44   ` Koen
@ 2016-02-22  9:09     ` smlng
  2016-02-22 12:42       ` Koen Zandberg
  0 siblings, 1 reply; 5+ messages in thread
From: smlng @ 2016-02-22  9:09 UTC (permalink / raw)
  To: Koen; +Cc: Alexander Aring, linux-wpan, Alan Ott

Hi all,

thanks for the replies and input. I'm happy to contribute on the enhancing the mrf24j40 driver and I've some time to spare on that. 

@Koen: briefly said my plan is to _port_ some of the functionality (i.e., reset) from the at86rf230 driver - I know it's a different device but the driver seems to be well written and implements/uses reset, sleep and so on. I think it is a good starting point, or not? Currently I've 1 (maybe 2) mrf24j40ma transceiver(s) at my disposal, and use them with a Raspberry Pi via SPI for testing.

I'll report back, as soon as I got some of the planned _enhancements_ running, maybe you (@Koen) can review and test them as well?

Best
 Sebastian

> Am 21.02.2016 um 13:44 schrieb Koen <koen@bergzand.net>:
> 
> On 02/21/2016 01:29 PM, Alexander Aring wrote:
>> Hi,
>> 
>> Am 02/20/2016 um 10:20 PM schrieb smlng:
>>> Hi all,
>>> 
>>> I'm using 2 lowpan transceivers on a Raspberry Pi namely openlabs at86rf233 and microchip mrf24j40ma. I found that the latter one seams to be somewhat _incomplete_, that is it doesn't support handles for _reset_ and _wake/sleep_ gpio-pin configuration. Further, this makes connecting the mrf24j40ma to the RasPi pinout inconvenient (IMHO). On the other hand the atmel driver (at86rf230)[1] does support these functions, so I'd like to _port_ the reset and sleep functionality into the mrf24j40 driver[2]. 
>> Yes, hard-reset functionality would be nice.
>> 
>> Remember the wake/sleep functionalty is limited only, if the subsystem doesn't use the
>> transceiver then it will go into sleep mode. Nothing more is supported for powersaving
>> currently.
>> 
>>> Is anybody working on this, and if not: do you think it is useful/worth while doing so? I'm willing to work on that and implement these extension, maybe also restructure/clean up the driver code a little bit in this process.
>> ok. Great!
>> 
>> If I remember correctly Koen Zandberg (I cc him here) said something about the
>> hard-reset functionality @irc, that he plans to implement it.
>> 
>> Koen, do you already working on this or still try to bring mac802154 led-trigger
>> functionality mainline? :-)
> Real life gave me a kick in the nuts, but I haven't forgotten the led
> triggers.
>> 
>> Also I cc "Alan Ott" the maintainer of mrf24j40 driver.
>> 
>> - Alex
> Hello,
> 
> I'm using multiple mrf24j40ma radio's in my setup. I've had some plans
> too to extend the driver. Maybe we could collaborate with this since we
> seem to have the same ideas. As Alexander said, I've got the reset
> functionality on my to-do list, but haven't found time to implement it
> yet. I also had the idea to implement some sanity checks in the
> interrupt code. Furthermore it might be nice to have some kind of check
> in the hw_init code to probe the device somehow and error if the radio
> does not respond (correctly).
> 
> It would be great if you have time to implement some of these functions.
> When I find the time to start working on these things I'll notify you so
> we don't do the same work twice :)
> 
> Koen


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: extending driver mrf24j40
  2016-02-22  9:09     ` smlng
@ 2016-02-22 12:42       ` Koen Zandberg
  0 siblings, 0 replies; 5+ messages in thread
From: Koen Zandberg @ 2016-02-22 12:42 UTC (permalink / raw)
  To: smlng; +Cc: Alexander Aring, linux-wpan, Alan Ott

On 22-2-2016 10:09, smlng wrote:
> Hi all,
>
> thanks for the replies and input. I'm happy to contribute on the enhancing the mrf24j40 driver and I've some time to spare on that.
>
> @Koen: briefly said my plan is to _port_ some of the functionality (i.e., reset) from the at86rf230 driver - I know it's a different device but the driver seems to be well written and implements/uses reset, sleep and so on. I think it is a good starting point, or not? Currently I've 1 (maybe 2) mrf24j40ma transceiver(s) at my disposal, and use them with a Raspberry Pi via SPI for testing.
>
> I'll report back, as soon as I got some of the planned _enhancements_ running, maybe you (@Koen) can review and test them as well?
>
> Best
>   Sebastian
Hello,

If you've got any patches that need testing send them this way, I can 
test them. My test setup consists of three raspberry pi's, all of them 
with mrf24j40ma radios. Unfortunately I don't have a logic analyser so I 
can't verify whether reset or wake signals are correctly applied.

Regards
Koen

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-02-22 12:42 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-20 21:20 extending driver mrf24j40 smlng
2016-02-21 12:29 ` Alexander Aring
2016-02-21 12:44   ` Koen
2016-02-22  9:09     ` smlng
2016-02-22 12:42       ` Koen Zandberg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox