Shield pin usage list

On a similar note, that's why I came unstuck looking at the Etthernet shield schematic the other day, P1 and P3 where "swapped" between the shield schematics and the Arduino but I assumed that there was a standard and "P1" was the same on all schematics.

Usually you name components in order on a board so they are easy to find but for important, common, and static components like these headers I think they should have standard names. If not P1 etc then "Power", "Analogue" etc. This is often done on the PCB as mentioned, but they they should have standard names on the schematics.

This is a good argument for the Apple model whereby a single entity defines what will be done and there's little room for interpretation. That's not the model we want here I guess but some standardisation should be striven for.


Rob

Hi Jon,
Thanx for these sites, lot of good info. these sites should be mentioned on http://arduino.cc/en/Main/ArduinoShields but I have no rights :frowning:
Furthermore you might put a link "Shield Design Considerations" on the homepage of http://shieldlist.org/ and teach the world :slight_smile:

Rob

One of my personal irks (and one of the reasons for http://shieldlist.org) is not being able to figure out what pins are used on a shield simply by looking at it. I mentioned it in the video review I did mid last year for the WiShield v1, ....

;D I used pet peeve in my write up here last week

If you have ever seen Jon Oxer, author of the book Practical Arduino, discuss a shield, as he does in this video review of AsyncLabs WiShield for Arduino, you would probably easily observe that one of his pet peeves is designs that dont let you know shield pin assignments when using the shield.

Because I couldn't catch the term you used, what was the term at
4:42 was it bug bears?Video 4:42

One of my concerns has been I would like to add more to the list but just can't tell what pins are used on some boards I have found, that aren't in the database, but I just I dont know how to enter them.

My concern was if I entered them with the wrong pins(as in guesses) it might stop someone who would know would then not enter the right info, so I just chose not to enter them.

Would you still like the info entered?

Om nom nom free stuffs :slight_smile:

Do I get something for each shield I submit or just the one? :smiley:

Would it be tricky to add the ICSP header onto your pin usage diagram? Quite a number of shields use it now (especially to become mega compatible).

What about Mega shields, you accepting those too?

Mowcius

Hmm no free stuffs yet...

Mowcius waits patiently.

Hi Mowcius, I emailed asking for your postal address but I don't think I ever got a reply. I've just searched my email again to make sure and I can't find anything.

Could you please email your postal address to jon@oxer.com.au again?

Cheers

Hi Mowcius, I emailed asking for your postal address but I don't think I ever got a reply.

Hmm, didn't receive anything but it might have been due to my end. My email program had a phase of sending out random reply email addresses...

I'll send it. :wink:

The website's coming on great.

Mowcius

You should make sure you have a way to handle optional pin usage.

My new motor shield http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1288647984/0#0 can use any of the 6 PWM outputs, several of the digital outputs for enable and any of the 6 analog inputs - all user selectable via jumpers.

Further different numbers of pins can be used for this shield in different operational modes. The minimum number is 1 and the maximum is 5.

It doesn't seem fair to say the unit uses all of the possible pins and yet it should be indicated somehow those CAN be used.

Just a comment, hard coding particular pins seems dumb to me if you want your shield to be able to work with others.

/me

You should make sure you have a way to handle optional pin usage.

That would be nice, but I haven't figured out a nice way to handle it. It would add a lot of complexity to the user interface (both current and intended) for the site because there are so many possible scenarios.

It's not as simple as adding a third pin option so they can be flagged as "used", "not used", or "optional". Often the options are tied together, so a shield may use one combination of pins in one mode and another combination of pins in another mode. A good example of this is the Spikenzie Labs Button 64 Shield (Arduino Shield List: SpikenzieLabs Button 64 Shield) because it can use either:

D0

OR

D2, D3, and D4

but not both groups at the same time.

So if I just marked D0, D2, D3, and D4 as "optional" it would be technically correct, but just as misleading as marking them as all used. People might think they could use any one of them or even none of them when that's not the case. D2-4 would really need to be bound together into a group, and D0 defined as another group, and those groups be defined as mutually exclusive but with one or the other required. But how would that be represented visually?

Mutually-exclusive-but-required groups is one scenario. Then there are others such as optional pins that are required by some features that may not be used by others such as the SD card slot on the new Ethernet shield that may not be used by many people (Arduino Shield List: Arduino Ethernet Shield v5.0). Or shields that are nothing but breakouts, so they could use all the pins or none of them, depending on what else is attached (Arduino Shield List: Seeed Studio Electronic Brick Chassis v1.1).

Showing optional pin usage sounds good in theory, but when you try to figure out how to actually store / represent that information it suddenly becomes a surprisingly difficult problem!

For now I'm handling it by marking the "default" or basic pin use in the DB, and adding a text note about alternative assignments. At least having all this info in text form in one place is a huge improvement on how things were a month ago.

Jon
Freetronics: www.freetronics.com

As a minimum I'd say we need the SPI header as some shields now use that and some bring it up with through headers too.

Mowcius

I'd say we need the SPI header

I assume you mean the ICSP header? I planned for that right from the start and the fields are included in the DB, but when I was putting together the form with the pins represented by checkboxes it was late at night and I couldn't be bothered adding them in. I planned to get back to it, but I just haven't yet :frowning:

By the way, there's now a parcel heading your way. It will probably take a week or so to the UK though.

Jon

I assume you mean the ICSP header? I planned for that right from the start and the fields are included in the DB, but when I was putting together the form with the pins represented by checkboxes it was late at night and I couldn't be bothered adding them in. I planned to get back to it, but I just haven't yet

Yeah that's what I meant ;D

By the way, there's now a parcel heading your way. It will probably take a week or so to the UK though.

Great!

Hey, Jonathan, you mentioned that you would release the source code for the website.
I'm looking to do something with a database like you have but I have never dealt with them before so it'd be nice to have something to start off from.

Thanks,

Mowcius

That's right, I'd forgotten I was going to do that. I'll do a bit of a cleanup and put it on GitHub.

I wouldn't take it as an example of a great way to do it though!

Jon

I wouldn't take it as an example of a great way to do it though!

Well it seems to work ok :smiley:

I've used one of my protoshields now :wink: Well, almost. I have it reserved for something...

Hi,

I love the site, but PLEASE get the tabular form up.

Also, since I view this from a developers side,
IF a shield uses I2C, please list the ADDRESS or ADDRESS Range usable.

Also how might one develop a spi shield and give a few choices for CS/SS pins? Everyone can't be on 10 or whatever the default CS is.
What if a user wants to use >1 spi device?

Thanks.

IF a shield uses I2C, please list the ADDRESS or ADDRESS Range usable.

For things like that I list it in the "notes" section that appears directly below the shield diagram, but only if I know what it is. I've spent many, many hours going through circuit diagrams and documentation for shields trying to find info like that but I can't do it all myself! If you have information about any particular shields please click the link at the bottom of the page to send me a correction.

Also how might one develop a spi shield and give a few choices for CS/SS pins?

That's entirely up to you. The easiest is probably to run something like a 2x3 male header, with all pins on one side connected to the chip CS and the other three pins connected to three digital lines. Then users can put a little 2-way jumper header in place to select which digital line to use.

Jon
Security Sensor Shield: Security Sensor Shield for Arduino | Freetronics

Ok, you guys are the pin experts... I have found 100 different takes on this... so what is the answer:

I have an Arduino Mega 2560 and and EthernetSD- V5 it looks like from your "Shield" website.

Does one have to run jumpers and bend out the pins for 10,11,12 and 13 and jump them to 50,51,52 and 53??? :cry:

please help the noob! ::slight_smile:

Hi,

Version 5 is compatible with the Arduino Mega 2560. The PCB has an ICSP connector at the bottom to reach the right pins i believe.

This is from the shield page (i couldn't post a link, 1st post?)

  • 8< ----
    It is compatible with the Arduino Duemilanove and Mega (using the Ethernet library coming in Arduino 0019)
  • 8< ----

I'm using these 2 boards myself without modifying anything

Sooo.... NO pin bending needed :wink:

Rinus