• AVR Freaks

AnsweredAdvanced work with I2C on simulink

New Member
  • Total Posts : 16
  • Reward points : 0
  • Joined: 2014/03/25 07:04:40
  • Location: 0
  • Status: offline
2014/12/14 15:39:13 (permalink)

Advanced work with I2C on simulink

I2C is always tricky and it feels even more so in simulink especially when the interface to a device involves a state machine and even more when interfacing more than one I2C device on the same bus. A good example for a complex I2C device is the BMP180 pressure sensor from BOSCH which is used on the AUAV3_V3 autopilot (33EP512MU810).
I have been digging through the BMP180 example to be released soon with V3.36 of the blockset and I have some questions about it:
  1.  The data sheet and the code samples I have indicate that BMP180 device address is 0xEE. In the example 0x77 is used why?
    I can explain it with some funky big/little endien issue but none of the other fields is like that.
  2. I think I understand the cross-calling between reading UT and UP. In simulink I2C read block produces output only at the next time step. So when you send a request on one block you actually get a response on the other block. But why the different sample time and what creates the phase between the blocks? [.01] vs [.01 .005] isn't the latter equal calling that block in the base sample rate of 0.005?
  3. Is there an uncertainty on when a read request on the I2C will produce data ie in the next call or later?
    In the past I have tried a switch case logic to read the BMP180. In this schema I send a request (case 1) then I call the block that read the data twice (case 2,3) in hope to get fresh data on the 2nd call. Then I repeat the sequence for the other type of data ie switch between UT and UP.
    I now understand that this may not work because the case blocks are actually disabled when it's not their turn. Is this description correct?
  4. When you add in reading of more sensors on the bus I understand you need to time multiplex them by setting a different sample time for each device. How do you do that without using them in blocking mode? How do you make sure they do not run over each other?
I feel I need to get some insight about how I2C should be done here and I appreciate your help with that. 
The mentioned demo is attached zipped.
Super Member
  • Total Posts : 3836
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: online
Re: Advanced work with I2C on simulink 2014/12/14 17:06:22 (permalink)
3 (1)
Have not used Simulink, I use real hardware when communicating with I2C devices.
I2C addresses is a common source of confusion.
A I2C device address may be specified as a 7 bit address, which is 7 bits that may distinguish one device from another.
Or as a byte that include the R/W bit in the LSB position.
In order to possibly avoid confusion, the Bosch datasheet do not specify the 7 bit address, which is 0x77.
Instead it specify 8 bit Write address, which is 0xEE and 8 bit Read address, which is 0xEF.
Do you want to connect multiple pressure sensors to the same I2C bus?
That may be troublesome, since BMP180 only have a single I2C device address.
You may have many other devices on the same bus, and talk to each one individually,
as the I2C device address is always the first byte every time a I2C message is started.
Each I2C device will answer only when called with it's address, and I2C slave devices will speak only when spoken to.
You may communicate with other I2C devices on the same bus while waiting for BMP180 to perform a measurement conversion.
New Member
  • Total Posts : 16
  • Reward points : 0
  • Joined: 2014/03/25 07:04:40
  • Location: 0
  • Status: offline
Re: Advanced work with I2C on simulink 2014/12/15 01:51:04 (permalink)
Got the explanation about the address.
The LSB is the READ/WRITE bit so for a notation that uses 7-Bit address the LSB is discarded and the address is shifted to the right 1-bit.
Thank you for the insight.
  • Total Posts : 442
  • Reward points : 5
  • Joined: 2007/03/31 07:38:15
  • Location: Bayonne, France
  • Status: offline
Re: Advanced work with I2C on simulink 2014/12/15 13:26:33 (permalink) ☼ Best Answerby manora 2014/12/15 14:11:04
4.5 (2)
Thanks for theses questions and inputs.
We tried to make I2C block for Simulink as easy as possible, However as Manora mentioned, I2C is tricky ; prior knowledge on I2C BUS might help.
Let's reply point by point:
1. Address (7 or 10 bits, see  figure)

The I2C block set the chip address using the 7 (or 10) bit address. Last bit (read/write) is set appropriately depending whether the next action following the « Write address » is a read or a write action. As Mysil mentioned (post above), data sheet of component might be confusing as some define the address using the 7-bit value, others define 8-bit address that takes account the last bit as with the BOSH BPM180 data sheet.
2. Several I2C blocks / Blocks sample time (see time offset on figure)

The I2C generated code handle I2C in background through interrupt and a state machine. (The Blocking mode in the GUI can override the “background” execution)

Background / Interrupt driven mode are interesting :

  • It save MCU time (Background & Interrupt)
  • It is safer : if the I2C Bus get stuck for any reasons, the overall model execution continue ; When one I2C block does not finish its sequence after, it free up the I2C BUS and reset its state (after 3 of its own sample time). In most case, the I2C will recover even after an important EM perturbation. 

Price to pay » is the block output delay: The block does not wait for the end of I2C transfer. Block outputs are thus « delayed » by 1 « block » sample.
One I2C block allows addressing many chips.
However, it is possible to use several I2C blocks driving the same I2C peripheral/BUS. Using several I2C blocks allows addressing different chips with different rates.
Multiple I2C blocks with different rates are used within this example: The BMP180 sensor provides both pressure (P) and temperature (T). There is only one conversion unit within the BMP180 chip. User must initiate a conversion of either P or T, wait for end of conversion and read the result of that conversion.
Each conversion takes 4.5ms.
  • one block (green on figure) reads the result T from the previous conversion and initiate a P conversion each 10ms, (block sample time set as [0.01], time offset not provided is 0 by default) while
  • a second block (blue on figure) reads result P from the previous conversion and initiate a T conversion each 10ms with a delay of 5ms. (sample time set as [.01 .005])
Delay for each conversion is 5ms and fit with the 4.5ms requirement. (see[image]C:\M91449\MCHP_Blockset\doc\Figs\forum[/image]***)
Sample time offset are not used very often with Simulink but this capability worth to be known for code generation.
To go further with the BPM180: The dynamic (rate of change) difference between T variations (slow) and P variations (fast in UAVs) is important. It might worth using only one I2C block setting the conversion command as a block input (i.e. not static value as with this example), and add the appropriate logic so as to convert P with a higher rate than T…
3.      Blocks data are independent
With this blockset, data for each I2C (or SPI) blocks are isolated: data from each I2C blocks result from transaction initiated by itself. (This was different from the outdated « LK » blockset). The implementation you described is not Ok as you mentioned.
4.     Several I2C block with the same sample rate 
Using two I2C blocks at 1ms would be equivalent to one I2C block where the transaction sequence is the concatenation of the two I2C blocks.
We do not provide an estimated time of the transaction. User must make sure that BUS clock rate and component responsiveness/task comply with the sampling rate of the I2C blocks.
*** Lower rate tasks have lower priority thus jitter might appear for these tasks and might then violate the 4.5ms requirement for the BM180 conversion. If the mcu is heavily loaded, it might be safer to either add margins, check for end of conversion (see BMP180 doc), or place theses blocks within a higher rate with a custom logic to run theses at a lower rate..

Attached Image(s)

Jump to:
© 2020 APG vNext Commercial Version 4.5