Problem Adding two extra Ethernet ports to Pi

1 Like

There’s an awful lot of levels where problems could be occurring - wiring, communication protocols, data encoding, kernel driver implementation, SPI implementations, and these can all be doubled up because both the Pi and the Ethernet Chip will need to work in compatible ways, so you’ll need to check each of them. More than 2 ethernet ports on a Pi is quite an unusual requirement so it’ll be difficult to find examples from people who’ve tried to do this in the past.

This is venturing well into the territory of professional engineering - it’s pretty complex stuff. Are you specifically trying to develop a Pi Hat with multiple Ethernet ports? And if you are, why? What’s the use case? A Pi as a networking device/teaching tool?

Why not just use a USB-> Ethernet adapter? Or a cheap Ethernet switch - you can get a second hand 24 port switch for under $100.

This is only one specific solution to whatever your actual problem is, and there are easier ways to do it. What’s your real goal?

As for trying to get this working specifically, have you checked the datasheet for the WiZ820io, and the datasheet for whatever ethernet interface it’s using? Particularly, have you checked whether the Ethernet inteface will be happy to share the SPI bus with other devices?

https://www.wiznet.io/product-item/wiz820io/

Have you been over the Pi documentation too?

https://elinux.org/RPi_SPI

2 Likes

My specific application requires a Pi platform which has an Ethernet port to interface to a network and two extra Ethernet ports of lower speed which are low cost and can be split out in a configuration that is unique, I will also need to make many of these and it needs to be a solution which I can build not buy. So NO I cannot consider using a switch that is way too expensive and bulky etc, needs to be a simple low cost purpose manufacturable part. There are ultimately innovations in this and so I cannot use an off the shelf solution because it will not provide me with the flexibility that I require. The ultimate reason for the two extra ports is a redundant bus, and so there MUST be two separate ports. When I read the information in the link I provided how someone so easily got a single port working I expected that this would be similarly simple to add a second extra port since the descriptions clearly provide for a second SPI device in the pin descriptions, further the SPI buss in INTENDED to provide for for multiple slave devices - that aught to be NORMAL. I have not researched the Pi software etc as I do not know much about this, I should expect it to work in a logical manner. I have put this on the forum because I know there are skilled people who know these details which I do not - that is the purpose of the forum surly. I am asking for help because this is exactly the purpose and type of problem which the forum exists to help. I have no idea how to dig into the Pi software operating . driver issues but it aught to match the logical pinout of the hardware connector and provides the functionality which is self evident from the circuitry.
This should simply work - I have no idea how to find why the configuration instructions do not seem to be behaving properly or how I might adjust them. So can someone please help me.

1 Like

Please - lets start with this:
What is the proper command / text to put into the configuration file to get the Pi to find the slave device on the SPIo bus as device 1 instead of device 0?

I used this command:
Append these two lines to the /boot/config.txt file:
dtoverlay=anyspi,spi0-0,dev=“W5500”,speed=30000000
dtoverlay=W5500

When I have one W5500 plugged into the board with its chip select SCNn pin p1.5 connected to the Pi CE0 pin p24,
This works fine both as adding eth1 as seen in the ifconfig command and able to ping the device.

If I now want to use Pi CS1 pin p26 instead of CS0 pin p24, what text must I use in the config file? I expected to use the following:
Append these two lines to the /boot/config.txt file:
dtoverlay=anyspi,spi0-1,dev=“W5500”,speed=30000000
dtoverlay=W5500

It does not work - only one little wire change!

Why not?
What should it be?
I have no idea how to find out?
Please advise

1 Like

I have just repeated this experiment again:

image

A)
Put W5500 in slot 2, connected CE0 to SCNn
Append these two lines to the /boot/config.txt file:
dtoverlay=anyspi,spi0-0,dev=“W5500”,speed=30000000
dtoverlay=W5500

ifconfig finds eth1 AND can ping device IP:192.168.1.205

B)
Put W5500 in slot 2, connected CE0 to SCNn
Append these two lines to the /boot/config.txt file:
dtoverlay=anyspi,spi0-1,dev=“W5500”,speed=30000000
dtoverlay=W5500

shutdown, remove power, reapply power
ifconfig finds eth1 AND can ping device IP:192.168.1.205

C)
Put W5500 in slot 2, connected CE0 to SCNn
Append these two lines to the /boot/config.txt file:
dtoverlay=anyspi,spi1-0,dev=“W5500”,speed=30000000
dtoverlay=W5500

