Sheepdog Software HOME ArduServer HOMEFarWatch HOME
-d- Bookmark this on Delicious   Recommend to StumbleUpon

If only it were simple...

Ethernet Shield Pins

Avoiding clashes... Ethernet, SD cards, Etc

This page is browser friendly, by the way. Make your browser's window less wide than your whole screen and you will find the narrower columns much easier to read. For more tips, see my Power Browsing hints.

I've written a number of tutorials about connecting things to the internet. And those activities are a lot of fun. This page addresses something which is not fun... but on top of which you need to be. (Would that sentence please Mr Churchill?)

You can skip down to the ArduServer / ArduSimpSrv pin assignment specs, if that's all you came here for.

First a bit of good news: I got away with murder before I learned to worry about what I discuss here.

On the other hand, at the excellent Arduino Forum, we often see plaintive cries from people who's ethernet shield, SD card carrier, or other device "won't work" when it "should".

Something for nothing? Not in this life!

Shields are wonderful things... but you don't get something (new features, easily added) for nothing.

Let's say I've plugged an official Arduino ethernet shield into my Arduino Uno. It would be nice if the various "official Arduino ethernet shields" had version identifiers on the PCB. Write your congressman. But for now, we just have to struggle.

Once you've done that, you're (mostly) set to create one of my Arduserver2s... and it will probably work fine. Enjoy!

And then you decide to add some extra features, and put an input or an output on, let's say, the digital i/o lines D11 and D12.

It may work. It may do no harm to try....

But.....

Remember I said you don't get something for nothing? When you plugged the shield in, you connected "stuff" to various pins of the Arduino, didn't you?

It is (almost) "rocket science" to figure out exactly what you've done when you connect a shield!

The fundamental principles are simple enough... the devil is in the details... and finding the information you need.

At the very simplest level, let's say that the shield has something on it which is an output, from the shield. If all is well, then the library software running in the Arduino to service the shield will configure the relevant pin as an input when you make the right library calls, and all would be well... UNLESS, not realizing what the shield and library software are doing, you decide to use the same pin as an input from a simple button. The usual way to use a button is to connect one side to ground and the other to Vcc through a pull up resistor (be it a discrete component added by you, or a pull up resistor inside the Arduino if you know how to "connect" that, and if you don't, find out how).

So far so good?

Now... what happens if you've got the button pressed, connecting the pin to ground, and something in calls you program is making to the library causes it to tell the shield to try to drive the input to the Arduino high? That's right: You've created a short circuited from 5v to ground through bits of the silicon on the shield. Not good.

I have been very, very lucky over the years, "getting away" with outrageous things. (Often the voltage will fall as the current rises, and the falling voltage falls fast enough to "save" you) But even if it "still works"... at the moment... after an abuse... you may now be working with an unreliable, damaged component.

What do we need to know?

Let me mention at this point that this essay is written as if the Mega did not exist. Most of the general points apply in Mega-land, too, of course... but my specific comments are all B.M. ("Before Mega". Not B.S. as some of my friends(?) would charge.)

We need to know...

Neither is easy to determine, for certain. The software issues aren't as simple as you might at first think. You might say to me "but I'm writing the software! I know what the pins have been asked to do!"

Do you? Are you going to work with an ethernet shield without using any libraries??

When you call subroutines from the ethernet library, you will Do Things to/ with the pins. Sorry. Ditto if you are using an SD card interface on the same shield, or another in the same stack. (SD card interfaces are common on ethernet shields)

Even if you don't use any libraries, there are little "gotchas" waiting to get you. There's often an LED on pin 13. The system software pulses line 13 high before it does what you've asked in your setup() subroutine. Given the time it took me to find out about that little "wrinkle", I'll bet there are others! If you are very new to the Arduino, you may still be using D0 and D1 for things. This is best avoided, given that those lines are also used by the programming signals and the serial monitor... even if you aren't using the serial monitor, I would stay away from D0 and D1... but then I am a bit conservative, I suppose. On an Arduino Uno, D11, D12 and D13.. at least... connect to "stuff", even before you add a shield. Now it may connect in a way which doesn't compromise their use as general purpose I/O... but until I know more, I will avoid them!

So where to we go for answers?

I wish I knew. On the hardware side, there are various circuit diagrams available online. I will be talking about some of the things I've found... but what you see below is the fruit of discussions which moved me from being quite mistaken to being less mistaken, but still not at all "an authority".

