0
\$\begingroup\$

I have two microcontrollers that are both pretty maxed out on their capabilities. MC1 needs to make a 14bit measurement result available for MC2. MC1 can communicate with SPI, and MC2 can communicate with I2c, but they are operating asynchronously.

Is there some sort of simple IC available out there such that MC1 can save a value to the IC using SPI, and then MC2 can read that value using I2c, at each other's leisure?

\$\endgroup\$
6
  • 3
    \$\begingroup\$ Dual ported RAM is often seen as a solution for low level exchange, if the exchange rate is not very often, dual ported i2c FRAM (EEPROM) might even give your interface \$\endgroup\$
    – crasic
    Jul 14 at 23:02
  • 2
    \$\begingroup\$ See CAT24C208 from ON as an example of dual ported i2c serial eeprom, would something like that work? If yes I can write as an answer \$\endgroup\$
    – crasic
    Jul 14 at 23:05
  • 1
    \$\begingroup\$ Dual port can also be done with another MCU as @MarcusMüller suggests in their answer, see for example this development board: ti.com/tool/TIDA-00230 \$\endgroup\$
    – crasic
    Jul 14 at 23:20
  • 2
    \$\begingroup\$ Seems like doing it the hard way. What resources are remaining on each. and what bit-rate do you need? \$\endgroup\$
    – Jasen
    Jul 15 at 0:27
  • \$\begingroup\$ Well, there are ultra cheap MCUs that can do the bridge/buffering. The smallest MSP430 comes to mind since there's an application note exactly for that but probably a TinyAVR or some M0 could do the job. \$\endgroup\$ Jul 15 at 7:27
9
\$\begingroup\$

I'd concur with @Voltage Spike, probably, upgrading either MCU is the easiest solution.

However, if it's really just about marshalling data in and out, well, that would be a job for another MCU. I can understand you'd be hesitant to bring even more software onto a board. But honestly, setting up the SPI peripheral on that third MCU to DMA into a large buffer, and an I²C handler to give the latest data on demand to MC2 would certainly sound easiest.

Note that I think this actually makes the case for letting the third MCU take over MC1's job: if the data volume is low enough so that it can be queried via I²C, then it wouldn't be pushing a somewhat modern Cortex-M0+ to interface with whatever ADC you have, or take over significant part of the calculation of that 14 bit value.

\$\endgroup\$
6
\$\begingroup\$

It would be a lot easier to find an MCU in a different package with better capabilities and upgrade an existing MCU than to add something in between.

Another thing you may want to consider is looking into hardware SPI or I2C peripherals if you are not currently using them (almost every modern MCU has something like this). A hardware SPI receives information, then stores it in memory without polling the SPI, and then toggles an interrupt so you can retrieve the information. Same goes for hardware I2C.

If that doesn't suit your needs I suppose an FPGA (like in lattice part) could be used for the interface you describe, but much more difficult and time consuming to implement.

\$\endgroup\$
5
\$\begingroup\$

There are I2C/SPI bridges with built in buffers such as the SC18IS602B that might suit the purpose.

\$\endgroup\$
2
\$\begingroup\$

Can you implement an I2C master in software on MC1? You’d only need 2 GPIOs. Of course it would take up some time but if your transmission is short and rare enough it might be feasible.

Since I2C is synchronous and you are implementing the master side you don’t have tight timing requirements. You could continue with your main program loop after setting each bit. In this case the runtime requirements would be minimal, just a single store instruction for each bit and a branch instruction. Alternatively you could set a timer interrupt to trigger at e.g. a 100kHz frequency and transmit each bit in the interrupt. In this case you’d have more overhead because you have to enter and exit the interrupt.

If you implement it in software on MC2 as well (e.g. with a GPIO interrupt for the clock line input) it doesn’t even have to be I2C with its overhead for start condition, address and so on. You could just transmit the 14 bit serially, synchronously. If you have more than 2 GPIOs available you could even transmit multiple bits in parallel.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.