Again I am for sure no expert in these devices. I have tried to fix a few bugs in some of these libraries and do have a board I did for myself to maybe monitor my well systems from a different building using some RFM95s...
Sorry in advance for my probably to verbose ramblings below.
However regardless if you are using one or two SPI buses, unless your code and the library code is setup to do SPI in an asynchronous way, than you are only going to be talking to at most one radio at a time.
And for example if you look at the radiolib library examples like the SX127X_Transmit.ino or even their transmit with interrupt example when you see code in the loop
When you see calls like:
Code:
void loop() {
Serial.print(F("[SX1278] Transmitting packet ... "));
// you can transmit C-string or Arduino string up to
// 256 characters long
// NOTE: transmit() is a blocking method!
// See example SX127x_Transmit_Interrupt for details
// on non-blocking transmission method.
int state = radio.transmit("Hello World!");
or even better more asynchronous calls like:
Code:
transmissionState = radio.startTransmit("Hello World!");
The library code will do all of the SPI transfers to the radio for the whole packet before it returns. Note: as far as I can tell it also uses the most common and as such the slowest way to transfer:
That is wait for each byte to transfer before starting the transfer of the next byte... Most of the code I believe revolves on calling:
Code:
void Module::SPItransfer(uint8_t cmd, uint8_t reg, uint8_t* dataOut, uint8_t* dataIn, uint8_t numBytes) {
So what is the difference between the radio.transmit("Hello World!"); and radio.startTransmit("Hello World!"); ?
The first one waits for the Radio to complete the actual transfer of the packet, which I am guessing may include waiting for an ACK from the other side. The second one does not, instead it tells the raido to change the interrupt IO pin when the transfer completes. Which depending on how code is setup, you can either poll that IO pin or have it interrupt you...
And again the read operation is similar... That is you can setup to have the Radio set the interrupt IO pin when it receives a packet or you can sit there waiting for a new packet. But then in either case the library code will then use SPI to retrieve the packet from the module and it will do this with the calls like: int state = radio.readData(str);
Which again I am pretty sure again will boil down to multiple calls to Module::SPItransfer
So are there good reasons to use multiple SPI buses with this library code? Maybe. For example some SPI hardware does not play well with others. For example they don't properly handle the MISO pin and always drive it High or Low even when they are not active. This can cause other devices to not be able to respond. You can fix these cases either by using different SPI buses and/or in some cases add in hardware like a tri state buffer between the offending device and the buss... Have done that with some TFT displays.
Likewise if you had the two radios on two different SPI buses, could you have code that has SPI transfers going on both buses at the same time... Yes. With a lot of work one could write the library code to allow you to setup the transfers to be done either using DMA or interrupts. For example we do have display driver code that transfers whole frames of data to a display without waiting. And I have setup where you can have multiple of these display on different SPI buses and have them updating at the same time.
Probably more important is maybe experiment some, to see if the simple more direct ways work for you. For example if it were me, a few tests I would run include things like:
a) start with one radio and the transmit_interrupt example and get an idea of how long does it take to setup to send a packet versus how long does it take to complete sending the packet.
What I mean is something like: (Note I edited out most their comments to keep things shorter here.
Code:
[COLOR="#FF0000"]elapsedMillis em_transfer;[/COLOR]
void loop() {
if(transmittedFlag) {
enableInterrupt = false;
transmittedFlag = false;
if (transmissionState == ERR_NONE) {
// packet was successfully sent
[COLOR="#FF0000"]Serial.printf(F("transmission finished! %u\n"), (uint32_t)em_transfer);[/COLOR]
} else {
Serial.print(F("failed, code "));
Serial.println(transmissionState);
}
// wait a second before transmitting again
delay(1000);
// send another one
Serial.print(F("[SX1278] Sending another packet ... "));
[COLOR="#FF0000"]em_transfer = 0;[/COLOR]
transmissionState = radio.startTransmit("Hello World!");
[COLOR="#FF0000"]Serial.printf("Startup time: %u\n", (uint32_t) em_transfer);[/COLOR]
enableInterrupt = true;
}
}
This should give you an idea of how much time is being spent in SPI versus time for sending the whole packet...
b) Could do similar for reads if need be.
c) I would try something like a) again but with two radio object, Probably start off with both on same SPI bus. Would probably get rid of delay... And instead keep a time to send next packet for each radio and send then.
Hope that makes sense.
Again sorry for the rambling.