linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* IEEE 802.15.4
@ 2009-02-24  0:44 Rahul Jain
  2009-02-24  1:42 ` Inaky Perez-Gonzalez
  0 siblings, 1 reply; 3+ messages in thread
From: Rahul Jain @ 2009-02-24  0:44 UTC (permalink / raw)
  To: linux-wireless

Hello all,

I am working on implementing a Linux device driver for IEEE 802.15.4 NanoLoc 
Chipset for my bachelor's thesis. Currently, I am writing the research 
proposal, and therefore am collecting background information on this topic so 
that I can come up with a concrete work plan. I have no previous experience 
with device drivers as such, however since this is something I really want to 
do I am more than willing to learn.
Now, here is the thing - if someone could point me to some good documentation 
on this topic (device drivers for IEEE 802.15.4) it would help me a lot. The 
NanoLoc chip is capable of range measurement (reasonably accurate) between 
transceivers and the final goal of the project is to realize this. 
I would really appreciate background information on this topic - I do not mind 
RTFM. :) Any pointers would also be deeply appreciated.

Thanks
Rahul Jain
Jacobs University Bremen

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

* Re: IEEE 802.15.4
  2009-02-24  0:44 IEEE 802.15.4 Rahul Jain
@ 2009-02-24  1:42 ` Inaky Perez-Gonzalez
  2009-03-01 23:49   ` Rahul Jain
  0 siblings, 1 reply; 3+ messages in thread
From: Inaky Perez-Gonzalez @ 2009-02-24  1:42 UTC (permalink / raw)
  To: Rahul; +Cc: linux-wireless

On Monday 23 February 2009, Rahul Jain wrote:
> Hello all,
>
> I am working on implementing a Linux device driver for IEEE 802.15.4
> NanoLoc Chipset for my bachelor's thesis. Currently, I am writing the
> research proposal, and therefore am collecting background information on
> this topic so that I can come up with a concrete work plan. I have no
> previous experience with device drivers as such, however since this is
> something I really want to do I am more than willing to learn.

Haven't seen any doc written about it, but what you probably want to do 
is start at top level and figure out answers to:

- what are the usage models?
- what do I want to do with the device?

Once you have those answers, you start to break them down in "requirements",
for lack of a better word. Then you need to implement those "requirements",
which probably will be high level actions that a "client" application would
do, such as (quick dirty list):

- discover available adapters in the system
- have each adapter scan for available connection peers/nodes
- tx/rx information from those peers (this will probably expand a lot)
- etc...

and then you'll have to break the functionality in areas, where do you
implement which functionality?:

- a user space daemon/library/d-bus interface?
  (so many applications can be client of the service and take advantage
   of the high level functionality without reimplementing it); this
  would talk to a very low level kernel API...

- ...implemented by a kernel stack to abstract out the common parts that 
  all the drivers will have to offer

- the drivers themselves doing the bare minimum to expose the interface
  that the kernel stack needs drivers to have.

Sometimes there is no need to do some of those parts, or any (for example,
if all the devices will ever be USB, it could be implemented all in user
space with libusb), but there is normally no way to know that ahead of time
and you just take your best judgement at the time :)

Don't be shy on starting and then realizing you got it wrong from the start.
If you wait to learn everything, you'll never finish. You might have to go
over two or three whole redesign and reimplementation phases until you get
it right. That's not bad at all, as it gives you time to stop, rethink, 
put together all the accumulated knowledge that you lacked at the start and
clean up dead wood.

An example of that model, with things split out, is the bluetooth stack.
If I remember correctly how Zigbee worked, there might be some similarities
you might use for an starting point.

-- 
Inaky

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

* Re: IEEE 802.15.4
  2009-02-24  1:42 ` Inaky Perez-Gonzalez
