I have a PCIe connected to my linux server and want to use SMBus pins to communicate via I2C to a slave uC (atmega128). This slave will, similarly, read some temperature also via I2C (the wires are multiplexed by a signal controlled by the uC, so it can be slave/master depending on the state of this signal). In master mode, the uC can get all the information from the sensors attached to it. In slave mode, the linux server will be seeing this device and will be able to ask for the information. Now, my question is:
How can I get my device to appear in the list shown when we write "sensor" in the console with the library lm_sensors installed? I have no idea what is the format in which the data is sent to this library, or whatever I would need to do. Would really appreciate some help!
Thanks!
Related
I have this configuration of the devices HOST_PS <----> Transmitter<---- Touchscreen.
Currently on my transmitter I have created a composite USB gadget device which could contain up to 5 HID devices, (2Mouse, 2Keyboard, Touchscreen). HOST PC could enumerate all of them and everything is working properly. From transmitter side I am writing HID report data comeing from the touchscreen to the corresponding /dev/hidg device and Host PC acts correctly. The problem occurred when
I have bought a new usb_touchscreen.
Extracted the report descriptor from that touchscreen.
Pass the report descriptor and all the corresponding data(dev, no_out_endpoint, protocol, report_desc, report_length, subclass) to /sys/kernel/config/usb_gadget/Nhid/functions/hid.usb0/.
After all this steps the HOST_PC could enumerate the touchscreen properly but the tocushes doesn't work(I also know why).
HOST_PC printing this message hid-multitouch xxx:yyy:zzz.uuu: failed to fetch feature 7.
Some touchscreens using Feature reports for allowing the HOST to have configurable device. If I connect the Touchscreen directly to the PC I can see the following under the hood. I'll describe the final steps before sending the input reports from the touchscreen.
pc -> touchscreen (GetDescriptor(Report))
pc -> touchscreen (GetReport(Feature eport))
touchscreen ->pc (Input Report)This is already HID report that sends the touchscreen
The problem hid-multitouch xxx:yyy:zzz.uuu: failed to fetch feature 7 is though I am setting the report descriptor to USB_GADGET's HID device and HOST_PS enumerates it properly, I am not sending the feature report to the host as it requested in step 2 above.
QUESTION:
How to send feature report from device to HOST_PC, if the device is USB_GADGET composite HID device. In usual for sending the Input report (HID data) I am writing the incoming data from the touchscreen to the corresponding /dev/hidg<N> device.
NOTES:
The HOST_PC is Linux(Ubuntu, CentOS,... doesn't metter) and I ma not interested on Windows.
The Touchscreen works perfectly if I connect it to the PC directly.
I don't want to modify the touchscreen's report descriptor, remove feature report part and solve the problem like that.
PS:
I know this is a little bit complicated but Thanks in advance.
In case someone would have this kind of problem in future.
This is not a bug in Linux USB_GADGET driver but I would honestly say that it is a missing feature which is not implemented. This is a link to the place where the implementation wasn't done
https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_hid.c#L652.
If someone wants to send feature_report(s) from device to HOST, than you probably will need to implement it in driver.
This is my modification to USB_GADGET driver that will allow to send feature reports to the HOST.
https://github.com/torvalds/linux/compare/master...AydinyanNarek:patch-1
PS. I don't have enough time to create pull request and other staff for applying this patch to the kernel. If someone would be interested on this than you can take this patch that I have created, polish the code and apply for a patch.
I have a raspberry pi connected with multiple i2c devices and want to be able to programmatically work out the type, manufacturer name, device name and/or description for each device on the i2c bus.
Is there any way to do this? Can it be done in python?
I can already get the ID numbers with python code the does essentially the same as i2cdetect, but it doesn't give any information that tells what each device is.
That means I have to manually dig through data sheets and then still have to disassemble the hardware and test with each individual device as the only one connected, to identify which device is at which ID, since some devices can be customized by altering their factory ID.
Putting it together in the first place was a huge job that I don't want to repeat, so I would rather have a way to identify each device programmatically.
Does anyone know how or if this can be done? Does i2c protocol lend any support for that?
Could it be done indirectly, ie. is it possible to power down or otherwise temporarily mute or disable an i2c compatible HAT while the Raspberry Pi is running and then rescan the i2c bus and identify which ID no longer shows up?
No, the I2C bus is not designed for this.
The only way to do something like this is to have the knowledge of the possible addresses for each type of device stored somewhere, together with a way of detecting whether it's really that particular device. Some devices (such as the BMP/BME sensor family) have a ID register that can be used for this, but others don't have that. There are even devices (such as displays) that don't even support reading any data from them.
I'm currently in a situation that my SoC will be connected via its I2C bus through a I2C-to-UART converter MAX3107 to the UART port of a microprocessor.
Although the communication between the two shouldn't be an issue, the part were the Soc should update the firmware of the microprocessor has to be done with the Y-Modem file transfer protocol.
Although a question is pending at the manufacturer, I still wanted to check here:
Would this even be possible
The SoC runs Linux, is this depending on the MAX3107 driver
Does this concern the I2C bus or is only the UART driver and bus interesting.
https://datasheets.maximintegrated.com/en/ds/MAX3107.pdf
I used the SC16IS750 instead with the Linux kernel driver.
Sending a file via Y-Modem doesn't seem to be a problem. I tried both Minicom and TeraTerm to send a file and it works. The receiver responds is just 1 character each time before sending a part of the file. If the responds would have been more than 64-byte at a time (instead of the one character) this would have been a problem, because the FIFO first needs to be read and cleared before another sting can be received.
I am writing MIPI csi-2 camera driver on Linux but I have a problem about communication enable signal. I have the technical data sheet in my hand but the communication enables register or another info about how to set or get this signal is not mentioned. I think this signal is getting from device tree I don't know. This signal called datasheet as an XCE signal and these are the information about that;
XCE: Communication enable 4-wire: XCE pin and I2C: Fixed to High
The pin for 4-wire serial communication and I2C communication is shared, so the external pin XCE must be fixed to power supply side when using I2C communication
these are some information about that other information of XCE is about how to use it while configuring the camera.
I need some advice or any idea to figure out how to solve this issue.
Thanks.
Best Regards
I have a hardware device that consists of 3 separate chips on an I2C bus. I would like to group them together and expose them to userland as one logical device. The user would see the logical device represented by a single directory somewhere in /sys as well as the nodes you'd expect from the I2C chips under /sys/class/i2c-adapter/i2c-?/*.
One of the chips is an MCP23017 which as far as I can tell already has a driver (drivers/gpio/gpio-mcp23s08.c) and I'd like to reuse it. Another of the chips is a PCA9685 and I would like to contribute a driver for this chip that uses the PWM system in include/linux/pwm.h. The third chip is an MCU running custom firmware.
How should I structure the set of drivers? One idea I had is to register a platform driver to present the logical device, and use I2C drivers from within that. Is this a good way to go? Are there better ways?
The logical device is a motor driver board and IR receiver. I have a simple diagram of its structure.
I'm looking to create two interfaces. The first similar to /sys/class/gpio where motors can be 'exported' and then accessed via reading and writing attributes. This would be useful for shell script access and quick debugging of the mechanical parts of the system attached to the motors. The second a character device node in /dev where data can be read or written in binary format, more useful for application control.
it seems not usual design, are you sure you have access to I2C bus of all chips ?
I think you should be able to talk only to MCU, and MCU should manage other devices.
Otherwise, why MCU is there ?
However, I cannot see your diagram, perhaps link is wrong.