What is our experience with Drivers?
Bottom Up or Top Down?
What is a Driver and why do I need one?
What about test? How do I get started?
What do I get?
Base, Channels, and Architectural Considerations
"Necessity is the mother of invention" and "Repetition is the mother of skill".
In 1988, with 10 years of embedded systems experience under his belt our founder was ready for a change. Dynamic Engineering started out as a hardware consulting company. In order to test our hardware designs, surprise surprise, we needed software. At the time most embedded systems were using assembly, C or a mixture and homegrown or no OS. Development on a PC and cross-compiling to the target 68XXX or 87XX embedded processor was the norm.
When better tools and the PCI bus became available we transitioned to start testing on the PC. At first we used a generic driver - WinRT. After a while our clients began to ask for drivers for Windows® and we responded by learning how to write device drivers for NT. The first drivers written were heavily influenced by our client´s requirements in terms of functionality, performance and documentation. Over the course of many, many drivers for PMC, PCI, PCIe, PC104p, IP and other platforms we have developed an extensive library of driver components and application software.
Windows® has progressed from NT to the Win32 model and beyond, and at the same time Linux has moved from a fringe activity to a viable alternative implementation concept. More and more of our clients are using Linux to directly or indirectly (when coupled with VxWorks) meet their needs. Dynamic Engineering has grown and migrated along with the OS and has been offering Linux drivers and application software for many of our products for several years. In addition Dynamic Engineering offers Windows® drivers as they are still popular for embedded applications. Whether using Linux or Windows® Dynamic Engineering has developed a consistent look and feel which anticipates most client requirements and allows for consistent, easy to integrate systems.
Dynamic Engineering is now in the position of being skilled with driver writing and testing. It has been said that it takes 10,000 hours to become a master of something. Dynamic Engineering has multiples of this metric.
Over the years the distinction between hardware and software has blurred. You can do more in VHDL or more with the driver/application code. The trick is to do the right amount of each to off-load the CPU as much as possible without requiring an overly expensive hardware set.
We start with some sort of requirements definition. Sometimes this is "Just like but different" referencing another product, and sometimes a full blown requirements document. Our designs frequently have an FPGA or other programmable device plus drivers plus the application software. The VHDL <=> Driver <=> Application boundaries all affect each other. We frequently start with the VHDL and progress to the driver and then application code - a bottom up approach starting from the top it would seem. We use design experience as our feed-back loop to improve our VHDL to make our drivers easier to write. Things like consistent register definitions, direct rather than indexed access to the registers, independent channels for independent functions; the driver, and consequently the application software are easier to conceive and write. Testing is also improved with fewer interactions between components.
A "Driver" is a computer program allowing application level computer programs to interact with hardware.
Drivers typically interact with the hardware using the computer´s internal bus or external IO. The driver in response to an application request makes system level "calls" to move the requested data to the hardware or from the hardware back to the application. With PCI and PCIe the driver will interact with the operating system to determine the actual address of the hardware since it is determined at run time. With Dynamic Engineering Drivers, simple IO [read and write], interrupts, and DMA [Direct Memory Access] are handled along with system functions like determining the address of the hardware. A driver interacts with the OS and hardware and is therefore HW and OS specific. With a standardized interface between the application software and the driver the application software can be more portable between OS types using the same hardware.
The driver typically executes multiple steps for each call made from the application level. Driver calls can be combined within the driver to do basic or repetitive tasks more rapidly. Dynamic Drivers come with the basic level calls - each HW interaction separately - plus enhanced calls which combine strings of operations to be more efficient. This way our clients always have the ability to manipulate the bits and "do things their way" or can take advantage of the higher level calls. Dynamic Engineering frequently adds new calls to help clients optimize their system performance. Since each system is different, Dynamic Engineering relies on our client´s to ask for new and improved calls to implement. Please contact us with your enhancement requests.
Since the driver is operating in close contact with the OS it is easy to have the driver "break the system" and cause a blue screen or similar result depending on the OS in question. It is important to get the driver right. Dynamic Engineering has intimate knowledge of the HW and a lot of experience with the OS to make sure our Dynamic Drivers are written properly and tested thoroughly before the client receives them. Debugging drivers is a difficult task. As the hardware designer we have the ability to see what is happening at a hardware level within our VHDL as well as monitoring the driver activity to efficiently debug any issues that do come up to prevent our client from being bitten by a bug. Typically it is in our clients best interest to focus on their system and their application requirements, and better served by leaving the drivers to us.
Testing the driver is an important step. The best way to test the driver´s operation is to use the driver to do real world tasks. Each Dynamic Driver comes with a User Application "UserAp" which contains a complete set of C routines. The UserAp has a menu and routines to allow the user to run the routines with keyboard control. Since the routines are supplied as source files the user can set break-points and observe operation, including parameters passed, counts etc. The routines are written to test the hardware and are used in our manufacturing to do an ATP on the hardware.
It is reccomended to the new user [for a particular type of HW] to start by running the ATP on their hardware. By executing the test software the user can gain confidence in the hardware set-up and in the case of some issue - DMA not being enabled on their computer etc. - it is easier to work it out with a known good set of software. Once the routines are running, the user can make changes to the routines to more closely mimic their system requirements. Through this process the user can become familiar with the calls, where to find them, how to compile altered software and so forth. It is encouraged to reuse our software as much as makes sense for your system.
Adding tests is easily accomplished. The menu system has two components; menu.c which incorporates the mechanics of operating the menu, and menu_d.c which contains the menu data. In most cases menu.c will not need to be touched. New software can be added to the menu by adding new lines to menu_d.c. At the bottom of the file is an array. We recommend "copy and paste" and then edit to add your test(s) to the menu. Comments are easily added to your test with the additional data arrays located above the menu array. Again, copy one and rename for your purpose(s). When a non '0' return value is received by the menu, the comment array is indexed to extract the data and/or text to print to the screen.
The menu has several handy features. Multiple tests can be run sequentially. A limit can be set for a number of loops to run, plus once and forever. Tests can halt on failure or continue after displaying the comment. Error numbers are stored so multiple errors of the same type do not kick out new lines unless the verbose feature is enabled. All of the features are programmable via keyboard. The options are printed at the bottom of the menu when it is redrawn.
The menu can handle multiple cards within a system. For example if you have two PMC-SpaceWire cards, the software will number them 0 and 1. The menu will ask which board to communicate with as it initially launches. Answer 0 for board 0 and 1 for board 1. Since the 0 and 1 are determined by the system, the DIPSwitch on the board can be read to allow you to associate Board0 and Board1 with a specific board. This task can be done automatically to allow for multi-board operation in the same system. For example the UserAp for the IP-ReflectiveMemory board autodetects up to 5 boards [can be set to a larger total easily] and prints out the data for each of the 5 - FLASH, driver in use, address and so forth.
Don't you hate it when you get a new piece of hardware and then realize you have no idea where to start and the documentation that sounded good on the website seems not to apply to what you want to do? With the software provided to support your hardware purchase you can have a "quick start" and many times be running the test software that first day. Installing the driver is easy with Plug and Play operation. Starting the reference executable is a double-click away. The menu system is intuitive. In many cases you can open our project with your editor and see the structure.
The test software is not your typical "reference software" - it is in active use in our manufacturing facility so you know it is something to depend on. Our designers will support you by adding new calls or reference cases to execute on the hardware. Confidence in your set-up and reference cases will have you making progress rapidly which makes everybody happy because your manager is happy.
The "Driver" has several components as part of the deliverable package.
The Dynamic Driver fileset includes the Device Driver which is either an executable [.sys and .inf or similar] or the source in the case of Linux. UserAp is delivered as source code. We use Visual Studio (for Windows®) to develop. If you have the same software you can open the project directly. If not you will need to recompile into your tool set. Within UserAp are the include [.h] files to tie the application software to the driver. The include files contain the Driver Call definitions - sometime referred to as an API. The software manual also defines the Driver Calls. The Software Manual is a PDF located on the Dynamic Data Sheet for the product. Usually located toward the bottom of the DDS.
Typical Files included within the UserAp file set for a particular design.
Please be sure to refer to the manuals for the Hardware and for the Software. The Driver or Software manual has installation instructions and a list of the included driver calls. The Hardware manual has the detailed operational information for the design. Operational concepts, features, address maps, bitmaps, pinouts, loop-back fixture connections, ordering information and more. When using the Driver, many of the calls allow direct access to the bits or to structures to change settings. Detailed information about those settings are contained in the Hardware manual. Even if you are a Software designer, please refer to the Hardware Manual too.
 |
