MATLAB Answers

Simulink and the I2C interface

6 views (last 30 days)
Joe on 27 Mar 2011
Hi all,
I'm trying to use Simulink to program a Lego Mindstorms NXT vehicle. The main program is complete, except for the sensor interface. The I2C optical sensor is already constructed and meant to be connected to one of the Lego ports. However, I'm not sure how to do that. I've downloaded a tool (Embedded Coder Robot or ECRobot) that is supposed to make Simulink work with the Lego system. However, it only works with standard sensors. See link below.
Since I haven't the faintest clue about how to do this, I thought I would look under the masks of some of the blocks in the ECRobot blockset to get a hint. The interface blocks for all the sensors (compass, gyro, motor, sound, touch, etc.) seem like a good place to start. However, looking under the mask reveals just a Saturation block and a Data Store Write block with no mention of any associated files. Surely, that can't be all there is?! It tells me very little about how to write my own code (or at least modify existing code) to achieve my goal. There are several files in other subdirectories which have codes that address the I2C communication protocol. As I haven't seen them used in any way and I also don't know how they're linked to the Simulink blocks, I'm unable to figure out how they work.
Could somebody please tell me how to uncover more of the inner workings of these blocks? If not, would someone like to share his/her knowledge of getting I2C to work with Simulink? Thanks very much.


Sign in to comment.

Answers (1)

Kaustubha Govind
Kaustubha Govind on 28 Mar 2011
I don't have experience with ECRobot, but have written drivers for other boards in the past. Typically, device drivers are implemented as S-functions with an accompanying TLC file to inline driver code into any code generated for the model. (If you do not intend to generated code from your model, you do not need to write a TLC script).
I downloaded the files for ECRobot and found several such drivers under ecrobotNXT/environment (for example, sfun_color_sensor).
If you have access to C/C++ drivers for the I2C optical sensor, then you can easily write S-function wrappers to create driver blocks.


Show 4 older comments
Kaustubha Govind
Kaustubha Govind on 29 Mar 2011
Also, it is perfectly okay for multiple blocks to be present in the same library model. In fact, this is how most Simulink block libraries are defined.
Joe on 29 Mar 2011
Thanks for your patience, Kaustubha. I'm aware of Mr Chikamasa's situation and have extended my sympathies to him in a previous email. It's also why I waited a week before sending another email.
I read the documentation again and it does mention several times about the placeholder status of the blocks. But that's why it's so confusing. Other than the few blocks that include S-functions, the rest of the blocks make no reference to any other files that call or are called by these blocks when generating code. How then does one follow the code-generation trail? The whole thing just seem so convoluted.
I had a look at iGetColorSensorBlockPortID and a few other files, but again I'm unable to glean any information about the comms operation from them. I'll keep looking...
Kaustubha Govind
Kaustubha Govind on 30 Mar 2011
Thanks for understanding, Joe. With regards to how the device APIs are generated, unfortunately, my understanding is limited. Have you tried generating code from some simple test models and examined the emitted code? The documentation for the S-function+TLC technique is pretty solid, so you may be able to extend that information to create an S-function driver block.

Sign in to comment.

Translated by