AnsweredAssumed Answered

Master/Slave I2C on the same interface

Question asked by Harvey White on Aug 11, 2017
Latest reply on Aug 21, 2017 by KIC8462852 EPIC204278916

I'm working on getting two microprocessors to talk.  One of them is an F446, the other is an L432.  The communications scheme is that (for example) the 446 sends a message to the L432, which then executes it (command for a graphics display).  The L432 then assumes master mode, and sends a message to the F446 confirming execution.

The display infrastructure works, the message building works, but using Cube32, there's a problem.

The reply from the L432 never gets sent. 

I have an RTOS task reading buffers, looking for a full one.  With the right status and address, the Master_send_IT routine is called and the buffer sent.

At the same time, since the node (any processor) can be accessed as a slave, another RTOS task is waiting for a message, and there's the problem. 

Under cube32, getting a slave message is a task that leaves the interface in busy_rx status.  This effectively blocks the transmit task.

Apparently, according to the Cube32 writers, one never uses the I2C any differently.

I've solved the problem in Atmel XMEGA's by writing the interrupt routine myself, which I could do, but I'd rather not.

The only tentative solution I have is to have the transmit task cycle through one buffer scan, then call receive message (programmed receive and blocking) with a 1 ms timeout, then if there is no error, execute a slave command, otherwise scan the TX buffers again looking for something.

Working on an interrupt basis is nicer, but I'd have to abort the interrupt receive, reset the peripheral, and see if there's a message to be responded to.

Just to make a point, the L432 is not intended to originate a message without the F446 first sending a command.  The F446 will be the only device sending unsolicited messages. 

Is it reasonable to leave the interface in slave mode (which is normal) and then use the addressed interrupt hook to start up a receive task?  That task would then call the normal (either programmed or otherwise) read routine to build a buffer, then go from there.

The overall flow is:  Send command to slave, slave executes command.  Slave then assumes master role and sends status message to former master. 

Anybody do this before?

Any ideas?

 

Harvey

Outcomes