[Home]History of HalSchematicsUsingGschem

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

Revision 32 . . January 18, 2010 3:41 am by adsl-75-4-36-95.dsl.emhril.sbcglobal.net [refactoring needed]
Revision 31 . . January 17, 2010 6:10 am by adsl-75-4-36-95.dsl.emhril.sbcglobal.net
  

Difference (from prior major revision) (no other diffs)

Changed: 2c2,59

2010 01 156



2010 01 17




I added thread components (base,servo user1,2,3,4)
each with 32 priority outputs
the component is dbl-clicked to edit its speed (u32)
it has 32 numbered pins (prioritized) to connect to functions
(do i need corresponding input pins for and gates et al?)

to test the tool, i created a schematic of 'stepper_mm' from ...configs/stepper
this was to compare the hand generated .hal to the automated .halmost file

the schematics, files, netlists and codes are here

the library goes into /usr/share/gEDA/sym upload:halGEDA.tgz


the schematic can be viewed by loading this file upload:stepper_mm.sch


the schematic looks like this upload:stepper_mm.png


the netlist is here upload:stepper_mm.net


the hal file is here upload:stepper_mm.halmost

the differences between the /config files show what needs to be done...
a) naming conventions need to be constant thru HAL
motionDOTservoDOTlast-period versus motionDASHcommandDASHhandler
(the former shows inheritance the latter is a bastard :P
b) containers must be respected and kept together as much as possible
motmod contains motion and axis
c) division must be used to avoid huge widgets
parport functions occur once for all parports used,
it'd be redundant to have the functions in each parport widget,
so a separate parport-function widget should exist
so:
make a parport-funct widget ( only one instance necessary for 1 thru N parports)
make a parport-pin widget ( one needed for every parport)
keep params for funcs with the func widget,
parport readall time-max belongs with functions
keep params for pins with the pin widget
parport invert & reset belong with pins
there will still be an parport-in-pins and a parport-out-pins widgets.


d)individual halfiles wont result from a single graphic schematic
multiple schematics dont know about other schematics
multiple pages of one schematic may be useful
but nets spread across files would be problematic
(net name in file 1, pins added in file 3&6)
i suppose its just reading all the files in a directory and building lists

it may well be back to the drawing board
esp since its getting more complicated to draw than to just text edit

2010 01 16




LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org
Search:
Published under a Creative Commons License