Ich suche nach einem Schaltplaneditor, mit dem ich einen ATtiny und ein wenig Peripherie in ASCII darstellen kann, um dies in die Beschreibung einer Software einzufügen. AACircuit habe ich gefunden, aber keinen µC in der Datenbank. Gibt es irgendwo aktuelle Datenbänke zum Download oder vielleicht eine Alternative zu AACircuit? Frank
Frank S. schrieb: > Ich suche nach einem Schaltplaneditor, mit dem ich einen ATtiny und ein > wenig Peripherie in ASCII darstellen kann, um dies in die Beschreibung > einer Software einzufügen. Was haben dir die Nutzer deiner Software getan, dass du sie mit 80er-Jahre Graphik aus dem vorigen Jahrhundert quälen möchtest? Einen Spannungsteiler in ASCII-Art darzustellen, mag hier fürs Forum ok sein. Bei allem, was darüber wesentlich hinaus geht, wird es aber schnell grenzwertig.
Auch wenn dies mit Deiner eigentlichen Frage nur am Rande zu tun hast: Solltest Du Dir nicht besser eine Möglichkeit ausdenken, Deine Doku über die Hilfetexte hinausgehen zu lassen? Schaltpläne, mathematische Betrachtungen Deiner Programme, mechanische Komponenten, Bestückungsvarianten, Beschriftung der Bedienelemente etc. sind alles Sachen, die besser in einem separaten Dokument aufgehoben sind. Die Quelltext-Kommentare beschreiben nur noch die konkrete Implementierung des Quelltextes, für die Hardware steht da etwas wie z.B. Hardware siehe MeinBoard Rev. 0.3f. Normalerweise pflege ich für die Doku jedes Projekts ein LaTeX-Dokument nebenher, aber wie die Doku gepflegt wird, kann man ja nach seinem Gusto gestalten. Die Doku für ein Hardware-/Softwareprojekt rein im Quelltext vorzunehmen halte ich für keine gute Idee. Just my 2 Cents. Viele Grüße W.T
http://www.jave.de/ und Andy´s ASCII-Circuit http://www.tech-chat.de/ . Vielleicht hilft auch http://code.google.com/p/freie-schaltzeichen/
Walter T. schrieb: > Normalerweise pflege ich für die Doku jedes Projekts ein LaTeX-Dokument > nebenher, aber wie die Doku gepflegt wird So weit vom Quelltext muss man sich gar nicht weg bewegen. Schon Kommentare direkt im Quelltext entfernen sich leicht genug vom eigentlichen Code. Trotzdem ist die Doku besser im Quelltext aufgehoben, aber auch dann ist es in Fällen von Graphiken wohl eher angezeigt, dort vernünftige Graphikdateien in adäquatem Format einzubinden. Mit Doxygen läßt sich das dann automatisch als vernünftig formatierte Dokumentation extrahieren. https://de.wikipedia.org/wiki/Doxygen
Guten Morgen, als einfache Einstieg in ein CAD Programm sei expresspcb erwähnt: http://www.expresspcb.com/free-cad-software/
Von Doxygen halte ich überhaupt nichts. Es ist schlußendlich ein zwar formalisierter Text, aber eben nur die Zusammenfassung von Funktionsköpfen. Eine echte Dokumentation ist so etwas ganz und gar nicht. Dem TO sei hier angeraten, als Dokumentation eine PDF Datei dem Programm mitzugeben. PDF kann heutzutage jeder lesen - und auch jeder schreiben (siehe FreePDF und so). Der Vorteil ist, daß man dort neben der besseren Textformatierung auch Bilder, Grafiken, Formeln haben kann und daß es eben (mal wieder) nur eine einzige Datei ist, die alles enthält - und genau das wird für eine ordentliche Dokumentation gebraucht. Alles andere ist Krampf. W.S.
W.S. schrieb: > Dem TO sei hier angeraten, als Dokumentation eine PDF Datei dem Programm > mitzugeben. Und die kann man am besten mit Doxygen erzeugen. > daß man dort neben der besseren > Textformatierung auch Bilder, Grafiken Ja, auch das geht mit Doxygen. > Formeln haben kann Und das ebenfalls.
Bernd K. schrieb: > Und die kann man am besten mit Doxygen erzeugen. Oder mit LaTeX. Oder dem Office-Programm der Wahl. Oder Pagemaker. Oder.
W.S. schrieb: > Von Doxygen halte ich überhaupt nichts. Es ist schlußendlich ein zwar > formalisierter Text, aber eben nur die Zusammenfassung von > Funktionsköpfen. Eine echte Dokumentation ist so etwas ganz und gar > nicht. > > Dem TO sei hier angeraten, als Dokumentation eine PDF Datei dem Programm > mitzugeben. Tja, wenn man nichts weiter gemacht hat, als die Option
1 | EXTRACT_ALL=YES |
zu setzen, dann hast du sogar Recht. Woher soll doxygen auch wissen, wofür die Funktion
1 | doSomethingElse
|
gedacht ist. Man muss schon auch sinnvolle Kommentare (vorzugsweise im Quelltext) schreiben und so kennzeichnen, dass doxygen diese zuordnen kann. Dann bekommt man eine Super-Dokumentation, die man unter anderem auch als vollverlinktes PDF ausgeben kann. Sinnvollerweise startet man doxygen direkt mit dem Build, und hat so immer eine aktuele Dokumentation zum Projekt. Ich erstelle sogar meine Online-Hilfe (CHM-Datei) und Benutzerhandbücher (PDF) mit doxygen, beides aus dem gleichen Roh-Text, und alles zusammen (Anwendung, Online-Hilfe, Handbuch und Entwicklerdoku) immer in einem Rutsch. - Ein definierter Prozess, einfacher kann man es sich wohl kaum machen. Ach und: Bilder einbinden ist easy, und auch Grafiken sind kein Problem. Doxygen kann das Tool Grahviz ansteuern, und generiert dann klicktbare Graphen, die Zusammenhänge und Abhänigkeiten im Code darstellen. Das ist einfach nur genial, und man sollte es zuerst mal richtig ausprobieren, bevor man meckert und schlechtredet. ;-)
:
Bearbeitet durch User
Walter T. schrieb: > Bernd K. schrieb: >> Und die kann man am besten mit Doxygen erzeugen. > > Oder mit LaTeX. Oder dem Office-Programm der Wahl. Oder Pagemaker. Oder. Klar. Kann man alles machen. Man kann auch neben dem Fahrrad her rennen, statt aufzusteigen. ;-)
Michael L. schrieb: > Das ist > einfach nur genial, und man sollte es zuerst mal richtig ausprobieren, > bevor man meckert und schlechtredet. Es ist überhaupt nicht genial, sondern nur überflüssig. Wer glaubt, aus dem Extrakt von Prototypen und Kommentaren zu irgend einer Programmquelle bereits eine taugliche Dokumentation eines Programmes erzeugt zu haben, hat GARNICHTS verstanden. Von der Doku zu einer Baugruppe - wie hier mit Stromlaufplan - ganz zu schweigen. Eigentlich sollten (jedenfalls bei C) die betreffenden Headerdateien die Quellen der Information sein, wenn es um konkretes Nachschauen zu Details von Funktionsaufrufen etc. geht. Eine Dokumentation enthält grundsätzlich andersartige Informationen: Einführung in die Thematik, Funktionsprinzipien, Benutzungshinweise, Theorie soweit erforderlich, Diagramme zu Meßergebnissen, Grenzwerte, Anwendungsbereiche, Anleitung zur Benutzung und so weiter. Ein läppisches Exzerpt aus irgendwelchen Quellen ist hingegen blanke Scheuklappe. Soviel zu Doxygen. W.S.
Frank S. schrieb: > AACircuit habe ich gefunden, aber keinen µC in der Datenbank. So schlimm ist das doch nicht. Mal den µC eben von Hand in AACircuit. Da die Pins sowieso bei jedem Projekt anders genutzt werden, ist ein festes Symbol nur von Nachteil. Für die kleine 8-Pinner ist das doch kein Aufwand. Für größere µCs würde ich schon ein richtiges Schaltbild mit Eagle o.ä. in einem PDF zum Projekt packen. Walter T. schrieb: > Solltest Du Dir nicht besser eine Möglichkeit ausdenken, Deine Doku über > die Hilfetexte hinausgehen zu lassen? Schaltpläne, mathematische > Betrachtungen Deiner Programme, mechanische Komponenten, > Bestückungsvarianten, Beschriftung der Bedienelemente etc. sind alles > Sachen, die besser in einem separaten Dokument aufgehoben sind. Das ist schon richtig und für z.B. Kundenprojekte sowieso gefordert. Aber wenn ich eine kleine Tiny-Schaltung habe und für mich selber dokumentiere (so dass ich die Pinbelegung nicht jedes Mal aus dem Quellcode extrahieren muss), reicht die ASCII-Art als Kommentar doch völlig aus. Wie z.B. hier:
1 | VCC
|
2 | +
|
3 | |
|
4 | .-----------------------o |
5 | | | |
6 | | .----------o---------. |
7 | | | | |
8 | .-. | | SSR out |
9 | | | | (5) PB0 o---------o |
10 | | | NTC | | |
11 | '-' 10k | | |
12 | | | | |
13 | .----o------------o ADC2 PB4 (3) | VCC |
14 | | | | | + |
15 | | .-. | | | |
16 | | | |10k | | .-. |
17 | | | |R1 | | | | |
18 | | '-' | | | |10k |
19 | | | | | '-' |
20 | | | | | | |
21 | C1 --- o-|| | (1) RES o-----o |
22 | 10n --- ->|| | | | |
23 | | +-||---------o PB1 (6) | --- |
24 | | | | | --- 100n |
25 | | | '---------o----------' | |
26 | | | | | |
27 | === === === === |
28 | GND GND GND GND |
Danke für die vielen Vorschläge, die zumeist auf etwas umfangreichere und/oder professionellere Projekte abzielen. Da ich relativ talentfrei "programmiere", gehen meine Programme nicht wesentlich über eine Hand voll einfacher Zeilen hinaus. Diese schreibe ich dann auch noch in der (für mich) sehr anwenderfreundlichen Arduino IDE, mit der ich es dann auch gleich auf den ATtiny flashen kann. Über den Programmzeilen schreibe ich meist einen kleinen Kommentar als Gedankenstütze für die angedachte Funktionsweise. In diesem Fall habe ich vor, eine kleine Skizze hinzu zu fügen. Der Vorschlag von HildeK kommt meiner Idee am nächsten. So werde ich es wohl machen. Frank
W.S. schrieb: > Michael L. schrieb: >> Das ist >> einfach nur genial, und man sollte es zuerst mal richtig ausprobieren, >> bevor man meckert und schlechtredet. > > ... überflüssig ... hat GARNICHTS verstanden. Na wenn du das sagst. - Dann muss es ja stimmen. Dass es in Visual Studio ein zu doxygen vergleichbares Dokumentationskonzept gibt, und auch noch weitere Tools existieren, zeugt natürlich auch nur davon, dass die im Gegensatz zu dir alle keine Ahnung haben. > Von der Doku zu einer > Baugruppe - wie hier mit Stromlaufplan - ganz zu schweigen. Der TO hat ein nettes kleines Mini-Projekt, ("ATtiny und ein wenig Peripherie"), wo man locker alles in eine Datei packen kann. Also ja, Schaltplan als ASCII zum Quelltext. Mag ja sein, dass du dir das nicht vorstellen kannst, aber das ändert nichts daran, dass es diese Anwendungsfälle in der Praxis gibt. > Eigentlich sollten (jedenfalls bei C) die betreffenden Headerdateien die > Quellen der Information sein, wenn es um konkretes Nachschauen zu > Details von Funktionsaufrufen etc. geht. Welch weitreichende Aussage. Wie du selbst bemerkt hast, sind Headerfiles sind nicht unbedingt die Regel. > Eine Dokumentation enthält grundsätzlich andersartige Informationen: > Einführung in die Thematik, Funktionsprinzipien, Benutzungshinweise, > Theorie soweit erforderlich, Diagramme zu Meßergebnissen, Grenzwerte, > Anwendungsbereiche, Anleitung zur Benutzung und so weiter. Ein > läppisches Exzerpt aus irgendwelchen Quellen ist hingegen blanke > Scheuklappe. > > Soviel zu Doxygen. Code-Dokumentation ist ebenso Teil der Dokumentation, auch wenn du das unterschlägst, um deine Argumentation zu stützen. Und um diesen Teil geht es primär bei Doxygen. (Mehr ist machbar.) Ein läppisches mag-ich-nicht ist hingegen blanke Scheuklappe. Soviel zu dir. Zum Glück bin ich nicht auf deine Befindlichkeit angewiesen, und generiere weiter inhaltlich identische Unterlagen mit Bildern, Grafiken etc. als PDF, RTF, HTML und CHM, und das in einem Rutsch. Und während man in Villabajo noch sucht, wo überall in der Doku noch was zu ändern ist, wird in Villariba schon Feierabend gemacht. An den TO: Deine Entscheidung/Vorgehensweise ist vollkommen in Ordnung und angemessen zum (geringen) Umfang deines Projektes.
:
Bearbeitet durch User
Für allgemeine ASCII-Skizzen, wie Flussdiagramme oder UML, eignet sich http://ASCIIflow.com Die alte Version ist hier: http://stable.ascii-flow.appspot.com
Ich mache auch öfter kleine Skizzen in den Quelltext, auch mal eine kleine Beschaltung oder sowas. Meistens nehme ich dafür einfach den Zeichenmodus im EMACS. Aber das Thema erinnert mich daran, daß es doch mal WEB/tangle/weave gab bzw. CWEB/ctangle/cweave. Ist ja eigentlich nicht uninteressant, habe mich aber nie aufgerafft dazu. Ich glaube, das war ein Fehler. http://www.literateprogramming.com/cweb_download.html
Vielen Dank für den Tip zu ASCIIflow.com. Das ist genau das, was ich immer schon mal gesucht habe. Mal eben auf die Schnelle, egal von welchem Rechner solch eine Skizze erstellen können. Für meine aktuelle Problemstellung, eine kleine Skizze über das Programm zu setzten, war es auch recht hilfreich. Frank
Michael L. schrieb: > Na wenn du das sagst. - Dann muss es ja stimmen. > > Dass es in Visual Studio ein zu doxygen vergleichbares > Dokumentationskonzept gibt, und auch noch weitere Tools existieren, > zeugt natürlich auch nur davon, dass die im Gegensatz zu dir alle keine > Ahnung haben. Freilich weiß ich das besser als du. Daß es sowas wie Doxygen überhaupt gibt, liegt daran, daß ganz viele Leute nach Dokumentation lechzen und sie nicht bekommen - weil die werten Autoren sowas entweder nicht können oder nicht wollen. So, mal ein Beispiel: Laß Doxygen mal nen Exzerpt der St-Lib machen und gib das jemandem, der mit den STM32 anfangen will, als Doku zum STM32F40x. Was glaubst du, wie gut der sich anhand derartiger "Doku" in die Technik dieser Cortex M4 einarbeiten kann? He? Nee, wie ich schon schrieb, Dokumentation ist was GANZ ANDERES. W.S.
W.S. schrieb: > Dokumentation ist was GANZ ANDERES. Doxygen macht schön dicke Hefte die man jemandem auf den Tisch knallen kann dem der Inhalt egal ist. Das ist für die Faulen ideal, die nicht dokumentieren wollen. Natürlich sind Doxygen Outputs unbrauchbar.
W.S. schrieb: > Eine echte Dokumentation ist so etwas ganz und gar nicht. Das liegt doch an dir, wieviel und was du alles da rein schreibst. Hast du mit Doxygen überhaupt schon mal mehr gemacht, als das Tool über einen Standard C File zu jagen? W.S. schrieb: > Was glaubst du, wie gut der sich anhand derartiger "Doku" in die Technik > dieser Cortex M4 einarbeiten kann? He? Wenn du in die Doxygen-Kommentare nicht das rein schreibst, was hinten rauskommen soll, darfst du dich nicht wundern. Wenn du z.B. erklärende Worte über die Technik der Cortex M4 unterbringen möchtest, schreibst du das in einen Doxygen-Kommentare-File und bindest den an passender Stelle ein. Von selbst passiert das nicht. Allerdings sollte man Anfängereinführungsbuch und Lib-Dokumentation doch vielleicht besser separat behandeln ;-)
Doxygen hat absolut seine Daseinsberechtigung. Man kann ja auch problemlos seitenweise Dokumentation schreiben, ist also in keiner Weise auf Sourcecode-Kommentare limitiert. Es ist ein geniales cross-referencing Tool, und einfach wunderbar, wenn man mitten im Fliesstext auf eine besprochene Funktion klickt, weil die Beschreibung automatisch direkt verlinkt ist. Klassenhierarchien, include Hierarchien, forward und back referencing, alles vollautomatisch und auf Wunsch grafisch. Natürlich kann man mit Doxygen auch schlechte Dokumentation generieren, aber wenn man sein Köpfchen ein wenig anstrengt, dann ist Doxygen wirklich sehr hilfreich. Hilfreicher als "Wörd" ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.