New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Basic 802.15.4 driver code based on mrf24j40 #24

Closed
wants to merge 7 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@farcaller
Member

farcaller commented May 7, 2014

This demo can talk to arduino and to contiki mote, which looks awesome. The code, however, isn't finished yet, I'll clean it up in a few upcoming days.

The primary reason for this driver is to raise code complexity and to see how zinc looks if things are starting to get tricky. So far, passing timer around feels a bit cumbersome.

The code doesn't support interrupts yet, as there are no interrupts in hal, that would be next piece of work to do before this PR lands.

Also, this code hardcodes parts of IEEE 802.15.4 MAC, which is a bit unreasonable, but acceptable for the moment. Further improvement should be done to decouple MAC from PHY (more complexity and more challanges).

Still pending:

  • add interrupts support to LPC17xx GPIO
  • add NVIC management code
  • add interrupt handing to mrf code
  • document mrf code

Next steps:

  • decouple 802.15.4 MAC from PHY
@bharrisau

This comment has been minimized.

Contributor

bharrisau commented May 9, 2014

Regarding interrupts - how would you feel about a Erlang/Node.JS style event handler and message passing? It solves the issue of the handler running with the psp, and you don't need that 1.5Kb of flags for the banks.

The event handler would also store a flag to enable/disable. And you would define it in your platform struct. It is still early in the morning, but I think that should all work with static allocation.

@farcaller

This comment has been minimized.

Member

farcaller commented May 9, 2014

I'm not sure I'm getting the idea, any pseudocode to illustrate?

@bharrisau

This comment has been minimized.

Contributor

bharrisau commented May 9, 2014

Roughly

interrupt: GPIOConf {
  pin: map::port2::pin5::GPIO,
  direction: In,
  handlers: [myIntHandler],
}

pub fn myIntHandler(port, pin, risingFalling) {}

Something like interrupt.enableHandler(0) could be added to add some sugar to enable/disable handlers?

@farcaller

This comment has been minimized.

Member

farcaller commented May 9, 2014

That requires some way to get from handler to struct instance and is roughly something I had here minus ownership transfer to GPIOConf.

@bgamari

This comment has been minimized.

Contributor

bgamari commented May 9, 2014

Regarding interrupts, I've tried handling a similar issue in my K20 I2C implementation. I think it ended up being rather nice.

@farcaller

This comment has been minimized.

Member

farcaller commented May 9, 2014

So you rely on signal() to pass control flow to the receiving thread? How do you figure out what thread do you need to wake, if there are several threads waiting on hardware? How do you pass control to thread if it's not actively waiting at all (out of band interrupt)? I assume, you'll need a dedicated task that would just block, right?

I like the concept, but I'm not sure about the above corner cases.

@farcaller

This comment has been minimized.

Member

farcaller commented May 9, 2014

Also I wonder if it's optionally possible to make isr without bottom half at all, in case if someone wants a scheduler-less code running in single execution context.

@bgamari

This comment has been minimized.

Contributor

bgamari commented May 9, 2014

@farcaller, that is right, a condition variable is used to pass control to the receiving thread. Note that in the case above only one thread can use the peripheral at a time; control of the peripheral is represented by a Context object which takes the peripheral lock in its constructor. For this reason I don't need to worry about the several thread case (unless I've misunderstood your concern).

I don't have a good answer for the out-of-band case. You are right that dedicating a task to an event loop would be one way to deal with this. If you had the ability to wait on several critical sections this might not be so bad. The advantage to blocking is that you preclude many concurrency issues, but I can see many cases where you really just want asynchronous notification. This comes with several questions though (e.g. what context will the callback run in? What does this mean for task lifetime?)

@farcaller

This comment has been minimized.

Member

farcaller commented May 9, 2014

Let's say we have a GPIO peripheral (the one I'm dealing with in this PR, actually). It has one ISR that can be triggered by ~60 pins. If you have five buttons, you can't block all five tasks on one single mutex, as they are independent. How would you solve this problem?

@bgamari

This comment has been minimized.

Contributor

bgamari commented May 9, 2014

While there is only one ISR, it really represents five (or sixty?) distinct events; each of these is represented by a separate condition variable. The ISR knows which pin triggered the interrupt; it just signals the appropriate condition variable.

@errordeveloper

This comment has been minimized.

Member

errordeveloper commented Jun 27, 2014

@farcaller would be awesome to have Freescale MKW01 support!

@farcaller

This comment has been minimized.

Member

farcaller commented Jun 27, 2014

I actually had some plans for KW2x-series, if only the reference boards could be a bit cheaper. Anyways, I'm definitely bringing some wireless to zinc, at least for the MRF24J40MA / nRF24L01.

@errordeveloper

This comment has been minimized.

Member

errordeveloper commented Jun 27, 2014

Ah... and nRF51 would be amazing too!

@farcaller

This comment has been minimized.

Member

farcaller commented Jun 9, 2015

This code did rot away by now.

@farcaller farcaller closed this Jun 9, 2015

@farcaller farcaller removed the in progress label Jun 9, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment