search

buixuanan / fritzing

Automatically exported from code.google.com/p/fritzing
0 stars 0 forks source link

Eagle lbr importer #1941

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
It's already working very well, here are some suggestions for improvement:

DIP & DIL ICs:
- bb: all dils are one step too wide (dips are correct)
- bb: chip label should be the part name, not "IC"

SMD ICs:
- bb: chip labels should be the part name, not the package name
- bb: show pin names instead of pin numbers?

GENERAL:
- sch: pin labels are missing
- bb: we could use Lionel's set of subparts to auto-generate more graphics
- bb/pcb: doubly defined connectors are only showing up once (e.g. LT1014, 
MAX6675, ATTINY24)
- bb/icon: some parts show a graphic from some equally named core library part 
(e.g. battery holders, Thumb Joystick, Switch-DPDT, Trackball)
- bb: odd number of pins leads to a big red blob on the part, because it 
doesn't know where to put the last connector (e.g. OPA344)(this doesn't have to 
be fixed, it should probably be treated manually)
- specific part problems: LTC6244 (missing all connectors), X9015_DIGI_POT 
(schematic parse error), apa3010sf4c & luxeon-rebel (bb view giant connector)

CONNECTORS:
In order to distinguish the connectors which should be treated separately (in 
the generator) we can pick the ones that have a _part title_ of "Header 1" etc. 
or _family_ "m01", "m02", "m05x2" etc.
A few exceptions need to be included: PINH2X12, PIN HEADER, PINHD-2X26
-> I already manually updated the table to reflect this.

A _package name_ of "1x06" etc. is not a reason to treat these parts separately 
as generated connectors. It just tells us what the breadboard graphic should 
look like:

package name > graphics

1x06-... > male pin headers, vertical
molex-... > molex vertical
jst-... > jst right angled
screwterminal-... > screw terminal

Original issue reported on code.google.com by andre.knoerig@gmail.com on 10 Apr 2012 at 5:54

GoogleCodeExporter commented 9 years ago 
are there any parts on the wishlist we should add to this?  
http://fritzing.org/about/roadmap/parts-plan/  Are there other open source lbr 
files we should include?

Original comment by irasc...@gmail.com on 16 Apr 2012 at 11:54

GoogleCodeExporter commented 9 years ago 
chip labels: this will probably have to be handled by making these generative 
in Fritzing.

schematic pin labels: easy enough for rectangular schematics (the trick will be 
to figure out which ones are rectangular), no idea what to do for other cases.  
This may also have to be handled by the Fritzing app.

Original comment by irasc...@gmail.com on 16 Apr 2012 at 11:58

GoogleCodeExporter commented 9 years ago

Original comment by irasc...@gmail.com on 16 Apr 2012 at 12:06

GoogleCodeExporter commented 9 years ago 
I do not think the lt19014, max6675, and attiny24 (and others like them) can be 
fixed automatically because they are underspecified in the xml. Since the 
max6675 has the least number of pins of the three parts, I will use that for an 
example, but all three have a similar issue.

The max6675 uses the so08 package, so there are indeed 8 pins in the footprint. 
However, both the schematic xml and "device" xml only specify 7. I don't see 
any way to recover information about what the 8th pin is doing. The schematic 
defines 7 pins:

VSS, T-, T+, VDD, MISO, CS, SCK

the "device" links these to 7 pads (in order):

1, 2, 3, 4, 7, 6, 5

---------------------------

Aside from this, I see a bug that though the right number is associated with 
the right name on the generated parts, these are not in the correct physical 
position on the chip in breadboard and pcb view.

Original comment by irasc...@gmail.com on 17 Apr 2012 at 11:33

GoogleCodeExporter commented 9 years ago

Original comment by irasc...@gmail.com on 21 May 2012 at 10:33

GoogleCodeExporter commented 9 years ago 
reposting Andre's comment from issue #921:

After the SparkFun library, we could also include these: 

Adafuit - http://www.ladyada.net/library/pcb/eaglelibrary.html
Seeed Studio - https://github.com/Seeed-Studio/EagleLib-of-Seeedstudio
Dangerous Prototypes - 
http://dangerousprototypes.com/docs/Dangerous_Prototypes_Cadsoft_Eagle_parts_lib
rary

Original comment by irasc...@gmail.com on 21 May 2012 at 10:36

GoogleCodeExporter commented 9 years ago 
r5994: schematics include pin names. They look decent in a surprisingly large 
percentage of cases, but there is some hand_tweaking or programmatic nudging 
required.  I wonder whether to add this to the googledoc, or make a separate 
xml params doc.

Original comment by irasc...@gmail.com on 23 May 2012 at 12:13

