Skip to content

Improvement: Eagle files for Shield design #4012

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
QRikard opened this issue Oct 21, 2015 · 25 comments
Open

Improvement: Eagle files for Shield design #4012

QRikard opened this issue Oct 21, 2015 · 25 comments
Assignees
Labels
Component: Documentation Related to Arduino's documentation content Component: Hardware Related to the design of Arduino's hardware products feature request A request to make an enhancement (not a bug fix)

Comments

@QRikard
Copy link

QRikard commented Oct 21, 2015

This suggestion is valid for all your arduino products (uno, mega, due and so on) which i hope you can consider.

It would be really nice with eagle files containing only basic features required for shields.
Such as headers and silkscreen (top and bottom please)
Hole and feature marks
Dimension

This would make it easier for users to create shields or other adapters without having to worry about placement.

I know it's possible to take the full design (huge thanks for distributing those files) and start deleting stuff but it would be nice with the option to download a simplified version for shield designs.

Best regards // Rikard

@q2dg
Copy link

q2dg commented Oct 21, 2015

+1!

@juaalta
Copy link

juaalta commented Oct 21, 2015

+1

@NicoHood
Copy link
Contributor

I personally dont like +1 github issue spamming but i definitely agree with the idea.

@agdl
Copy link
Member

agdl commented Oct 27, 2015

Hi, actually there is for example the Adafruit's library that has the various Arduino boards described as symbols and packages that can be easily added to a new design having in this way everything you ask for

@agdl agdl added the Waiting for feedback More information must be provided before we can proceed label Oct 27, 2015
@q2dg
Copy link

q2dg commented Oct 27, 2015

Well...I think facilitate the work to people who wants to extend Arduino ecosystem should be a priority. If Arduino wants to remain a main actor in "tinkering" hardware's world, it has to give all the possible tools to increase the community around him. And the requested issue is one of these tools. But that's only an opinion.

@agdl
Copy link
Member

agdl commented Oct 28, 2015

Something like this?

MegaDueR3BRD_shield.pdf
MegaDueR3SCH_shield.pdf

@NicoHood
Copy link
Contributor

I only looked at the pdf file, but the 16u2 is missing. you can remove it anyways, so it would be nice to have the header position of it at well.

@agdl
Copy link
Member

agdl commented Oct 28, 2015

@NicoHood to undestand if a component touches or not the header?

@QRikard
Copy link
Author

QRikard commented Oct 28, 2015

@agdl Yes exactly like that. Looks very nice!
Small improvements: Please include the ICSP, Debug and JP5 headers as well so all 2.54mm header are included. Maybe also the JTAG header.
I don't see a real reason to add DC-jack, capacitor or other large components, that's up to the user to verify where the large stuff is when required.
You are missing a +5V on the ICSP header.
For cosmetics Place the descriptive text to the headers centered to the output connection point. Tip set the Alt. grid to 0.5 and it will become easy to get them centered.
Sorry for picking on minor details but i'm a bit pedantic ;)

@NicoHood 16u2? I don't understand which component/header you are referring to.

If the entire board is a library component (as in the arduino/adafruit library) you can't choose to remove for example the digital header while keeping the rest. So i see a point to have both the library and separate schematic option.

Limitation is of course that you need to start with this schematic for the new shield design because copying the design looses the layout. The library component can always be imported for reference purpose but might not be possible to use for actual design.

Reason why i want all headers is because i plan to make my shield stackable (if all goes to plan) so it's possible extend/access all the debugging features without disassembling the board.

Edit: @agdl How did you make those neat ports? SCL, SDA, RESET and so on.

This is what my current schematic looks like (layout is same as original arduino). Not sure if it's an advantage of this approach with net names or if @agdl has a better solution with open pins. I'm leaning towards agdls because that limits the risk of interfering nets and leaves all connections up to the user even if my version is more practical in my current project.
due_isolator_shield_v1 00

@NicoHood
Copy link
Contributor

