Simulink and the I2C interface

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.

http://www.mathworks.com/matlabcentral/fileexchange/13399

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.

Cheers

Answer 1

[Kaustubha Govind]

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.

[Joe]

Thanks for the reply, Kaustubha. I've used Matlab and Simulink for number of years now. However, this is the first time that I'm attempting to connect to actual hardware as opposed to merely running simulations. As such, I don't have any experience in writing drivers. That's why I'd like to have a look at the inner details of a working block in order to learn how it operates. By the way, the optical sensor actually has an SPI interface. Since the Lego system uses the I2C protocol, I've programmed a microcontroller to work as an intermediary between the sensor and Lego port. So, there aren't any manufacturer's drivers I could use in this case.

I did look at all the S-function files, but they don't seem to mention anything about how the blocks communicate via the I2C interface. The code mainly deals with parameters such as number of ports or packet sizes. Also, as I pointed out before, blocks such as compass, gyro, motor, sound and touch, only reveal Saturation and Data Store Write blocks under their masks. They don't have any S-functions or other associated files as far as I can tell. How can that be? What about those files with I2C-related names in the subdirectories? How are they linked to the Simulink blocks or S-functions files?

I haven't been able to find much information on this issue. So, I'd really appreciate if you could enlighten me. Thanks.

Cheers

[Kaustubha Govind]

Joe: Any answer that I can give will be mostly speculative. Have you tried contacting Takashi-san, who is the author of the ECRobot: http://www.mathworks.com/matlabcentral/fileexchange/authors/68132

[Joe]

Indeed, I have. I had an installation problem that he addressed a couple of weeks ago. After I managed to install it, I encountered this issue and sent him an email enquiry. I waited nearly a week without a response, so I sent him another email two days ago. Hopefully, I'll get a reply this time.

I've a general question for you, though. When looking under a mask, is that all there is to a block, or could there be other hidden information (i.e. associated files and functions)? If it's the latter, how do I uncover further details? I ask this because the unmasked contents of some of the blocks that I mentioned previously are quite obviously too basic for their tasks. In fact, I don't even see the individual mdl file for each block. It seems they're all embedded in one mdl file. Thanks.

Cheers

[Kaustubha Govind]

The operations of our Japan office have been affected by the current circumstances in that country. Please excuse any delays in communication from Takashi-san.

Regarding your question about "look under mask" - the simple answer is "Yes, that is all there is to the block". For more perspective, I looked into the ECRobot documentation and found this line for the blocks that you mentioned: "In simulation, these blocks are just place holders; however, they will be used to implement an appropriate device API in the generated code."

I also found several files under the private directory that actually help generate code for these blocks. For example, you can look for usages of iGetColorSensorBlockPortID in that folder and navigate through the code to see how additional source files are generated for these drivers.

This is not a standard way to write drivers, but is legitimate.

[Kaustubha Govind]

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]

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...

Cheers

[Kaustubha Govind]

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.

HTH.