Moin, Softwareentwicklern wird ja gern eingebaute Hardware-Unterstützung fürs Software-debugging/profiling schmackhaft gemacht, beispielsweise bei ARM mit SWD, DAP etc. . Neben dem bekannten "raus pusten von Statusmeldungen über UART" wird da auch von Coresight-Baukastensystem und anderem fabuliert. Wie sieht es in der Praxis damit aus ? Und wird manches von manchen Prozessoren vermisst, so das man sich bei der Prozessorauswahl (bspw zwischen AVR, ARM, DSP) auch von den Möglichkeiten der Debug-Schnittstelle leiten lässt ? Und an die aus dem FPGA-SoC Bereich: Welche "Extras" fürs Software-debugging an/im einem Softcore haben sich als nützlich erwiesen ?
:
Bearbeitet durch User
Bedeutet diese Fragestellung, daß Du Dich mit Microcontrollern oder generell dem Thema Programmierung noch nicht näher beschäftigt hast? Schon Deine Formulierung "wird schmackhaft gemacht", "wird ... fabuliert" lässt eine deutlich ablehnende Grundhaltung erkennen. Warum? (Übrigens: Du plenkst. Aus irgendeinem Grund aber nicht beim Komma.)
> Und wird manches von manchen Prozessoren vermisst, so das man sich > bei der Prozessorauswahl (bspw zwischen AVR, ARM, DSP) auch von > den Möglichkeiten der Debug-Schnittstelle leiten lässt ? Selbstverständlich. Das war jetzt einfach. HTH
Harald K. schrieb: > Bedeutet diese Fragestellung, daß Du Dich mit Microcontrollern oder > generell dem Thema Programmierung noch nicht näher beschäftigt hast? > > Schon Deine Formulierung "wird schmackhaft gemacht", "wird ... > fabuliert" lässt eine deutlich ablehnende Grundhaltung erkennen. Das ist eine Frage der Sozialisation. Wenn man erstmal ein paar Jahre Software-Entwicklung ohne diese Möglichkeiten hinter sich hat, dann hat man Techniken entwickelt um auch ohne sie auszukommen. Ich z.B. habe einen Debugger erst in Form des Borland Turbo-Debuggers gegen Ende des Studiums kennen gelernt (und mich dann gewundert, wie grottenschlecht der Codegenerator/Optimizer von TP ist). Da hatte ich aber schon 10 Jahre Programmierung mit Z80, Z8 und 6510 (C64) hinter mir. Speziell bei µC kommt hinzu, daß das meist proprietär und die notwendige Software heillos überteuert ist. Für den Heimanwender nicht zu stemmen. Die Ausnahme ist SWD auf diversen ARMen. Für meine Projekte für Küche und Haus nutze ich seltenst einen Debugger.
Bradward B. schrieb: > Wie sieht es in der Praxis damit aus? Also bei den STM32 ist das ja standard und es ist schon sehr nützlich, wenn zur Laufzeit, also ohne Breakpoints, Variablen und sonstiger Speicherinhalt angeschaut werden kann, ohne den Programmablauf zu beeinflussen.
> Das ist eine Frage der Sozialisation. Wenn man erstmal ein paar Jahre > Software-Entwicklung ohne diese Möglichkeiten hinter sich hat, dann hat > man Techniken entwickelt um auch ohne sie auszukommen. Geht aber nur bei kleinen Firmen wo man Einzelentwickler ist. Sonst faellt es irgendwann auf das man 10x solange braucht um Fehler zu finden. Und das man SELBSTVERSTAENDLICH einen Debugger benutzt heisst im uebrigen nicht das man nicht auch manchmal nur ein Portpin oder serielle Schnittstelle benutzt. Debugger ist einfach nur ein zusaetzlich zu nutzendes Tool im Werkzeugkasten. Wer den nicht nutzt ist auf dem Stand von 1990 stehen geblieben. Vanye
Bradward B. schrieb: > Moin, Wie, deine Frage ist etwas allgemein gehalten und gar nicht auf ein spezifisches Problem zugemünzt? So soll man doch gar nicht fragen, motzt du doch immer, wenn ich mal eine allgemeine Frage bezüglich eines simulierten Problems stelle, das gar nicht auf spezifischer Hardware läuft. Leg dich doch erstmal fest, was du eigentlich wissen willst.
Vanye R. schrieb: > ... Wer den nicht nutzt ist auf dem Stand > von 1990 stehen geblieben. > > Vanye 1990 gab es bereits sehr wohl sehr ordentliche Debugger! Wenn man den ADB nicht mochte, hätte man sich ja selbst etwas schreiben können. Mitte der Sechziger Jahre sah es allerdings noch trüb aus.
Axel S. schrieb: > Für meine Projekte für Küche > und Haus nutze ich seltenst einen Debugger. Chuck Norris hat auch keinen benutzt. Er hat immer optimierten Maschinencode im esten Durchlauf geschrieben! ;-)
Bradward B. schrieb: > Wie sieht es in der Praxis damit aus ? In den letzten 10 Jahren hatte ich 2-3 Projekte in der Firma mit einem PICCOLO der C2000 Serie von TI. Dort geht es praktisch gar nicht ohne Debugger, denn der ist gleichzeitig auch Programmieradapter. Jaja, es geht prinzipiell auch anders, wird aber eher selten genutzt. Mit Code Composer Studio läuft das relativ gut. Kann man sich nicht beklagen. Wobei mir allerdings der Vergleich zu anderen Debuggern fehlt 8-)
Beruflich: Genutzt wird was effektiv ist und hilft Zeit zu sparen. Debug Interface geht in die Prozessorauswahl ein. Nutze keine Prozessoren mehr ohne gutes Interface. Trotzdem immer Einsatz von Logging Funktionen auch ohne Debugger um im Feld Fehler zu analysieren. Privat: für simple Dinge Arduino mit Logging Ausgabe, aber am liebsten ARM mit SWD…
Vanye R. schrieb: > Geht aber nur bei kleinen Firmen wo man Einzelentwickler ist. Sonst > faellt es irgendwann auf das man 10x solange braucht um Fehler zu > finden. Das ist Unsinn. Schon damals bei meiner Unternehmensgründung war ein Lauterbach TRACE32 ICD eine meine ersten Investitionen und ausgesprochen gut angelegtes Geld. Und ich nutze ihn immer noch fast täglich. Vor ca. zwei Jahren fragte ich bei Lauterbach nach, ob es ein Upgrade-Angebot für einen neuen Hardwarestand gäbe. Das wurde schon fast als Beleidigung aufgefasst mit der Feststellung, dass mein Stand (von 2004!) immer noch voll unterstützt werde. Und gerade als "Einzelentwickler" kann man es sich nicht erlauben, viel zu lange herumzuwurschteln.
:
Bearbeitet durch User
Bradward B. schrieb: > Neben dem bekannten "raus pusten von Statusmeldungen über UART" Für Meldungen ist UART nur eine von vielen Möglichkeiten: SPI, Ethernet… Mit Debugger zum Beispiel Seggers "Real Time Transfer" über SWD. Das möchte ich nicht missen.
Andreas S. schrieb: > Das ist Unsinn. Ich lese die Aussage nicht so, daß man in kleinen Firmen keine Debugger braucht, sondern so, daß man nur in kleinen Firmen ("Frickelbuden") es sich überhaupt leisten kann, auf Debugger zu verzichten.
Ich habe mich daran gewöhnt, Debugger nutzen zu können. Früher ging es auch alleine mit printf(). Heute würde ich nur noch ganz kleine Projekte ohne Debugger anfangen wollen.
:
Bearbeitet durch User
Bradward B. schrieb: > Wie sieht es in der Praxis damit aus ? > Und wird manches von manchen Prozessoren vermisst, so das man sich bei > der Prozessorauswahl (bspw zwischen AVR, ARM, DSP) auch von den > Möglichkeiten der Debug-Schnittstelle leiten lässt ? > Ja. Für einen vernünftigen Prozessor erwarte ich heutzutage eine fehlerfreie In-Circuit-Emulation (ICE), die komplett non-intrusiv arbeitet, also alle relevanten Prozessor-Zustände per Test-Access-Port (TAP) gesetzt/zurückgesetzt werden können. Damit hat man eigentlich schon gewonnen, sofern ein gewisser Grundsatz im Prozessordesign gilt, nämlich der, dass das Emulations-Ereignis (wie durch durch einen Breakpoint) wie eine Exception behandelt wird. > Und an die aus dem FPGA-SoC Bereich: > Welche "Extras" fürs Software-debugging an/im einem Softcore haben sich > als nützlich erwiesen ? Schön sind solche Features wie kleine Speicherarrays um on-chip kleine Programmsequenzen per JTAG-TCK-Zyklus zu fahren, um z.B. Speicherblöcke auszulesen, oder virtuelle Interfaces zu tunneln (für printf-Debugging ohne UART). Mehr braucht's eigentlich nicht auf CPU-Seite, wenn der JTAG/SWD-TAP echte ICE-features bietet. Dementsprechend empfinde ich solche Ungetüme wie CoreSight oder die RISC-V/MIPS-Debug-Interfaces eher als unnötige Verkomplizierung. Bei FPGAs ist allerdings die Sache etwas kniffliger, da muss man sich mit den architekturabhängigen JTAG-Primitiven herumschlagen, oder halt "von Hand" einen separaten JTAG-TAP implementieren.
Angehängte Dateien:
-
DebugHost2ARM.png
28 KB -
DebugFeaturesCortex.png
35 KB
Zwischenfazit: Eine Frage nach der Debug-Schnittstelle greift eigentlich zu kurz, im Kern geht es um: * Hardwaremodule (debug Unit/ breakpoint unit) im Controller * debug Host (PC) mit Debug Software * eine Schnittstelle zwischen den beiden zum Austausch von Daten/Kommandos (siehe Anhang aus: ISBN: 978-0-12-408082-9) Mancherorts wird zwischen debug und trace features unterschieden, im Cortex M3/M4 werden für trace/debug jeweils getrennte Interface benutzt, im serial wire debug sind das die Pins SWCLK und SWDIO für Debug und das Pin SWO/TDO für Trace Zur Debugschnittstelle wird gezählt: * download des programm images * reset-steuerung * start/stop/single Step des programms * breakpoints * watchpoints * auslesen/Ändern der Daten von Speicher und Peripherals (on-the-fly memory access) * Zugriff (lesend/schreibend) auf Variablen * nach einem Halt können die Register innerhalb des Processors gelesen/geschrieben werden Zum Trace (Echtzeit) wird gezählt: * data watchpoint events (ie. Programm counter-Value, address values, ..) * events von Profilining - counters (i.e. timestamps) IMHO haben bis auf einen (universellen) Speicherzugriff die meisten controller die genannten debug-Features seit Jahren. Frage: hat es den Speicherzugriff auch bei externen Speicher oder beschränkt sich das auf internen Speicher (wie bei embedded mikrocontrollern eigentlich üblich) ? Und je nach Arbeitsroutine wird es genutzt oder auch nicht. Eine Debugschnittstelle taugt nur soviel wie deren Unterstützung durch die benutzte IDE. Im ARM/Cortex Bereich kann man keine allgemeine Aussage zu den unterstützten Debug/trace-features geben, das unterschiedet sich doch zwischen M0/M3/M4 (siehe Anhang). Die STM32-Reihe benutzt je nach Untertyp verschiedenen komplexe Cortex-Cores und hat damit wohl auch unterschiedliche Debug-features neben den basic-features breakpoint/Einzelschritt. Nach dem „cyber resiliance act“ sollte eine Debugschnittstelle in Geräten mit Netzverbindung deaktiviert sein, um eine Zertifizierung zu erreichen. Interessant wird in diesem Zusammenhang, das eine solche Schnittstelle auch für Service im Feld benutzt wird, nicht nur zur Entwicklung. Damit dürften die Servicemöglichkeiten bei Netzfähigen Systemen auf das Einspielen von autorisierter Firmware begrenzt sein.
Bradward B. schrieb: > Eine Debugschnittstelle taugt nur soviel wie deren Unterstützung durch > die benutzte IDE. Nein. Ich verwende explizit keine IDE zum Debugging, sondern eine separate Applikation (TRACE32 GUI), da ich beide Welten separat halten will. Für ein paar kleinere Dinge mag es zwar praktisch sein, alles in einer IDE zu haben, aber ich will meistens die Quellcodebearbeitung und -kompilation getrennt von der Debuggeroberfläche haben. Das ganze setzt natürlich hinreichend viel Platz auf den Bildschirmen voraus. Und gerade das T32 GUI besitzt enorm viele Features, die eine allgemeine IDE völlig überfrachten würden. Außerdem kann ich sie bei laufendem System nebenher im Auge behalten und bei längeren Tests immer mal wieder einen Blick darauf werfen, ohne den Fokus meiner Arbeit in anderen Programmen zu verlieren. Auf Grund des großen Platzbedarfs nutze ich allerdings auch vier Bildschirme und hätte auch schon auf sechs aufgerüstet, wenn das Modell der beiden Hauptbildschirme noch auf dem Markt erhältlich wäre.
Bradward B. schrieb: > IMHO haben bis auf einen (universellen) Speicherzugriff die meisten > controller die genannten debug-Features seit Jahren. > Frage: hat es den Speicherzugriff auch bei externen Speicher oder > beschränkt sich das auf internen Speicher (wie bei embedded > mikrocontrollern eigentlich üblich) ? > Siehe ICE, wenn darauf basierend, kann alles, was der Core kann. > Und je nach Arbeitsroutine wird es genutzt oder auch nicht. > Eine Debugschnittstelle taugt nur soviel wie deren Unterstützung durch > die benutzte IDE. Eine IDE habe ich die letzten 10 Jahre nicht mehr aktiv genutzt, mit gdb scripting oder einer Python-API debuggt man deutlich effizienter, gerade bei so harten Systembugs, die man sonst iterativ aufspüren muss. Bradward B. schrieb: > Nach dem „cyber resiliance act“ sollte eine Debugschnittstelle in > Geräten mit Netzverbindung deaktiviert sein, um eine Zertifizierung zu > erreichen. Interessant wird in diesem Zusammenhang, das eine solche > Schnittstelle auch für Service im Feld benutzt wird, nicht nur zur > Entwicklung. Damit dürften die Servicemöglichkeiten bei Netzfähigen > Systemen auf das Einspielen von autorisierter Firmware begrenzt sein. Wie kommst du darauf? Für JTAG-Debugging muss jemand vor Ort ein Kabel anstecken und die Kiste aufschrauben. Autorisierte Firmwareupdates laufen eher über Bootloader per Signatur. Wenn der nicht im ROM sitzt und gebrickt wird (oder key kaputt), dann greift man allenfalls nochmal zum JTAG. Einer Zertifizierung steht das nicht im Weg. Der andere Aspekt ist, dass man Hardware, die dem "Feind" in die Hände fallen könnte, das Auslesen der Firmware verunmöglichen möchte. Das Interface wegfusen macht dann final das Törchen zu, Aktivierung nur per secret key hat in der Vergangenheit gemischte Resilienz gezeigt, bei min. 2 mir bekannten Cores kann man sich beim Powerup in den TAP trotzdem reinglitchen. Was Trace-Debugging angeht, erachte ich den Nutzen auch eher so als gemischt, hängt stark vom Core ab, ob echte Trace-Buffer vorliegen, oder einfach nur per JTAG (ICE oder BSCAN) gepollt wird (und events verpasst werden können). Bei FPGA SoCs erübrigt sich die Nummer, da man ja eh alles in der Simulation tracen kann, für andere Plattformen gibt es Simulatoren wie Renode, Skyeye, usw. wo man mit der entsprechenden Trace viel weiter kommt.
>> Eine Debugschnittstelle taugt nur soviel wie deren Unterstützung durch >> die benutzte IDE. > > Nein. Ich verwende explizit keine IDE zum Debugging, sondern eine > separate Applikation (TRACE32 GUI), Stimmt natürlich, das mit der IDE (Integrated Development Environment) bitte nicht zu eng auslegen, gemeint ist eben die auf dem Host-PC Rechner laufende "Debug/trace)-Steuersoftware. Wobei viele eben vor dem Debugging nicht die Dokumentation (des Debug-Systems/Schnittstelle) konsultieren sondern lediglich in dem "Debug"-Menu der IDE herumstochern und nur das verwenden, was dort findbar ist.
> Mitte der Sechziger Jahre sah es allerdings noch trüb aus.
Ich kann nicht beurteilen was damals war, weil noch nicht auf der Welt,
aber wenn ich so ueberlege was es in den 60ern an Embeddedcontrollern
gegeben hat dann vermute ich das der gesamte Programmablauf noch ins
Ingenieurgehirn oder auf zwei Seiten dieses gruen weiss gestreiften
Papiers gepasst hat oder? :)
Jedenfalls war es 20Jahre spaeter bei mir mit dem MCS48 so. Also da gebe
ich zu habe ich auch noch durch EPROM wechsel debugt. Aber wir waren arm
und hatten ja nichts.
Vanye
Bradward B. schrieb: > Wobei viele eben ... nur das verwenden, > was dort findbar ist. Fühlt sich richtig an, aber: Gemäß einer Studie liegen die Menschen meistens falsch, wenn sie schätzen, wie sich die anderen verhalten. Deswegen habe ich beschlossen, solche Aussagen künftig zu vermeiden.
>> Mitte der Sechziger Jahre sah es allerdings noch trüb aus. > aber wenn ich so ueberlege was es in den 60ern an Embeddedcontrollern > gegeben hat dann vermute ich das der gesamte Programmablauf noch ins > Ingenieurgehirn oder auf zwei Seiten dieses gruen weiss gestreiften > Papiers gepasst hat oder? :) Nö, das war damals noch richtige Raketentechnik und es braucht Promotionswürdige Erfindungsgabe bei der (fehlertoleranten Echtzeit:-) Programmierung: * https://de.wikipedia.org/wiki/Margaret_Hamilton_(Informatikerin)#Apollo_11 Mglw., war auch das grün-weisse gestreifte Papier noch nicht erfunden und die einzige Dokumentation war der in Tusche gezeichnete Schaltplan.
:
Bearbeitet durch User
Vanye R. schrieb: > wenn ich so ueberlege was es in den 60ern an Embeddedcontrollern > gegeben hat Garkeinen, den ersten konnte man 1971 kaufen: https://de.wikipedia.org/wiki/Intel_4004 Und das war eigentlich nur ein Prozessor (d. h. er hatte keine integrierte intelligente Peripherie), also kein Controller. > Jedenfalls war es 20Jahre spaeter bei mir mit dem MCS48 so. Also da gebe > ich zu habe ich auch noch durch EPROM wechsel debugt. In den 1960ern haben ich Assembler im Selbststudium auf dem Großrechner der Uni gelernt. Das war ein https://en.wikipedia.org/wiki/CDC_1604A. Da gab man einen Lochkartenstapel ab und bekam eine Woche später den Ausdruck des Quellprogramms zurück, wo der Operator oft genug "Spult Magnetband aus" gekritzelt hatte. Das simple OS war nicht vor Überschreiben geschützt. Da fing dann das Debuggen im Kopf an. Wer diese harte Schule durchlaufen hat, der muss auch ohne Debugger hier nie fragen, warum sein Code nicht läuft. :-)
Rolf schrieb: > Vanye R. schrieb: >> wenn ich so ueberlege was es in den 60ern an Embeddedcontrollern >> gegeben hat > > Garkeinen, den ersten konnte man 1971 kaufen: > https://de.wikipedia.org/wiki/Intel_4004 > > Und das war eigentlich nur ein Prozessor (d. h. er hatte keine > integrierte intelligente Peripherie), also kein Controller. Aus Slices aufgebaute Prozessoren gab es natürlich schon vor dem Zwergenhirn 4004/4040.
Cartman E. schrieb: > Aus Slices aufgebaute Prozessoren gab es natürlich schon vor dem > Zwergenhirn 4004/4040. Ich hatte mich früher schon mal dafür interessiert, wie Prozessoren aussahen, bevor sie "Mikro" wurden. Die Fotos von Schränken voller Relais und Röhren kenne ich, aber kann man due Variante auf Transistoren und Mikrochips auch irgendwo bewundern, falls es sie gab? Damit meine ich jetzt nicht die diskreten 6502 Nachbauten und ähnliche Experimente aus dem 21. Jahrhundert, sondern Sachen, die früher wirklich ernsthaft benutzt wurden.
Cartman E. schrieb: >>> wenn ich so ueberlege was es in den 60ern an Embeddedcontrollern >>> gegeben hat >> >> Garkeinen, den ersten konnte man 1971 kaufen: >> https://de.wikipedia.org/wiki/Intel_4004 >> >> Und das war eigentlich nur ein Prozessor (d. h. er hatte keine >> integrierte intelligente Peripherie), also kein Controller. > > Aus Slices aufgebaute Prozessoren gab es natürlich schon vor dem > Zwergenhirn 4004/4040. Und das waren - ich zitiere - "Embeddedcontroller"?
Hans W. schrieb: > Die Fotos von Schränken voller Relais und Röhren kenne ich, aber kann man > due Variante auf Transistoren und Mikrochips auch irgendwo bewundern, falls > es sie gab? Klar gab es die. Die waren z. T. sogar größer, wegen der umfangreichen Peripherie (Speicher usw.) in separaten Schränken. Die Relais-/Röhren-Rechner waren aber für den kommerziellen Einsatz zu teuer, nicht leistungsfähig genug und zu unzuverlässig. Es waren Forschungsprojekte. Früher hieß die IT noch EDV und war interessant für den Einsatz in Buchführung, Datenbanken usw. Das fing aber erst so richtig an mit dem https://en.wikipedia.org/wiki/IBM_System/360 Vorher gab es nur wenige größere Computer auf Halbleiterbasis, die meisten standen in Unis. Der erste deutsche Großrechner war der https://de.wikipedia.org/wiki/TR_4_(Rechner)
> Ich hatte mich früher schon mal dafür interessiert, wie Prozessoren > aussahen, bevor sie "Mikro" wurden. Die Fotos von Schränken voller > Relais und Röhren kenne ich, aber kann man due Variante auf Transistoren > und Mikrochips auch irgendwo bewundern, falls es sie gab? Ja, die PDP irgendwas, war ein prozessrechner, stand also bei Automibilherstellern am Motorprüfstand, die hatten Transistoren mit Golddotierung für die Sättigung. Wurde hier auch mal durchgekaut. Zu sehen bspw. in der Datarena : * https://www.unibw.de/datarena/web_minidecpdp8e_001.jpg/@@images/image/large * https://www.unibw.de/datarena * https://commons.wikimedia.org/wiki/Category:PDP-8?uselang=de#/media/File:Okona-GfhR-DEC-PDP-8-Logikgatter.jpg * Für Ostalgiger: https://www.robotrontechnik.de/index.htm?/html/sonderbeitraege/rzs.htm
:
Bearbeitet durch User
Cartman E. schrieb: > Rolf schrieb: >> Vanye R. schrieb: >>> wenn ich so ueberlege was es in den 60ern an Embeddedcontrollern >>> gegeben hat >> >> Garkeinen, den ersten konnte man 1971 kaufen: >> https://de.wikipedia.org/wiki/Intel_4004 >> >> Und das war eigentlich nur ein Prozessor (d. h. er hatte keine >> integrierte intelligente Peripherie), also kein Controller. > > Aus Slices aufgebaute Prozessoren gab es natürlich schon vor dem > Zwergenhirn 4004/4040. Die 60er Minicomputer waren aus Hybridmodulen aufgebaut. Die IBM 360 z.B war aus SLT (Solid Logic Technology) Modulen aufgebaut. Siehe: https://en.wikipedia.org/wiki/Solid_Logic_Technology Slice Processoren als Chip kamen erst mitte der siebziger mit AMD 2901, Intel 3002 und MMI 5701 auf den Markt. Die erste ALU als Chip war der 74181 mit dem ich meinen ersten Recher gebaut hatte. Kurz bevor Elektor den 1974 Computer heraus brachte. Dann bekam ich einen 8080 in die Hand ;-)
Rolf schrieb: > Cartman E. schrieb: >>>> wenn ich so ueberlege was es in den 60ern an Embeddedcontrollern >>>> gegeben hat >>> >>> Garkeinen, den ersten konnte man 1971 kaufen: >>> https://de.wikipedia.org/wiki/Intel_4004 >>> >>> Und das war eigentlich nur ein Prozessor (d. h. er hatte keine >>> integrierte intelligente Peripherie), also kein Controller. >> >> Aus Slices aufgebaute Prozessoren gab es natürlich schon vor dem >> Zwergenhirn 4004/4040. > > Und das waren - ich zitiere - "Embeddedcontroller"? Ei gewiss. Aber NOFORN. Wobei die "Kundschaft" eher nicht an Publicity interessiert war. Und "Kosten" auch keine ausschlaggebende Rolle spielten. Solange das eine abgegrenzte Baugruppe ist, sehe ich kein Problem in der Verwendung des Begriffs: "Embeddedcontroller". Und klugscheiss: Ein 4004 war ein Prozessor, also standalone auch nix mit "Embeddedcontroller". Also ein ganz schlechtes Beispiel.
Dankeschön. Mit den Begriffen findet man einiges. Meine "Welt" begann erst später mit dem IBM XT. Der hatte ja schon einen Mikroprozessor, wie wir ihn heute kennen (nur primitiver). Assembler hatte ich zuerst auf einem C64 (6502) gelernt. In eigenen Schaltungen habe ich mit dem 8031 angefangen.
:
Bearbeitet durch User
Bradward B. schrieb: > Ja, die PDP irgendwas, war ein prozessrechner, stand also bei > Automibilherstellern am Motorprüfstand, die hatten Transistoren mit > Golddotierung für die Sättigung. Naja, es gab nicht nur "die" PDP irgendwas, sondern die Familien PDP-1 bis PDP-16, die in alle möglichen Technologien aufgebaut waren, d.h. vom diskret mit Transistoren aufgebauten Einzelgatter über niedrig integrierte ICs bis hin zu vergleichsweise modernen hochintegrierten Prozessoren wie z.B. Jaws-11 und Fonz-11. Letztere sind Multichipmodule auf keramischem Träger, wie man sie auch heutzutage bis einigen Mikroprozessoren noch bzw. wieder findet. Die mit Abstand verbreitetste Familie war DEC PDP-11, als Nachfolger von PDP-8. Sie ist auch heutzutage noch im Einsatz. Die großen PDP-10-Systeme, auch unter DECsystem-10 und DECsystem-20 bekannt, waren ganz klar im Bereich der klassischen Großrechner angesiedelt, mit teils zigtausend Benutzern. Compuserve basierte komplett auf einem Haufen weltweit verteilten PDP-10-Systemen mit einem eigenen Betriebssystem. Ich kann mich auch noch sehr gut an meine Studienzeit erinnern, als eine gigantische PDP-10 im Rechenzentrum lief und dort aus etlichen Reihen an Schränken bestand. Die anderen dortigen Großrecher waren eine Siemens Fujitsu H90 mit ähnlichen Dimensionen wie die PDP-10, eine Cray XMP 216, eine Convex C-irgendwas und natürlich der von mir überwiegend genutzte VAX-Cluster aus etlichen Systemen verschiedener Generationen.
Das ist ja schön, daß die Rollatorengruppe* jetzt in ihren Minicomputererinnerungen schwelgen kann, aber mit einem "embedded controller" oder auch Microcontroller haben die, abgesehen davon, daß sie Strom verbrauchen, eher nichts bis überhaupt nichts zu tun. Auch ein IBM PC hat nichts mit einem Microcontroller zu tun. Der Threadersteller fragte einigermaßen konkret nach dem Debugging von "embedded controllern", und hat damit so etwas wie JTAG, SWD oder ähnliches gemeint. *) Sorry, Leute, ich bin ja auch schon etwas weniger jung, aber um PDP & Co. in einer Diskussion über "embedded controller" anzubringen, muss man noch einige Jahrzehnte älter sein, also so aus der Altersklasse des "alten Knackers" stammen, oder gar den als Jüngling betrachten ...
Hans W. schrieb: > Ist das dein Topic? Nö, aber genausogut, wie hier jemand was über Minicomputer posten kann, kann ich (oder irgendjemand anderes) das auch kritisieren. Wem "das Topic" 'gehört' spielt dabei keine Rolle.
Harald K. schrieb: >> Ist das dein Topic? > Nö Der TO hat selbst mit der Nostalgie angefangen. Wer das blöd findet darf sich gerne heraus halten.
:
Bearbeitet durch User
Beitrag #8047563 wurde vom Autor gelöscht.
Rolf schrieb: > Die Relais-/Röhren-Rechner waren aber für den kommerziellen Einsatz zu > teuer, nicht leistungsfähig genug und zu unzuverlässig. Vielleicht die Beispiele, die du kennst. Gegenbeispiel: https://www.spiegel.de/geschichte/erster-ddr-computer-oprema-a-951147.html
> aber mit einem "embedded > controller" oder auch Microcontroller haben die, abgesehen davon, daß > sie Strom verbrauchen, eher nichts bis überhaupt nichts zu tun. Yep, hab ich gerade auch so gedacht. Embedded fing nach meinem dafuerhalten so mit dem MCS48 an. Und damals gab es wohl die Zweiteilung. Leute in einer grossen Firma mit Kohle hatten mindestens einen Epromemulator oder gleich einen Emulator fuer die ganze MCU und die armen und auch mein Kinderzimmer hatte nur ein Eprombrenner und Loescher. Da hat man also nicht nicht mit einem Debugger gearbeitet. Man musste aus armer Verzweiflung oder seeliger Unkenntnis ohne auskommen. Umso weniger kann ich es verstehen wenn einer heute solche Tools nicht nutzen will. Das ist ja so als wenn einer freiwillig barfuss durch den Schnee 10km zur Schule laufen will obwohl er ein Hooverboard nutzen koennte. Vanye
ab 1974: TMS 1000 https://de.wikipedia.org/wiki/Texas_Instruments_TMS1000 Vanye R. schrieb: > Embedded fing nach meinem > dafuerhalten so mit dem MCS48 an. ab 1976: MCS-48 https://de.wikipedia.org/wiki/Intel_MCS-48 Aber passt schon, Intel dürfte mit 8 Bit populärer gewesen sein, als TI mit nur 4 Bit...
Cartman E. schrieb: > Und klugscheiss: Ein 4004 war ein Prozessor, also standalone > auch nix mit "Embeddedcontroller". Also ein /ganz schlechtes/ > Beispiel. "Embedded" bezieht sich aber nicht auf den Integrationsgrad (Einzelchip vs. Mehrchip), sondern eher auf die Verwendung als integrierte Gerätesteuerung statt als "Universalrechner". Die Abgrenzung mag teilweise schwer sein, z.B. bei einem Laborgerät mit einer PDP-8 oder PDP-11 und einem Terminal. Ganz klare "Embedded"-Anwendungen sind aber das erste mikroprozessorbasierte Motorsteuergerät (~1975 in Serie) von Ford mit einem Toshiba TLCS-12 (1973) sowie unzählige, teils auch heute noch in Betrieb befindliche Fußgängerampeln mit Intel 4004. Ich gehe aber weiter und (nicht nur ich) behaupte, dass auch z.B. die im Rahmen des Apollo-Programms eingesetzten Computer (AGC, LVDC, AGS) als "Embedded Controller" zu bezeichnen sind. Insbesondere beim AGC handelt es sich um den allerersten Computer, bei dem ICs eingesetzt wurden, allerdings bei den ersten Versionen nur als Einzelgatter. Diese Einschätzung bzw. Definition wird auch hier vertreten: https://de.wikipedia.org/wiki/Apollo_Guidance_Computer
:
Bearbeitet durch User
Harald K. schrieb: > Ich lese die Aussage nicht so, daß man in kleinen Firmen keine Debugger > braucht, sondern so, daß man nur in kleinen Firmen ("Frickelbuden") es > sich überhaupt leisten kann, auf Debugger zu verzichten. Gerade als Kleinunternehmen kann man es sich nicht erlauben, bei hinreichend komplexen Projekten auf Debugger zu verzichten. Ganz im Gegenteil habe ich es bei einem Projekt mit einem seeehr großen Konzern erlebt, dass dort auf die Anschaffung von Debuggern verzichtet werden sollte, weil das ja früher(tm) auch ohne funktionierte. Im Rahmen dieses Projektes musste aber auf Wunsch des Projektleiters auch so ziemlich jede andere moderne Methodik verzichtet werden. Stattdessen musste unbedingt auch der VHDL-Code zwangsweise wiederverwendet werden, den er Anfang der 1990er Jahre mal für das Vorgängerprodukt geschrieben hatte und für das aktuelle Projekt völlig ungeeignet war. Auf Grund einiger "sehr spezieller" Merkmale hätte dieser Code auch einen Ehrenplatz in der Vitrine der Antipattern verdient. Als kleines oder mittleres Unternehmen würde man an solche einem Projekt pleite gehen, aber im Großunternehmen interessiert das keine Sau. Ich teile durchaus die Einschätzung einiger ausländischer Fachleute, die Deutschland großenteils als Industriemuseum betrachten.
:
Bearbeitet durch User
Andreas S. schrieb: > Ich gehe aber weiter und (nicht nur ich) behaupte, dass auch z.B. die im > Rahmen des Apollo-Programms eingesetzten Computer (AGC, LVDC, AGS) als > "Embedded Controller" zu bezeichnen sind. So ist es. "Embedded" bedeutet, dass der Computer mit festgelegtem Programm Bestandteil der Anlage ist. Im Gegensatz zur generischen EDV, wo ein und die selbe Hardware immer wieder andere Aufgaben übernimmt, je nachdem welchen Programm von Lochkarte, Diskette oder SSD geladen wurde.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.