shutdown, remove power, reapply power
ifconfig finds eth1 AND can ping device IP:192.168.1.205

D)
Put W5500 in slot 2, connected CE0 to SCNn
Append these two lines to the /boot/config.txt file:
dtoverlay=anyspi,spi1-1,dev=“W5500”,speed=30000000
dtoverlay=W5500

shutdown, remove power, reapply power
ifconfig finds eth1 AND can ping device IP:192.168.1.205

Change circuit configuration to connect CE1 pin26 to SCNn

image

E)
Put W5500 in slot 2, connected CE1 to SCNn
Append these two lines to the /boot/config.txt file:
dtoverlay=anyspi,spi1-1,dev=“W5500”,speed=30000000
dtoverlay=W5500

shutdown, remove power, reapply power
ifconfig does NOT find eth1 AND CANNOT ping device IP:192.168.1.205

F)
Put W5500 in slot 2, connected CE1 to SCNn
Append these two lines to the /boot/config.txt file:
dtoverlay=anyspi,spi1-0,dev=“W5500”,speed=30000000
dtoverlay=W5500

shutdown, remove power, reapply power
ifconfig does NOT find eth1 AND CANNOT ping device IP:192.168.1.205

G)
Put W5500 in slot 2, connected CE1 to SCNn
Append these two lines to the /boot/config.txt file:
dtoverlay=anyspi,spi0-1,dev=“W5500”,speed=30000000
dtoverlay=W5500

shutdown, remove power, reapply power
ifconfig does NOT find eth1 AND CANNOT ping device IP:192.168.1.205

H)
Put W5500 in slot 2, connected CE1 to SCNn
Append these two lines to the /boot/config.txt file:
dtoverlay=anyspi,spi0-0,dev=“W5500”,speed=30000000
dtoverlay=W5500

shutdown, remove power, reapply power
ifconfig does NOT find eth1 AND CANNOT ping device IP:192.168.1.205

SO:
There are no wiring problems here;
What is the correct way to configure the Pi to talk to SPI0:1 slave device instead of SPI0:0 slave device?

There is defiantly a problem here and I need to know what the solution is.

Regards

1 Like

You’re running headlong into a minefield because you’ve got a fundamental misunderstanding/lack of knowledge of the hardware. SPI does not necessarily work the way you believe it does or the way you believe it ought to, nor do the Linux drivers . Exactly how it works can very much be implementation specific - and I am yet to see anything that describes connecting multiple of these chips explicitly.

I’m not saying this is a technically impossible solution - I’m saying it’s infeasible. This in and of itself is a significant engineering challenge - a commercial budget for this would reasonably be around $30k. The Core guys are great, but I’m pretty sure they’re not engineers - it’s not reasonable to expect to buy a $100 Raspberry Pi and get $30k of engineering support with it for free out of them, I’m fairly certain you’re just unaware of how complex and difficult what you’re trying to do is. Getting this working IS going to require getting out an oscilloscope/logic analyzer and checking what’s actually happening in the circuit, and possibly modifying the network and SPI drivers in the Linux kernel. I’ve provided you direct links to the documentation you need to start reading if you want to continue down this path.

The only ones who might have answers for you without needing to completely engineer you a custom solution are engineers/devs who’ve worked with the Wiz ethernet chip (eg. sparkfun and Adafruit make PCBs with this chip), and/or Raspberry Pi devs - because they’re already familiar with these specific bits of hardware and won’t need to learn them. Other than that, I’d strongly recommend contacting an electronics product design and engineering consultancy who specialise in taking ideas and inventions and turning them into marketable products - that way you can sign a contract to protect your IP.

Also, two ethernet connections on the same Pi does not make a redundant system, so I’m not sure what this solution actually achieves or what kind of redundancy you hope/need to gain. About all it does is double the probability you’ll have a communications failure on at least one of your ethernet interfaces.

Whatever you’re trying to do, there are much better ways to do it. If you want advice and help, my advice is that you are way off track. You need to go back about 5 or 10 steps and reconsider how and why you ended up here, rather than plowing on with trying to solve your problem with this specific solution. You need to share some higher level information about your project and overall goals so you can get help from the community that will get you back on track with whatever it is you’re trying to do.

I’m no electronics engineer though, this is just a hobby for me and I like helping out.

