On 10/29/2011 12:35 AM, Kirk Wallace wrote:
> On Fri, 2011-10-28 at 21:54 -0400, Kent A. Reed wrote:
> ... snip
>> OK, Kirk. I grep'ped the attribute names from all the symbols in the hal
>> library. Not counting misspellings, there appear to be either 13 or 14
>> unique names:
>>
>> ...
> I only looked at a few symbols and it looked like author, comment and
> device at least where given hal keyword values instead of schematic
> features. I suspect they were borrowed to get a schematic to .hal file
> utility working. If that is the case I would like to learn how it works
> and incorporate these. I don't really need the utility because I think I
> would most likely end up needing to edit the .hal files anyway. What I
> really would like is to be able to move the symbols and have the
> connections stay connected. I am looking at gEDA because I have already
> tried using it for circuit layout. I suppose any graphic utility that
> can maintain connections between objects would do what I need.
Yes, but I believe gEDA is a rational choice for several reasons. It is
probably the best available open source program for this kind of
schematic design and it has a strictly ascii file format that is easy to
parse and reuse. You may not want to use the gEDA and Python scripts for
building a partial hal file now, but you may in future. It's not that I
don't like this software suite. I actually think well of it. It's that I
don't like the task of technical drafting ;-)
Here's how I believe the original author meant the attributes to be used
(who was it by the way? I call him/her adsl in the following, after the
IP address reported at the bottom of the page). "gEDA" means the
attribute is defined in the gEDA master attribute list.
author (gEDA) - redefined by adsl to indicate hal data type: bit, float,
u32, s32
comment (gEDA) - redefined by adsl to indicate hal pin/param/funct
description (gEDA) - redefined by adsl to indicate hal r/w/rw
device (gEDA) - redefined by adsl to indicate hal component or thread name
hal-data-type - apparently adsl meant to define a set of hal
attributes but these are hardly used
hal-param-datatype - perhaps there were scripts being planned that would
use these hal-xxx attributes
hal-pin-datatype - I think cleanly defining hal attributes was the
right approach; don't know why it wasn't continued
pinlabel (gEDA) - adsl seems to force pinlabel and pinnumber both to
hold the hal pin name
pinnumber (gEDA)
pinseq (gEDA) - pretty much the same in gEDA and this work; a unique
numbering of pins in a component
pintype (gEDA) - pretty much the same in gEDA and this work; values are
in, out, io
refdes (gEDA) - somewhat redefined by adsl to indicate the component or
the thread name
value (gEDA) - pretty much the same in both works
I note that values in the device and refdes attributes differ slightly,
for example for the and2 component, device=and2 and refdes=and2.?
I also note there are a number of inconsistencies in the library. For
example, author=out ("out" is not a data type). pintype=.out (should
have no "."), pintype=i0 (should be "o", not "0"), etc.
> I think I'll go ahead and start on the rest of the HAL symbols and leave
> the non-essential attributes off. It should be easy to add them latter
> if needed.
This looks safe enough to me. At this point in the game, I don't see the
need to define a complete set of hal-specific attributes. If the need
arises later, the library can be modified in one fell swoop using a script.
> I can look at Dia too.
I won't tell you not to, but I also won't be surprised if you find it
unsuitable.
>> While perusing the gEDA docs, I discovered the strictly ascii file
>> format borrows from svg to define paths.
> You found this I presume?
> http://geda.seul.org/wiki/geda:file_format_spec
Yes I did, thanks.
>> Hmmm. If I had a decent
>> Manhattan-type autorouter algorithm, I could use Graphviz to do just the
>> component layout, saving the result to its own ascii format, use my own
>> autorouter to lay in the signals (and no, Virginia, Graphviz's new
>> "ortho" spline function can't handle our complexity), do more filtering
>> in Python like I'm already doing, and bring up the result in gschem for
>> you folks who want to manipulate your configurations in a GUI. Hmmm.
>> Where's the coffee.
> Good luck. Please keep us posted.
>
Well, we'll see. No promises. I found two old references on automatic
line routing. Unfortunately, ACM wants me to pay 15 bucks a piece for
an electronic copy of the few relevant pages. I'm not sure if I'm that
motivated. On the one hand, I'm interested in the algorithms. On the
other hand, this is beginning to sound like real programming rather than
a quick-n-dirty gluing together of bits of other people's work.
Regards (and good night!),
Kent
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ now supports Android™ Apps
for the BlackBerry® PlayBook™. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
