Ethernet LEDs on Spinneret Web Server
David Carrier
Posts: 294
We are about done with the Spinneret Web Server design, but there is one last aspect that we haven't locked down: the LEDs on the Ethernet connector. There are two LEDs; one is green and the other is yellow. The green LED will light when there is a valid link, and it will blink off when there is traffic. We had set the yellow one to blink on when there is traffic, but it didn't convey any more information than the green LED.
My question is, what would you like the yellow LED to indicate? There doesn't appear to be any standard, but on 10/100 connections there are two common themes:
Speed indicator:
The yellow LED is on for a 100 mbps connection and off for a 10 mbps connection.
Duplex/collision indicator:
The LED is on for a full-duplex connection and off for a half-duplex connection. When half duplex connection is established, the LED will blink on to indicate collisions.
Which would you prefer? Is there another option that may be more useful? The second option conveys more information, but it seems like 10 mbps networks are more common than half-duplex networks, so the first option may apply to more networks. Keep in mind that this only effects the LEDs on the Ethernet jack itself. There are LEDs for all of the status signals on the PCB, but only the signals brought out to the Ethernet jack LEDs are visible when the PCB is housed in an enclosure.
Thank you,
David Carrier
Parallax Inc.
My question is, what would you like the yellow LED to indicate? There doesn't appear to be any standard, but on 10/100 connections there are two common themes:
Speed indicator:
The yellow LED is on for a 100 mbps connection and off for a 10 mbps connection.
Duplex/collision indicator:
The LED is on for a full-duplex connection and off for a half-duplex connection. When half duplex connection is established, the LED will blink on to indicate collisions.
Which would you prefer? Is there another option that may be more useful? The second option conveys more information, but it seems like 10 mbps networks are more common than half-duplex networks, so the first option may apply to more networks. Keep in mind that this only effects the LEDs on the Ethernet jack itself. There are LEDs for all of the status signals on the PCB, but only the signals brought out to the Ethernet jack LEDs are visible when the PCB is housed in an enclosure.
Thank you,
David Carrier
Parallax Inc.
Comments
For consistency sake, I see a lot of network equipment that uses one of the above choices. However, neither of these is terribly useful. It seems like either of these can usually be determined by looking at the LEDs on the switch (unless we're trying to diagnose a problem with the switch and prop disagreeing about link state or protocol).
Some things that might be nice:
1) transmit indicator - lets me know when the prop is sending packets.
2) overflow indicator - lets me know when packets have been dropped from the network buffer because the prop can't service them fast enough.
3) error indicator - lets me know if a packet is rejected due to some problem (bad IP or TCP or UDP checksum, malformed frame, etc)
From one who has done some work using a TCP/IP stack on the prop, the above were some things that would have been handy. In particular it's nice to know when packets are being sent as it lets me know the device is running, as opposed to a receive or traffic indicator that only lets me know there is traffic on the line, which the device could be locked up and ignoring.
As I'm not sure how you're driving the lights (is it software running on the prop that's toggling the lights, or are you constrained by what the ethernet chip can do), I don't know whether my suggestions are feasible or not.
I haven't read the specs, but my question is: why can't you just use wire-or or use a gate to make the LED indicate a collision -OR- a mis-matched physical layer?
In other words, if 10baseT is the only physical type supported and either a Gigabit or 100baseT network is detected, the LED should also light to indicate a problem.
The Propeller has a theoretical maximum sampling rate of 20 Msps when using four cogs running at 80 MHz. (The PropScope runs at 100 MHz, so it can sample at 25 Msps.) The resources required for such high speed sampling may not be practical on the Spinneret Web Server, but with the 8-bit data bus, anything over 1.25 Msps will out-do a 10 Mbps Ethernet connection. Transmitting, on the other hand, can be much faster and lower overhead, using the video generation hardware.
smbaker,
The status indicator lines I have been referring to all come directly from the W5100 chip, and the Propeller doesn't control any of them. There is a user controlled LED on the PCB, and I could bring its signal out to the Ethernet jack. I hadn't thought of that earlier, but it could be very useful. It could use blinking patterns, like the beeps in a PC BIOS, to report any kind of error. Under normal operating conditions, it could be used in any of the ways you described, or it could be programmed to indicate full or half duplex, or 10 or 100 Mbps.
David Carrier
Parallax Inc.
The green LED on the Ethernet jack only turns on if there is a valid link, and the only indicator of a mis-matched physical lay is a lack of a valid link. The W5100 datasheet doesn't give any information about what it considers a collision; the chip just has a line that goes low when it occurs. The second option, to indicate the duplex status and blink whenever there is a collision, did involve ORing the duplex and collision lines with a pair of diodes. It could be actively XORed instead, to indicate collisions no matter what type of connection there is. I don't know if it reports every type of collision, though. I don't think that sharing a MAC address in and of itself would be considered a collision on the physical layer, it is more of a logical collision.
I am beginning to think that connecting it to the user LED will be the best option, because the Propeller can read the status indicators directly from the W5100, so the meaning of the LED could be set in firmware instead of hardware.
David Carrier
Parallax Inc.
Ok then, so I take it then that when traffic stops the LED does not blink back on
A user configurable LED is a good option if it doesn't use more than a few instructions. If a user runs out of pins, it would be easy enough to remove the LED if necessary.
Cheers,
--Steve
Would it be possible to have additional pads on the board that would make it "easy" to reconfigure the hardware to get the other choices? This way, someone could cut traces and add a few extra wires to get the other options if they were required. If there are diodes required for these options, then empty pads could be left for them.
I think that's the best idea. I wish I could change my vote to "Other", now that I know user controlled could be an option.
123.123.123.123?led=on