Project files management (was Re: Welcome)

Tue Apr 21 15:35:49 CEST 2009

On Tue, Apr 21, 2009 at 1:39 PM, Lothar Behrens
<lothar.behrens at lollisoft.de> wrote:
>
> Am 20.04.2009 um 20:50 schrieb Werner Almesberger:
>
>> Lothar Behrens wrote:
>>>> 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.
>>
>> I was just thinking of what sort of mess it would leave in the
>> SCM. If the files are text, the effect of most changes would be
>> relatively small and wouldn't put an undue burden on the SCM.
>>
>
> Heh they are propably commitable as text files, but not tested I
> think :-)
>
>
>>> It was about sorting the nets and the parts and pint out which parts
>>> then are on different nets. It saved the project :-)
>>
>> Heh :-) Such a script to compare two netlists for equivalence
>> would indeed be useful. E.g., when someone sends a patch you
>> can't or don't want to apply automatically, you could still
>> verify that, in the end, all the manual changes yield the same
>> result.
>>
>
> It was a concrete application using MFC classes, but console only.
>
>> That would be similar to "diff without the whitespace changes."
>>
>> But also a way to compare two files for identity and to highlight
>> the changes would be useful.
>>
>
> That was it for, highlight the nets and components, that were
> different, missing on left / right and the like.
> The rest was hand made job to correct exactly that nets and parts. The
> problem happened because one
> has send a FAX !!! to communicate changes.
>
> The result was the pain that there was no way to compare.
>
>>> 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.
>>
>> Hmm, four layers perhaps ? Layer "before", layer "after", layer
>> "removed" (present in "before" but no identical copy exists in
>> "after"), and one layer "added". If one could toggle layers from
>> color to grey/invisible, that should be sufficient for visually
>> finding all the changes. If items in each layer can be deleted,
>> it would even be possible to check off the changes one by one.
>> Add an "items in this layer" count to know when you're done.
>>
>
> I also mean the schematic to be compared by a visual compare with an
> overblending of the old compared to the new.
> Using an offset also helps finding removed or added parts, because
> there are missing these doubly painted sysmbols.
>
> It is like you unfocus on the picture, you will see it doubly :-)
>
>>> KICAD supports subsheets, so these may be 'modules'.
>>
>> And they go into separate files already. Cool, problem solved :-)
>>
>>> 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)
>>
>> That would new code, right ? In general, I find that KiCad lacks
>> the ability to merge "boards" into larger structures, e.g., to
>> make panels. By introducing an object that is a - possibly
>> recursive - "live" reference, we could have something that serves
>> both purposes.
>>
>> Properly separating the netlists would be a little harder, but
>> then, if one runs the DRC only at the level where everything
>> should come together, that's probably good enough to get started.
>> (You'd see other people's mistakes, but that's not so different
>> from compiling programs ;-)
>>
>> Getting new items from the netlist would be messy if we don't
>> have a means to separate netlists. But perhaps solving that can
>> be deferred until a "phase two", and one would either add new
>> things manually or get the whole rabble, pick the one one really
>> wants, and delete the rest. Some sort of external tool could also
>> help.
>>
>>> 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 :-)
>>
>> Yeah, I think some visual helps are indispensable for normal
>> work. But it's good to have an easy access to the internals if
>> necessary.
>>
>>> The Lines do not seem having an ID that also is used in 'connections'
>>> from line to pin.
>>
>> That would again be needed for a test for equivalence. A visual
>> comprison could do without it.
>>
>>> 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.
>>
>> Hmm, I'm somewhat sceptical about the concept of "joint editing".
>> I think distributed editing with tools that help to merge the
>> result would go a long way. You can do the "locking" on IRC :-)
>>
>> Instead of a patch, you would just send the resulting file in one
>> way or another. That's the fallback mode for code as well, if
>> someone sends you something cryptic that doesn't seem to fit
>> anywhere. Bandwidth is cheap :-)
>>
>> So ... seems that all that's needed to make KiCad better for
>> collaborative development would be:
>>
>> - a "diff" mode for eeschema and pcbnew that shows the content of
>>  two files in four views ("a", "b", "a-b", and "b-a"), with ERC,
>>  netlists, etc., only being done on either the current view or
>>  just "b".
>>
>> - a new object for pcbnew that acts as a "live link" for other
>>  .brd files and just merges whatever is in them into the current
>>  board, with the appropriate offset.
>>
>> Still looks feasible ;-)
>>
>
> Usually experts state that CAD files or similar stuff has to be at
> least in BLOBS to speed up the loading
> of a sheet or board.
>
> Another idea would be logging the changes - writing the undo stack to
> the database and keep version before linked
> with the undo stack against the new version, thus you have a
> transaction log from version to version.
>
> What I mean with a central storage is the avoidance to post files
> around, because this leads to the following problem:
> What was the actual or correct file, I have four?
>
> BTW I have posted a question about success stories using KICAD for
> high integration projects (using FBGA howsings).
> http://tech.groups.yahoo.com/group/kicad-users/
I didn't know that group list. I'm going to take a look.
>
> The topic is 'KICAD success stories ?' and it would be interesting.
> One told me they are using SVN. One is about up to 1.3 GHz frequencies
> in a Vector analyser.
>
> But untill now only up to 6 layers. So I'll look forward and wait :-)
>
> What about creating the SOC 2442, NAND / NOR chips and related as a
> sample and try to create a small test project using 8 layers to create
> a prototyping board?
Well, i'd like to start some experiments. Some of us could start with
KiCAD, or gEDA, and post some "ussability".

>
> It doesn't need to be ready for real usage, but to see if the
> development cycle up to a prototyping firm could be done.
>
> Beside of all this stuff: Is there an option for an FPGA to add custom
> logic to the phone?
> There are Linux based prototyping boards that are having / based on
> FPGA chips. Except the size of these chips I saw, if they are
> available as
> smaller versions, they may fit into the phone. This is nothing for the
> mass market, but for custom appliances in the industry :-)
It will be wonderfull to have a FPGA, i think that this is related to
the wishlist of GNURadio integration desired by Steve & Joerg in other
e-mail: http://lists.openmoko.org/pipermail/gta03/2009-April/000068.html
>
> Stupid idea, right? :-)
>
> Lothar
>
>> - Werner
>>
>
> -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de
> Lothar Behrens
> Heinrich-Scheufelen-Platz 2
> 73252 Lenningen
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Gta03 mailing list
> Gta03 at lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/gta03
>


-- 
___________
Rafael Campos
o0 Methril 0o
http://openblog.methril.net/