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?
Related
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.
I am using nucleo-wb55 development board with STM32WB55 processor. I want to connect sensors like IIS3DWB, STTS22H to this board. How can I go about connecting the modules of these sensors to nucleo-wb55?
You can connect them via the I2C and SPI interfaces the board provides. Either built your own I2C/SPI or use the STM32 HAL provided functions.
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.
We have a FTDI device, FT2232H and an EEPROM M93C46-WMN6TP. Is there a utility or a way to program the eeprom in Linux using command line? We do not have provision for GUI in Linux or for connecting it to a windows system.
There is a sample EEPROM folder provided with the driver package that cab used for programming the EEPROM device (/release/examples/EEPROM/write/ )
Write can be checked used the read program in /release/examples/EEPROM/read/
You can absolutely program an EEPROM with a FT232H, but you will have to write your own program.
I am more a Windows person, but the code should similar on Linux.
I just sent a tweet yesterday doing just this with an FT4222 board
that I will use for my USB device Nusbio v2.
https://twitter.com/MadeInTheUSB/status/808868754146914304
A video experimenting with the FT232H
https://www.youtube.com/watch?v=8i8_EFs_j0I
The EEPROM M93C46-WMN6TP protocol seems to be SPI
see datasheet page 6
I suppose you may already have an FT232H evaluation board, so once wired on a breadboard to your EEPROM all the 4 SPI wires (CLOCK, MOSI, MISO, CS) you can start talking to the EEPROM.
Unfortunately the source code from one EEPROM to another thing can change.
I know very well the I2C 24LC256 family and the SPI 25AA1024.
Some of my code is available on github, this is for the SPI EEPROM 25AA1024,
that should help
MadeInTheUSB.Nusbio.SPI.EEPROM_25AA1024
MadeInTheUSB.Nusbio.Components/EEPROM
You can find a 100% already made solution hardware and software at
Nusbio Thumbdrive
Using the source mentioned above.
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.