I'm looking help to understand the concept of device drivers in embedded Linux system and why they're necessary. From what I've gathered, a device driver is a program that enables an operating system to communicate with hardware devices. I'm still a bit unclear about their importance, but here's how I see it: Let's say I have a Linux operating system on my personal computer, and it already has device drivers for things like audio, video, network, mouse, and keyboard. Now, if I want to connect a new hardware device that uses I2C communication, I think we'd need a specific I2C device driver because the existing drivers won't work with it. Once we create an I2C driver, we can use it for various I2C devices, and we'd only need application programs to support these new devices. Is this interpretation correct?

 

It is unlikely that you have a hardware interface to support I2C. I don't think a device driver would support different types of device connected via I2C. I think you would need a device driver that communicates with the the device via I2C. There are many different devices that comunicate via I2C for example real time clock chips, memory chips, current and voltage sense chips (INA219), chips that measure temperature pressure and humidity (BME280) etc. An I2C hardware interface would probably be designed to connect to the computer via USB. Think of something like a USB to RS232 serial converter.

Les.

 

There are at least two (there are platform drivers for specific types of board types like PC motherboards, RPi boards, etc... CPU level devices like I2C) types of Linux drivers, hardware drivers translate each type of low level device register hardware details into a standard generic hardware interface (I2C, SPI, etc ...) API and protocol drivers that use that generic I/O API to provide a specific level user service type API (sensors, memory, etc ...) for each individual chip.
https://lwn.net/Articles/448499/
The dividing line between types can be blurred as there are protocol driver hooks to enhance or even replace hardware driver functions at the kernel level. Today the device tree interface can interact with the various driver types to configure the platform defined hardware as needed.

 

I appreciate the information you've shared about I2C and Linux drivers. However, I'm still eager to hear your feedback on my project requirements and whether you think my approach aligns with best practices or if there are areas where it could be improved.

 

I appreciate the information you've shared about I2C and Linux drivers. However, I'm still eager to hear your feedback on my project requirements and whether you think my approach aligns with best practices or if there are areas where it could be improved.

Actually build something (software or hardware) instead of writing requirements that seem lifted from an LLM to get feedback.

 

Actually build something (software or hardware) instead of writing requirements that seem lifted from an LLM to get feedback.

I have already developed character drivers for PC and attempted to create a driver for a LED blinking device on a Raspberry Pi.

I'm finding it challenging to grasp the significance of doing this. I want to understand why we need device drivers in the first place.

Could you offer a simple practical use case that demonstrates the need for a device driver?

 

Actually there already is an I2C driver available to use so you really don't have to develop one. VGA, DVI, and HDMI ports all use I2C to get information from the monitor to determine it's capabilities. i2c-dev is the module name.

Besides the fact that only 10% of the population would ever have a use for such a driver, there are thousands more like it. If you were to compile every bit of code into the kernel to run every possible device you would end up with something that pretty much does nothing but waste memory. While there are standards for many things, they only define the basic operation. Different chipsets have different capabilities and different instructions to match.

Another reason for drivers is because your normal application programming cannot directly manipulate hardware and certain aspects of memory due to the CPU running at a secure level (not at ring 0). Pretty much anything that deals with system resources and hardware has to be done with the CPU running at ring 0 which opens the doors for a wide variety or attacks or stupid mistakes. Your device drivers are kind of the bridge between the kernel which can access ring 0 and applications that cannot. I don't remember the exact mechanism, but I believe it has something to do with the global descriptor table and memory tables that are set up at boot before the CPU is even switched to 32 or 64 bit protected mode. Sure it's possible to exploit bad programming to crash the system, but it's a lot harder when you can't directly manipulate hardware and memory.

 

I have already developed character drivers for PC and attempted to create a driver for a LED blinking device on a Raspberry Pi.

I'm finding it challenging to grasp the significance of doing this. I want to understand why we need device drivers in the first place.

Could you offer a simple practical use case that demonstrates the need for a device driver?

Why to we need drivers?
I could endless go on about specific devices, drivers, processor specifications and OS configurations but that IMO is not what's needed here. The OP needs to study computer and OS architecture at a basic level to answer his questions.

The word 'driver' in software was taken from the hardware 'driver' context. A driver is a stage that converts a signal (as generic information of some sort) into a form usable to drive (with very specific types of signals) the 'final' output stage.


An early software usage of the term.

A software driver is simply a design abstraction so we can build software like hardware in modular stages that isolate generic informational signals from specialized device/protocol signals. It's way to convert 'Complex' (hard to control and to predict) software control problems into 'Complicated' (not so simple but knowable) software control problems. It's a software design feature of (operating) systems to make the bulk of software development more modular and less hardware dependent by standardizing a software interface using software called a 'driver'.