Sensor Datasheets, Driver Code, and Arduino Code

Hi there,

I've worked on several projects where I had to use some sensors and chips accompanied by datasheets that contain timing diagrams and descriptions on how to program the device. In particular, I've worked with the Pololu MinIMU-9 (accelerometer), MAX7221, and more recently the nRF24L01 radio frequency transceiver.

Since I'm a newbie to software development, I was wondering if software developers distinguish between code that tell the hardware what to do to implement higher level functions, and the code that allow users to use the same device without having to program the hardware.

Do they call the latter "device drivers"? Are they of the same type as the software that one would need to install when, say you change a graphics card and must install the graphics card "driver"?

For instance, there is a library called Parola out there that implements functions to display text animation. The creator of that library also created a library called MD_Max72xx. In it, it seems he has written functions that sends bit via SPI to program the chip. The Parola library itself seems to be an abstraction. That library is just a collection of .cpp files that each implement a different text effect (scrolling, scan, etc.).

When hardware developers create the sensors/chips do they already have an idea of what kind of driver code should be written? Do they write any code? It seems like they would be the most qualified to write a hardware library, being the designers and manufacturers of their product.

It seems the hardware designers leave it (very) open to the programmers to write the device drivers so that it is up to the programmers to determine what features of the hardware to use. The data sheets I've seen don't include ANY code at all -- just register maps, timing diagrams, ... info needed to program the hardware to implement features that the hardware designers propose that the device can implement.

There are different levels to all this - there may be a hardware abstraction layer (HAL) that produces a generic interface for all devices of a particular class but different manufacturers or models, say a UART, and there may be further drivers above the HAL to implement higher level functions like serial protocols.

For graphics devices, you may write a high level driver to implement drawing graphics primitives into a frame buffer in RAM, but leave the methods to write the frame buffer to the underlying physical display as pure abstract methods to be implemented in a derived class, because the means of writing the data to the display will be specific to that device. The primitives are things you would want to do apron any graphical display e.g. set pixels, draw lines, draw characters

On larger systems like Linux servers, it can get really convoluted. For example, a RAID system would have a file system over the RAID device driver, and the RAID driver would talk to a disk interface, possibly a Fibre Channel driver, which would incorporate a SCSI driver to talk to the disks themselves.

AWOL: There are different levels to all this - there may be a hardware abstraction layer (HAL) that produces a generic interface for all devices of a particular class but different manufacturers or models, say a UART, and there may be further drivers above the HAL to implement higher level functions like serial protocols.

Can you comment on what level of abstraction Arduino programmers work at?

For graphics devices, you may write a high level driver to implement drawing graphics primitives into a frame buffer in RAM, but leave the methods to write the frame buffer to the underlying physical display as pure abstract methods to be implemented in a derived class, because the means of writing the data to the display will be specific to that device. The primitives are things you would want to do apron any graphical display e.g. set pixels, draw lines, draw characters

That makes sense as it gives computer hardware designers flexibility. But who does the actual job of implementing the derived class for a given physical display?

On larger systems like Linux servers, it can get really convoluted. For example, a RAID system would have a file system over the RAID device driver, and the RAID driver would talk to a disk interface, possibly a Fibre Channel driver, which would incorporate a SCSI driver to talk to the disks themselves.

In such a system, would the subsystems fall into a respective abstraction layer category (wiki "Abstraction Layer")?

ElusivePi: Can you comment on what level of abstraction Arduino programmers work at?

Objects. In C++ (the language behind Arduino) everything is an object. Serial is an object which does serial communication. Stream is an object that works with any kind of data that's in a linear stream, such as Serial, I2C, USB, whatever. Serial is based on Stream, which provides a lot of services to Serial, so Serial doesn't need to implement a print() function, even though most of the time you're using Serial, you're using print().

ElusivePi: That makes sense as it gives computer hardware designers flexibility. But who does the actual job of implementing the derived class for a given physical display?

The device manufacturer is expected to produce a simple library, just to prove the device works. Each time I buy a new Arduino gadget, I download the example code from the shop's web site and run that.

Often there is a large enough community of Arduino hackers that a library will be written by someone who saw a way to do something better than the manufacturer. Simpler devices such as encoders are usually done by volunteers like this.

ElusivePi: In such a system, would the subsystems fall into a respective abstraction layer category (wiki "Abstraction Layer")?

There are different standard abstractions for each field. Networking uses physical layer, transport layer, authentication layer etc. None of those are relevant for Arduinos - even the ones using Ethernet shields - because they're all abstracted away by the library code for the shield.

You may think a chip designer at Atmel is drawing lines on a computer and connecting together transistors and other components on the chip? No, they work at a level of abstraction too. They have functional blocks such as a memory block or an arithmetic block and they place them on the chip and draw wires between them. In fact, in the case of the SAM3X processor inside the Due, they buy the ARM M3 main processor block and place it into their chip design.