Wired Ethernet using W5100 and the Spark

Hi All

There has been some discussions on a version of the Spark Core with wired Ethernet. Rather than take up that thread with technical stuff, I thought it might be useful to create a new thread where those people who are interested could discuss findings, and determine a way forward.

Assuming it was to go ahead, there were two basic choices for a device. They were the Microchip ENC28J60, and the WizNet W5100. The comment was made that the ENC28J60 would need a TCP stack to be loaded into the CPU of the Spark, and this would therefore necessitate an upgrade in CPU. The W5100 however has the TCP stack built in, much like the CC3000 WiFi device.

The W5100 would be connected to the CPU presumably via SPI. This would take some pins away from being used for I/O on the device. One of the tasks will be to determine what the best solution is here - should be accept the loss of pins, or should we route some other CPU pins to the external connections of the Spark Core.

Initial devel work could be done using the existing Spark module with an external SPI ethernet module. Once that is working, it should be possible to spin a PCB without the CC3000 and with a W5100, at least as a prototype.

As for doing the work, I am not sure that my ‘C’ skills are up to the hacking of these two components together, but I can try, at least as work permits. And I can also make it as easy as possible to get other people who have greater abilities to work on this project.

Darryl

Resources:

Arduino Ethernet Library Link

There is an existing library for the Arduino to interface to the W5100. This is a link to the GIT for this library.

WizNet Data Sheet Link

I have grabbed a copy of the datasheet for the W5100 from Octopart, and this should give an idea of the physical and logical interfaces for the device.

The similar W5300 datasheet is also available. The suggestion has been made to start working on the W5100 and then maybe move to the upgraded device later link

Spark Design Documents

All the design documents are in GitHub. The PDF directory is probably a good start, along with the BOM directory. Link

Devices
eBay has a good collection of boards for interfacing to the device. I ordered an SPI breakout board from there for about US$12 including postage. Arduino shields could also probably be interfaced to the Spark Core. Similar modules are available on AliExpress, but there does not appear to be any cost saving, at least for me in Australia as opposed to eBay.

Sparkfun W5100 Ethernet Shield with PoE Link

FreeTronics W5100 Ethernet SHield with PoE Link

Two different shields giving PoE. The FreeTronics device gives hints on design when you also want to use other SPI devices along with the W5100

2 Likes

OK. I have had a quick look at some code

There looks to be some structural changes needed. For instance, there are numerous cases of the assumption that any network interface will be wifi.

WiFi.status()

It may be that such functions should be abstracted to the type of network capability that is installed, something more like:

Network.status()

This would then overload [if that is the right word] to the type of physical connection that is in existence.

Another change that would be needed would be with regard to NVRAM, and the type of data stored there. If we make the assumption that only WiFi OR Ethernet will be operational, even if both are installed, there should not be too many issues. It may be that we need to check to make sure that the data stored is appropriate for the device.

I can see the NVRAM being used to store DHCP/IP/Mask/Gateway rather than SSID and the like.

Looking through the code, it appears that the software interfaces within the Arduino W5100 library are fairly close to the interfaces in the Spark CC3000.

Now onto some specific files.

core-firmware/src/wifi-credentials-reader.cpp

Code to read the WiFi credentials off the Serial Port. This would be needed to determine the MAC address of the device, and also change static IP and port speed (10/100) if required

core-firmware/src/wiring-wifi.cpp

Definition of the interface status for turning wifi Off, and also determining if the Wifi is connected or connecting.

core-firmware/src/spark-wlan.cpp

Main interface to the WiFi

core-firmware/src/spark_wiring_network.cpp

Has interfaces for SSID and RSSI. Probably need to add an interface here for DHCP or Static IP mode.

More work will be required but the work required to interface to the W5100 does not look majorly difficult

Darryl

P.S. Just a clarification with regards to W5100 units on eBay. I was thinking basically a W5100 shield, or break out board, and connecting this to the SPI pins of the Spark. That way the Spark becomes the main development environment.

@vk2tds, I was lookink at this breakout on eBay:

Note that there is already some work being done on “rationalizing” the WiFi/Network classes. I’ll have to refresh myself on where that’s at. :smile:

That is the one I have ordered too…

Thank you @vk2tds for starting this thread to dive into the technical details.

For my development setup, I’m going with a Core, disassembling the CC3000 off of it and adding in some wires to a W5100 module. I need to dig out my modules to confirm which one. So, it will be using the same SPI and INT from the STM to the W5100, I think and thus no loss in Spark I/O lines.

You are on the right approach for looking through the firmware. I was wondering if there were any block diagrams or similar pictorial documents illustrating the firmware sections and structure. Not flow diagrams, but some high-level stuff to get oriented with as for what is bare metal firmware (and would need JTAG) and what is the boot loader and what can be in the part that is flashed by the boot loader.

Then, with each section defined we can breakdown what needs to evolve in each section. Starting, obviously, closes to the metal and working our way out. My thoughts on the approach, but certainly welcome to be lead by those more experienced.

Hi Swieter… I had forgotten about the ‘internal’ SPI, which is of course the way to go. But in my mind, I thought that during the early stages was to use the external SPI to interface to the Ethernet. You could then, i imagine, boot on factory default WiFi, upload new Ethernet only firmware and test it. Then you could factory reset the module with a 10 second mode press reset.

I am not sure if anyone has noticed, but I have been updating my first post here with new links as needed. I will add a link to the GitHub repository for the hardware reference for the Spark Module in a moment.

But you touched on an important point that I had missed, which are the interfaces to the CC3000. Ground and 3.3V are obvious. Then there are:

  • SPI Clock - STM32 Pin 29
  • SPI MISO - STM32 Pin 27
  • SPI MOSI - STM32 Pin 28
  • WiFi CS - STM32 - Pin 25
  • WiFi Int - STM32 - Pin 22
  • WiFi EN - STM32 - Pin 45

From the circuit, SPI_DOUT from the WiFi goes to in of a 3 state non-inverting buffer (U4, ON Semiconductor NL17SZ125XV5T2G), which is also gated by WiFi_CS, which presumably gates the signal when the device does not want to relinquish control.

Hope this helps

Darryl

1 Like

The buffer is just there because the CC3000 does not tristate MISO when it is not selected, so it does not play nicely with the other children on the SPI bus (the flash part in the :spark:) I believe we can leave it in-situ and wire the W5100 to the pads vacated by the CC3000.

Doing background reading on the W5100, it appears that long wires for the SPI connections are a problem, so we should all work to keep those as short as reasonably possible; although at present the SPI bus doesn’t go very fast when talking to the CC3000, but it would be good to max that out when we get a chance (the speed settings on the STM32 are very coarse, sadly.)

2 Likes

I just got my eBay W5100 today, and went looking for documentation on it. I found a schematic diagram of the board and also interfacing instructions for the Arduino Due link

Importantly, this board does not bring the interrupt output out to a header. Interrupt is available on Pin 56 of the chip, and should be available with some very careful soldering. Having said that, it would appear that the existing Arduino Ethernet drivers do not support Interrupt anyway.

I think my first port of call might be to see if I can get the Ethernet driver running simultaneously with the WiFi one, using the external SPI port. If I can get that working, it might be a bit easier to move to using the internal port without the WiFi module. This is all subject to RAM of course.

If I can get the standard Arduino driver working without Interrupt, we can then start looking at more detail at getting the firmware upgraded with an Interrupt handler.

Darryl

Hello there

I’m doing an ethernet version, I therefore created a unique topic about the Ethernet Version
topic ethernet

++

1 Like