Multi Core Operation - Cores as I2C slaves

[stryd_one]

Hey all,

I've been looking into the way I should go about designing an application which requires multiple cores, and I've realised that due to the inherent latencies of sending MIDI information, using the MBLink functions would just be too slow.

As such I figured that the best way would be to use the IIC (I2C) bus. From what I can gather in the code, the IIC routines which exist will only allow the core to be a master, and they don't seem to be checking for collisions and so won't work in a multimaster environment. (I could be wrong about this!)

So I have two jobs on my hands...

The first is to write some new IIC routines to allow slave mode, and to collision check when in master mode, so that multiple masters on one bus will work.

The second is to design some kind of MIDIBox Core Module Intercommunications Protocol that will be a language for the cores to speak, over the I2C buss.

Obviously this is not a small job, but I'm pretty keen to do it, so I thought I'd drop a quick post and see if anyone (especially you Thorsten) has any ideas on this.

Of course I could just go ahead and write the code up for my own good, but I think it would be best for the community here, if I do this in a way that will allow the code to be used for other applications. I guess what I'm saying is that I want this to be a protocol that can be used widely for many different customised MIDIBox apps, not just my own

I'd really like lots of feedback on this, so if you have any thoughts at all please post them :)

I went to work early today so that I could write this post  :) Sorry it's so long!    :-X

[TK.]

Hi,

maybe you should contact Duggle who is also working on an IIC slave driver

Best Regards, Thorsten.

[stryd_one]

/me calls out

Duuuuuuuuuuugggllllllle!!

You've got a PM mate   ;D

[stryd_one]

Seeing as Duggle is doing university exams at the moment, I think I will not bother him too much with this right now... He will be back in a month, so we should all wish him good luck in his exams in the meantime. Go Duggle! :)

I've found lots of information regarding PIC IIC slave operation, but almost all of it uses the on-chip IIC support through the SSP module, which isn't available in our case... I wonder how hard it would be to use the hardware IIC support? It looks like the SCL line for IIC is being used as the clock for the shift registers with the current design, so without any buttons/faders maybe it would be possible?

If it's not possible to use the SSP module, then it appears that the only way to implement a IIC slave would be software polling of the pins, which could take a lot of cycles (or maybe not... Am I worrying too much?)... And even then, I don't know if collision detection would be possible (This is something that I cannot find on the 18F datasheet, hopefully someone here has a better understanding of it's capabilities).

Any thoughts anyone?

[TK.]

I wouldn't use the IIC slave interface for a common MIOS core, since the transfers are so slow that it would stall the whole system (thats also the case if you would use the internal peripheral). MIOS wouldn't be realtime capable anymore - in timing critical applications like MBSID or MBSEQ the IIC slave couldn't be used...

So, I would prefer Duggles Idea to use "Gadgets" (PIC16F cores with dedicated firmwares). Of course, you could also use a dedicated PIC18F core -- which doesn't run under MIOS, but with a special IIC slave driver system.

A more performant way to connect several PIC18F cores is a parallel interface. I've implemented something like this some months ago, but it isn't finished yet - it's in experimental state, currently words can be transfered in both directions via the LCD port. I haven't found the time (and motivation) to continue with this concept yet, since there are so much other interesting things ;-) But I could send you the application if you want.

Best Regards, Thorsten.

[stryd_one]

Heya TK

Man, a parallel interface would be GREAT! I looked at that, but gave up on the idea as I wasn't sure how to mesh it with existing MIOS functions... Sounds like you already took care of that!

I'd love to check out the application for this... You can email it to me if you like, I'll PM you my address now.

Thanks again  :)

PS I like that "gadgets" idea too, it's got me to thinking.....  :)

[Synapsys]

Hi Thorsten,

I am a bit confused by your comment about the transmission speed. When you said "(thats also the case if you would use the internal peripheral)" were you referring to the MSSP? As I read the data sheet for the 18F452 it appears to indicate that using SPI mode and a fosc/4 SCLK rate the transmission speed is 10mHz with a 40 mHz oscillator. That means one byte would be transmitted in 1.25usec. And since the SPI uses an interrupt to indicate transmit / receive complete the processor is free to do other things during this time. I don't see how this is any different (other than a significantly higher speed) from using the uart for inter-processor communications. What am I missing here?  :-[

[TK.]

Hi,

you are right, I haven't taken into account that the serial interface can also run at higher clock speeds so long no "common" IIC peripherals (like the BankStick EEPROM) are connected to the serial bus. This shouldn't be a big problem, so long the SPI pins are not allocated at the master and slave side (this isn't the case for some MIOS applications).

I'm not sure if you are able to reach the same performance like with the parallel interface, but the wiring would be easier. My initial idea was to provide a high-speed solution for graphical LCDs:

http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1070211477;start=0#0

where MIOS has to transfer a high amount of data.

Best Regards, Thorsten.