gEDA-user: Support for heterogeneous symbols?
Hi All, I am evaluating gEDA and came across one feature I am extensively using today with a commercial EDA tool when dealing with large components, like SOC, FPGAs and ASICs: heterogeneous symbols. I searched the doc, the mailing lists and the Web but could not find how I could create and use such symbols with gschem and gnetlist. As Roger Williams defines it in his post: http://www.geda.seul.org/ mailinglist/geda-dev6/msg3.html Heterogeneous devices are non-identical symbols that represent different parts of the same device for REFDES and layout purposes. They can be tied together by the same 'HETERO=DEVICE1,DEVICE2...' attribute on each device. Typical examples include: - large complex logic devices split between multiple symbols because of space constraints; - multi-function devices split so that each different functional block has its own symbol (relays, for instance); Does gschem support such a way to deal with large devices? If the answer is yes, then how? If the answer is no, then how are people dealing with it? Thanks, _jP ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Zoom without cursor redraw in gschem (make it like PCB?)
Hi, Does anyone know if there is a setting in gschem to prevent the cursor being redrawn to the middle of the screen upon zooming in or out? I'm sorry if this has been dealt with before, I googled to no avail. My problem is that I use synergy (synergy2.sourceforge.net), a program for sharing the mouse and keyboard between multiple machines. I happily move my cursor off the right side of my PC screen and it smoothly moves into my laptop screen from the left. My laptop is where I have gEDA tools installed, and I use the keyboard and mouse connected to my PC to work within it. But because synergy only knows an absolute position of the mouse on the client screen, after a zoom the mouse is redrawn in the centre of the screen by gschem, only to be pinged back to it's original position by synergy. I have used synergy for a long time, and this is the first app to have a problem with it! Another situation where gschem's zooming behaviour causes a problem is when using it with graphics tablet or tablet pc (drawing schematics and PCB layouts on a tablet pc is very nice!), because of course the cursor is controlled by a stylus and therefore can't be relocated to the centre of the screen. I'm guessing that this behaviour has been designed to allow the cursor to be moved over a particular point which can then be zoomed into by as much as required, zooming into and out from this point. However other programs (PCB for example) achieve this more elegantly without ripping the cursor up from it's current position. Any advice welcome. thanks, Justyn ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Support for heterogeneous symbols?
Yes, gschem supports heterogeneous symbols. Just set refdes (u101) the same for all parts of the same device. Further, if you'd like to have different labels for different symbol parts you can append lower case characters which are ignored by everything but are there for user convenience. (U101a, U101b, U101ioports, U53power, etc) -Lares On Thu, 8 Feb 2007 15:13:52 +0100 fricker [EMAIL PROTECTED] wrote: Hi All, I am evaluating gEDA and came across one feature I am extensively using today with a commercial EDA tool when dealing with large components, like SOC, FPGAs and ASICs: heterogeneous symbols. I searched the doc, the mailing lists and the Web but could not find how I could create and use such symbols with gschem and gnetlist. As Roger Williams defines it in his post: http://www.geda.seul.org/ mailinglist/geda-dev6/msg3.html Heterogeneous devices are non-identical symbols that represent different parts of the same device for REFDES and layout purposes. They can be tied together by the same 'HETERO=DEVICE1,DEVICE2...' attribute on each device. Typical examples include: - large complex logic devices split between multiple symbols because of space constraints; - multi-function devices split so that each different functional block has its own symbol (relays, for instance); Does gschem support such a way to deal with large devices? If the answer is yes, then how? If the answer is no, then how are people dealing with it? Thanks, _jP ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user pgpglOcQt2hVM.pgp Description: PGP signature ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Support for heterogeneous symbols?
fricker [EMAIL PROTECTED] wrote: I am evaluating gEDA and came across one feature I am extensively using today with a commercial EDA tool when dealing with large components, like SOC, FPGAs and ASICs: heterogeneous symbols. I searched the doc, the mailing lists and the Web but could not find how I could create and use such symbols with gschem and gnetlist. Ah yes, as the mailing list archives can attest, this was also one of my first questions when I started using gEDA! (No, I've never used any commercial EDA tools because I refuse to use Weendoze or Solaris or whatever other proprietary OS they require, but I've entered the HW eng field from a software background after watching the HW engs I was working with and wanting to do that too. As my work has always been with large microprocessor-based systems, all schematics I've ever seen (for very complex microprocessor-based boards) use lots of heterogeneous symbols.) Does gschem support such a way to deal with large devices? Yes. The schematics for the SDSL board that I've just captured and getting ready to lay out make heavy use of heterogeneous symbols. The MC68302 microprocessor is split into 3 symbols, the SDSL transceiver into 5, and the FLEX10K FPGA also into 5. If the answer is yes, then how? Make separate and independent symbols. Each symbol would cover a subset of the device pins, and each pin would have its correct number, so when this is done right each pin number will appear in exactly one of the symbols. Instantiate all these symbols on your schematic (can be on the same page or different pages of a multipage non-hierarchical schematic, the kind I'm used to) and give the same attributes, particularly the refdes (and the footprint if you attach it at the schematic level rather than in the symbol) to all symbol instances describing parts of the same physical component. HTH and welcome to Free EDA! MS ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Re: dxf?
Igor2 wrote: I'll need to find some way in the HID API to provide interface for the user to run scripts (like tiling scripts). For exporting it's easy, the export dialog is extensible. I think there should be a similar Import interfce and a 3rd one, which I can't find a good name for, to run plugin functions that would not import/export but would change the PCB itself. Of course. I tested some of the first efforts you made. You have a hook in the source code now so you can use the GPMI library, right? To me it seems the import interface is just the idea of the outward acting HID API functions. Once we get the inward acting ones done, they would not have to be just one way... We could call it the external in out interface or some such language. You are wanting a no compile way to hook in -- that's great! Perhaps a c coded plugin could do the interfacing to GPMI? It would not be a very specific plugin, just a presenting of the internal function names so external scripts could use them by name and parameter list as in a subroutine call. Does GPMI convert all the many ways in scripts to define a subroutine call to one form? If so, that one form could be what the scriptio plugin transforms into a HID API function call. I will help some more with testing. I gave DJ's plugin code examples a look, ( * RenumberBlock * Teardrops ), and they are maybe obvious to him, but the c language without comments was opaque to me... I will welcome a script interface. John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Re: dxf?
I will help some more with testing. I gave DJ's plugin code examples a look,
(
* RenumberBlock * Teardrops ), and they are maybe obvious to him, but
the
c language without comments was opaque to me... I will welcome a script
interface.
The only thing you really need to understand is the very last bit:
static HID_Action teardrops_action_list[] = {
{Teardrops, NULL, teardrops,
NULL, NULL}
};
REGISTER_ACTIONS (teardrops_action_list)
void
pcb_plugin_init()
{
register_teardrops_action_list();
}
If you read src/hid.h in pcb's source tree, it tells you all about how
these work. The net result of the above, is to add an action called
Teardrops() to the master action list in pcb. Once you've done that,
it is available to the :command window and the action-script command
line options, and with the lesstif hid, you can bind it to a menu
entry or hotkey.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Re: gEDA: inter page connectors
I googled the mailing lists to find a way to automatically number the inter page connections, i.e. to have the PAGES=? attribute on the page connector symbol being updated post schematic capture. This is a purely visual cross-checking feature I am looking for. Thanks, _jP ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Re: dxf?
On Thu, 8 Feb 2007 [EMAIL PROTECTED] wrote: Igor2 wrote: I'll need to find some way in the HID API to provide interface for the user to run scripts (like tiling scripts). For exporting it's easy, the export dialog is extensible. I think there should be a similar Import interfce and a 3rd one, which I can't find a good name for, to run plugin functions that would not import/export but would change the PCB itself. Of course. I tested some of the first efforts you made. Yeah, I remember (thanx again), that was the pre-plugin ages. Now we have a proper way doing all this. You have a hook in the source code now so you can use the GPMI library, right? To me it seems the import interface is just the idea of the outward acting HID API functions. Once we get the inward acting ones done, they would not have to be just one way... We could call it the external in out interface or some such language. You are wanting a no compile way to hook in -- that's great! Perhaps a c coded plugin could do the interfacing to GPMI? It would not be a very specific plugin, just a presenting of the internal function names so external scripts could use them by name and parameter list as in a subroutine call. Yes, but actually it can be written more in a more elegant way. The plugin needs to be only a thin wrapper that loads GPMI and the specific module for the language you have your script in, then the script itself could load small packges to access internal functions. I planned to have about 6-8 such packages, like one for manipulating the drawing, another related to hid-registering and so on. This means a script doesn't need to load tons of bloat it will never use. Does GPMI convert all the many ways in scripts to define a subroutine call to one form? If so, that one form could be what the scriptio plugin transforms into a HID API function call. GPMI has an unified interface towards the scripts which covers calling package functions from the script (which then can directly call pcb internals) and delivering events to the script(s) (which actually may result in function calls in the script, depending on hwo the script bound the events). All this doesn't need any modification in the host app, if we have the plugin support which we already have. The only thing that needs modifications in PCB itself is the GUI: currently I see no proper solution for displaying simple dialog boxes similar to the exporter. Of course when I write a script for tiling I could pretend that it's an exporter, register an exporting hid but then instead of writing a file just call PCB interlans trough the interfacing packages to modify the layout data, but it would just be an ugly hack :) I will help some more with testing. I gave DJ's plugin code examples a look, ( * RenumberBlock * Teardrops ), and they are maybe obvious to him, but the c language without comments was opaque to me... I will welcome a script interface. Ok, if we can meet on irc this weekend, and we could work out some way to share the tasks. I think togehter we could make it all work in less time. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Re: gEDA: inter page connectors
Hi All, What I meant to ask was: is there a tool (like grenum for refdes=) that can be used to update the page= attribute of the inter page connectors? Thanks, _jP ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: pcb-20070208 snapshot
Hello, I have uploaded a new pcb snapshot to sourceforge. The release notes below don't really do justice to the huge amount of work that harry and DJ both put in between the last snapshot and now. harry implemented polygon clipping which has greatly improved how PCB deals with polygons. Among other things issues with some board houses not fully supporting RS-274-X should not be a problem now. Also islands in polygons created by cutting the polygon with traces are removed and the connectivity checker correctly deals with this case. Just in time for this weekends code sprint! Have fun -Dan Release Notes for PCB snapshot 20070208 - Add polygon clipping code. This is a big change to how polygons are handled. The new code now removes islands and correctly identifies open circuits caused by a trace fully cutting through a polygon. In addition, the RS-274-X output is now simpler and works with some board houses that use older non-conforming sofware. Different styles for thermal reliefs are also now supported as part of the polygon clipper code. - Add support for plugins - Many improvements to the autorouter. - Various improvements to the trace optimizer. - Add a fontmode for editing pcb fonts - Add progress() hook to HID structure - Fix a bug with non-functional windows on some window managers commonly found on OS-X - Add support for controlling pcb via dbus - Fix various bugs which would cause a crash - Add --scale for postscript scaling - Intercept window manager delete events with the GTK gui - Scan the .pcb file for a FileVersion value. This is not written out yet but will be in future versions. - Warn if non-manhattan lines are trying to become pads. - Allow no-solder paste pads to support fiducials - Report in mm or mils as selected by user - Allow reordering of layers - add some more QFN packages - fix building with sun studio c compiler - Made a pcb installation be relocatable. - Convert the m4 libraries to newlib libraries as part of building a distfile. The m4 libraries are still considered the sources and as such are still distributed but this eliminates the need for m4 at runtime for footprints. - Got rid of the pcb wrapper script around pcb-bin. - Remove some old footprints of questionable naming, accuracy, or usefulness. - Get the autosave/backup code working on all GUI's - Fix some drill size rounding in the reports - Changed the backup file name to be derived from the .pcb file name - Added a command line option for DrawGrid - Fix logic for adding new ratlines - Fix gtk grid when board is flipped - Add find and rip-up buttons to the netlist window - Draw plated holes when exporting - Fix some bugs when converting selection to element - Fix build on cygwin - Enhance the win32/build_pcb script used to generate a non-cygwin windows installer. - Make pcb work under non-cygwin windows ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
