i2cm Master Only driver - example???

[lpcware]

Content originally posted in LPCWare by robertpalmerjr on Thu Mar 20 12:26:15 MST 2014
I have a configuration where I have:
- one master (lpc18xx)
- one slave device
- want to use interrupt based communication

Looking at the lpcopen examples, there is a driver for master only (i2cm_18xx...) and even an interrupt based master only example.  I thought, perfect!, but then I started looking at the example and it uses many function from the basic i2c_18xx driver.  For example, instead of using Chip_I2CM_Init(id) (which would make sense since this is a master example) it uses Chip_I2C_Init(id).  Looking at the code, they do the same thing, but with different levels of abstraction (i.e. I'm guessing they were written by different developers, certainly they did not copy/paste).

Only the Chip_I2CM_Xfer is used in the example.  Are there any samples that show how to use ONLY the i2cm driver?

Specifically what I'm having trouble with is the setting up the appropriate event handling on the interrupt. 

The example project uses: Chip_I2C_SetMasterEventHandler(id, Chip_I2C_EventHandler);

What is the equivalent for the master only driver?  Is there an equivalent.  It looks to me like this may not even be needed in the configuration I'm attempting.

[lpcware]

Content originally posted in LPCWare by robertpalmerjr on Wed Mar 26 05:25:17 MST 2014
I just realized looking at your code that you are using the CMSIS libraries.  I would suggest downloading and using the LPCOpen libraries.  There is one specific for the NGX_xplorer_1830 board (and others).  These libraries have broken out Board Level functions and chip level functions (e.g. on the xplorer, in the board API, there are audio apis).  This is a much cleaner and more compartmentalized design.

NXP appears to be migrating to supporting the LPCOpen libraries more than the CMSIS libraries

[lpcware]

Content originally posted in LPCWare by robertpalmerjr on Wed Mar 26 05:20:15 MST 2014
Look at the LPCOpen examples for the NGX_eplorer_1830...

I2C1 may be on the external pins, but in all likelihood,when it first comes up, those pins are configured as GPIO pins - I haven't looked at the data sheet to be sure.

You must call the following before the I2C will work correctly. 

SystemCoreClockUpdate();
Board_Init();

Board_I2C_Init(I2C1);  // <--- configures the I2C pins

/* Initialize I2C */
Chip_I2C_Init(I2C1);   // <--- enables the I2C module clock
Chip_I2C_SetClockRate(I2C1, SPEED_100KHZ); // or SPEED_400KHZ

[lpcware]

Content originally posted in LPCWare by vincentl on Wed Mar 26 03:50:50 MST 2014
Thank you for your reply,

I'll check the board API but in my case on the LPC1830, I2C1 is the module which is by default connected to external pins, so I thought this would work when just initialising the  I2c module, don't you think?

[lpcware]

Content originally posted in LPCWare by robertpalmerjr on Tue Mar 25 09:16:16 MST 2014
Which mode you should use is really dependent on your application.  Generally speaking...

Polling Advantages:
1. simpler to understand.  You start the transfer, the call blocks until the transfer is complete, when the call returns, your code continues on doing the next thing
2. uses fewer resources (no interrupt required)

Polling Disadvantages:
1. the call blocks, which means you can't do anything else while the transfer is occurring (well, there are exceptions, you could be running in an RTOS task, see below)
2. draws more power, the CPU is constantly running attempting to determine the state of the transfer and progress through the transfer.

Interrupt Advantages:
1. asynchronous, the transfer happens in the back ground.  You just set up the transfer and start it then go off and do other work.  You'll get notified with the transfer is complete.
2. if you use any low power configurations and use the WFI instruction, the processor will go to sleep in between states, thus saving power.

Interrupt Disadvantages:
1. more complex, you must understand and deal with the fact that when your code returns from the "write" call that the data has not yet been written, it is only complete after you receive the final state in the interrupt.
2. uses more resources - you have to manage the interrupt for i2c interface

One other option is to use an RTOS (e.g. freeRTOS) and put a polling instruction in a separate task.  This can give you the non-blocking effect, you send a message to the i2c task with the data to be transferred, the task will then handle the transfer.

This addresses the blocking disadvantage, however, this does not address the power savings disadvantage of polling.  The i2c task will still keep the processor awake and consume more power.

If you're developing a simple app that just periodically updates a digital potentiometer and you're only transferring a few bytes at a time, and you don't care about power consumption, then polling is for you.  If you're developing a complex application that has many things to do, needs to be very responsive, has to transfer large numbers of bytes at a time and you're sensitive to power consumption, interrupt driven is for you.

Taking a quick look at your code and not testing it, I'm guessing you need to use the board API (board.h) or chip API to configure the I2C1 pins and enable the I2C module.  I2C0 is by default connected to external pins, I think I2C1 may be multiplexed with GPIO and therefore the pins need to be configured first.  Look at the examples in lpcopen for the i2c driver.

[lpcware]

Content originally posted in LPCWare by vincentl on Mon Mar 24 06:24:29 MST 2014
Hi there,

I'm also having troubles with I2C on the LPC1830 board which I want to use in order to drive a digital potentiometer. So I only want to use the lpc1830 as a master sending the same 8 bits after each other.

My first question is: which mode should I use: the polling mode or the interrupt mode?
Second question: I did some programming but this without the I2c to work properly:


#include "lpc18xx_i2c.h"

I2C_M_SETUP_Type masterTransferControl;
uint8_t txData[10]={0x11,0xff,0xab};

masterTransferControl.sl_addr7bit=0xA0>>1;
masterTransferControl.tx_data=txData;
masterTransferControl.tx_length=8;
masterTransferControl.rx_data=NULL;
masterTransferControl.rx_length=0;
masterTransferControl.retransmissions_max=0;

I2C_Init(LPC_I2C1, 400000);
I2C_Cmd(LPC_I2C1, ENABLE);
I2C_IntCmd(LPC_I2C1, DISABLE);
I2C_MasterTransferData(LPC_I2C1, &masterTransferControl, I2C_TRANSFER_POLLING);
I2C_DeInit(LPC_I2C1);

Why won't this code work?

[lpcware]

Content originally posted in LPCWare by robertpalmerjr on Thu Mar 20 14:16:04 MST 2014
I guess I should have dug deeper first.

short answer, there is no equivalent - it's not required.  I commented out the calls to SetMasterEventHandler() and it appears to work just fine.  I think this is only needed if one is in an environment where there are either the device can be a slave (and you couldn't use I2CM) or where there are multiple masters on the I2C bus.

I2CM_... appears to have been an afterthought, it's header file is NOT included in board.h  It uses the ADDRESS of the I2C modules for the INIT and BusSpeed calls (as opposed to an index of 0 or 1 as the basic i2c driver uses).  It seems to work fine, but it was not tightly integrated into the LPCOpen library like the main i2c driver was.