diff options
Diffstat (limited to 'www/writing-a-driver.xml')
-rw-r--r-- | www/writing-a-driver.xml | 50 |
1 files changed, 25 insertions, 25 deletions
diff --git a/www/writing-a-driver.xml b/www/writing-a-driver.xml index 8a878893..6a8993ec 100644 --- a/www/writing-a-driver.xml +++ b/www/writing-a-driver.xml @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="ISO-8859-1"?> -<!DOCTYPE article PUBLIC +<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ <!ENTITY homepage "http://gpsd.berlios.de"> @@ -156,7 +156,7 @@ sigma).</para> <para>So for me, the decision whether to write a driver or not was already made; either write one or forget -connecting this high quality time source to my network, as +connecting this high quality time source to my network, as <application>gpsd</application> can also use the GPS device to synchronise the ntpd daemon either to the GPS data or to the 1PPS, if it is available. A 25ns accurate input to <filename> @@ -171,7 +171,7 @@ to be able to code in C and compile/install the results. If you can't do that, you should temporarily shelve the driver project and start learning to code. While I would not advise this as the way to go for a complete novice, you will find some good -code to follow in the +code to follow in the <application>gpsd</application> files and there are some good clues in the existing drivers.</para> @@ -371,7 +371,7 @@ want compiling and then issue a the software to that configuration. If it compiles successfully, you can then issue a <quote> <command>make install</command></quote> command to -install the driver. This last command will need to be done as +install the driver. This last command will need to be done as <function>root</function> because the daemon is designed to be invoked by root.</para> @@ -561,11 +561,11 @@ code <quote> <function>packet_parse</function></quote> and is based on existing drivers.</para> -<para>The file +<para>The file <quote><filename>packet_states.h</filename></quote> is simply a list of every state needed by every type of GPS which will -produce a long list of unique entries (a big -<filename>enum</filename> list) for use in the +produce a long list of unique entries (a big +<filename>enum</filename> list) for use in the <quote><filename>packet.c</filename></quote> state engine. The changes here are limited to a small change to the TNT code, since both drivers share a common first character, @@ -583,8 +583,8 @@ I did not know what would need to be updated; you, on the other hand, now have a nice list to guide you.</para> <para>The basic entry points or data values -required of every driver are in visible in the -<userinput>struct gps_type_t proto_binary</userinput> in +required of every driver are in visible in the +<userinput>struct gps_type_t proto_binary</userinput> in <quote><filename>drivers_proto.c</filename></quote>. If any functions are not needed or not provided for your device, then the corresponding table entry should be a @@ -646,13 +646,13 @@ this event does <emphasis>not</emphasis> fire for USB devices, in order to avoid spamming unidentified devices behind USB-to-serial adapters that may not be GPSes at all.</para></listitem> -<listitem><para>When the driver has a trigger string and the NMEA driver +<listitem><para>When the driver has a trigger string and the NMEA driver sees it, 'event_triggermatch' fires. An 'event_switch_driver' should follow immediately.</para></listitem> -<listitem><para> +<listitem><para> Whenever <application>gpsd</application> first achieves packet lock -with a device, with event type 'identified'. +with a device, with event type 'identified'. </para></listitem> <listitem><para> Whenever a full packet is received, with event type @@ -701,7 +701,7 @@ or someting triggers a device change.</para> <para><structfield>.get_packet</structfield> points to a block of code that actually gets the packets from the serial stream. You will -almost certainly use the generic routine +almost certainly use the generic routine <function>packet_get</function>. If you know this won't do, you already know enough not to need this explaining.</para> @@ -713,7 +713,7 @@ driver.</para> used if the GPS type is capable of accepting differential-GPS corrections in RTCM-104 format. This is the routine needed to ship the data to the device. Usually it is a straight binary -write of the data, which is provided by the default routine +write of the data, which is provided by the default routine <function>pass_rtcm</function>. If the device does not accept differential data, the value is NULL.</para> @@ -729,8 +729,8 @@ binary mode (1).</para> <para><structfield>.rate_switcher</structfield> points to a block of code to change the maximum number of fixes your device can generate -in 1 second. If this method is present, you should also fill in -<structfield>.min_cycle</structfield> to indicate the device's +in 1 second. If this method is present, you should also fill in +<structfield>.min_cycle</structfield> to indicate the device's minimum cycle time in seconds; a 0 value indicates that it is limited only by the data throughput of the reporting channel.</para> @@ -743,7 +743,7 @@ though, you may find it useful for implementing the other switcher methods and whatever other probe strings you need to send. Note: if possible, assemble your packet in <structfield>session->msgbuf</structfield> and put the length in -<structfield>session->msgbuflen</structfield>; this will allow +<structfield>session->msgbuflen</structfield>; this will allow gpsmon to display the control messages it sends for you.</para> <!-- added by ESR, 2009 --> @@ -781,7 +781,7 @@ available. In my case, all the fields could be filled directly from the data shipped by the GPS in the two messages which I activated. The satellite status data contained exactly what was needed. The navigation data was all present but some fields did need some -massaging; for example, my GPS reports location data in +massaging; for example, my GPS reports location data in milliArcseconds whilst <application>gpsd</application> works in degrees. All conversions were achieved by simple division by constants. A few of the more exotic fields such as the quality of the @@ -792,8 +792,8 @@ were extracted by simple masking and testing.</para> results from just the two command/report strings that were set in Windows, but later on I added the capability to bring the device into use from a cold start through the daemon by adding -the routines such as -<structfield>.probe_detect</structfield> and +the routines such as +<structfield>.probe_detect</structfield> and <structfield>.trigger</structfield> along with some status requests.</para> @@ -819,11 +819,11 @@ off></para> <para>As I mentioned earlier, my GPS device needed to be <quote>woken up</quote>, otherwise it would never be detected by the normal packet -scanner. The +scanner. The <structfield>.probe_detect</structfield> function is intended for just such a case and allows you to seek your device and claim the port ahead of the normal initialisation, since a check for -devices supporting the +devices supporting the <structfield>.probe_detect</structfield> is made at a very early point in the startup. The unfortunate thing is that to implement the function could mean getting down to low level @@ -837,9 +837,9 @@ this process in some detail in the hope that it may save some other poor soul the trials I went through.</para> <!-- Mick actually looked at sirfmon --> -<para>I looked at the code in -<quote><filename>serial.c</filename></quote>, -<quote><filename>garmin.c</filename></quote> and +<para>I looked at the code in +<quote><filename>serial.c</filename></quote>, +<quote><filename>garmin.c</filename></quote> and <quote><filename>gpsmon.c</filename></quote> for inspiration and noticed some important things:</para> |