Mpu6050 - Module #140
Open
Mpu6050 - Module #140
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Driver skeleton consist of two functions: 1. Module entry point (mpu6050_init) This function is called when driver is loaded. Should return 0 on success (driver will be loaded) or negative error value on failure (driver will not be loaded). 2. Module exit point (mpu6050_exit) This function is called on driver removal. No return value. Both functions should be exported using module_init and module_exit macroses. Debug information may be printed using printk() function and can be read using dmesg program. But checkpatch.pl script treat printk(KERN_INFO as warnings so pr_info() was used instead. Signed-off-by: Andriy.Khulap <[email protected]>
I2C driver consist of:
1. probe and remove functions. Called on driver load and removal respectively.
2. i2c_device_id structure. Should contain strings exact equal to devive tree.
MODULE_DEVICE_TABLE() macro is mandatory for match with dtb. Without it
driver will not be probed.
static const struct i2c_device_id mpu6050_idtable [] = {
{ "mpu6050", 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, mpu6050_idtable);
3. i2c_driver structure itself.
Important fields: probe, remove and id_table should point to items described
above.
static struct i2c_driver mpu6050_i2c_driver = {
.driver = {
.name = "gl_mpu6050",
},
.probe = mpu6050_probe ,
.remove = mpu6050_remove,
.id_table = mpu6050_idtable,
};
I2C driver is created using i2c_add_driver(&mpu6050_i2c_driver) function.
It will return 0 on success and most likely is called from module_init().
Please note that without device tree match probe function will not be called,
but i2c_add_driver() will return OK. With device tree match, probe function
will be called right after i2c_add_driver().
I2C driver is removed with i2c_del_driver(&mpu6050_i2c_driver) function.
If driver was created, remove function will be called.
Signed-off-by: Andriy.Khulap <[email protected]>
Most of i2c chips have a special read-only register with unique id. So the easiest way to communicate with the device is to read that register. It should be accessibe even during power off modes and so failing to read it means no communication with the device. Reading non-expected value will indicate wrong adress or data size used, or incorrect device connected (other revision). Reading small amounts of data is easiest done using i2c_smbus_read_byte() or similar functions. Why smbus? Because they are wrappers to i2c_transfer() function and have internal device address as a parameter. This eliminates need to fill i2c_transfer structure for each small read or write. Using i2c_transfer() should be considered for large blocks of data and gives a performance boost over i2c_smbus wrappers. Signed-off-by: Andriy.Khulap <[email protected]>
This mpu6050 driver functionality consist of reading relevant values and exporting them to the user space. Needed parameters are: accelerometer x, y, z, gyroscope x, y, z and temperature (as an easiest check that device is configured and operating properly). First, the chip must be configured. This consist of programming all setup registers with correct values. For example: clear power down, set prescalers, configures fifos and so on. Configuration is usually done in driver probe routine. Second, reading values or performing needed actions can be done in a separate theread inside driver, or in the workqueue. But this driver is supposed to give values on demand so there is no need for that. All values are read at once in a single function. To export data to the user space was decided to use sysfs. A class was created and 7 attributes for each parameter. Since all parameters are read-only, all attributes have only show function and their access rights are set to 0444. So all _show() fuctions are almost the same: read all parameters first, then return the needed one. The summary how this driver works: 1. Create i2c device in module_init() and configure the chip from i2c_probe(). 2. Create sysfs class and attributes for each parameter from module_init(). 3. Read and return mpu6050 parameters in each sysfs_attribute_x_show(). Signed-off-by: Andriy.Khulap <[email protected]>
Signed-off-by: Yevgen Kovalyov <[email protected]>
Signed-off-by: Ivan Hudzinskyi <[email protected]>
yekovalyov
suggested changes
May 7, 2019
yekovalyov
added
changes requested
Add new /sys interface for showing temperature in Fahrenheit in addition to Celsius Signed-off-by: Ivan Hudzinskyi <[email protected]>
Added conversion to Fahrenheit, new /sys entry to show the value |
JohnTheUnigoat
added
ready
yekovalyov
suggested changes
May 11, 2019
| g_mpu6050_data.temperature); | ||
| dev_info(&drv_client->dev, "TEMP (CELCIUS) = %d\n", | ||
| g_mpu6050_data.temperature_c); | ||
| dev_info(&drv_client->dev, "TEMP (FAHRENHEIT) = %d\n", |
There was a problem hiding this comment.
The resolution is 1 F but required 0.001 degrees F
yekovalyov
added
changes requested
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Modified, compiled and ran provided module on target platform