When you add a 3rd device to the SPI bus, the SPI arbiter code should be modified to allow the 3rd device access. See the code in spi_bus.c, and also where this is used by the CC3000 and the sFLASH api.
Without chaging the code, there is a chance that your W5100 and either the CC3000/sFLASH will attempt to access the SPI bus as the same time, causing the data on the bus to be corrupted.
My advice would be to work on the W5100-only version first, because you can remove the WiFi code and it’s RAM usage, as well as not worry about SPI-bus coexistence.
I see you have already found the other threads covering this topic and the 3 people that have expressed an interest working on such a beast (myself included.)
Any movement on this? I’d still like to see an easy path for an ethernet supported version, because one of the great things about the core isn’t just the wifi but the environment. I could switch to an RPi, but all I need is a Core/Photon with ethernet so I can cover environments where wifi is restricted, and then I could keep it all in the spark cloud.
Actually, I put my initial W5100 work on hold because the photon needs to implement a full TCP/IP stack, and hence could sit atop a STM32F207 instead of the STM32F205 used in the photon. The '207 has a built-in ethernet interface, and so would be cheaper, smaller and simpler than the W5100 design.
The firmware repository is not opened up to the public yet, and I am still learning my way around it myself so I have not had a chance to scope the effort involved in adpating the firmware to talk to the on-chip MAC instead of the broadcom wifi chipset.
Film at 11. Like you I think that a wired core (especially with POE) has a value proposition.
@niddin: Once I finish up a project of mine, hopefully at the end of march or early april, I plan on working on an ethernet version of the core (hence my forums topics asking about HAL and gcc compilations of the firmware). Perhaps we could collaborate?
@AndyW: I would love a POE version. Perhaps we could start w/ Mode B which provides power on the unused ethernet pairs and then look into Mode A
I quickly looked around for Ethernet MCU solutions as a non-wireless gateway for SparkLE/Bluz. Put it on hold due to other priorities, but agree with @AndyW that the STM32F207 is the way to go. Seemed like the best option I found.
I would be very interested in helping set this up, I really believe the more HW options that Spark gets to, the more powerful the overall platform. Let me know if you get started.
Interesting. An STM32F2 looks interesting. I’ll look into that. I was looking at the ENC28J60 module since they are super cheap and I already have a few
Well, if everyone interested can purchase the same hardware, that would be a good start.
I recommend (and already have) the Olimex '207 prototype board, I suggest this as the first test & development vehicle, and we can worry about spinning a more compliant footprint later.
Now the spark firmware developers are embracing the STM32F2xx series, and implementing a protocol stack, I see zero reason to work with lower integration components such as the ENC28J60 or W5100.
HW purchased, I should have the board early next week. I guess whoever has the chance first can set up a repository to work from, then the fun can begin!
I will see if I can find a way to clone the currently private repo and remove the Broadcom bits that are still under NDA, if it looks like the code release process with Broadcom is going to become a pacing factor.
Gonna have to pull a few extra hours