![[RTEMS Logo]](/images/logo.png){kind=logo}
Changes between Version 5 and Version 6 of TBR/Review/RsgTrialsAndTribulations
- Timestamp:
- 12/11/18 17:13:04 (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TBR/Review/RsgTrialsAndTribulations
v5 v6 8 8 As is commonly done in various OS environments, device resources are assigned major and minor "device numbers" by RTEMS. While this concept is quite simple on the face of it, with libi2c things are a bit more complicated. An explanation of how these numbers are assigned was provided to me by Till Straumann: 9 9 10 <blockquote>11 "Traditionally, the major number is associated with a particular driver (registered with the OS) the minor number with a device instance; ultimately the semantics of the minor number are defined by the driver, the major number by the OS.12 10 13 libi2c registers itself with RTEMS under one major number and it uses specific semantics for the minor number." 14 </blockquote> 11 **"Traditionally, the major number is associated with a particular driver (registered with the OS) the minor number with a device instance; ultimately the semantics of the minor number are defined by the driver, the major number by the OS." 12 13 "libi2c registers itself with RTEMS under one major number and it uses specific semantics for the minor number."** 15 14 16 15 One thing to realize here is that the major number here applies to the libi2c driver, which includes both I2C '''and''' SPI interfaces. So a hypothetical system could have two I2C and three SPI controllers, each with a number of devices attached. RTEMS would assign the same major number to all controllers and devices; only the minor number for each device would differ. 16 17 17 18 = Device Minor Numbers = 18 19 19 20 20 So, device minor numbers hide quite a bit of complexity behind a simple integer! Again from Till: 21 21 22 <blockquote> 23 "The 'minor' number actually encodes three things:22 23 ''"The 'minor' number actually encodes three things: 24 24 25 25 # 'device' driver (e.g., temp. sensor) as registered with rtems_libi2c_register_drv(). The device driver knows what to write to/read from the device to achieve certain things. However, it doesn't know how to interact with the particular i2c/spi controller chip in order to write to/read from the device. 26 26 # 'bus' driver (for a particular i2c/spi controller) as registered with rtems_libi2c_register_bus(). The bus driver knows how to communicate with the attached devices but it doesn't know about the semantics. 27 27 # device address on the bus (multiple devices using the same 'device' and 'bus' drivers may be present." 28 </blockquote> 28 '' 29 29 = SPI Usage = 30 30 … … 32 32 Yet again, from Till: 33 33 34 <blockquote> 35 a) you register a bus-driver for your SPI chip with libi2c and get a bus number returned.[[BR]][[BR]]34 35 **a) you register a bus-driver for your SPI chip with libi2c and get a bus number returned.[[BR]][[BR]] 36 36 b) you register a device-driver for your EEPROM with libi2c on a bus (use number from step a) at a device address on that bus. You obtain a minor number back.[[BR]][[BR]] 37 37 Optionally, step b) also creates a file system entry (mknod) with your name of choice, libi2c's major number and the minor number from step b)[[BR]][[BR]] 38 38 Step b) can be repeated for multiple instances of identical devices (same dev-driver but different dev-address => different minor number). 39 </blockquote> 39 ** 40 40 41 41 = Read Example = 42 42 43 44 43 Even more from Till: 45 44 46 <blockquote>47 45 "Here's what happens when you e.g., read() from a libi2c device: 48 46 49 # OS knows (by major number) that it has to call libi2c 50 # OS dispatches rtems_i2c_read() 51 # libi2c figures out what bus and device drivers (as registered in a+b) to use. It sends a addressing sequence using the bus driver and the device address (encoded in minor number) 52 # libi2c calls the 'device' driver's 'read' function 53 # the 'read' function does it's job (e.g., if you read from a thermometer the driver has to i) trigger a measurement, ii) read back from the device, interpret the results and hand them to the user. 54 # the device driver accomplishes i), ii) using libi2c's low-level routines rtems_libi2c_start_write_bytes & friends to interact with the device 55 # low-level routines use the bus driver (as encoded in 'minor') to actually perform the communication 47 * OS knows (by major number) that it has to call libi2c 48 * OS dispatches rtems_i2c_read() 49 * libi2c figures out what bus and device drivers (as registered in a+b) to use. It sends a addressing sequence using the bus driver and the device address (encoded in minor 50 number) 51 * libi2c calls the 'device' driver's 'read' function 52 * the 'read' function does it's job (e.g., if you read from a thermometer the driver has to i) trigger a measurement, ii) read back from the device, interpret the results and 53 hand them to the user. 54 * the device driver accomplishes i), ii) using libi2c's low-level routines rtems_libi2c_start_write_bytes & friends to interact with the device 55 * low-level routines use the bus driver (as encoded in 'minor') to actually perform the communication 56 56 57 57 A bit complicated but it strictly separates drivers for the … … 59 59 the attached devices ('what' to read/write). 60 60 61 Look in libchip/i2c for examples of libi2c 'device' drivers." 62 </blockquote> 61 Look in libchip/i2c for examples of libi2c 'device' drivers."**
