Hey folks, any view on when DeviceOS will be able to configure alternative pins for the following:
Device OS is hardcoded to use D3, D4, and D5.
This would be an excellent option to have, given the legacy designs we have utilizing D3-D5. We’d love to provide an Ethernet option, but currently can’t.
@mblackler There is a G3CC meeting coming up on the 24 October - it is a good question, I will make a note to raise it with Particle. From memory of the various discussions about this subject on community threads I thought the bigger issue was to do with not being able to use any other SPI devices. When you talk about legacy designs - do have hardcoded pin assignments or are you simply talking about running out of digital pins?
@armor - take a look at this issue
Its a lot more than just SPI1 (since deiceOS does not allow SPI to be shared once Ethernet wing is in use
…and removes the second I2C from play as well as the CTS/RTS pins of Serial1. If these pins were moved to a general IO such as D6/D8 (yes and some will cry foul, but you get back an extra SPI bus and the RTS/CTS function as well as the second I2C - which if not used can be used as IO instead) , you now at least have SPI1 for your SD if the SPI0 bus is to be reserved for ETH only and the device suddenly becomes MUCH more useful. To have 2 such subsystems disabled by what appears to be an arbitrary pin assignment is really a waste.
The concurrent SPI issue should be fixed in 1.5.0-rc.1. You need to make sure the other devices on the bus use SPI.beginTransaction() and SPI.endTransaction(), but then you can include other SPI peripherals on the main SPI bus along with Ethernet.
@shanevanj Thanks for the explanation - I had in my mind only SPI use was restricted but you are right about the blocking that using those pins causes. Making the 3 pins re-assignable or at least shifting them as you suggest to a less overloaded range would be a big help all round. Clearly the Ethernet support in Device OS would have to change aligned with an Ethernet Featherwing V2? @rickkas7 Is there a plan alongside of 1.5.0 to consider a new Ethernet Featherwing PCB changes?
This is a great step but the fixed assignment still disables 3 very useful peripherals i.e. RTS/CTS, SPI1 and I2C1
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.