@Robert93820 Bob; what’s your 2c on this? I’m betting you know a thing or two about SPI and Ethernet.

Edit: Oh and PS - here’s the datasheet for the BCM2835 - https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

Looks like you’ll want to read Chapter 10.

And here’s the SPI driver in Pi OS: linux/spi-bcm2835.c at 7fb9d006d3ff3baf2e205e0c85c4e4fd0a64fcd0 · raspberrypi/linux · GitHub

2 Likes

Actually, here’s someone who did it commercially:

And they used the separate SPI interfaces. I’d say there’s a very good reason they didn’t chip select them!

1 Like

Hi Oliver

Sorry, mostly nothing. I am really basically an analog person. Fiddle with digital enough to get by. I have worked with logic a bit on different projects but one of the closest to getting serious was the display systems for the computer tote on the 4 Sydney racecourses. Have programmed Mitsubishi PLCs using Ladder Logic system and Mitsubishi Alpha series intelligent relay units where you actually produce a logic circuit using function blocks analog and digital inputs. To do this all you need to do is know what is required at the end of the day, what information in the way of inputs you need and then the best way of getting the required result.
To do this successfully you have to think in a logical manner but when it comes to digital communications like ethernet, SPI and the dozen or so others the engineers tell me this is what it has to do and how it does it and I believe them.
Believe it or not most of the problems I have come across and had to resolve were solved with what you might call an analog approach. One which comes to mind and crops up here on the Forum was on the last big project I looked after for AWA some 20 odd years ago. The digital comms system for diagnostics (I think) they called AUI (Asynchronous Universal Interface). Engineer sitting in front of a rack full of equipment with about 2m cable seemed to be quite happy. As per procedure the system checked with approximate real world conditions (75m cable) and guess what. Did not work. The problem turned out to be analog. The cable termination was effectively about 3kΩ instead of 120Ω. The reflections were adding and subtracting as they do (standing waves) and what was termed “collision detect” was doing its job and shutting the whole thing down. When the forward and reflected signals added the system was fooled into thinking there was more than one slave on line at the same time and shut down.
This is one of the reasons I have pushed this subject on a couple of posts on this forum. I may not know much of the nitty gritty details re how these systems work but I do know how to get it from point A to point B with minimal problems.
As far as doubling up is concerned I don’t know but probably not a good idea. This AUI system was duplicated but the change over was relays which physically switched from one system to the other. This had an impedance matching problem too which I won’t go into here. This whole project was duplicated right down to the 240V mains supply. In fact the Radio system was triplicated, primary, secondary and tertiary.
Cheers Bob

3 Likes

Hi Clem, thanks for making a post!

Here’s the link to the readme for config.txt:

There’s actually a dt-overlay for the W5500:

Name:   w5500
Info:   Overlay for the Wiznet W5500 Ethernet Controller on SPI0
Load:   dtoverlay=w5500,<param>=<val>
Params: int_pin                 GPIO used for INT (default 25)

    speed                   SPI bus speed (default 30000000)

    cs                      SPI bus Chip Select (default 0)

I’ve never looked this deeply into this before but on a first read it looks like you might be able to get it to work by connecting the interrupt pin for your first device to pin 25, and the interrupt for the second to pin 24, and:

dtoverlay=w5500,cs=0
dtoverlay=w5500,cs=1,int_pin=24

SPI will be enabled automatically when this device is called according to the readme, so hopefully this is all it takes! @Oliver33 is right that it may not work the way we expect and it could be quite difficult if it doesn’t go to plan.

2 Likes

I have just got a high level interrupt so will be away for a few days - but that does not mean that I am giving up. I KNOW how SPI bus is designed and supposed to work - if Oliver33 thinks that the Pi does not make it possible to implement SPI bus as it was designed - he may be right but that does not mean that that is not how SPI bus is intended to work and any fool can expect to logically proceed on the basis of how SPI is designed to operate!
I want to know why you choose pin 24 as an interrupt pin? The Pi pin out defines pin 24 and pin 26 as SPI0 CS0 and SPI0 CS1 respectfully.
Where do you get this information from how to configure the setup files on the Pi and the information for the parameters for dtoverlay?

regards

Looks like right here where he linked you to ^

Looking at pinout.xyz, he might’ve been referring to GPIO 24, not physical pin 24.

