Projektstruktur

Hallo,

da meine Elektronikprojekte immer größer und umfangreicher werden und sich auch zeitlich manchmal sehr strecken wollte ich mir mal ein paar Anregungen über eure Projektstruktur holen. Im Moment mache ich für jedes Projekt eine eigenes Verzeichnis mit folgendenden Dateien/Unterverzeichnissen:

Datasheet/ Datasheet/inactive/ Gerber/ konzept.txt DDMM/

wobei "DDMM/" jeweils das Datum an dem ich wieder an Schaltplan/ Layout gearbeitet habe und dann die Datei des EAD-Systems und andere die ich änderte zwecks Verlaufssicherheit etc. hineinkopiere.

In die Datei konzept.txt kommt dann laufend alle neuen Gedanken, alle Bauteile die ich ausgewählt habe etc. hinein, so dass es am Ende ein recht großer Haufen an unsortierter Information ist. Insbesondere beim Erstellen der Bestelllisten für die jeweilgen Distributoren habe ich dann so meine Mühe weil ich oft vergessen hatte die genaue Bauteilbezeichnung oder Bestellnummer aufzuschreiben und suche dann doppelt oder dreifach. Das ist was, was mir noch überhaupt nicht gefällt und wo ich nach brauchbaren Alternativen suche. Vielleicht kann ja der eine oder andere mal seine Organisationsstruktur für solche mittelgroßen Projekte vorstellen.

Vielen Dank, Martin L.

Reply to
Martin Laabs
Loading thread data ...

Hi!

Da nimmt man besser gleich eine richtige Versionsverwaltung.. guck' dir z.B. mal subversion (bzw. TortoiseSVN) an. Integriert sich nahtlos in den Explorer und für Repositories in denen man alleine arbeitet braucht man auch keinen Server aufsetzen oder so!

Ideal natürlich, wenn man mit mehreren Leuten zusammenarbeiten möchte, und auch praktisch, wenn man an verschiedenen Rechnern arbeitet.

--
thomas.kindler@gmx.de,
www.bredobrothers.de, www.dohbots.de,
 Click to see the full signature
Reply to
Thomas Kindler

Der Knackpunkt ist hierbei nur, dass ihm SVN in der Aufgabenstellung herzlich wenig bringt, weil es hier um binäre EDA Dateien geht, deren innere Datenbank-Struktur sich SVN nicht erschließt und die sich vorallem nicht per "von dieser Version nehme ich das in ASCII und von der jenes" Konzept wieder zusammenfügen lassen.