The 16u2 headers can be used for something useful. Just noone built a shield for it yet. Since its optional, you can remove the headers anyways, so this would be a nice addition.
https://github.com/NicoHood/HoodLoader2

The larger USB jack of the Uno should be added as marker, so people are aware that their components should not touch it (like the ethernet shield).

There should be two versions (1 for dure, 1 for uno etc) because of the 3/5v difference, the different 16u2 position and the large and small usb jack.

@agdl
Copy link
Member

agdl commented Oct 29, 2015

@NicoHood I was thinking to have only two versions
The Uno footprint
The mega footprint
That's why i didn't put the other non common headers. Infact as you said thy are not commonly used in shield design. It is also true that commercial shields are designed with the UNO footprint (whit a lot a mistakes like connecting SCL and SDA by default also to A4 and A5....) so maybe we can have 3 versions UNO, MEGA and DUE.

@QRikard I know :) I posted it just to have a feedback because I was in a hurry in doing something else and so I only wanted to know if I was or not in the way I know it can be improved!

@QRikard
Copy link
Author

QRikard commented Oct 29, 2015

@NicoHood Thanks for the link.
I'm starting to have my doubts about adding component references because height limitation depends on the users design so in the end there is no way to know to which component is "to high" so i think it's better to only include only the headers and leave all height restrictions to the user.

@agdl Perfect!
I like the idea to have as few designs/files as possible for simplicity. But if it's already a problem with people mixing up signals i think it's a good idea to separate the UNO, MEGA and DUE directly.
After reading up a bit on the 16u2 i understand why most users won't use this feature but if the schematics are already split i think it's good to add them anyway. It's easier to delete than to add afterwards, you can always place them in a box detailing that it's for extended features or something.

@matthijskooijman
Copy link
Collaborator

For KiCad, it seems there are some files available here: http://www.thingiverse.com/thing:9630

@agdl
Copy link
Member

agdl commented Jan 7, 2016

Sorry about the big delay. What do you think about this way of doing it? I think it is an average between all your requests. If it seems good to you I will proceed in this way
UnoShieldDesignBrd.pdf
UnoShieldDesignSch.pdf

@QRikard
Copy link
Author

QRikard commented Jan 10, 2016

@agdl Looks very nice exactly as i intended.
Noticed one thing about the due board. The serial TXn/RXn and I2C silkscreen and net names are not consistent between the eagle source and documentation. So please take an extra look at those when making the shield reference. For example Pin 14 = TX3 according to doc but TXD0 in eagle schematic.

