Proficiency with Eagle?

Hi,

This type of thing requires following the PDF user manual. It takes just a day to flick through it, and learn the features available. Otherwise you'll repeatedly do things the slow way when there

are built-in features that will save time.

From my perspective, I like the GUI paradigm in EAGLE. I wish other software would allow me to work as fast.

If I had 100 pins to connect, this is what I'd do:

First, try to break it down into groups of pins (e.g. data bus, address bus, port A 0-7, port B 0-7, etc.

Next, create a bus for each group. You only need to type the range (e.g. D[0..7]) when naming the bus.

Or just create a single bus for all, and separate with commas any signal names or groups of names. I prefer separate busses per group, for nicer looking schematics.

That's it, no more typing or confirmations or clicking on 'Yes'.

Next, bring a signal from the microcontroller onto the bus. Do the same from your other device(s), e.g. memory etc.

As you bring and connect to the bus, you'll be presented with the list of possible pins within the bus. Just click and choose.

Optionally afterwards, place a text name besides each pin (recommended for clarity and peace of mind).

I'm pretty confident 100 pins could be attached to two devices easily within 10 (ok perhaps 20 at a stretch) minutes with this method.

Who would use busses nowadays? To avoid clutter, modern schematics do away with wires and buses. In a normal CAD program you would select a pin, right click on it, and assign it to a net. Go to the next pin and do the same (the last net you selected is already in the pop-up box). With Eagle you can't even assign a specific net directly to a pin, you MUST first append a default net (or wire) and only then re-name it, and all this with its clumsy interface.

You must be kidding with your 10 minutes, if I do all the steps you described, I would certainly need a workday. Unfortunately, my application is about a micro controller (STM32F745) and there are no simple cases as a data/address bus with similar signals (i.e. D0...7 or A0...20), rather each pin has its function (three USARTs, a CAN, 2xUSBs, a SPI flash, SD card interface, JTAG, etc.). So you really have to deal with each signal individually.

Any other idea, anyone?

BTW, I read the manual several times, I spent way too much time with it. It is written on the same note as the User Interface, not very useful.

Who would use busses nowadays? To avoid clutter, modern schematics do away with wires and buses. In a normal CAD program you would select a pin, right click on it, and assign it to a net. Go to the next pin and do the same (the last net you selected is already in the pop-up box). With Eagle you can't even assign a specific net directly to a pin, you MUST first append a default net (or wire) and only then re-name it, and all this with its clumsy interface.

You must be kidding with your 10 minutes, if I do all the steps you described, I would certainly need a workday. Unfortunately, my application is about a micro controller (STM32F745) and there are no simple cases as a data/address bus with similar signals (i.e. D0...7 or A0...20), rather each pin has its function (three USARTs, a CAN, 2xUSBs, a SPI flash, SD card interface, JTAG, etc.). So you really have to deal with each signal individually.

Any other idea, anyone?

BTW, I read the manual several times, I spent way too much time with it. It is written on the same note as the User Interface, not very useful.

Lix Paulian wrote:

 

I appreciate your patience with me. If I am sometimes a bit rough is because I (falsely) presume that CadSoft people would read these posts and maybe change their minds (I am not alone having these views). Moreover, there are some long-time users on this board that have nothing else to do as to contradict people like me to the sense we have no idea what we are talking about, because Eagle is the best that could happen to the CAD world, and we better read the manual, etc. etc.

There are a few CADSoft people who read this forum. Maybe Jorge_Garcia will wade in with some sage advice for you. You are also right, there are some die hard EAGLE users on here too, most also have their own gripes list for things that are missing from EAGLE or just plain broken in the way things operate.

Like you, I use EAGLE for my freelance work. It runs on a Mac and for me it's actually quicker to use than DxDesigner for several parts of my workflow. So lets talk about stupid ways of having to do things in CAD tools. In DxDesigner, without back end trickery, a MOSFET or a bipolar transistor which comes in an SO-8 package for example has to have a custom schematic symbol with 8 pins on it because Mentor don't believe in connecting a single symbol pin to multiple pads on a device. So to get round this so I can have common MOSFET symbols, bipolar transistor symbols, or just large devices with hundreds of power pins that don't have stupid power connection requirements, I have pin mapping files for every part I create stored in my library and I had to write a netlist post-processor app to map the pins correctly in my netlist. To me this was a huge waste of time for something that really should just have worked as I wanted it to do. This is just one example of Mentor Graphics stupidity, there are many more, my point being no tool is perfect no matter how much you pay.

Lix Paulian wrote:

 

I can only say that if CadSoft wants to get over the current Eagle's status of software for hobbyists, they should really re-think their strategy. They can say ok, we have a certain number of loyal users and that's it, so we develop our software only for them; or they can stride towards greater market share. If they continue doing things as they do, I doubt they will survive for long. The problem is that most new users evaluating the software are  rapidly discouraged by its non-standard interface. And I find it's a pity, because Eagle has several compelling advantages: it is robust (doesn't crash), it is multi-platform (the latter can't be said for most of the CAD software out there) and not expensive.

The UI really isn't that bad once you get over the initial wtf? when you first use it which I admit probably does put some new users off initially. A lot of the issue is there isn't a very brief and readable getting started guide to get people going quickly (the manual is informative but it's a very dry read at times) and people have to rely on guides found on various websites.

So what is the issue with requiring the command line to do some things quickly? On any OS there are many things provided in a GUI that are simply done more quickly by dropping to the command line. Going back to my examples from yesterday, well in PADS you have to define the net names somewhere which will require the keyboard and adding them into a dialog box is likely to be more time consuming than the simple bus definition string I gave above. From then on its similar in both, either select a pin and select a pre-defined net name, or wire to a bus and select a pre-defined net name.

Lix Paulian wrote:

 

I would expect advanced features like RF trace matching, advanced routing, 3D support, etc. to be missing from a somehow lower priced product.

As much as I would love the UI to be improved in some areas (I admit it isn't perfect and could do with some polish) I would actually prefer the devs at CADSoft to spend their limited resources to provide some of the features you said you would expect in a higher priced product. Actually I will settle for them improving the features they do provide initially but more advanced layout features for those of us who use the software professionally would be most welcome.

Lix Paulian wrote:

 

Back to my original issue, I didn't manage to test your suggestions, as this is a project I am not doing for my employer, it's a consultancy job I do in my spare time. It seems however, that without the command line there is no efficient solution, which doesn't really speak for Eagle's UI. The workflow for the task I described must be straightforward, and it really is on most other CAD programs.

The workflow for the task you describes IS straightforward, albeit with the use of the command line just a little. Most engineers are usually quite happy with command lines though in my experience so this really shouldn't be an issue. Just for kicks, I knocked up a schematic last night with a microcontroller and some IO devices on I2C and SPI plus a couple of UART's going to some connectors and several other bits and bobs. I hooked up the entire schematic in the way I described, all labelled up, in a little over 20 minutes.

Lix Paulian wrote:

 

I disagree with your comment that if the price is low, the user interface can be bull-***.

I disagree with that too as I never said that at all! Don't say I have said things which I haven't.

I appreciate your patience with me. If I am sometimes a bit rough is because I (falsely) presume that CadSoft people would read these posts and maybe change their minds (I am not alone having these views). Moreover, there are some long-time users on this board that have nothing else to do as to contradict people like me to the sense we have no idea what we are talking about, because Eagle is the best that could happen to the CAD world, and we better read the manual, etc. etc.

I can only say that if CadSoft wants to get over the current Eagle's status of software for hobbyists, they should really re-think their strategy. They can say ok, we have a certain number of loyal users and that's it, so we develop our software only for them; or they can stride towards greater market share. If they continue doing things as they do, I doubt they will survive for long. The problem is that most new users evaluating the software are  rapidly discouraged by its non-standard interface. And I find it's a pity, because Eagle has several compelling advantages: it is robust (doesn't crash), it is multi-platform (the latter can't be said for most of the CAD software out there) and not expensive.

I disagree with your comment that if the price is low, the user interface can be bull-***. Writing a good and productive user interface is not a question of cost, because one needs essentially the same time and resources to write a good or a poor UI. I would expect advanced features like RF trace matching, advanced routing, 3D support, etc. to be missing from a somehow lower priced product.

Back to my original issue, I didn't manage to test your suggestions, as this is a project I am not doing for my employer, it's a consultancy job I do in my spare time. It seems however, that without the command line there is no efficient solution, which doesn't really speak for Eagle's UI. The workflow for the task I described must be straightforward, and it really is on most other CAD programs.

Lix Paulian wrote:

 

If you say you work with PADS, just don't tell me that their approach of doing this compares negatively with Eagle's approach. In PADS I would do it much, much faster.

Please remember this is a community forum, people here try to help just because they can. I understand your frustrations with trying to work on something and not being able to get the tools to do what you'd like but it won't help you solve your issues if that frustration influences the way to speak to the very people you are asking for help.

So, yes I do work with PADS, some aspects of it are great, others not so. In general it is better than EAGLE but then it costs 10x the amount so I would expect it to be. In this particular instance I personally don't find DxDesigner (I don't use the PADS schematic editor, only PADS layout) any better for me for how I like to draw my schematics. In fact the schematic editor isn't really where EAGLE falls down in comparison the other packages in my opinion with the exception of the implementation of hierarchy which they need to fix properly, but I believe they are working on that.

That said, EAGLE isn't perfect in other respects and in re-reading my previous comment I realised you'd have to be a little more explicit in the names of the bus contents, for example take the USART example I gave, you'd need to ensure that bus definitions of USART1, USART2 etc had unique contents as the bus contents are what ties things together and don't use the bus name as a prefix so bear that in mind. I think this is something CADSoft should improve on by allowing the bus name to auto prefix in these situations so the internal signal names would become USART1_CK, USART1_CTS etc...

Lix Paulian wrote:

 

Your example is a typical case where I wouldn't want to clutter the schematic diagram with busses and wires. Moreover I don't really see the difference between having nets going in and out of a bus, or being marked directly at their origins (at the device's pins). And I mean this both from how the schematic diagram looks, as well as from the way you handle this in Eagle. It takes the same amount of time.

The bus can just be short piece to give a visual grouping to related things and to add a textual label to help see what it's related to. It doesn't necessarily have to go anywhere in fact lets take my example of an FPGA and a CPU, both of which may have lets say at least 8 symbol sections each. So I may want to connect a memory bus from the CPU to the FPGA and these symbol parts from each device would likely be on different sheets. I'd create the bus with the appropriate content on the CPU sheet next to the CPU memory bus symbol section. I'd then simply wire from the CPU pins to the bus and select the appropriate wire name from the menu that popped up. I'd then do the same on the FPGA sheet for the FPGA bank I had ear marked for the CPU bus interface. Now, all the nets will have names so they are connected. As you'll have used the same command to create the bus on both sheets you can be assured there are no typos preventing nets connecting.

Lix Paulian wrote:

 

I have a question though, quote:

 

"Example: type bus SPI:!CS,CLK,MOSI,MISO<return> and then draw your bus. Then when you wire to it all the individual names of the SPI bus wires are available to select. You can easily add labels for clarity too."

 

The last sentence ("You can easily add labels for clarity too") implies this is optional. Then how does Eagle know what pin of the SPI goes to what net? And if this is not optional, then how is this efficient? I mean I still need to go several passes in order to connect two nodes!?

My comment about adding labels was purely a visual thing to help see quickly what is connected and to aid error checking, the nets will be connected without this step and they will have names, just not any visible label. It's very quick to add labels, just type label<return> and clickety click all the way down the wires to the bus placing all the labels (whose names are automatically taken from the wire name) and your done, less than a minute to do a CPU bus I reckon.

Your example is a typical case where I wouldn't want to clutter the schematic diagram with busses and wires. Moreover I don't really see the difference between having nets going in and out of a bus, or being marked directly at their origins (at the device's pins). And I mean this both from how the schematic diagram looks, as well as from the way you handle this in Eagle. It takes the same amount of time.

If you say you work with PADS, just don't tell me that their approach of doing this compares negatively with Eagle's approach. In PADS I would do it much, much faster.

I have a question though, quote:

"Example: type bus SPI:!CS,CLK,MOSI,MISO<return> and then draw your bus. Then when you wire to it all the individual names of the SPI bus wires are available to select. You can easily add labels for clarity too."

The last sentence ("You can easily add labels for clarity too") implies this is optional. Then how does Eagle know what pin of the SPI goes to what net? And if this is not optional, then how is this efficient? I mean I still need to go several passes in order to connect two nodes!?

Anyway, I will try this later, I don't have Eagle at hand now.

"There actually is a solution that would provide nets with names in the manner you describe that would take 15 minutes max for 100 nets, but I'm not sure I'd like to discuss further given the negativity when someone has tried to help you."

That means I was a bad boy and I don't deserve a cake...

Well, I am truly interested in a solution. I simply said that what you offered doesn't solve the issue. I am simply frustrated that for such a trivial problem (connect the pins of various devices on a schematic diagram) Eagle seems to me totally unproductive.

Lix Paulian wrote:

 

Who would use busses nowadays? To avoid clutter, modern schematics do away with wires and buses.

Really? So if I have a 1000+ pin FPGA connected to a 1000+ pin CPU, with literally hundreds of connections between them, if I want to see where one connects to the other I have to go reading all the net names until I find the one I want? That's not efficient either, especially when just looking at the schematics when printed or in PDF form on a machine in the lab. Busses and wires are there to help visualise the connections in a schematic so you can see at a glance where things are going.

You can use busses and still split them up so they don't have to run all around pages if that makes things easier, they will still connect by name reference, in fact with large designs with devices split across multiple pages this is essential as it would be impossible otherwise. And you can create busses with arbitrary internal signal names really easily so all of your small interfaces like SPI etc can be easily accommodated.

Example: type bus SPI:!CS,CLK,MOSI,MISO<return> and then draw your bus. Then when you wire to it all the individual names of the SPI bus wires are available to select. You can easily add labels for clarity too.

Example: type bus USART1:CK,CTS,RTS,TX,RX<return> and then draw your bus.... etc. Now press up arrow and change USART1 to USART2, press <return> and repeat... again for USART3.

Example: Now lets say you have a processor with a DDR3 interface. bus DDR_DATA:DQ[0..15],UDQS_P,UDQS_N,LDQS_P,LDQS_N<return> and again draw your bus. Now when you wire to it you can see the DQ bus and a sub menu with all its options as well as your DQS signals. Repeat for all the address and control portions of the interface, or put them all into a single bus bundle if you prefer.

None of this is hard and can be found quite quickly in the help. I suspect you disregarded this simple way of doing things because of your rather odd notion about busses.

EAGLE isn't perfect, there are many things that make using it less than optimal at times but this isn't one of them. I use DxDesigner and PADS layout a lot too and have used Mentor Graphics products like Design Architect and Board Architect as well as OrCAD in the past. They all have their flaws and are all as you say at least 10x more than the cost of EAGLE. You always have the options to spend 10x more if you dislike EAGLE so much....

Rachael

Lix Paulian wrote:

 

You must be kidding with your 10 minutes

I don't joke about such things : ) I wouldn't state a number if the procedure I mentioned was slower than that. Still if it doesn't suit your needs then we should move on.

There actually is a solution that would provide nets with names in the manner you describe that would take 15 minutes max for 100 nets, but I'm not sure I'd like to discuss further given the negativity when someone has tried to help you.