Two different SPI modes in one microcontroller

Question

I am interfacing two chips with SPI communication with atmega328. One chip uses SPI mode 0 and other one SPI mode 1. Is it advisable to toggle modes in micro each time interrupt request is received from any chip. What other options do i have. I tried doing bit bang SPI for one but the max clock i could achieve was 900kHz, while my min clock requirement is 1Mhz for both chips.

• Ignacio Vazquez-Abrams: Why not use an inverter?
• Maple: @IgnacioVazquez-Abrams Have you tried it? I need to mix mode 1 and 3 devices on the bus and had the same idea.

Answer 1

To try and answer all aspects of your question I quickly pulled up the relevant pages of the data-sheet. Unfortunately the Atmel download doesn't work right now, so I'm using the old one from my archive that only goes up to mega168(P)(A) devices, but they probably haven't removed any functionality. I'm even doubtful they changed anything other than the memory specs. So, I'm not going to link any pages, graphs or tables, because that would be confusing without a direct link to the one PDF I'm looking at.

One aspect of my answer is: Yes, you can switch between modes if you are not actively clocking to any of the connected devices, which means keeping their Chip-Selects unasserted is the easiest way of making sure. Then when you are in the one mode, make sure you don't accidentally assert the wrong chip, because you might be making choices on faulty data. If you have that secure you should be golden. You would be well of to switch over and have about 1.5 bus-clock cycle of waiting (interrupt based or otherwise), as the internals of the SPI device may possibly show some transient behaviour.

---

Edit1: Based on the post by Markt and commenting there, the turn-off, change, turn-on procedure may well be faster than waiting 1.5cycles of a 1MHz bus, as the core running at 10MHz+ will probably handle these instructions in less time than that. And even if that takes a tiny bit longer, it will be more reliable and easier to guarantee (wait 1.5 cycles isn't the most trivial thing right out of the box).

---

However, are you aware that the USART can also operate in Master SPI mode 0, 1, 2 and 3? In my data-sheet after the section about USART0 it shows a section specifically called "USART in SPI mode". If you are very worried about difficulties switching over, and possibly missed signals (I think missing signals is very doubtful if you plan your switches out well enough, but still) or just about total throughput with hosting both devices: Why not use the USART as another SPI port?

• Nirmala: yes my slaves are normally unasserted which makes things easier for me. I did not consider USART as SPI port,really a good catch there. I will test it once i get hands on my 2nd SPI slave. Thanks a lot for the pointer here.
• Asmyldof: No problem. I have been working so long with Atmel devices that I am always cautious to look if they haven't added any bonus features to comparable hardware. I feel they give quite a lot of "bang for buck" on the peripheral front. But even if it hadn't the switch-over should be relatively easy to implement as well, as long as you keep a "software eye" on your bus state.

Answer 2

Just change the mode when required while keeping both Chip Selects in the unasserted state.

Something to be conscious of is that it may be impossible to change the mode if the SPI module is enabled, or it may cause unstable behaviour if you try. For this reason I recommend disabling the SPI module before you change any settings (and then obviously enable it again before trying to use it).

• Nirmala: Wouldn't it be consuming 3 4 processing cycles, making some time critical processes unreliable. Both slaves will be sending/receiving data quite frequently
• markt: @user40602 It really depends on the CPU load and the amount of time you have. If you analyze how long your data transfers are taking, I wouldn't be surprised if you find the mode turnaround time is <1% of the data transfer time. If that's enough to destabilize your system then you should probably consider a faster MCU.
• Asmyldof: Not to mention that performing the full-shut-off, change and turn on can be performed at 8MHz or up to 20MHz core clock, so with about 7 to 11 CPU cycles of instruction handling that could fall within a single bus-clock of 1MHz, having a ten-thousandth of a percent effect on through-put.