And re SPI not being implemented as designed, it wouldn’t be a first. I know that I2C on the Pi is buggy (I think it’s actually an issue with the Broadcom chip) and does not support clock stretching - which is a completely standard part of I2C.

Here’s an Adafruit article about some of the quirks of SPI on the Pi:

Raspberry Pis are first and foremost, teaching devices, not industrial devices and they’re a merging of different computing worlds that don’t normally come together. As a result, they’ve taken some shortcuts in some places for high level ease of use - so they work most of the time easily, but when you get down to the nitty gritty or edge cases they’re weird, unusual, and quirky.

Regarding the redundancy - consider the case of a critical server/datacentre. They use multiple methods for reliability. Hard Drive RAID, Offsite backups, and a completely independent second data centre, then there’s triplicated systems where they use a plausibility analysis.

RAID combats MTBF but it does nothing for environmental situations like a fire, power surge, or power outage. In order to prepare against environmental risk factors you need fully independent systems - off site backups. If you need the system to keep working in the case of a failure, you need to completely duplicate the system. If you’re worried about signal interference you can consider a watchdog timer and/or a plausibility circuit. There’s also things like CRCs used in credit cards.

It’s all reliability engineering, and its complex - but I guarantee you there is a better solution than 2 ethernet ports and cables on a single Pi. Have a read:

A little bit of knowledge is a dangerous thing - especially when coupled with overconfidence and arrogance. Knowing how it’s supposed to work is only half the battle. Someone had to implement it, and they rarely get it completely right - or maybe how it’s supposed to work has changed since the hardware you’re using was manufactured, or maybe there are parts of the standard that aren’t well defined so different manufacturers do different things. 90% of the time, these aren’t problems. Edge cases like yours are where it bites - especially when you’re not just trying to communicate via SPI, you’re trying to do networking as well!

1 Like

Ah ok, nonetheless, you’re quite a fountain of knowledge and have a lot of experience! I’ve learnt a lot from your posts - especially about cable terminations and signal reflections. It’s amazing how regularly it crops up!

When I was looking into it in the past I found this great video from Tektronix:

1 Like

Hi Clem,

Here’s the link to the Readme for setting up config.txt: linux/README at rpi-5.10.y · raspberrypi/linux · GitHub

Info on how to format the config.txt file is all at the top, while the specific info on the W5500 dtoverlay starts on line 3277. I picked GPIO 24 (physical pin 18) because it’s a nearby free pin. Note that there are different numbering conventions for the Pins on a Pi header - the chip selects are on physical pins 24 and 26, but these are GPIO pins 8 and 7, respectively.

Let us know how you go!

1 Like

Hi Oliver.
AHHH, those old Tektronix oscilloscopes, about the size of 2medium suitcases with a very long 5" CRT. I have used many of these including the one pictured with an unbelievably fast time base. Beautifully built equipment (which was reflected in the price). All termination points and even the solder had a percentage of silver in the alloys. The instruments even had a coil of this special solder rolled up inside the top of the case for repair work. I had a mains transformer fail (green/brown smoke) and would you believe this type of component was guaranteed for the life of the instrument and we had one delivered free in 48 hours. Quality and service we don’t see very often now.

That video should be a compulsory view for anyone involved or are going to be involved with transmission of intelligence from point A to anywhere. It would be good if you can put it up separately so it is not confined to readers of this post. That is exactly what I was on about some time ago and I mentioned above. A very important point often overlooked or completely ignored.

That measurement technique is termed Time Domain Reflectometry. During my 22.5 years with AWA I got involved with Television transmitting antennas, Yes the ones on 500 to 700 ft towers (TCN9 is 785ft)
and this method was used to measure the return loss of the plumbing at the end of the cable. That video shows a return loss of about 6db open circuit which means that length of cable has about 3db loss at the frequencies involved. The TV cable is 3.25 or 4.5 inch diameter and cable losses are very low. We were able to accurately measure return losses of the antenna at something like 40db or a VSWR of about 1.02:1 or reflection co-efficient of about 1% whichever measurement type turns you on. Not bad for an antenna which had 96 full wave or 192 half wave elements as the transmitting medium at the top of that tower. You would have to see it to believe the plumbing and cabling involved.

Silicone Chip some time ago did an article on oscilloscope leads. Especially the higher frequency ones. This is a good read if you can find it. If you have ever measured these leads in the X 1 position you will find the centre conductor is a resistance wire of quite a few ohms. The article goes into the reason behind this and acknowledges the skills and patience of the design engineer at the time who did not have the luxury of computers and transmission line modelling. All done on paper.
Cheers Bob