Letzeres haben EDA-Daten so an sich, von links das Röhrennetzteil und von rechts doch den 65nm IC im Layout mal eben zusammen- geführt spielt nicht wirklich. Auch kann man das bei Layouts im Gegensatz zu einem Programm nicht mal eben ausprobieren, es gibt zwar einen DRC, aber der finale "sofort-nach-Hardware" Compiler ist (mit Ausnahme von FPGA's) immer noch nicht entwickelt worden ;-)

Martin setzt den BAE ein, da _ist_ die EDA Datei bereits eine Datenbank (mit Objekten und SQL-Anteilen) und da steht auch bei jedem Objekt bereits das Datum der letzten Änderung dabei, sowie zudem, wer was referenziert, soetwas nochmal in eine SVN Datenbank zu quetschen, führt bestenfalls bei der "Qualität" mancher unter SVN liegenden Datenbank (*) zu späterer Unlesbarkeit der EDA-Daten. Einfach ein "copy" der Datei sichert alle relevanten Daten weg, inklusive der verwendeten Bibliotheks- elemente, die auch als lokale Kopie in der Datei stehen, und die sich zudem nachträglich problemlos gegen neue Versionen austauschen lassen, mit DRC.

Wir setzen auch SVN ein, allerdings für _Programm_-Quellcodes. Bei EDA empfiehlt sich wirklich das Aufheben der EDA-Datenbank- Datei oder der wenigen Dateien (falls noch FPGA etc.) - bestenfalls als ZIP - eines wohldefinierten Versionsstandes (z.B. der tatsächlich gefertigten Leiterkarte). Das EDA System hat dann geeignete Werkzeuge, um ggf. verschiedene Versionen per Block-Copy oder Bibliotheksupdate zusammenzuführen.

Gruß Oliver

P.s.: (*) Ich rede z.B. von Berkley, wo Recovery meint, man möge doch bitte Recovery aufrufen ;-/ Ich weiß schon, warum wir im BAE eine Eigenentwicklung einsetzen, bei SVN-Projekten wird regelmäßig ein gesichert guter Stand auch als tar-Archiv abgelegt ...

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
Reply to
Oliver Bartels

Oliver Bartels schrieb:

Ich verwende für Eagle-Layouts auch SVN. Mir geht es dabei garnicht darum dass irgendwo irgendwas zusammengeführt wird, und es arbeiten zu

100% Sicherheit auch keine 2 Leute am selben Layout - in der Firma gibts keinen anderen der Layouts macht. Der Sinn ist
  1. eine Versions-History zu haben, falls man mal irgendwann versehentlich das Layout verpfuscht hat und 2. die Daten nicht lokal auf dem Arbeitsrechner zu haben, da der garnicht die Datensicherheit garantieren kann, die man benötigt.

Mfg Thomas Pototschnig

Reply to
Thomas Pototschnig

Hauptgrund für eine Versionsverwaltung (insbesondere bei Einmann- Projekten) ist für mich nicht unbedingt das Mergen, sondern die Projekt-History und die Möglichkeit, Marken und Kommentare zu setzen.

Das Kopieren in yyyymmdd-Ordner skaliert bestenfalls auf eine Handvoll Dateien (wenn man nur an einer der fünf Dateien aktiv arbeitet, hat man dann von den anderen vier dutzende Kopien). Außerdem benötigt man viel Disziplin, und darf auf keinen Fall vergessen, vor dem Öffnen der Version 20070728 selbige nach 20070729 zu kopieren. Und mit einer Versionsverwaltung muss man sich nicht von vornherein über das Namens- schema darauf beschränken, maximal eine Version am Tag zu schaffen, und kann bei Bedarf auch mal auf einem Branch experimentieren.

Ich mach allerdings zugegebenermaßen 99% Quellcode mit CVS.

Stefan

Reply to
Stefan Reuther

Naja - wie Oliver schon schrieb. Das EDA-Systeme erzeugt eine (erstaunlich) kleine Datei. Datenblätter und der ganze Rest bleibt ja immer gleich.

Da macht es dann ja auch wieder Sinn.

Viele Grüße, Martin L.

Reply to
Martin Laabs

Der Einsatz von Berzerkely-DB war von vornherein keine gute Idee. Mittlerweile hat Subversion ein eigenes, filesystembasiertes DB-Format FSFS. Alles Erfahrungen nach ist das stabil und zuverlässig, so daß ich die von mir administrierten Subversion-Repositories darauf umgestellt habe. Seitdem gibt es auch keine Probleme mehr mit dem Repository.

Man liest sich, Alex.

--
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison
Reply to
Alexander Schreiber

Martin Laabs schrieb:

Hallo,

ich arbeite gerne mit einem Dokumentenmanagementsystem, früher unter Windows habe ich gerne organice verwendet:

formatting link

Aktuell - unter Linux - verwende besonders gerne KnowledgeTree:

formatting link

Geeignet finde ich ausserdem phprojekt, achievo und tutos:

formatting link
formatting link
formatting link

Für Windows könnte auch noch die Open Workbench interessant sein:

formatting link

Bernd Mayer

Reply to
Bernd Mayer

Aber auch da ist es praktisch, nachschauen zu können, welche Datenblattversion beim Erstellen der Leiterplatte aktuell war :-)

Nun, beim Rest nervt mich die (historisch gewachsene) Nichtnutzung von CVS durchaus signifikant. Das sind dann halt irgenwelche Word-.docs, die per Hand versioniert werden. Und die dann von Word bei jedem Druckvor- gang komplett neu gespeichert werden. Und wo halt gelegentlich die Umbenennung vor dem Bearbeiten vergessen wird, und so Versionsinfor- mationen verloren gehen.

Stefan

Reply to
Stefan Reuther

Ein Grund, auch bei EDA lesbare Formate zu bevorzugen --- Im Zweifelsfall solche, deren Syntax offen gelegt ist.

------

--
Kai-Martin Knaak
http://lilalaser.de/blog
Reply to
Kai-Martin Knaak

Nö: , und zwar Festplatten und Bandbreite, sowie , nämlich Ladezeit ;-)

Du kannst beim BAE schon einen ASCII-Export machen, bei gefüllten Power Planes rate ich aber davon als Arbeitsformat ab, das willst Du nicht wirklich ...

Vorallem ändert das ASCII Format nichts an der Untauglichkeit des SVN für EDA Daten, und die hat einen ganz einfachen Grund, egal ob in ASCII oder binär oder sonstwie:

Programmabläufe sind eindimensional, das sagt schon der Name "Ablauf". EDA Daten sind mehrdimensional.

Das ganze Desaster der eindimensionalen Handhabung von Programmen wird z.B. bei der Multi-Core Programmierung offenbar, während bei einem sequentiellen Programm der "ich nehme die Funktion von dieser und jene von der anderen Version" Ansatz noch funktionieren mag, verkommt er bei echter Multi-Core Programmierung zum Glücksspiel. Weswegen z.B. der Linux Kern immer noch unter der Fuchtel relativ weniger Leute steht, und das ist auch besser so.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
Reply to
Oliver Bartels
  • Oliver Bartels [07-07-29 23:30]:

Multi-Core im Sinne von SMP-tauglich durch Multithreading bzw. mehrere Prozesse? Oder ganz was anderes?

Wobei sich beim Kernel wohl ein Großteil der Patches weitgehend automatisch mergen lässt. Der Vorschlag Subversion oder gar CVS zu verwenden, würde dort allerdings bestenfalls große Heiterkeit auslösen, da deren lineares Versionsmodell nicht wirklich brauchbar ist (für das Kernel-Entwicklungsmodell).

Reply to
Lars Noschinski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.