A the title says, I would just like to know how to adjust an I2C driver to handle smbus specs in general.
The SMBus command set is automatically translated to I2C on I2C adapters, but plain I2C commands can not be handled at all on most pure SMBus adapter.
This makes it possible to use the device driver on both SMBus adapters and I2C adapters.
So it is good to use SMBus APIs instead I2C as most of the devices are compatible wo handle SMBus api calls.
Related
If we have a particular ARM-based SOC which has a physical I2C controller included on it, and the intention is to run Embedded Linux on this SOC.
Now we have a separate off-board I2C slave chip connected to this I2C bus from the SOC. For argument's sake, let's say that it's an RTC chip.
The kernel driver for this external RTC chip would more than likely be developed by the RTC chip vendor. Would this vendor need to know about the exact register addresses on the SOC chip in order to write to and read from, or is there other architecture specific code for the chip that the kernel driver can link to?
I want to send data through USB between STM32 and Raspberry Pi. I don't want to use USB to Serial convertor, but instead have a actual USB Connection (maybe CDC class). I have to send data at high rate (Full speed). Please guide on how to achieve this?
A USB-serial connector is simply a microcontroller implementing a USB CDC/ACM virtual COM port and bridging to a UART which you would connect to a microcontroller's UART interface.
In your case you can simply implement the CDC/ACM directly on the STM32 using either of its USB device controller peripherals (USB support varies depending on the specific device https://www.st.com/resource/en/application_note/dm00296349-usb-hardware-and-pcb-guidelines-using-stm32-mcus-stmicroelectronics.pdf).
How you actually implement that will depend on what specific part, and what library or framework ecosystem you are using (e.g. SPL, CubeMX, Mbed). There are reference implementations, examples, drivers and libraries for all of these.
Your milage may vary, but I have measured ST's own USB library and example CDC/ACM virtual COM for STM32F1xx on a 72MHz MCU achieving 700kbits/s. Note that the performance is independent of the baud rate you might set on the host when you open the he VCP. Setting the baud rate simply sends a control packet to the device that can be used to set the baud rate of a UART in bridging applications. In your case such control packets can be ignored. There are similar packets for modem control signals such as DTR, RTS, CTS and RI, which you might choose to us for flow control or other signalling.
The STM32F3DISCOVERY board has an STM32F303VC microcontroller, which has built-in SPI and I2C support, and a gyroscope which supports both SPI and I2C.
Per the board's user manual and schematic, the gyroscope is connected to the microcontroller's PA5/6/7/PE3, which (under 'alternate function 5') are connected to its SPI1 bus (per the STM32F303VC datasheet).
So that makes it possible to use the on-chip SPI support to connect to this gyroscope.
But by keeping PE3 = CS_I2C/SPI high, the device (I3G4250D or L3GD20) runs in I2C mode, and the same PA5/7 pins can be used for I2C SCL+SDA.
My question: Is it possible to use the STM32's on-chip I2C support, to drive these PA5/7 pins and connect to this on-board gyroscope via I2C?
(I cannot find anything in the microcontroller's datasheet or reference manual, that would enable this. So the only alternatives seem to use SPI, or to do I2C by 'bitbanging' on PA5/7.)
There is no I2C on pins PA5 or PA7.
What you can do is put PA5 and PA7 into high impedance mode (input or analog mode) and then connect jumper wires from them to PB6 and PB7 respectively where the I2C function is available and pull-up resistors are already fitted.
I am porting an I2C driver to Linux-4. This device provides multiple I2C addresses for different function simultaneously.
For example:
address 0xAA is for access of SPI flash.
address 0xA0 is for access of EEPROM.
address 0x60 is for normal access (control purpose).
Is it possible to support access of different I2C address in single-one I2C device driver?
Any help appreciated,
Thanks
I think it is possible. Using i2c_transfer() you are giving particular address in i2c_msg structure of the device you want to communicate with. So your driver will be able to communicate with all of the functions of your i2c device.
Depends on what type of I2C driver you are talking about, bus(adapter) or chip(client) driver?
i2c-dev.c is a kind of bus driver with character device interface which exports kernel low level I2C API to userspace.
For each registered I2C adapter Kernel will add i2c-N device node in /devuserspace interface.
But you can't read/write EEPROM chip attached to /dev/i2c-N like simple character device or file. You need to write some utility program regarding chip protocol.
But in Linux there is are special EEPROM chip drivers like eeprom.c or at24.c for registering I2C EEPROM devices with addresses of 0x50..0x57(if I'm not wrong) to Kernel and creating files in /sys userspace interface.
You can access them as a file in:/sys/bus/i2c/devices/0-005x/eeprom
Thanks for Dražen Grašovec and user2699113 's help.
I am porting a I2C device driver (chip, client) to Linux-4.9.
This chip accepts different I2C device address for different purpose.
My goal is to create only one I2C device on Linux device tree file (.dts)
I resolved my issue by using i2c_new_dummy().
In driver probe function,
I made two i2c_new_dummy() to create two additional i2c clients.
One(client#1) is for accessing of I2C address 0xAA, another(client#2) is for I2C address 0xA0.
So I can use client#1 to communicate with its SPI flash and use client#2 to access it EEPROM.
I am currently dealing with two devices connected to the I2C bus within an embedded system running Linux. I am using an exisiting driver for the first device, a camera. For the second device, I have successfully implemented a userspace program with which I can communicate with the second device. So far, both devices seem to coexist happily. However, almost all I2C devices have their own driver module. Thus, I am wondering what the advantages of a driver module are. I had a look at the following thread...
When should I write a Linux kernel module?
... but without conclusion.
Thus, what would be the advantage of writing a I2C driver module over a userspace implementation?
Regards,
Stefan
In your situation, you probably don't have much use for a I2C driver module. If it ain't broke....
The main reason I would include a kernel module driver is when another kernel mode driver is a I2C client, or benefits from tight integration with the kernel. One example of this is the WM8350 audio codec, which is communicates audio data over an audio bus (I2S or AC97) and configuration (e.g. volume level) over I2C.
A power management IC is another example of a chip that you would want the kernel to directly control.
Finally, I will note that there are multiple kinds of I2C drivers. (See Documentation/i2c/summary.) In some cases your hardware might require an I2C bus adapter driver, to teach how to communicate over I2C. That would require a kernel mode driver.