Project files management (was Re: Welcome)

[Lothar Behrens]

Am 20.04.2009 um 16:55 schrieb Werner Almesberger:

> Lothar Behrens wrote:
>> The company handled that with a schematics file and board file for
>> each version. Adding those
>> files to a version control system is a nightmare, but I tend to argue
>> to use version control systems.
>
> One advantage of using a text-based format for EDA-specific files
> would be that SVN and friends wouldn't choke on them :-)

At least netlists and BOM's could be used to figure out differences.
If source code is available, even patching netlists would be a way -  
with an additional step of placing
new components on the sheet manually.

In one of my last company at EDA times I even wrote a netlist  
comparator to repair a broken project.
(What happens if two versions goes distinct ways, but have to become  
one again)

It was about sorting the nets and the parts and pint out which parts  
then are on different nets. It saved the project :-)
(Netlists were Eagle 3.5 version netlists I think)

>
>
> You would still need some means to highlight changes in the
> graphical representation, though.

Using an half look through layer for two versions would be a way :-)
Also helpful would be a visual 'offset' to ease spotting of small  
differences.

>
>
>> How do you manage the feedback (subprojects) of schematic changes,
>> when done in different files (copies)?
>
> Hmm, isn't this basically asking for the ability to break down
> a project into components (e.g., for the schematics, per sheet)
> that live in separate files ?

KICAD supports subsheets, so these may be 'modules'.

Using a virtual PCB ontop of another PCB may also be a module.
(System on a module, but board would be the same at the end)

If we look at the phone, we see some kind of 'modules' even they are
metal cases around some parts.

The only problem is to 'mary' the two boards into one physical.

Another way for modularity would be a board that has 'holes' in the  
inner of some
'pins' for the 'module'. But this makes placing parts on both sides on  
the module obsolete.
It will be too high.

>
>
> This doesn't sound impossible to do.

The KICAD sch and brd files are at least plain text. But it will be  
hard to 'understand' the differences if you are
not a 'crack' or a KICAD programmer. (I am not that crack :-)

But patching the plain files would be a night mare, because I think  
there are relations to 'text regions'.
Or simply - multiline plain text datasets.

Sample:

EESchema Schematic File Version 2
LIBS:power,device,transistors,conn,linear,regul,74xx,cmos4000,adc- 
dac 
,memory 
,xilinx 
,special 
,microcontrollers 
,dsp 
,microchip 
,analog_switches,motorola,texas,intel,audio,interface,digital- 
audio,philips,display,cypress,siliconi,contrib,valves,. 
\pic_programmer.cache
EELAYER 23  0
EELAYER END
$Descr A4 11700 8267
Sheet 1 2
Title "JDM - COM84 PIC Programmer with 13V DC/DC converter"
Date "15 apr 2008"
Rev "2"
Comp "KiCad"
Comment1 ""
Comment2 ""
Comment3 ""
Comment4 ""
$EndDescr
Wire Wire Line
	4850 4750 4850 5100
Wire Wire Line
	5700 1250 6100 1250
Wire Wire Line
	5700 1250 5700 1200
Connection ~ 8650 3200
Wire Wire Line

...

$Comp
L C C9
U 1 1 464AD280
P 5700 1000
F 0 "C9" H 5750 1100 50  0000 L C
F 1 "22OnF" H 5750 900 50  0000 L C
	1    5700 1000
	1    0    0    -1
$EndComp
$Comp
L VCC #PWR01
U 1 1 4639BB04
P 8650 2550
F 0 "#PWR01" H 8650 2650 30  0001 C C
F 1 "VCC" H 8650 2650 30  0000 C C
	1    8650 2550
	1    0    0    -1
$EndComp


...

$Sheet
S 9200 2850 1600 1750
U 4804A5E2
F0 "pic_sockets.sch" 60
F1 "pic_sockets.sch" 60
F2 "VPP-MCLR" I L 9200 3500 60
F3 "CLOCK-RB6" I L 9200 4150 60
F4 "DATA-RB7" I L 9200 3850 60
F5 "VCC_PIC" I L 9200 3200 60
$EndSheet
Text Label 1850 3800 0    60   ~
DTR
Text Label 1850 3700 0    60   ~
CTS
Text Label 1850 3600 0    60   ~
TXD
Text Label 1850 3500 0    60   ~
RTS
Text Notes 850  6500 0    60   ~
8 to 15V
NoConn ~ 6650 5750

So I do not understand all these content after a quick look. I  
wouldn't patch these files :-(

The Lines do not seem having an ID that also is used in 'connections'  
from line to pin.
(This would propably invalidate the patching, because it seems to  
'make' connections based on coordinates)

It would be better, if the EDA tool stores the 'project' in a  
database. Then a team could work on the same a little better.
(What I am trying with my project, but the project / model is a  
description of a database application - not EDA)

Also an option would be a XML format.

Lothar

>
>
> - Werner
>

-- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de
Lothar Behrens
Heinrich-Scheufelen-Platz 2
73252 Lenningen