GoogleCodeExporter commented 9 years ago 
Back to the aside in comment 4: in pcb view, the connector name is positioned 
correctly, but the connector number is wrong.  In breadboard view, the 
connector number is positioned correctly, but the name is wrong.  I think this 
is because the index number of the connectors is generated when they are 
encountered in <symbol> and <package>, rather than using the pad number 
specified in <device>.

Original comment by irasc...@gmail.com on 23 May 2012 at 1:17

GoogleCodeExporter commented 9 years ago 
r5996, comment 8 fixed

Original comment by irasc...@gmail.com on 24 May 2012 at 10:00

GoogleCodeExporter commented 9 years ago 
r5997 dil heights decreased (from original issue report)

Original comment by irasc...@gmail.com on 25 May 2012 at 9:39

GoogleCodeExporter commented 9 years ago 
r5998: X9015_DIGI_POT schematic fixed. 

Also added and deleted a handful of parts as the lbr files have been 
updated--need to fix up the googledoc to reflect the changes.

The LTC6244 bug is due to some missing <connect> elements in the analog-ic lbr 
file; apa3010sf4c and luxeon-rebel bugs are problems with the generator.

Original comment by irasc...@gmail.com on 25 May 2012 at 10:52

GoogleCodeExporter commented 9 years ago 
r6001: fixed the LTC6244 by adding a <connects> element to the <deviceset> xml 
in SparkFun-AnalogIC.lbr:

<deviceset name="LTC6244">
<description>Low-noise, high-speed rail-to-rail CMOS op-amp</description>
<gates>
<gate name="G$1" symbol="LTC6244" x="-22.86" y="2.54"/>
<gate name="G$2" symbol="LTC6244_2" x="20.32" y="0"/>
</gates>
<devices>
<device name="" package="MSOP8">
<connects>
<connect gate="G$1" pin="+IN" pad="3"/>
<connect gate="G$1" pin="+V" pad="8"/>
<connect gate="G$1" pin="-IN" pad="2"/>
<connect gate="G$1" pin="-V" pad="4"/>
<connect gate="G$1" pin="OUT" pad="1"/>
<connect gate="G$2" pin="+IN" pad="5"/>
<connect gate="G$2" pin="-IN" pad="6"/>
<connect gate="G$2" pin="OUT" pad="7"/>
</connects>
<technologies>
<technology name=""/>
</technologies>
</device>
</devices>
</deviceset>

Original comment by irasc...@gmail.com on 25 May 2012 at 2:24

GoogleCodeExporter commented 9 years ago 
apa3010sf4c and luxeon-rebel are both smds with an odd number of pads. Will try 
a general fix for this problem by adding an empty connector to bb view.

Original comment by irasc...@gmail.com on 25 May 2012 at 2:35

GoogleCodeExporter commented 9 years ago 
r6002: attempt to deal with bb svgs for smds with an odd number of pads

Original comment by irasc...@gmail.com on 25 May 2012 at 3:30

GoogleCodeExporter commented 9 years ago

Original comment by irasc...@gmail.com on 9 Jun 2012 at 9:39

GoogleCodeExporter commented 9 years ago 
Slight regression: The breakout boards seem to have all female connectors now, 
so they don't snap to the breadboard anymore.

Original comment by andre.knoerig@gmail.com on 18 Jun 2012 at 2:49

GoogleCodeExporter commented 9 years ago 
Eagle names multiple occurrences of physical pins as "GND@1", "GND@2", and 
gives them one connector in schematic view.
We normally do this by naming them all just "GND", and put multiple connectors 
on top of each other in schematic view.

I think Eagle's approach is actually more flexible, but it's probably too late 
to change this now? So the importer should try to be smart about this, and 
automatically convert Eagle style to our style.

Original comment by andre.knoerig@gmail.com on 23 Jun 2012 at 2:11

GoogleCodeExporter commented 9 years ago 
don't change breadboard symbol when switching resistor packages

Original comment by h...@supernodegree.com on 2 Jul 2012 at 10:43

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by andre.knoerig@gmail.com on 2 Jul 2012 at 10:53

GoogleCodeExporter commented 9 years ago 
@comment18: probably the same in breadboard view for LEDs, and likely the same 
for capacitors. Others?

Original comment by irasc...@gmail.com on 2 Jul 2012 at 11:41

GoogleCodeExporter commented 9 years ago 
@comment20: yes. it's the same for leds, diodes, relays, crystals, resonators, 
theres 1 strange voltage regulator.

Original comment by h...@supernodegree.com on 2 Jul 2012 at 12:49

GoogleCodeExporter commented 9 years ago 
not sure if those are intended:

#1 tantalum and electrolytic caps share the same packages. (same for resonators 
and crystals)

#2 resonators/crystals are listed in semiconductor-group.