On the software side? I really don't know where you go for help with that. But I will offer one idea: Where practical, when working with a shield, until you are "happy" with your investigations, maybe don't avail yourself of the "stack them" convenience. Connect the shield to the Arduino with wires. It is easy enough to do... the sockets in the interconnect accept suitable wires as nicely as breadboards do. Try using your shield with minimal interconnects. This won't tell you "all is well"... but if you have not connected something essential, you may find that your project doesn't work, which will be a clue! Of course, when you later stack the modules, you may make connections which you had not anticipated, and fried chips could result.




Things that I think are true...

As ever, before we can go very far, we have a "naming of parts" session to get through.

I will mostly be speaking in the terms used by the Arduino programming language. I.e., when I refer to "D13", I'm talking about the pin which would be affected by the command....

digitalWrite(13,HIGH);

I will refer in several places to things like "icso-1". By this, I mean "pin 1 of the connector on an Arduino Uno (and others) in the small group of six pins (2 rows of 3) which carries the "miso", "mosi" and "sck" signals... plus connections to Vcc, ground, and the Atmega's "reset" line. Please infer several other things from the above. (Whatever bright spark decided on the names "miso" and "mosi" won't be winning any prizes from the lysdexia association!)

If I refer to An0, that's short for "analog line zero", and refers to the pin you would be reading from if you used the command....

iMyDatum=analogRead(0);

An aside: Note that "A0" is also something the system "understands" as a pin identifier....

   "The analog input pins can be used as digital pins,
   referred to as A0, A1, etc. ",
   pp http://arduino.cc/en/Reference/DigitalRead

