I'm tasked with writing a GPS and BT driver in linux (v3.3) and am looking for some resources to gain basic knowledge on how to do this. I'm familiar with writing device drivers for linux, but am getting confused when reading about GPS and BT drivers.

I'm looking for an explanation on where the BT/GPS stack/core is located, and explanation of how they work as well. Essentially, I'm looking for how to interface a BT or GPS module with the kernel, and how the kernel handles the data. Other possible helpful info: The BT module will act as the host (supports up to BT 3.0), and the GPS module will be the receiver.

So to clarify: I am looking for a text/code resource that explains

* How Bluetooth works in the kernel (something along the lines of a LDD3 chapter - but for BT)
* How GPS works in the kernel (same info)
* How to interface these mechanisms (via kernel structures) with a specific chip

I realize this is a somewhat broad question, but I believe that is the point of the question. I'm not looking for a specific "how does BT work with chip X", but rather, "what's a resource I can use to learn how BT/GPS works inside the kernel".

=======================
OK - let's start with some facts:
...1) BT (bluetooth) is an evolving thing.
...2) GPS hardware is also an evolving thing.

Either of those things is sufficient to keep their code from being mainline kernel.
That means each driver, one for BT and one for GPS needs to be formulated into a module.
The kind that were once called "TSR" (terminate and stay resident)

If you are not familiar with Linux take a look in /lib/modules. Research how they communicate with the kernel and do the same. (many come with source code) It won't be long after you have the modules working that you will be needing to have a few dozen versions of each BT and GPS module. and counting.

About the time the DOD stopped dinking with the sat signals I took a Garmin GPS and attached a serial cable to it and the serial port on a laptop. I then wrote a LISP program to be run from inside AutoCAD to activate a compiled module to read the GPS on the serial line and then strip off the unwanted and write the wanted (in my format) to the disk and then to activate the next sequence (a script). That read the now formatted info from the disk and sent it to a command line program which converted the LAT/LONG to the desired UTM which was then placed on the hard drive and then returned control to the LISP that started the sequence which placed a red donut at my current location on the screen in front of me. Later, just for fun, I wrote another LISP that would run the first every X minutes and move the screen so as to center the new red donut in the middle. In your case, writing to disk isn't needed (and probably not wanted). Nor is it in mine. I keep a copy of last "just in case" and can, in the flow of my stuff activate a read and store of each WhereAmI just to keep people honest.

I have yet to take AutoCAD apart. Don't need to. As time has gone by - the compiled has had a few changes because the hardware has. Latest AutoCAD still runs the LISP unchanged. The LAT/LONG converter still works unchanged. My map still moves. If the GIS Land Use program at State of California isn't getting done it is strictly operator fault. The excuse "We got lost again" don't work. Then. Now.

Linux: modprobe, lsmod might be nice to use/understand.

Best of luck.

Norseman01