Remap Argon Ethernet Pin

Hardware
1

Hi

We are going to add SPI compatible device into Argon+Ethernet feather
But it looks like we cannot use both of SPI and SPI1 for our additional component.
I notice the SP1 is currently used for Argon Ethernet solution which is also something we need.

(SPI is used for main SPI for Wiz5500, SPI1 pins(D3, D4) are used for select pin and reset pin for Wiz5500)

Can we remap the pin assignments to align with our hardware design?

Thansk

2

It is not currently possible to have Device OS use different control pins for Ethernet. The pin numbers are hard-coded at this time.

3

If so, can we share SPI for both Ethernet and other SPI compatible component?

So, Ethernet connection will be used for cloud connection.

Thanks

4

Yes it is possible by toggling the CS pin for each device to make only one active at a time.

5

@chargeMan, @tommy_boy, because the DeviceOS operates asynchronously to the user thread, you can’t depend on the SPI bus being free. You would need to use SINGLE_THREAD_BLOCK() or ATOMIC_BLOCK() around the use SPI code to be sure.

1 Like
6

Thank you for your suggestion.

I tested various cases using SPI compatible LoRa module.

So, If I used this code as you suggested.

SYSTEM_THREAD(ENABLED); // I am using system thread mode for several reasons in my user application
SYSTEM_MODE(SEMI_AUTOMATIC);
STARTUP(pinMode(A4, OUTPUT));
STARTUP(digitalWrite(A4, HIGH));
STARTUP(System.enableFeature(FEATURE_ETHERNET_DETECTION));

void setup()
{
// Connect to cloud service in semi_automatic system mode
	Particle.connect();
	Ethernet.on();
	Ethernet.connect();
... ...
    const uint8_t loraNSS = A4;
    const uint8_t loraRST = A3;
    const uint8_t loraINT = A5;

    // Init LoRa module 
    SINGLE_THREADED_BLOCK()
    {
        LoRa.setPins(loraNSS, loraRST, loraINT);// set CS, reset, IRQ pin
        if (!LoRa.begin(470E6)) 
        { // initialize ratio at 470 MHz
            Serial.println("LoRa init failed. Check your connections.");
        }
        else
        {
            Serial.println("LoRa init succeeded.");
            LoRa.onReceive(onReceive);
            LoRa.receive();
        }
    }

....
}

By executing this code, in serial console. I was able to see this line

“LoRa init succeeded”

But Argon module enters into setup mode (blinking dark blue), it looks like there is no Ethernet credentials.

Of course, I have flashed firmware via Ethernet just before. I think Device os is not detecting Wiz5500 chip in current situation.

If I connect CS pin of LoRa module and VCC(to disable CS), Ethernet is working accurately.

Can you let me know what I am wrong?

Thanks

7

One note about that

The docs suggest a different approach
https://docs.particle.io/reference/device-os/firmware/photon/#startup-

1 Like
8

I am having same issue yet.

I am not sure what is issue yet.

can you help me once again?

9

In my prototype, Argon is plugged onto Ethernet feather and also LoRa device is connected Argon via SPI.

As you know, reason of startup code is to set CS pin for LoRa module when startup so that Ethernet chip could be detected by device os.

However, strange is that if I connect LoRa module with this code, Argon is not connecting to cloud.(blinking green )

If I remove LoRa module it is cloud part is working well.

And also when I connect LoRa, LoRa initialize also is failing

Can you give me accurate solution to use both on the same SPI together?

10

@chargeMan, upon reflection I now believe that what is needed is a MUTEX and resource locking mechanism for the SPI port. Locking out the system threads will not guarantee at anytime that an existing SPI transaction has not been started. A MUTEX would allow both system and user threads to wait on the SPI resource. Problem is, if you do bulk transfers or use DMA, that creates a complex requirement. Ideally, device requests are queued and handled by a separate thread. This is way too mush of a hassle to implement IMO.

Problem is, the Ethernet Featherwing is hardwired so changing pins is not really feasible and spinning up a new board to change the CS and RST pins is likely not a bit priority for Particle. You may need to rethink your approach.

1 Like
11

You can now reconfigure the control pins (CS, interrupt, and reset) in Device OS 5.3.0 and later. See Ethernet pin configuration. Ethernet must still use primary SPI, but by moving the control signals to other pins it would allow you to use SPI1 for other peripherals at the same time.