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.
Two different SPI modes in one microcontroller
microcontrollerspi
Related Solutions
Most micros support a low-power 32.768 kHz watch crystal oscillator with some kind of prescaler and timer interrupt. Set the prescaler so the timer is counting slowly and the interrupt happens at the period you desire.
Some micros also have a built-in low-power RC timer if exact timing isn't critical.
The datasheet for any low-power micro will list the power with 32.768 oscillator (and nothing else) running. It's pretty close to zero. You can do the math to see if this is acceptable, and compare it to the current drawn by the watchdog.
OK, for example on the msp430f2013, let's look at power in the datasheet.
0.5 μA is almost zero, although it is five times the true OFF mode.
For more detail, we can look inside the datasheet.
Going from LPM4 (everything off) to LPM3 (running the oscillator) is the difference between 0.5 μA and 1 μA.
Suppose the battery is CR2032 with 225 mAh capacity. Then standby in LPM4 is about 50 years and in LPM3 is about 25 years. 25 years is long enough for many applications, because the ON-current (during the measurement itself) dominates the consumption.
I don't know what you mean by "UWB" (use standard or common abbreviations, no I'm not going to look it up, it's your job to explain), but many many micros have 10 bit A/Ds and SPI hardware. Even without the SPI hardware, SPI is simple to do in firmware by controlling the I/O lines directly.
In the Microchip line, there is a wide spectrum that meet these requirements. A low end PIC 16 can be small, cheap, and very low power. A fast dsPIC33 can run up to 40 MIPS but of course will use more power. There are various PIC 18 and PIC 24 in between.
What you need to explain is how fast you need to sample the 10 bit A/D and what the micro needs to do to these 10 bit values before passing them on via SPI.
This "answer" is more of a comment because too much important information is lacking. It can be turned into a answer if you cooperate and answer the specific questions asked, not what you feel like answering or or you think is important. As it stands, this question is too vague to be reasonably answered and should be closed. People will come by and close it as they encounter it. When 5 close votes are cast, it's over. The clock is ticking. You may have only minutes to a few hours. Do what I said exactly as I said quickly and you may get your answer. Ignore it and not cooperate and you'll be sent home without a cookie.
Added:
You have now added that the A/D sample rate is 500 kHz and that this raw A/D data is to be passed on via SPI. Since the A/D is 10 bits, this is apparently where you got the 5 Mb/s SPI data requirement from.
This is doable, but will require a reasonably high end micro. The limiting factor is the 10 bit A/D at 500 kHz sample rate. That's quite fast for a micro, so that limits the available options. Another thing to consider is that there is more to SPI than just sending the bits. Bytes may need to be transferred in chunks with chip select asserted and de-asserted per chunk. For example, how will this 10 bit data be packed into 8 bit bytes, or will it at all?
The main operating loop of the firmware will be quite simple. You probably set up the A/D to do automatic periodic conversions and interrupt every 2µs with a new value. Now you've got most of 2µs to send it out the SPI. If the device really can just accept a stream of bits, then it might be easier to do the SPI in firmware. Most SPI hardware wants to send 8 or 16 bits at a time. You'd have to buffer bits and send a 16 bit word 5 out of every 8 interrupts. It might be easier to just send 10 bits each interrupt in firmware.
Sending SPI bits in firmware if you only need to control clock and data out is pretty easy. Per bit, you have to:
- Write bit value to data line.
- Raise clock
- Lower clock
It would make sense to unroll this loop with preprocessor logic or something. A PIC 24H can run at up to 40 MIPS, so you have 80 instructions per interrupt. Obviously you can't use 8 instructions to send each bit. If you can do it in 6 it should work. There is some overhead to get into and out of each interrupt, so you might make the whole thing a polling loop waiting for the A/D, but then the processor can't do anything else. I'd probably try to cram this into the A/D interrupt routine using every possible trick so that at least a few forground cycles are left over for background tasks like knowing when to stop, etc.
Check out the Microchip PIC 24H line. I think most if not all have A/Ds that can do 500 kbit/s, and they can all run at least up to 40 MIPS. The new E series is even faster, but I'm not sure how real that is yet.
Best Answer
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?