Sorry i forgot to save a copy of my due design before i started to add headers and change nets so my current version will probably not provide much help. I think it will take just as much time to revert mine as to make it properly from scratch :(

One thing, please clear all net classes (#0 is default and 0mil for all, all other empty). These settings will be up to the user anyway and i have run into a bit of problem when copying parts and components between projects with non-default net classes.

@agdl
Copy link
Member

agdl commented Jan 11, 2016

Ok, what about these for the due?
DueShieldDesignBrd.pdf
DueShieldDesignSch.pdf

@q2dg
Copy link

q2dg commented Jan 11, 2016

One question: would "UNO" shield be compatible with Zero and/or Yún board?
And "Due" shield compatible with Mega board? Thanks
El 11/01/2016 09:45, "Arturo Guadalupi" notifications@github.com escribió:

Ok, what about these for the due?
DueShieldDesignBrd.pdf
https://github.com/arduino/Arduino/files/85445/DueShieldDesignBrd.pdf
DueShieldDesignSch.pdf
https://github.com/arduino/Arduino/files/85446/DueShieldDesignSch.pdf


Reply to this email directly or view it on GitHub
#4012 (comment).

@agdl
Copy link
Member

agdl commented Jan 11, 2016

@q2dg if you can use the IOREF pin(that is intended for this purpose) of course the answer is YES

@q2dg
Copy link

q2dg commented Jan 11, 2016

It's good to know it! Maybe, then, these shield designs should be named as
"UNO-like shield" and "Due-like shield" (or "UNO/Zero/Yún shield" and
"Due/Mega shield") for clarity, don't you think?

2016-01-11 10:48 GMT+01:00 Arturo Guadalupi notifications@github.com:

@q2dg https://github.com/q2dg if you can use the IOREF pin(that is
intended for this purpose) of course the answer is YES


Reply to this email directly or view it on GitHub
#4012 (comment).

@agdl
Copy link
Member

agdl commented Jan 11, 2016

Yes, I think so because this was what I said when I said that I wanted only to files because at the moment there are only 2 form factors shields (UNO and MEGA let's say) and it is the designer that must have care of which kind of pins are present and other related board stuff!

@agdl
Copy link
Member

agdl commented Jan 11, 2016

However having only two files as I suggested imply that you cannot use additional headers like JTAGs, ICSP and moreover so maybe having a more general file as possible is the best way

@QRikard
Copy link
Author

QRikard commented Jan 11, 2016

@agdl If you look at the names of the COMMUNICATION header in the schematic the net names doesn't match the silkscreen in the layout. (I think schematic is correct but don't take my word for it)

  • Please flip all headers so the text becomes horizontal, makes it much easier to read. Put the text on top of the wires (not below like XIO header).
  • I see your point of mimicking the physical layout but i think putting them in order is enough. Same goes for the UNO design (didn't think of it before just thought it looked a bit odd).
  • In schematic please keep the green text to the headers that indicated pin numbers, that's information that most users probably want in schematic as well as the layout.
  • Add silkscreen for JTAG, Debug, ICSP and JP5 header.
  • Add the 4-pin JP5 16u2 header as well.
  • Why does debug header have a different GND symbol?
  • Repetition from before, please clear all net classes (edit menu).
  • Another picky detail, leave 1 grid space of wire sticking out after each net name (like PWMH header).
    I fell more confident to provide feedback on the due since i have been working with that design recently, i have never used the uno (and equivalents). Most of these comments also apply to the UNO design (with modification).

One idea is to put all additional headers in a box so the user can easily delete the non-relevant headers for the current design.

@agdl
Copy link
Member

agdl commented Jan 12, 2016

I already cleared the net classes!
Something like this?
DueShieldDesignBrd.pdf
DueShieldDesignSch.pdf

@QRikard
Copy link
Author

QRikard commented Jan 12, 2016

Much better!
How about naming the box "DUE specific headers"? And make another box for MEGA specific headers? Then it's easy for the user to remove the non-relevant headers and you get one file with all variants. Downside is that the silkscreen stays but thats easy to remove. If you make this i think it's best to remove all hints of large components (DC-jack, caps) since those move between designs and which component that is to high is still up to the users design.

Tiny tweaks just to aim for perfection (as you may have noticed i like details)...

  • Put the header name on top of each header (unsmach should work for most headers). Personally i don't see any point in the value field of the headers when the name contains the information.
  • Rename JP1 to JP5 (same name as original due schematic if i remember correctly)
  • Move RESET2 label up one step
  • Rotate COMMUNICATION header labels so they have the same origin as the other labels
  • Add the header name for the ICSP and SPI header as well.

That's all i can think of for the DUE design

@sandeepmistry sandeepmistry removed the Waiting for feedback More information must be provided before we can proceed label Aug 24, 2016
@EtienneGameSeed
Copy link

EtienneGameSeed commented Sep 16, 2016

Hi,

would you consider sharing your Due shield library for Eagle ? I've found a library on a forum but it generates a lot of DRC errors (http://forum.arduino.cc/index.php?topic=153875.0)
Thanks.

@per1234 per1234 added Component: Documentation Related to Arduino's documentation content Component: Hardware Related to the design of Arduino's hardware products labels Apr 12, 2020
@per1234 per1234 added the feature request A request to make an enhancement (not a bug fix) label Apr 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Documentation Related to Arduino's documentation content Component: Hardware Related to the design of Arduino's hardware products feature request A request to make an enhancement (not a bug fix)
Projects
None yet
Development

No branches or pull requests

9 participants