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.
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.
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 ;-)
> 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.
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.