2 Likes

Another couple of references regarding redundancy, checkout these videos:

1 Like

That’s quite impressive it could pick it up! That’s a tiny amount of reflection!

I’ll have to see if I can track down that article on probes, sounds like an interesting read :slight_smile: It always amazes me what could be accomplished with slide rules and brain power.

Edit: Here are the two articles I found, one from '89 and one from 2009. I’ll have to get a subscription so I can have a read :slight_smile:
https://www.siliconchip.com.au/Issue/2009/October/The+Secret+World+Of+Oscilloscope+Probes
https://www.siliconchip.com.au/Issue/1989/June/Understanding+Oscilloscope+Probes

1 Like

I think the spec from memory was about 36db. With the long cable anything much worse was re-transmitted as a ghost about 10mm after the main image. The measuring set up was a bit more sophisticated than the simple set up in the video although the CRO image was similar with the echo being right down in the noise. There was some R & S pretty fancy test equipment involved. I won’t go into the measurement technique here as it is a bit lengthy but I you are interested send me an Email I can reply to and I will do my best to describe.

When I was getting the printed version I used to tear out interesting articles so there is a possibility I have it somewhere. Will have a look later.
Cheers Bob

2 Likes

Hi Oliver33

Found the one from 2009. Knew I wouldn’t have thrown it away (bower bird me)
Scanned it for you as PDF, 8 pages at 600DPI to make sure of resolution so file size quite large.
This is getting away from the initial thread subject but is the only way I can get it back to you.
Feel free to add it to your U-Tube video if you want. It is a pretty good instructional read.
File is too big

This is a dropbox link, see how that goes.
I have removed the dropbox link as I am concerned that putting this up on a public forum may infringe some copy write laws or something and I could stir up a heap of trouble.
Cheers Bob

2 Likes

That’s awesome, thanks Bob! I managed to find a way to download it anyway. I’ll send you a direct message about the Rhode & Schwarz(?) test setup you used :slight_smile:

1 Like

Hi Oliver
Yes R & S is short for Rhode and Schwarz. They make some test gear that the average hobbyist can only dream about.
The particular instrument we used was known as an Impulse Reflectometer and designated ZUP-1 (I think, a long time ago). I can’t remember if there was an external reflectometer used or not. There must have been some sort of device to rectify the RF for display purposes or it may have been looked after in the instrument. I forget now.

The instrument was a big noise generator with a reasonable amount of power. This was applied through selected filters which passed the energy corresponding to the TV channels. That meant you had a great chunk of broadband energy covering a TV channel shoved up the antenna cable. The incident and reflected signal were displayed on the CRO screen. The CRO gain was increased to display the reflected signal at a usable amplitude and the reference level established. The incident signal is passed through a switched accurate attenuator which has a resolution I think of 0.1db. This attenuator was accessible via a row of knobs on the front. The rest was fairly simple really. The attenuator was increased until the incident display exactly equalled the reference level set earlier on the reflected signal. The attenuator figure was then read as return loss.

This worked fine for an antenna with a single channel. There are several situations where more than one channel uses the same antenna so tuning and measuring these is a bit more tricky. The instrument used here is a Polyscop/Selectormat combination (yes R & S again) with a very nice reflectometer and 50 ohm reference load. This reference is not a connector with a 50 ohm resistor in it but a 1% load with as close to zero reactance as you can get and the connectors are 1% Spinner types. A 50 ohm resistor really is only 50 ohm at DC. The Polyscop part is a sweep generator with a very wide sweep range. The one we had was pretty old with a CRT display of about 10 inches. The Selectomat is a tracking receiver which tracks the Polyscop sweep and amplifies the very small reflected signal to a usable and displayable level. I think this instrument is still available in a more modern form but basically operates the same. Probably at a mind boggling price. Very clever bit of kit really. Displayed VSWR on the forward sweep and frequency response on the reverse. I think that is right. Two different parameters anyway.

In a way it is sad not to be still involved in just using some of the beautiful and very smart items of test gear at our disposal. One HP instrument I remember using to demonstrate to a fitter that 50mm of component lead had inductance and what’s more we were able to measure it.

Hope you find all of this of interest.
Cheers Bob

1 Like