You are mostly right, you only need /dev/i2cX if you want to run the
i2ctool.
But some drivers could create its /dev/xyz even when the device is not
present, because some those drivers don't have a kind of probe() function
to get a confirmation from the driver.
When the extern I2C or SPI device has a product/vendor ID register it could
be read to confirm the device was detected.
BR,
Alan
On Sunday, May 2, 2021, yuta <yutr...@gmail.com> wrote:
> Hi Alan,
>
> Thank you for the information!
>
> ---
>
> My understanding for now is below. (For nucleo-F767 board)
> - An initialization file is lying in nuttx/boards/arm/stm32f7/nucle
> o-144/src/stm32_appinitialize.c. (Contents in this file is executed when
> launching NuttX.)
> - Initialization code for specific I2C sensor like MPU9250 should be
> called in the file to associate I2C lower-half and specific sensor's
> upper-half then register the associated driver as like /dev/mpu.
>
> What I'm not sure is if I always need to use i2c_drivers.c(i2c_register())
> which is in nuttx/drivers/i2c/.
> I guess that I don't need to do that. What I need to do is choose which
> upper-half driver to use this time. i2c_drivers.c is maybe a general I2C
> upper-half driver. That's why it can be used when I just want to read/write
> for specific register.
> I guess that a driver called I2C upper-half is basecally created not for
> communicate to general I2C device but created for a specific I2C device
> such as MPU9250 and it provides some data with the form which can be used
> directly like gyro, accel, temp... not like gx_h, gx_l, gy_h, gy_l,....
>
>
> Yuta Ide
>
> On 2021/05/01 21:10, Alan Carvalho de Assis wrote:
>
>> Hi Yuta,
>>
>> stm32_mpu9250initialize("/dev/mpu0");
>>
>> This function receive the name of the device file it will creste. The
>> /dev/i2cX is created by the funcion i2c_register().
>>
>> BR,
>>
>> Alan
>>
>> On Saturday, May 1, 2021, yuta <yutr...@gmail.com> wrote:
>>
>> Gregory,
>>>
>>> Thank you for your answer.
>>> I think I'm asking very easy question since I'm very new to NuttX.
>>>
>>> I'm not still sure how I can enable an I2C device.
>>> I understood that there are lower-half driver and upper-half driver and
>>> they should be associated each other with initialization code.
>>> Refering some documents like below, I added some lines to do that.
>>> I can see /dev/i2c1 now but i2c tool still does not detect any i2c
>>> device.
>>> https://github.com/apache/incubator-nuttx/blob/master/boards
>>> /arm/stm32f0l0g0/nucleo-g070rb/src/stm32_bringup.c#L89-L111
>>>
>>> I also tried to make upper-half driver refering here.
>>> https://github.com/micro-ROS/NuttX/issues/9
>>> In this case, I call mpu9250_register() which I made instead of
>>> i2c_register().
>>> /dev/i2c1 appeared with ls /dev.
>>> However, `i2c dev -b 1 0x03 0x77 ` did not detect any i2c device.
>>>
>>> Yuta Ide
>>>
>>> On 2021/04/30 22:18, Gregory Nutt wrote:
>>>
>>> On 4/30/2021 6:34 AM, yuta wrote:
>>>>
>>>> Hi all,
>>>>> I'm trying to use I2C.
>>>>> I configured below in menuconfig.
>>>>> - System Type > STM32 Peripheral Support > [*] I2C1
>>>>> - Device Drivers > [*] I2C Driver Support
>>>>> then compilation was done successfully.
>>>>> But no I2C device( like /dev/i2c1 ) showed up when I tried ls /dev
>>>>> Do I forget something to do?
>>>>>
>>>>> I'm using Nucleo-F767ZI board.
>>>>>
>>>>> Thank you.
>>>>> Yuta Ide
>>>>>
>>>>> Did you enable an I2C device? STM32 I2C peripheral support is not an
>>>>>
>>>> I2C device. It an I2C "lower half" and will not create a character
>>>> device. You also have to (1) enable an "upper half" device that uses
>>>> I2C,
>>>> (2) create an instance of the I2C "lower half", and (3) bind the "lower
>>>> half" to the "upper half" and register the driver.
>>>>
>>>> Remember, I2C is not a device. I2C is a bus that provides the physical
>>>> transport to devices on the bus. You should not normally do direct bus
>>>> access from applications .. although you can with
>>>> drivers/i2c/i2c_driver.c. i2c_driver.c can be used by your
>>>> board-initialization logic to create a character device that will allow
>>>> appliations to access the bus directly. So you can create some kind of
>>>> very limited user-space driver. It is limited because it cannot
>>>> integrate
>>>> simply with other aspects of the device such as GPIO controls or
>>>> interrupts.
>>>>
>>>>
>>>>
>>>>
