I am currenlty trying to monitor my battery status through SMBus.
I have a battery along with a control board that constantly outputs the battery status.
This control board is then connected to my mother board through a I2C-USB module.
I need to write a program to recognize the SMBus connection and transmit the battery status to the user.
I'm a beginner when it comes to dealing with smart batteries and I2C/SMBus, and I'm somewhat lost with how to approach this problem.
Any help of suggestions would be appreciated. Thanks.
Your question is a bit lacking. What kind of I2C-USB module? Or rather does it come with a Linux driver? If it does you probably won't need to write one. An application will do. You can read more about I2C and SMBus here.
Basically what you need is the I2C address of the control board (a single byte). When you have the address you (as the master) issue read commands over the I2C bus to the control board using its address and reads the response. If there's a driver for the I2C-USB module this should be straightforward enough. Plug in the device and open() the device (/dev/[i2c-usb-name] where [i2c-usb-name] is the name of the device). Then follow the driver implementer's guide how to setup and send data over that device (typically using read()/write() or ioctl()). Here are some additional information on working with I2C from user space: http://www.mjmwired.net/kernel/Documentation/i2c (select topics in the menu on the left hand side).
If you must write the driver yourself, the first stop for a Linux device driver beginner is the LDD3. Read it, it's quite a pleasant read.
Related
I understand the basics behind a UIO driver, as described in the documentation. The part I'm missing is how to write data from the user space program back to the device driver. My guess is that you'd write this data to the mmap region, but then how to do you let the device driver know it should read said memory?
Ultimately I'm trying to write a block device that can be implemented by a user space program. I've got the block device code stubbed out and working: https://github.com/wspeirs/usbd. My thought was that UIO was the most efficient way to transfer blocks/sectors between the block device and the user space program. Is this the wrong way to go about communicating with the block device driver from user space? Should I be using sysfs or some other communication mechanism?
UIO is designed so that user space bypasses the kernel to communicate with a hardware device. That does not seem to fit your needs.
In a standard Linux block device, you can use mmap() to write data to your block and msync() to indicate to the driver which regions you have written.
I am working with openmote-cc2538 for the project: https://github.com/cetic/6lbr/wiki
Here when I was trying to flash openmote with this command
sudo make TARGET=cc2538dk BOARD=openmote-CC2538 bootload0/dev/ttyUSB0 slip-radio.upload
This error message is displayed
ERROR:Cant CONNECT TO TARGET:Ensure bootloader is started(no answer on sync sequence)
cc2538 bsl.py script is available for uploading binary to openmote. But I don't have much experience about this. Can anybody give me some suggestions regarding how to proceed??
Grab a scope and probe different digital I/O pins on the CC2538. Typically a bootloader will initialize all the ports on the chip and you will see them change state, which is an indication that the bootloader is indeed running. I would guess one of the LEDs would change state as well (which doesn't require a scope).
I am writing a serial driver for UART in windows just for learning purpose. More specifically in WDM.
I will write both the bus driver and function driver.
Currently i am writing the bus driver. So my question is from where i can come to know in my driver that how many serial ports i have in my system, so that i can expose that number of PDO's from my bus driver?? And resources allocated to each port. Do i have to check some kind of registry or windows will provide some kind of structure.
Please help me!! Thanks in advance
Assuming your UARTs are part of the PC, there's already a bus driver which will enumerate them. ACPI.SYS gets information from the platform BIOS, which includes the number and resource assignments for built-in components like UARTs.
If you're writing your driver for an add-in multi-port serial board, then you would need to look at the documentation for the board to determine how you find the number of UARTs. It might be as simple as looking at the PCI Product ID and having a hard-coded count for the type of board you have.
When ACPI enumerates the device, your driver's AddDevice routine will be called to load on it, and you'll receive the assigned resources when handling the PNP START message.
I am studying windows device drivers on my own and I find it's very difficult to differentiate between PDO and FDO. Let me tell you the flow that I have in my head correct me if I am wrong !!
when system boots it loads the root bus driver that will create a FDO. Now it will enumerates its child devices and i guess some hot plug method of the bus driver will be called, when a new child will be found and that method will notify the PNP manager. PNP manager will call the AddDevice() routine of the root bus driver and that will intern create PDOs for new buses like one for PCI and etc. Please explain the whole flow in detail, this is just my imagination. And then it is documented that system will load the functional driver for the PCI bus that will create the FDO ??
what is this FDO?? and why would i need that?? According to me PCI bus driver should also follow the same as done by the root bus, enumerate its child and create PDOs for them, or by this FDO they mean PDO only ?? I am so much confused :( !!
What are you actually doing, or are you just trying to learn? I am just wondering how you ended up this low down in the stack.
PDO = Physical Device Object
FDO = Functional Device Object
A PDO acts as a physical device, but it does not necessarily have to be physical. It is essentially the interface between a device on a bus, and the bus itself. This is pretty well covered on MSDN.
Here is an example that uses USB sticks and this illustrates the difference quite well.
Here is a more in depth explanation and the important quote
If your point of reference is the PCI bus, then Pci.sys is the function driver. But if your point of reference is the Proseware Gizmo device, then Pci.sys is the bus driver. This dual role is typical in the PnP device tree. A driver that serves as function driver for a bus also serves as bus driver for a child device of the bus.
You also have filter drivers which allow you to sit between PDO's and FDO's and start doing naughty stuff like hiding files, POC rootkits etc. At this stage you can add extra functionality, or completely prevent access to the PDO.
And here is all the MSDN links.
http://msdn.microsoft.com/en-us/library/windows/hardware/hh439632(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff554721(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/hh439643(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff554731(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff564859(v=vs.85).aspx
http://technet.microsoft.com/en-us/library/cc776371(v=ws.10).aspx
If that doesn't clear it up for you, feel free to post back.
Here is the excerpt form "Programming the Microsoft Windows Driver Model", 2nd edition, Walter One:
- PDO stands for physical device object. The bus driver uses this
object to represent the connection between the device and the bus.
- FDO stands for function device object. The function driver uses
this object to manage the functionality of the device.
- FiDO stands
for filter device object. A filter driver uses this object as a place
to store the information it needs to keep about the hardware and its
filtering activities. (The early beta releases of the Windows 2000
DDK used the term FiDO, and I adopted it then. The DDK no longer
uses this term because, I guess, it was considered too frivolous.)
Hope this helps you out.
According to me PCI bus driver should also follow the same as done by the root bus, enumerate its child and create PDOs for them --WRONG!.
If you are talking about WDM, PnP Manager creates PDOs. Earlier to that, YOU had to create it(after detection of device) in DriverEntry().
Hello Linux Kernel Driver Gurus!
I'm writing a v4l2 driver for a camera that uses a serial interface for configuration. I'd like the driver to configure the camera, as it keeps the client code consistent across camera models. The question is: what's the best way to access the camera's serial interface from the driver module?
From what I hear, accessing files from a kernel driver is a big no-no, but it can be done. As such, I'm currently using the following code snippet, but it feels like a hack.
oldfs = get_fs();
set_fs(KERNEL_DS);
fd->f_pos=0;
fd->f_op->write(fd, data, data_len, &fd->f_pos);
set_fs(oldfs);
My question is really: what's the right way to do this?
I presume that since a serial port is involved, this must be some kind of embedded system. After all, not many PCs even have serial ports. I also assume that the serial port can be considered a permanent connection, at least from the user's perspective. If that is all true, then you don't really want a TTY device. You want to access the device as a private UART.
If you have a look at the Wolfson audio codecs (sound/soc/wm*.c) you will see an example of devices that primarily communicate over I2S but have an auxiliary I2C interface for configuration. This is conceptually what you want, I believe. The driver presents a unified interface to software, and issues commands to whatever hardware is appropriate. Obviously this is much cleaner than having to expose hardware implementation details to userspace.
I couldn't find a good example of a UART driver in the kernel that works this way, but hopefully I've described what to look for. From a practical rather than technical purity point of view, it might just be better to do file I/O from the kernel.
First I would advise you to find a way to do this from the userspace if possible: what you try to achieve here really is userspace code in kernel code.
But if you don't find a way to do it, this article shows you how to do userspace calls in kernelspace.
Since you want to access a serial port, you should have calls that tty oriented, for instance for open:
serial_fd = sys_open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NONBLOCK))