Original comment by h...@supernodegree.com on 2 Jul 2012 at 12:53

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
All of the generated schematic images (pinheaders, dips, sips, mystery parts, 
screw terminals) currently use the old schematic sizing spec. I imagine these 
should be converted to the new spec. For pinheaders, do we prefer the old 
male/female arrow shapes, or do we move to the rectangle-with-pins 
representation favored by the sparkfun library?

Original comment by irasc...@gmail.com on 5 Jul 2012 at 6:02

GoogleCodeExporter commented 9 years ago 
@comment18: I think these probably need to be marked "programmatic", or maybe 
"discard" in the googledoc.

Original comment by irasc...@gmail.com on 20 Jul 2012 at 12:19

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
@comment24: keep the male/female distinction but redraw them to the new 
schematic spec

Original comment by irasc...@gmail.com on 20 Jul 2012 at 12:23

GoogleCodeExporter commented 9 years ago 
@comment17: r6201

Original comment by irasc...@gmail.com on 23 Jul 2012 at 10:20

GoogleCodeExporter commented 9 years ago 
Issue 1790 has been merged into this issue.

Original comment by irasc...@gmail.com on 25 Jul 2012 at 1:20

GoogleCodeExporter commented 9 years ago

Original comment by irasc...@gmail.com on 25 Jul 2012 at 1:30

Attachments:

GoogleCodeExporter commented 9 years ago 
Adding this comment here, since the discussion is otherwise hidden

Currently each translated lbr file is going into its own bin. This adds another 
13 bins to the 6 or so we already have, and having 20 total bin tabs is way too 
many--the UI becomes unwieldy. 

Andre's solution (which Hans is working on) is to reorganize all the parts into 
around 6 total bins with sections.

Original comment by irasc...@gmail.com on 4 Aug 2012 at 12:48

GoogleCodeExporter commented 9 years ago 
Another big issue that is not otherwise documented: what do we do about 
schematic view, since the new schematic view parts all have a completely 
different grid size.  In particular, what happens to all the old parts. On the 
one hand we could obsolete every part, which is a logistical nightmare. On the 
other hand we could change all the old sketches, which would be another kind of 
nightmare for people who spent time in schematic view.

I have a proposal, which works similarly to the way we made the switch from .fz 
to .fzz. We declare all old .fzz files read-only. When a user opens an old fzz 
file, they will be asked whether they want to convert it to the new schematic 
view. If "yes" a copy of the file is created, and all old schematic images are 
updated, with whatever chaos occurs with the wiring (or we could autoroute).

I am not sure what to do about old .fz files, in the sense of whether to 
convert in two steps (i.e. first convert to fzz, then when that is loaded, ask 
about the schematic conversion), or whether to convert all at once (i.e. once 
you consent to convert to fzz, schematic is automatically converted as well).

Underneath it all is the following. All old schematic images are moved to the 
obsolete folder but not renamed. If the file is unconverted, the obsolete image 
would be used instead of the new image. For obsolete generated parts (mystery 
part, sip, dip, pinheader) I think the old generator code would have to be 
available, and if the file is unconverted, the old code would be invoked 
instead of the new code.

So I would call this nasty but not a nightmare.

Original comment by irasc...@gmail.com on 4 Aug 2012 at 1:02

GoogleCodeExporter commented 9 years ago

Original comment by irasc...@gmail.com on 4 Aug 2012 at 1:03

GoogleCodeExporter commented 9 years ago 
More about schematic view. Probably we need to make an svn branch for this 
code. We should also make a new google doc for the old part schematic view 
images: for each part, mark whether there is already a new svg to use, whether 
the new image can be generated (i.e. this is straightforward if the old image 
uses the standard rectangle style), or whether the new image must be 
illustrated.

I will generate a first pass of this document.

Original comment by irasc...@gmail.com on 4 Aug 2012 at 1:32

GoogleCodeExporter commented 9 years ago 
all the examples will have to be updated for the schematic switchover.

Original comment by irasc...@gmail.com on 4 Aug 2012 at 10:36

GoogleCodeExporter commented 9 years ago 
what happens to custom part SVGs during the changeover? Rectangular schematics 
can be automatically upgraded, but what about the rest. I am tempted to say 
leave it to the user.

Original comment by irasc...@gmail.com on 7 Aug 2012 at 6:14

GoogleCodeExporter commented 9 years ago 
latest schematic template

Original comment by irasc...@gmail.com on 12 Sep 2012 at 4:02

Attachments:

GoogleCodeExporter commented 9 years ago 
Issue 921 has been merged into this issue.

Original comment by irasc...@gmail.com on 4 Jul 2013 at 3:31

GoogleCodeExporter commented 9 years ago 
parts are released.

Original comment by irasc...@gmail.com on 30 Jul 2013 at 6:11