Bei embedded Projekten ist es ja so, dass man für die Dokumentation 1.) die Schnittstelle und das Zusammenspiel der Software mit der Hardware darstellen muss. Zusätzlich gibt es ja noch die µC-Peripherie. Außerdem ist oft die Einhaltung bestimmter Timings wichtig. Mir geht es also darum, ein Blockschaltbild von dem Gesamtsystem aus Firmware, µC-Peripherie und externen Hardwarekomponenten komfortabel und zügig zeichnen zu können. Ich habe hier und im Internet schon nach Fertiglösungen oder Lösungsansätzen gesucht - aber nix gefunden! Das kann doch irgendwie nicht sein, ich bin doch nicht der einzige embedded Programmierer? - Kennt jemand Tools, die dafür geeignet sind? - Wie macht ihr die Dokumentation eines embedded-Systems?
Cyblord ---- schrieb: > draw.io - Bietet dieses Programm eine Bibliothek mit µC-Peripherie? - was bietet es mehr als reines Diagramm zeichnen? - wie wird das Zeichnen von Timing-Diagrammen unterstützt? > > MS Visio Ich hatte mal Visio, aber die µC-Peripherie hätte ich mir alles selber zeichnen müssen und Timing-Diagramme wurden gar nicht unterstützt - oder irre ich mich da?
Deine Anforderungen sind Humbug! µC Peripherie? Mach ein Kästchen und schreibe ADC rein. Was willst du denn da mehr? Für mehr Details gibt es Schaltpläne. Für Timing Diagramme gibt es einige spezielle Programme. Alles in einem Programm wirst du nicht finden.
Was spricht gegen Visio? Du kannst dir ja eine Shape-Bibliothek erstellen. Dann hast du die Symbole genau nach deinen Vorstellungen und brauchst sie in Zukunft nur noch per Drag-n-Drop ins Diagramm einbauen...
z.B. bei einem ADC gibt es differentiellen-/singleended-Eingang, Vorverstärker, umschaltbare/wählbare Referenzspannungen/Eingänge, verwendete Samplingrate... Zudem ist es sehr hilfreich die verwendeten Portpins darzustellen. Darstellen möchte ich auch, welcher Peripherieinterrupt welche SW-Routine triggert u.v.m. Bei einem Xmega kann man die interne Peripherie über das Eventsystem miteinander verschalten. Das alles ist für eine Übersicht und für Treiberroutinen doch wichtig - und kein Humbug?
Alexxx schrieb: > z.B. bei einem ADC gibt es differentiellen-/singleended-Eingang, > Vorverstärker, umschaltbare/wählbare Referenzspannungen/Eingänge, > verwendete Samplingrate... Also das geht für eine Skizze oder sonstige Zeichnung einfach zu weit. > Zudem ist es sehr hilfreich die verwendeten Portpins darzustellen. Schaltplan! > Darstellen möchte ich auch, welcher Peripherieinterrupt welche > SW-Routine triggert u.v.m. UML Wobei man hier einfach NICHT übertreiben sollte mit der Doku. > Bei einem Xmega kann man die interne Peripherie über das Eventsystem > miteinander verschalten. > > Das alles ist für eine Übersicht und für Treiberroutinen doch wichtig - > und kein Humbug? Man kann einfach kein komplettes Embedded System mit jedem HW und SW Detail in EINER Zeichnung festhalten.
@Martin: Ja Visio wäre eine Möglichkeit, habe aber bis jetzt noch keine Ahnung von Erstellung einer Shape-Bibliothek und Timing-Diagramme gehen damit gar nicht(?) Außerdem hätte ich mir halt gewünscht, nicht jedes Element selber zeichnen zu müssen.
Die Software eines Mikrocontrollers dokumentiere ich für gewöhnlich mit Doxygen. Hier lassen sich auch rudimentäre Blockschaltbilder und Flussdiagramme darstellen. Aber die Hardware wird definitiv nicht in der Software-Doku dokumentiert. Hardware und Software sind zwei verschiedene Dokumente. Schlieslich wird ja nicht erwartet, dass ein IT-ler Layouts designen kann, und Layouter Applikationen schreiben kann. Schnittstellen zwischen Hardware und Software machen das natürlich schwierig. Ich packe es gern in die Hardware-Doku, denn da sieht man ja die Pinbelegung des Controllers. Dann packt man eben eine kurze Erklärung zu der Entscheidung mit dazu. (Auf die selbe Weise wie man die Auswahl der Bauteile begründet) Timing Diagramme sehe ich an der Stelle als übertrieben an. Timings zu externen Geräten brauchst du nicht dokumentieren, schließlich haben die schon eine Dokumentation mit den entsprechenden Timings. Gerätenamen angeben und auf dessen Datasheet verweisen. Analoge Timings, wie ADC-Eingänge o.Ä. würde ich nur mit einer Berechnungsvorschrift in der Software-Doku beschreiben. Ein Timing Diagramm kommt dann in den Test Report zur Verifikation.
:
Bearbeitet durch User
Ich mache viel documentationen von pinning, adc-mode, memory-locations usw in Doxygen. Dann kann man im sourcecode als kommentar bestimmte sachen documentieren auf der stelle wo es auch im software gemacht wird, zB das teil meiner code wo pinning settings gemacht wird, da schreibe ich im kommentar die info die wichtig ist. Der Doxygen compiler gibt dann am ende ein document wo alles beieinander steht als pdf oder website. Vorteil ist das man die documentierung automatisch gleich mit software schreiben macht, wenn man das in ein separates document macht ist mein problem das ich das oft vergesse (eigentlich ist mir das zuviel arbeit). Nachteil ist das man sich einmal aussuchen musz was da alles moeglich ist mit Doxygen. Wenn es um timing und so geht gebe ich im docu oft screendumps von oscilloscope, logic analyser oder simulation. Kein problem weil die se docu nur intern benutzt wird.
Cyblord ---- schrieb: > Man kann einfach kein komplettes Embedded System mit jedem HW und SW > Detail in EINER Zeichnung festhalten. Mir geht es nicht um jedes Detail - ich möchte ein Blockschaltbild zeichnen, das 1.) eine Übersicht(nicht mehr!) über die Gesamtfunktionsweise und die Verbindung von Software - Peripherie - externe Hardware darstellen. Wenn SW- und HW-Entwicklung personell getrennt ist, ist nachvollziehbar, dass es keine gemeinsame Doku gibt, finde ich aber erstaunlich und schade. PS: UML finde ich gerade dafür völlig ungeeignet, da es rein auf objektorientierte Software ausgelegt ist.
Ich entwickle ja ZUERST (das Blockschaltbild, dann) die Hardware, wo ich die Portpinzuordnung und die Auswahl der Periphereiemodule machen muss - und erst dann die Firmware. Mit einem Blockschaltbild, auf dem diese Zuordnung zu sehen ist, erspare ich mir, für die Software wieder im Schaltplan und im µC-Datenblatt nachschauen zu müssen...
Meinst du vieleicht eine Projektbeschreibung? Eine kurze Erläuterung, was das Ziel des Projekts ist, anhand eines Blockschaltbilds? Das steht eigentlich VOR der Entwicklung fest. Aber auch da sind keine Pins oder Timings zu sehn. Was du hier beschreibst habe ich bisher in noch keiner Doku gesehen.
Alexxx schrieb: > ich möchte ein Blockschaltbild zeichnen, > das 1.) eine Übersicht(nicht mehr!) über die Gesamtfunktionsweise und > die Verbindung von Software - Peripherie - externe Hardware darstellen. Na dann mach das doch. Das geht sogar in Microsoft Word. Einfach ein paar Rechtecke, die beschriften, die Verbindungen dazwischen zeichnen, diese ebenfalls beschriften.
Angehängte Dateien:
-
Blockschaltbild.png
19 KB
Mit MS-Word(2013) zu zeichnen finde ich eine Zumutung. Bis jetzt habe ich es mit EAGLE gemacht, da ist es aber viel Aufwand sich ein Blockschaltbild-Device zusammen zu basteln. Dann ist es aber sehr komfortabel. Ich habe halt gehofft, dass es sowas wie UML für embedded gibt...
Alexxx schrieb: > Mit MS-Word(2013) zu zeichnen finde ich eine Zumutung. Daher Visio. Für Blockschaltbilder top. Aber nicht für die von dir gewünschte Detailtiefe. > Bis jetzt habe ich es mit EAGLE gemacht, DAS ist eine Zumutung.
Alexxx schrieb: > Mit MS-Word(2013) zu zeichnen finde ich eine Zumutung. > > Bis jetzt habe ich es mit EAGLE gemacht, da ist es aber viel Aufwand > sich ein Blockschaltbild-Device zusammen zu basteln. Dann ist es aber > sehr komfortabel. Ich meinte etwas mit weniger Detailgrad. Also quasi sowas, im einfachsten Fall:
1 | +----------+ +----------+ |
2 | | | | | |
3 | | | | | |
4 | | | /---------------------------\ | | |
5 | | Device 1 |< CAN Bus >| Device 2 | |
6 | | | \---------------------------/ | | |
7 | | | | | |
8 | | | | | |
9 | +----------+ +----------+ |
> Ich habe halt gehofft, dass es sowas wie UML für embedded gibt... Selbstverständlich kann man UML-Diagramme auch im Embedded-Bereich verwenden. Das macht man aber eher dann, wenn es bereits um konkrete Details geht. Beispiel: Ein Sequenzdiagramm, welches aufzeigt wie der chronologische Ablauf der Kommunikation zwischen zwei Geräten aussieht. Für eine Übersicht reicht ein stark vereinfachtes Blockdiagramm aus. Da braucht es keine Pinbelegung, kein Timing oder dergleichen. Solche Details sind in anderen Dokumenten festgehalten, auf die man in dem so genannten "Dachdokument" verweist. Von daher ist diese Teil des Anspruchs hier: Alexxx schrieb: > Mir geht es also darum, ein Blockschaltbild von dem Gesamtsystem aus > Firmware, µC-Peripherie und externen Hardwarekomponenten komfortabel > und zügig zeichnen zu können. eher wenig sinnvoll, denn die Firmware taucht in einem Übersichtsbild des Gesamtsystems natürlich nicht auf. Dass traut man dem Gutachter oder sonstigen Leser dann schon zu, dass er weiß dass auf einem Mikrocontroller etc. denn auch Software läuft. Die für sich selbst dokumentiert wird. Böse Zungen behaupten: Bei Software ist es schon eine große Errungenschaft, wenn sie überhaupt dokumentiert wird ;-)
:
Bearbeitet durch User
> UML finde ich gerade dafür völlig ungeeignet, da es rein > auf objektorientierte Software ausgelegt ist. Das ist nicht richtig. UML wird teils dazu verwendet, Software zu generieren oder zu dokumentieren. Das sind aber nur zwei von vielen Anwedungsfällen. Tatsächlich ist UML jedoch nur eine Sprache. Sie legt unter anderem fest, was ein Quadrat und was eine Raute bedeuten, worin der Unterschied zwischen gestrichelten und durchgezogenen Linien besteht und in welche Richtung man Pfeile Zeichnet. Es gibt auch UML basierte Malprogramme nach Visio Art. Enterprise Architect ist ein tolles Tool zur Dokumentation von Produkten und Prozessen - auch (aber nicht nur) Software. Es ist UML basiert, gibt einem in den "Extended xyz" Diagrammen aber auch die Freiheit, die Symbole frei zu verwenden und zu missbrauchen, wie bei Visio. Enterprise Architekt ist was für Leute, die effizient dokumentieren wollen. Für Leute, denen der Fachliche Inhalt wichtiger ist, als die Form.
Angehängte Dateien:
-
uc.PNG
8 KB -
actDrossel.PNG
5,9 KB -
actFreigabe.PNG
7,5 KB -
actBlinken.PNG
6,6 KB -
actBlinkTon.PNG
5,4 KB -
actAnzeige.PNG
7,7 KB -
bdd.PNG
12 KB -
class.PNG
36 KB -
sm.PNG
8,1 KB -
seq1.PNG
1,9 KB -
seq2.PNG
2,3 KB -
seq3.PNG
1,9 KB
als alter SiSy Anwender hab ich mal ein kleine Projekt mit Junior zusammen gemacht und wollte den nicht vorhandenen UML Profi raus hängen lassen ... hat dann sogar richt Spaß gemacht das Ganze mit UML und SysML zu dokumentieren ... dabei hängen die Diagramme alle miteinander zusammen... Anwendungsfälle sind mit Aktivitätsdiagrammen verfeinert ... Methoden des Klassendiagramms sind in den Aktivitätsdiagrammen zum Beispiel referenziert, die Sequenzdiagramme werden aus den Klassenmethoden automatisch generiert usw... na guckt mal selbst ;-) übrigens ist das ganze dann aus dem Klassendiagramm und dem Zustandsdiagramm vollständig generiert läuft auf einem ATmega328P bei 20MHz seit fast einem Jahr super und zuverlässig... nen UML Profi wird vielleicht drüber schmunzeln aber Junior und ich waren ganz Stolz drauf lg J.R.B. PS: bei den Sequenzdiagrammen hab ich nur ne Auswahl dran gehängt ... sind zu viele da die komplett aus den einzelnen Codesequenzen vom Tool generiert werden:-(
Cyblord ---- schrieb: > draw.io > > MS Visio Du arbeitest im Konzern oder? Hauptsache alles in Visio, Word oder Excel reinklatschen, egal ob die Tools dafür geeignet sind oder nicht. Meine Highlights: Pseudocode in Word, sogar mit Einrückung Schaltplan in Excel, mit 1 Zelle = 1 Pixel
Schermi schrieb: > Cyblord ---- schrieb: >> draw.io >> >> MS Visio > > Du arbeitest im Konzern oder? > Hauptsache alles in Visio, Word oder Excel reinklatschen, egal ob die > Tools dafür geeignet sind oder nicht. Und arbeitest du überhaupt? Hört sich nicht danach an. Eher nach Pseudo Nerd der Linux-Pickel Fraktion. Von Word und Excel sprach ich auch überhaupt nicht. Visio ist genau dafür da um zu VISUALISIEREN. Nomen est omen. Das geht auch recht gut. Da du ansonsten nur von Word und Excel schwadronierst, denke ich mal, du kennst Visio gar nicht.
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.