A bit strange(?)... but true! (I prefer/ preferred the scheme (being written out?) which allowed you to use....

pinMode(D14,INPUT);
iMyDatum=digitalRead(D14);

... if you wanted to use "A0" as a digital input. (Similar things can be done to use it as an output.)

End of aside. Back to work.

That will do for "naming of parts" for now. But if you get serious about reading schematics, you will have to learn to use and recognize several different naming schemes. What I am calling D5 here is sometimes referred to by the name of it's pin on the Atmega (pin 11), PD5. And that's sometimes called "T1", too. (Don't be too encouraged by the "D5"/"PD5" link up. It is (almost) coincidence. D13 is aka PB5... where's the mapping there?! (I'll try to do a page with a comprehensive guide to those issues... but if you want it sooner, write and tell me. Cite "a2ethpin.htm" and say "please do FULL pin "names" discussion".)

Onward!

What pins do ethernet interfaces use?

Even if a shield connects something on the shield to one of the digital I/O lines (D1-D13) or one of the analog lines (A0-A5) use them, you can, with care, use them for your needs alongside the ethernet interface's needs... but that is an advanced topic. I would suggest simply avoiding the pins the ethernet interface needs, until you really, really need (want?) MORE pins!

I'm pretty sure that you can depend upon D10-D13 being heavily involved in talking to the ethernet shield... indeed anything operating over an "SPI" interface. If the code includes the SPI or ethernet libraries, that's a big hint. I've used boards... the RBBB from ModernDevice... which have NOTHING on those lines on the Atmega's board, the "Arduino". (In quotes as the RBBB is "just" a clone).. with a NuElectronic ethernet shield (ENC28J60 based), and they worked just fine with only D10-D13 interconnected. I subsequently noticed that D2 is connected to something on the NuElectronics shield, so added an interconnect between the two, "just in case". Maybe the fact that my code "worked" was luck, not design?

The Arduino Ethernet shield, version 5, schematic shows the following as connected to things on the shield. (I gather there's a version 6 schematic out there, NOT showing some of the following. Some may be "scraps" of provision for having an SD socket on the same shield. I don't know, and until I do, or really want some more I/O lines, I will just avoid the lines which may be needed by the ethernet interface (and/ or SD card)

Used, I think, in Arduino Ethernet shield, version 5:

A stopping point

That's it, for the main points this page addresses.

Two things remain:

a) I will next make some comments on the implications of the above for my Arduino based servers, the ArduServer and Arduserver1 web servers, and the ArduSimpSrv, which doesn't use HTML.

b) Then I will tell you a cautionary tale about how I failed to see something important in the "official" Arduino schematics I was studying while trying to get to grips with all of this.


Pins used, ArduServers and ArduSimpSrv

What a "merry" time I've been having. My Arduino servers have three programs and 7 web pages devoted to them. And one of the actual servers is 3,000 miles from the other two.

I had "everything done". (Ha!) And then discovered what I thought was a problem. I re-wired two of the servers. Rewrote two of the programs. Changed what was on the web... all seven pages got at least a warning that there could be a problem, and that pin usage was in flux, and that there might be contradictions between various elements of my postings on the Arduino servers subject.

I was pretty well along with "fixing everything"... when, thanks to some superb advice from someone at the Arduino forum, discovered that I had things wrong! (That's when I decided to write the page you are reading, and just refer to it from all of the pages affected! If I have to change things again at some point, I am not going through making parallel changes in seven places again!!

So... At the moment, whatever it may say on the ArduServer and ArduSimpSrv pages, I recommend, the following for either an ArduServer or an ArduSimpSrv. (Not every device in the "product line" requires everything in the list.)

(The "beeper" should be a device which makes an ongoing noise as long as the input to it is high.)

You may need to mentally alter what some of the tutorial pages say and you may have to make slight tweaks in the software to make an ArduServer/ SimpSrv today which matches these hardware specs. I will try to get around to re-editing them all, to be "perfect", but for now, those documents must be read in conjunction with this one.

In most cases... all, eventually, I hope... tweaking the software will be a matter of changing a line near the start, e.g....

const byte bLEDpin=2;

... might need changing to...

const byte bLEDpin=8;

(Assuming that the LED is still meant to be on D8 by the time you read this! If I change the recommendation, I will try to change this example, too!)

That's a "simple" change. You may also encounter places where something like the following is buried in the depths of the code....

client.print("<br>Analog input 0 reads: <b>");
client.print(analogRead(0));

... must be changed to...

client.print("<br>Analog input 1 reads: <b>");
client.print(analogRead(1));

... because I haven't yet figured out how to put the "1" in a variable, and use that where ever a reference to where the sensor is must appear. Sorry. Shouldn't be hard, just haven't got to it. Too busy writing tutorials for you!

That's a "complicated" tweak. Intelligent use of your "Find" tool will make things easy, I hope.

Cautionary Tale

When I examined the schematic I have for the Arduino ethernet shield... (ver 5... and please: if you are in a position to influence these things: Get "them" to put version numbers on PCBs!!)... I saw, at connector "J1" ("IOH" on the Uno schematic), an LED (with resistance) on pin 6, which will connect to the Arduino D13 pin. Unlike the Uno's schematic, the line was not also la belled "SCK", but I probably wouldn't have noticed it anyway, even if it was there. It looked like the ethernet shield had only the LED and resistor on that pin.

However, elsewhere on the schematic a connector called ICSP appears. It has "SCK" on pin 3 (icsp-3)... and there are "things" connected to icsp-3 which I hadn't realized were there. I suspect that icsp-3 and D13 connect on the Ethernet shield, even though this isn't shown. "Everyone knows" that they are "always" connected, after all. In any case, as icsp-3 and D13 connect on the Arduino board, if you were to... as you might well, interconnect the ICSP headers of the shield and the Arduino, the "things" connected "only" to icsp-3 on the Arduino Ethernet shield would also be connected to D13... even if I am wrong about them being connected on the shield.

And the story is still not complete! In a third place on the schematic, going into RN5B, we have "another" SCK line... the same one, of course, as appears in other places. So RN5B (and the things connected to it) connects to icsp-3 and D13, too.

Moral of story? If you see "just" an LED on a pin... be careful that the same pin, or something connected to it, doesn't appear elsewhere on the diagram.

To conclude: Oh joy! A chance to use a phrase I like! "Absence of presence is not proof of absence"!

(While researching all that, I discovered that the same thing applies another way to the connections shown to the ICSP connector: On the Arduino Uno schematic, on first inspection, one sees, for example, pin 1 going to the D12 line, and la belled MISO. Closer inspection reveals a "second" ICSP connector... really just another representation of the one I saw first, and there we see further connections to pin 1 of the ICSP connector. Had I looked at the "second" one first, I would have made a similar mistake, just the other way around. (I would not have realized that ICSP-1 also goes to D12. There are some similarly "cryptic" connections to D0 and D1.)

But don't give up!

You are not by now vowing never to use a library or shield, I hope? They are very useful... but you have to be careful, and you have to look at exactly what is going on. As I said way up at the top: You don't get something for nothing. But if you eschew libraries and shields, you will won't get anything... Getting nothing will be the price of not getting any of the agony which goes with the ecstasy of Making Something WORK!




Contact this page's editor, Tom Boyd


Valid HTML 4.01 Transitional Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org. An early draft of the page was valid apart from several things inside the code to embed the video clip of the ocelots.

- - - Page ends - - -