The block diagram shows the interaction of the hardware and software, client and Dynamic Engineering as well as a peak at our basic approach to architecture. The hardware is the embedded firmware, PCB and components used in the design. The driver is really several pieces of software that are compiled together to make the "Base" and "Channel" system files. The base is aligned with the general purpose functions of the board. The base module is installed first and facilitates the loading of the channel(s). The channels are the logic associated with a specific function. For example the PMC-SpaceWire design has 4 channels. Each channel is independent of the other channels from a programming model point of view. By breaking the HW into groups that contain a common function - Channels - the software can be much easier to implement for the Driver and for the Application layers. For the Driver it is easier because the same channel software can be called multiple times since each channel is identical - just with a base address offset. This means less software maintenance and fewer places where "accidents" can occur. This also means the corresponding channel application SW can be identical since each channel uses the same calls. For example, the PMC-BiSerial-III-HW1 has 32 identical channels. The channel number is passed in to differentiate. In cases where the channels have different functions, the channels are loaded with different channel drivers corresponding to those channels. For example the PMC-BiSerial-III-ORB2 has 2 channels each of 4 different functions plus a GPIO function which is loaded in the base driver. |
To solve the issue of knowing which instance of which card is in which slot on which carrier the carrier driver writes to the installed HW with a code. For older cards designed before this break-through the driver has the ability to break the code into bits and use any available register(s) [no side affects]. Once the Child driver is loaded for that instance it can read the data, reassemble and store allowing the standard use of the register(s) to resume. For newer designs or ones we have updated, we add an extra register for this purpose. The carriers have an 8 position DipSwitch installed which allows up to 256 of the same carrier type in system. Between the carrier name and stored code in the IP the designer has unambiguous knowledge of which instance of the driver is controlling which piece of hardware for multi-board and multi-carrier systems. This is important for obvious reasons - it would be a real bummer if you are controlling the wrong "Launch Control".
We have taken a similar approach to operate with Linux. Again the IP Module drivers can be used on any of our IP Module Carriers, and you have deterministic operation from a driver instance to hardware point of view.
Dynamic Engineering uses the DIPSwitch approach on all of our PCI/PCIe based designs to allow for multi-card operation or for whatever purpose the client decides. Simple and effective. Full disclosure: we had the necessity for a solution after designing the PMC-Parallel-IO card - our first PMC. All other PMC, PCI, PCIe, PC104p etc. cards that have a dynamic addressing scheme have the DIPSwitch feature.
