Before embarking on driver development, you should have the ASCOM Platform Developer Components installed on your system. Driver templates, most of the developer documentation, and the installer generator are included in the Developer Components installation. The developer components are provided as a separate download from the Platform itself.
Here is a video by Tom How showing how he developed a driver for his telescope control system using the popular Arduino microcontroller kit.
GO FULL SCREEN 1080p TO SEE THE CODE!
The Platform development team has done quite a bit of work to assist driver developers who use .NET languages. .NET is Microsoft's supported development environment, with Visual Basic and C# being the most commonly used languages. For those who are starting driver development, it is suggested that you use one of these languages, and use the appropriate driver project template we have provided.
The worst way to undertake driver development is to use the sources for another driver. While it may seem like a shortcut to success, it is almost always a shortcut to troubles, misunderstandings, and propagation of others' mistakes. Roll your sleeves up, learn what you need to learn, use the tools, and do your best.
Most drivers will need to save persistent data (e.g. COM port selection). It's highly recommended that you use the DriverHelper.Profile object for this. It has a very simple interface and guarantees that you will get private storage for your persistent data items. It uses an area of the registry set aside for ASCOM drivers. A browser, the Profile Explorer, is provided in the Platform to help diagnose ASCOM registration issues and to allow inspection and editing of driver-specific data.
It is possible that the layout of data in the registry will change due to future opperating system restrictions. This already happened twice(!) for Vista and Windows 7. Either way, if you write directly to the registry you're asking for trouble. Drivers which used the Profile object were unaffected by those changes to the Platform. On the other hand, if you choose to write your own private persistence storage code (e.g. to an XML file) that's fine too. Just be aware that your persistent data will not show (and be editable) in the ASCOM Profile Explorer, which is a useful troubleshooting tool.
All ASCOM interfaces include a SetupDialog() member. This is intended to display a modal dialog that provides access to device-specific things like COM port selection and controls for device-specific features. Keep in mind that many client programs expect a "perfect" device looking into the driver, and will use the device to support observing. Features like PEC, pointing/tracking models, backlash compensation, etc. that aren't exposed through the standard interface belong in the setup dialog.
This is a frequent source of confusion and frustration for driver developers, as they want to expose the "value added" features of their device where the driver interface doesn't support those features. Try to resist the temptation to have your driver open a "permanent" modeless window with a bunch of doodads like position or coordinate displays, switches, buttons, etc. The client sofware users will see these windows appear when they connect to the device, and they will think the window is part of the client program. This generates pain for client software developers who get asked for support. It also allows users to change things during normal usage, risking obscure problems and confusion.
Besides registering your driver as a Windows Object (COM), it also must be registered for ASCOM in order for it to appear in Chooser. At a minimum, your installer needs do this. If you use C#.NET or VisualBasic.NET and the templates included with the Platform 2008, this issue is handled in the driver by the template code. Otherwise, if you use the Inno Setup tools included with the Platform Developer Components, it will be done for you. Otherwise, you'll need call the Profile.Register() method during install and the Profile.Unregister() method during uninstall. It's up to you to figure out how to do this with your installer tools. Be sure to remove the driver's ASCOM Chooser info when the driver is uninstalled.
A driver can expose multiple interfaces (for example Telescope and Focuser for a mount that has both pointing and focuser controls). In order for different client programs to use the two interfaces, though, the driver must be a "local server" or executable type Windows Object (COM) server. In order for this type of driver to be accessible from TheSky 6 (via the TeleAPI or DomeAPI plugins), special registry info must be created and removed by your installer. If you use C#.NET or VisualBasic.NET and the templates included with the Platform 2008, this issue is handled in the driver by the template code. Otherwise, if you use the Inno Setup tools included with the Platform Developer Components, it will be done for you. Otherwise, it is up to you to figure out how to do this with your installer tools.