This is a cover of several posts on the support of Ethernet.
I started leaning me on the subject.
I developed two maps:
- One with WiFi and Ethernet, ARM with 48k of RAM (dual release)
- Other than the Ethernet (version ethernet)
If it interested, I have a map of each unassembled.
I’m trying to validate the Hard Part Wifi and then Ethernet (RJ45 connector I expected).
But I have not found the same button (MODE, RESET), if the team can give me that would be cool
The hard level, here are the details:
The W5100 is connected to the same SPI as the CC3000
If there are people willing to try to bring the bookstore on the W5100 spark let me know
Sorry for my English, it is the google translation
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.
ok, it is noted, thank you
But I did not touch the source code.
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.
yes I understand, but I’m still installing the card (I miss the button and the RJ45 connector)
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.)
what would be nice is to have a git repository for an ethernet version ca be easier for the dev of W5100?
What do you think the team?
Sure - first one with content gets to create a development branch.
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
If you’re looking for help, I’m in too.
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
[Edit] I can’t read posts apparently
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.
I agree. I was planning on playing around with the ENC28J60 simply because I already had it.
I’ll look into the Olimex board.
[Edit] Good lord I’m cheap. That board is expensive Gonna have to pull a few extra hours
Believe me, it is pennies on the dollar if you have any respect at all for your time.
I have no doubt. Though I’m out of school I am unfortunately still in “Poor College/Graduate Student” mode
[Edit: Spelling things correctly is not something I am good at apparently]
‘unfortunately’ - you keep using that word, I do not think it means what you think it means [*]
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.