innerhalb von Mikrokontrollern habe ich die Chanche innerhalb von sehr kurzer Zeit sehr viel abarbeiten zu lassen. Kommen noch,jenseits des Pollings,geschachtelte Interrups dazu, begreift das Ganze letztendlich nur noch derjenige der das Konzept des dahinterstehenden Programmcodes erstellt hat. Oft ist der Konzeptersteller und der Programmierer ein und dieselbe Person.
Wenn ich jemanden, oder Jemand mir, etwas verständlich machen möchte, das innerhalb einer Mikrokontrollers nach menschlichem ermessen parallel abläuft, wie kann ich das am einfachsten auf einem Blatt Papier darstellen?
Ablaufdiagramm? Petrinetz?
Gibt es dafür ein Patentrezept oder läuft das auf eine Mischung verschiedener Darstellungstechniken heraus?
Sicherlich könnte man den Programmcode durchgehen. Das wird aber sehr schnell sehr ermüdent, Kernprobleme bleiben da oft lange unentdeckt.
Aufruf-Verbindungslinien zwischen Interruptroutinen und normalem Programm gibt es nicht, der Datenaustausch erfolgt über den Speicher, idealerweise übergeben alle Routinen und das Hauptprogramm ihre Daten auch nur an
*einer* Stelle innerhalb ihres Ablaufs. Klassisch ist das eine Event-Hauptschleife, die in einem FIFO ihren nächsten Auftrag abholt. Die Eingabe-Interruptroutinen füllen den FIFO der Hauptschleife mit Eingabedaten auf. Wenn man auch Aufgabe-Interruptroutinen hat, bekommen dieses ebenfalls jeweils einen FIFO, in dem die Hauptschleife Daten zum Raussenden ablegen kann -- dann kann die Hauptschleife in der Zeit mit was anderem weitermachen.
Wenn man es richtig macht, hat man keinen Spaghetticode, der einander wild mit unterschiedlicher Intention aufruft. Wenn man es anders macht, hat man nicht nur ein Problem mit der Visualisierung, sondern meist auch mit der Programmfunktion (daraus wächst dann der Wunsch nach Visualisierung des Geraffels).
"Jan Kandziora" schrieb im Newsbeitrag news:fb4nu9$kjg$ snipped-for-privacy@online.de...
Seh ich aehnlich. Ich hatte noch keine Schwierigkeiten, Code uebersichtlich auf einem Zettel darzustellen, auch wenn es ein Hauptprogramm und eine Handvoll ereignisgesteuerter Interruptroutinen gibt.
Liegt vermutlich einfach daran, dass es von vorneherein sinnvoll strukturierter Code war.
Dann braucht man aber eigentlich keine Diagramme, nur um den allergroebsten Ueberblick zu geben (Prozesse nebeneinander, Datenfluss dazwischen).
Aber wenn ich heutigen Studenten bei den Uebungsaufgaben zu UML zusehe, verstehe ich, wieso man damit Probleme haben kann, schliesslich ist entweder das Problem gegenueber dem Diagramm total unterdimensioniert, oder die Diagramme waeren bei echten Problemen komplett unuebersichtlich.
Das ist so weit ganz sinnvoll, schliesslich sollte derjenige, der sich den Muell ausgedacht hat, es auch umsetzen, und nicht meinen, die wirkliche Arbeit den anderen Deppen zu hinterlassen. Prinzip Hewlett Packard (aus den guten Zeiten).
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Es gibt anscheinend Diagramme, die sich nur für Vorlesungen eignen.
Ich programmiere seit knapp 30 Jahren, Assembler, Basic, C, Pascal/Delphi. Die Flussdiagramme, wenn überhaupt vorhanden, habe ich genauso gemacht, wie MaWin das schon beschrieben hat: Flussdiagramm des Hauptprogramms von oben nach unten. Daneben die einzelnen Interrupt-Routinen, ohne Verbindungslinien zwischen Hauptprogramm und INT-Routinen.
Da erzählte mir doch letztes Jahr so ein Schlaumeier (abgebrochener Wirtschaftsinformatiker, jetzt Geschäftsführer bei einem ehemaligen Kunden von mir), ich müsste ein Klassendiagramm für ein GCC Programm vorlegen. Hab mir dann dazu mal was durchgelesen und bin zu dem Ergebnis gekommen, dass das für praktische Anwendungen, insbesondere wenn es um Microcontroller geht, Unfug ist.
Am Thu, 30 Aug 2007 08:59:17 +0200 schrieb Stefan Brröring:
In dem Fall wahrscheinlich schon mangels Klassen ...
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Neu: Ethernetbox jetzt auch im 19 Zoll Gehäuse mit 12 Ports für Sensoren
Ah, die Bindestrichinformatiker sind mir die liebsten. Bei denen wird (zumindest an der TU) der technische Teil der Informatik weggelassen. Das führt dann natürlich zu besonderer Kompetenz bei Entscheidungen, die HW bzw. Performance derselben betreffen...
Naja, manchmal geht C++ bei grösseren Mikrocontrollern schon, ob es sinnvoll und vor allem auch "sicher" ist, ist was anderes. Aber Klassendiagramme bzw. Beziehungen lassen sich auch aus unbekannten Programmen per doxygen leicht rausfinden. Selbst bei C-only-Programmen ist die Anzeige der Strukturverflechtungen manchmal praktisch.
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Ja ;-) Du brauchst das dot-Paket zur Grapherzeugung und die Option "CLASS_DIAGRAMS=YES". Das visualisiert dann Klassen und auch normale structs mit ihren Abhängigkeiten.
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Tut es ja gewöhnlich nicht, von solche Teilen wie dem "Propeller" mal abgesehen. Schließlich hast du bei den allermeisten µC halt nur einen Kern.
Klar. Im Prinzip läuft's darauf hinaus, daß es mehrere Ablaufdiagramme gibt, nämlich für jede Ebene der Interrupthierarchie eines. Jedes dieser Ablaufdiagramme hat einen Anfang und ein Ende, mit Ausnahme dessen der niedrigsten Hierarchieebene (des Hauptprogramms), das hat nur einen Anfang und mündet in eine Endlosschleife. (Alles, was anders aussieht, ist ein Bug! ;o)
Nun muß man nur noch die Diagramme in der Reihenfolge ihrer Prioritäten nebeneinanderlegen und sich klarmachen, daß die Teile mit der höheren Priorität zwischen jedem Paar von atomaren Operationen der niedriger priorisierten Teile sozusagen als void Unterprogramm(void) laufen _kann_, wobei das Auftreten eines Hardwareereignisses darüber entscheidet, ob es abläuft.
Das Kernproblem von geschachtelten Interruptroutinen hat sehr viel Ähnlichkeit mit dem Kernproblem von präemptiven Multitasking. Nicht der Ablauf der einzelnen Tasks ist schwierig zu verstehen, nur die Interaktionen zwischen den Tasks.
Und die Lösung ist auch ganz ähnlich. Man minimiert die Synchronisationspunkte, isoliert sie und erklart die Abläufe an diesen Stellen als Statusmaschine.
Und hier wird's sogar etwas einfacher als bei präemptiven MT. Hier kann nämlich immer nur einer der Partner (der am höchsten priorisierte) seinen Status wechseln, während der Status _aller_ anderen Beteiligten sicher konstant wie vorgefunden bleibt.
Richtig schwierig wird es eigentlich erst, wenn das µC-Teil so gut ausgelastet ist, daß zusätzlich zu den expliziten und gewollten Interaktion zwischen den Abläufen auch noch die ungewollten durch Resourcenverbrauch (RAM und Rechenzeit) wichtig werden. Da kann dann so manche Milchmädchenrechnung auch mal nicht aufgehen. Man bemerkt das in erster Instanz durch unmotivierte Abstürze und bei genauerer Analyse daran, daß es Stack-Überläufe gibt.
Wenn es keine Hardwareunterstützung für diese Sache gibt, sollte es zumindest in der Debug-Version also immer Code geben, der das prüft. Blöd nur, daß der bei häufigen Interrupts sehr viel Rechenzeit kostet. Manchmal wird dadurch der eigentlich gewollte Hütehund zum Wolf.
Letztlich helfen also nur zwei Sachen wirklich: Kompetenz und Erfahrung. Ein Anfanger wird komplexe Fehlerszenarios in solchen Systemen niemals lösen. Auch nicht mit einer "1A"-Dokumentation, gleich welcher Art. Die helfen nur dem Profi, der kann sich schneller dem Kern des Problems nähern.
Und wie wird man Profi? Die Frage ist durchaus ernst gemeint. Ich finde das hochspannend aber habe nun tatsächlich keine Zeit mal eben, für den Lerneffekt, ein eigenes OS zu schreiben. Überhaupt scheint mir die Literatur die wirklich erklärt wie die modernen CPUs und OSs funktionieren sehr spärlich gesäht zu sein. Es hat mich et- liche Besuche in der Bibo gekostet um die MMU vom xScale zu verstehen und auch die eher groben Details dazu habe ich auch schon wieder ver- gessen. Vielleicht sollte ich mal ein paar Vorlesung von den technischen Infor- matikern besuchen. Muss mich mal erkundigen ob das wohl auch für das Diplom angerechnet wird.
Nein. Effektiver ist "lerning by doing" - auf der Arbeitsstelle lernen! In konkreten Projekten oder meinetwegen auch in OpenSource- Projekten. Setzt nat=FCrlich voraus, dass man auf Grundlagen aufbauen kann. Je besser die Grundlagen in der Ausbildung, von desto h=F6herem (und breiterem) Sockel aus kann man sein berufliches Lernen starten.
Und selbst, wenn nicht: Wenn Du Dich f=FCr das Thema ernsthaft interessierst, dann solltest Du die Chance wahrnehmen (sagt einer, der dies nicht ausreichend getan hat und sich jetzt auf eher niedrigem Niveau mit Software herumschl=E4gt).
|> Und wie wird man Profi? Die Frage ist durchaus ernst gemeint. Ich finde |> das hochspannend aber habe nun tatsächlich keine Zeit mal eben, für den |> Lerneffekt, ein eigenes OS zu schreiben.
Profi kommt von Profession, d.h. wenn man lange was in dem Fach erfolgreich gemacht hat. Sonst heisst man Consultant ;-)
Profi heisst damit aber auch, dass man schon alle möglichen Fehler selbst gemacht hat und damit Erfahrung gesammelt hat, was man wann wie am besten tut oder eher sein lässt. Das sind dann die Dinge, die nicht im Lehrbuch stehen und man für dieses Wissen Geld verlangen darf...
Im speziellen Fall eines OS kann ich nur raten, zumindest mal die Grundstrukturen (Taskscheduler, Interprozesskommunikation) zu versuchen. Das ist gar nicht soviel Code wie man denkt. Nur muss man an einigen Stellen je nach CPU etwas nachdenken. So hat Linux ja auch mal angefangen :-)
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Muß auch nicht sein. Die wenigsten Entwickler von Anwendungssoftware wissen, wie das OS intern wirklich funktioniert, das ist auch nicht unbedingt notwendig, hilft aber dennoch oft ungemein.
Es muß für den Anfang keine moderne CPU sein. Nimm etwas richtig einfaches, z.B. den 6502. Den kann man noch verstehen. Und der ist IMHO als Einstieg weitaus geeigneter als z.B. ein Z80, bei dem man am Anfang schon beim Befehlssatz kapituliert. Und programmiere ihn zunächst in Maschinensprache _ohne_ symbolischen Makroassembler. Früher hatte man dafür einen KIM-1 oder, wenn genug Geld da war, einen AIM-65. Später haben wir uns Rennen geliefert, wer die schnellste Grafikbibliothek für den Apple-II schreibt oder so.
Oder man schreibt mal Treiber für irgendwas, nimmt einen x-beliebigen alten Peripherie-chip, bastelt den an den Prozessor und fängt an ihn zu programmieren. Die alten Dinger sind nett, da gibt es haufenweise Application Notes und gute Datenblätter. Dann denkt man sich anspruchsvollere Aufgaben aus: Ton an einem Portpin erkennen, wenn das klappt, Morsezeichen dekodieren und auf Display als Laufschrift anzeigen z.B. Wenn das alles klappt, fällt Dir vielleicht ein, daß Du unbenutzte Portpins hast, und versuchst parallel zur vorhandenen Aufgabe da noch etwas zu machen.
Wenn Du besser wirst stellst Du fest, daß vorheriges Überlegen oft hilft, bestimmte Muster zu finden, um eine Aufgabe zu lösen. Relativ triviale Aufgabe aus dem Mikroprozessorpraktikum an der FH bei mir war: Einen Schrittmotor mit 200 Schritten pro Umdrehung ansteuern, der Schrittmotor dreht eine Scheibe, mittels der die Position angezeigt wird. Ausserdem soll die akt. Position auf einer 7-Segmentanzeige dargestellt werden. Das Programm soll einen bestimmten Ablauf der Scheibe zur Folge haben: Rechtsherum drehen auf Pos. 20, 5s warten, links drehen auf 190, 2s warten, etc. Ein Taster ist abzufragen und bei Betätigung ist auf dem kürzesten Wege auf 0 zu drehen, dort 10s zu verharren, dann an die Unterbrechungsstelle zurückzudrehen und weiterzumachen.
Die meisten haben tagelang gesessen und gehackt und getestet und trotzdem (bzw. gerade deswegen) Bugs im Programm gehabt (die der Laboring natürlich treffsicher fand), ich hab nach theor. Überlegung das Programmm auf Papier geschrieben und in kurzer Zeit fertiggestellt, es war zudem eines der kürzesten. Der Trick dabei war: Die Pos. der Scheibe wurde intern nicht als 0 bis 200, sondern als -99 bis +100 gespeichert, dabei zeigt das Vorzeichen stets an, in welche Richtung auf 0 gedreht werden muß. Und mittels Vorzeichenumkehr hat man immer, ohne Ausnahmen, sofort den kürzesten Weg hin und zurück. Für die Anzeige bastelt man dann eine Funktion, die die interne Darstellung in die gewünschte externe umsetzt. Den Rest teilt man dann auch in passende Funktionen ein.
Ansonsten hatte ich z.B. viele interessante Aufgaben (auch viele langweilige :-)), die oft kniffelig und herausfordernd waren. Egal ob es um die Steuerung einer Strumpfstrickmaschine ging oder um die Schweißmaschine, die Stahlmatten für den Bau nach Plan zusammenschweißt (die haben wir beim Probelauf fast zerlegt, weil die Dokumentation der Hardware unvollständig war und das Fischertechnikmodell [kein Witz!] sich auch eher gutmütiger verhielt als der tonnenschwere Schweißroboter. Was in der Doku fehlte war die geringfügige Einschränkung, daß die Hardwaresteuerung _keine_ eigene Rampensteuerung der Motoren durchführte sondern der Anlauf und das Abbremsen in Software erfolgen muß). Demgegenüber ist die Anwendungssoftwareentwicklung, mit der ich mich derzeit herumschlage, arg dröge.
Naja, man schreibt sich in sehr frühen Jahren sein eigenes OS ;-) Biete 6502 und Z80 mit eigenem Floppy und Harddisk Controller mit Interrupts und Hintergrund DMA.
Hehe ;-)
gemacht
Ja. Es kommt allerdings noch ein Punkt hinzu:
Es gibt Programmierer, die haben mit Parallelverarbeitung und Interrupts wenig Probleme und es gibt solche, die werden es nie hinbekommen, ergo schreiben sie besser kommerzielle Software.
Will sagen: Bestimmte Lösungswege und Fehlermöglichkeiten muss man einfach "sehen" können, das läßt sich nur sehr begrenzt über Kurse und Vorlesungen lernen. Kein Debugger der Welt verweist hier so einfach auf Fehler wie in einem rein sequentiellen Programm.
Man kann natürlich versuchen, das rein mit FIFO und einem Sync-Punkt zu machen, aber dann wird es womöglich nicht sehr performant sein.
Im Mimum gehört Erfahrung dazu, aber auch - und das soll jetzt bitte nicht arrogant rüberkommen - die grundlegende Fähigkeit zur Vorstellung (Modellbildung) derart mehrdimensionaler Abläufe im Kopf. Warum es der eine kann und der andere nicht, weiß ich nicht, aber die Erfahrung zeigt, dass dem so ist.
Das ist genau so, wie wenn ein unmusikalischer Mensch fragt, in welchem Kurs man lernt, ab morgen Violine wie Anne Sophie Mutter zu spielen. Ich finde es ehrlicher, hier rechtzeitig zu warnen, dass auch noch soviele Kurse hierfür keine Garantie sind. Oder nehmt Mathe, da gibt es den Spruch "Differenzieren ist Handwerk, Integrieren ist eine Kunst".
Bei uns in der Firma wurde in den 80ern ein Gerät mit eigenem Rechner, grünem CRT, eigenem OS, Floppy, SRAM usw. entwickelt, dazu ein aufwendiger Analogteil, mit A/D-und D/A-Wandlern, CPU zur Signalverarbeitung... Hat damals auch ziemlich eingeschlagen, der Apparat, und von denen laufen heute noch welche! Vor dem Ding habe ich echt Respekt, da haben ein paar pfiffige Leute ein wirklich feines Produkt gebaut.
Naja - ich kann ja durchaus progammieren und tue dies auch gelegentlich wobei mich aber Anwendungen, so im eigentlichen Sinne für PC im Userland, wenig interessieren. Da steckt oft nicht viel Grips dahinter und der Großteil der Arbeit geht für Userinterface usw. drauf.
Ich habe schon viel mit einfachen CPUs hantiert und mir auch mal einen kleinen Bootloader geschrieben der den i386 in den protected Mode schal- tet und Hello World ausgibt.
Ich habe auch schon eine kleine Firmware für eine PCI Karte mit einem xScale Prozessor geschrieben um erst mal zu sehen, ob das überhaupt so funktionieren könnte. Aber da habe ich halt gemerkt, dass ich mit dem MMU und den Cachelines, weniger mit DMA oder Interrupts vom Verständnis her Probleme habe.
Hehe - es gibt meines Wissen noch keinen richtg guten CW Dekoder der auch handgegebene Zeichen mit schlechtem SNR dekodiert. Habe da ja noch eine Wette als Option weil ich glaube, dass eine gute Software das ähnlich gut wie ein Mensch machen kann. (Natürlich mit vergleich- baren Vorraussetzungen - also keiner Redundanz durch Wissen aus dem Kontext was der Mensch oft hat, der Software aber idR. fehlt.)
Wenn ich meine aktuellen Projekte jetzt mal irgendwann endlich zu Ende gebracht habe werde ich mir mal einen etwas größeren ARM besorgen und eine kleine Schnuckelige Box bauen die Herrn Schäubles Bundestrojaner einen kleinen Strich durch die Rechnung macht. (Echter Zufallszahlengenerator, quasi ROM USB-Massstorage Device für einen unveränderlichen Kernel + Grundsystem, RAM für kryptographische Schlüs- sel samt "Notfallknopf" und zweiten Weg der Authentifizierung gegen Keylogger, Honeypott USB-Masstorage Device usw.)
In der Mustererkennung ist das menschliche Gehirn nach wie vor unschlagbar gut. Ähnliche Erkennungsleistungen, wenn auch nur für sehr einfache Muster, wie etwa CW, kannst du nur mit neuronalen Netzen erreichen. Das ist dann aber weniger eine Frage der Programmierung als des Trainings des Netzes.
In article , "Ralph A. Schmid, dk5ras" writes: |> Oliver Bartels wrote: |> |> >Naja, man schreibt sich in sehr frühen Jahren sein eigenes OS ;-) |> >Biete 6502 und Z80 mit eigenem Floppy und Harddisk Controller mit |> >Interrupts und Hintergrund DMA. |> |> Bei uns in der Firma wurde in den 80ern ein Gerät mit eigenem Rechner, |> grünem CRT, eigenem OS, Floppy, SRAM usw. entwickelt, dazu ein |> aufwendiger Analogteil, mit A/D-und D/A-Wandlern, CPU zur |> Signalverarbeitung... Hat damals auch ziemlich eingeschlagen, der |> Apparat, und von denen laufen heute noch welche! Vor dem Ding habe ich |> echt Respekt, da haben ein paar pfiffige Leute ein wirklich feines |> Produkt gebaut.
Ich stehe immer noch voller Respekt vor dem ZX80/81 wo mit wirklich minimalstem Aufwand und raffinierten Tricks das Videobild erzeugt wurde. Und auch ein recht tauglicher Basic-Interpreter samt Single-Precision-FPU-Interpreter und Zeichensatz in 8192Byte ROM passt. Sicher wurde dabei alle Regeln des SW-Engineering verletzt, aber das Ergebnis zählt ;-)
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Was macht denn der Notfallknopf? Sich vor dem Bundestrojaner zu schützen geht aber auch einfacher: Alle eMails vom Finanzamt ungeöffnet löschen oder Linux einsetzen, da der Bundetrojaner bestimmt für Windows geschrieben wird.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
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.