@ 2009-03-01 23:49   ` Rahul Jain
  0 siblings, 0 replies; 3+ messages in thread
From: Rahul Jain @ 2009-03-01 23:49 UTC (permalink / raw)
  To: Inaky Perez-Gonzalez; +Cc: linux-wireless

On Tuesday 24 February 2009 02:42:39 Inaky Perez-Gonzalez wrote:
> On Monday 23 February 2009, Rahul Jain wrote:
> > Hello all,
> >
> > I am working on implementing a Linux device driver for IEEE 802.15.4
> > NanoLoc Chipset for my bachelor's thesis. Currently, I am writing the
> > research proposal, and therefore am collecting background information on
> > this topic so that I can come up with a concrete work plan. I have no
> > previous experience with device drivers as such, however since this is
> > something I really want to do I am more than willing to learn.
>
> Haven't seen any doc written about it, but what you probably want to do
> is start at top level and figure out answers to:
>
> - what are the usage models?
> - what do I want to do with the device?
>
> Once you have those answers, you start to break them down in
> "requirements", for lack of a better word. Then you need to implement those
> "requirements", which probably will be high level actions that a "client"
> application would do, such as (quick dirty list):
>
> - discover available adapters in the system
> - have each adapter scan for available connection peers/nodes
> - tx/rx information from those peers (this will probably expand a lot)
> - etc...
>
> and then you'll have to break the functionality in areas, where do you
> implement which functionality?:
>
> - a user space daemon/library/d-bus interface?
>   (so many applications can be client of the service and take advantage
>    of the high level functionality without reimplementing it); this
>   would talk to a very low level kernel API...
>
> - ...implemented by a kernel stack to abstract out the common parts that
>   all the drivers will have to offer
>
> - the drivers themselves doing the bare minimum to expose the interface
>   that the kernel stack needs drivers to have.
>
> Sometimes there is no need to do some of those parts, or any (for example,
> if all the devices will ever be USB, it could be implemented all in user
> space with libusb), but there is normally no way to know that ahead of time
> and you just take your best judgement at the time :)
>
> Don't be shy on starting and then realizing you got it wrong from the
> start. If you wait to learn everything, you'll never finish. You might have
> to go over two or three whole redesign and reimplementation phases until
> you get it right. That's not bad at all, as it gives you time to stop,
> rethink, put together all the accumulated knowledge that you lacked at the
> start and clean up dead wood.
>
> An example of that model, with things split out, is the bluetooth stack.
> If I remember correctly how Zigbee worked, there might be some similarities
> you might use for an starting point.

Rather late response here, have been thinking about this a little and had a 
talk with my supervisor. 
Device to be basically used for range measurements (to measure the link 
distance between two nodes).

The work is currently divided between two students - I am supposed to be 
working on the PHY and MAC related part, as I understand it. The other guy is 
supposed to work on connecting USB devices to Linux and then figuring out a 
way to connect this nanoLOC chip through USB and registering it is a IEEE 
802.15.4 network device.

What I am supposed to figure out (or work on) is then the kernel API for IEEE 
802.15.4 devices. (at least that is how I understand the task distribution) 
Now, I had a look at the mac80211 project and that is a stack which is 
providing API for developing 802.11 drivers. (frankly speaking though, the 
project is too large for me to grasp properly within a week.) 

What I see now is to implement the PHY and the MAC layers based on the IEEE 
standard and then provide some sort of API for the driver to be able to use 
these functionalities.  Please correct me if I am mistaken. 

I found the NS-2 implementation of the MAC layer for 802.15.4 and am currently 
reading that, see how much I can understand for there is no documentation on 
it as such (or at least I cannot find any).

So, it would be a great help if someone could tell me whether this is the 
right approach - as in whether developing the kernel API does indeed mean 
writing an implementation of the MAC and the PHY layer. And if yes, is there a 
general approach that I should follow in implementing the MAC and the PHY 
layer for the kernel (if that sentence makes sense). 

I know I am still beating around the bush - but my focus right now is indeed 
on collecting and understanding as much background information as I can 
gather. This is so because I need to come up with a proposal that lists what 
exactly do I want to do and how I intend to do it. When I have a clear idea, I 
take the draft to the prof. for his edification pleasure.

Any help would be hugely appreciated, I am very new to this area of 
programming, but remain hugely interested in accomplishing this task.

Thanks
Rahul

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

end of thread, other threads:[~2009-03-01 23:56 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-24  0:44 IEEE 802.15.4 Rahul Jain
2009-02-24  1:42 ` Inaky Perez-Gonzalez
2009-03-01 23:49   ` Rahul Jain

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).