C tut weh!

Naja, aber die Erzählungen von Jörg bezogen sich WIMRE an die externe RESET-Schaltung, also eben mit externem Reset-IC in den Griff zu kriegen.

Aber wenn der externe RESET richtig beschaltet ist (und der Clock passt), muss ich mich als Programmierer darauf verlassen können dass das Datenblatt (modulo Errata) stimmt. Weil sonst kommst du vom Hundertsten ins Tausendste: Dann kannste auch anfangen, bei jeder Addition die zweimal auszuführen und die Ergebnisse zu vergleichen. Oder direkt zweimal vergleichen, könnte ja auch einmal schief gehen. Und wer garantiert dir überhaupt, dass der Core die Instruktionen richtig aus dem Flash liest?

Und ja, mir is durchaus bewusst dass es Prozessor-Kerne gibt, die im Lockstep eben genau das machen. Aber es geht hier um die Behauptung von Wolfgang, das grundsätzlich und immer alle Register "nochmal" initialisieren sollte (auch wenn der RESET sauber, datenblattkonform durchgeführt wurde). Das ist Unfug.

Gruß, Johannes

Am 11.10.19 um 17:31 schrieb Johannes Bauer:

Zu 8085 / Z80-Zeiten gab's von AMD den AM9511 Floating Point Coprozessor, und es gab jede Woche entweder einen neuen Chip oder ein neues Datenblatt, aber niemals Sicherheit, ob die irgendwie zusammengepasst haben. Das GRAUEN!

Längere Berechnungen waren meistens falsch, aber wenn man den Z80 single-gesteppt hat, dann ging das eigentlich immer gut. Aber für lange Berechnungen war die Datenlage eben dünn. Unser Abteilungsleiter hat dann beschlossen, dass der AM9511 vor jeder Operation rückgesetzt wurde. Von da ab ging garnix mehr.

Es hat sich dann gezeigt, dass bei diesem späten stepping nur die erste Instruktion nach dem Reset defekt war. Die vorläufige Initialisierung war dann Reset, Wegwerf-Berechnung, nix mehr anfassen, aber weiterrechnen. Irgendwann hat AMD das dann doch auf die Reihe gekriegt. Es war letztlich eine racing-condition für die ready-Anzeige.

Gruß, Gerhard

Am 11.10.2019 um 11:34 schrieb MaWin:

Thema verfehlt, setzen.

Es ging nicht darum, was eine Programmiersprache "nicht kann", sondern nur darum, dass die Assemblerinstruktion "springe an Adresse 0" als eine C-Anweisung aufgeschrieben einen Klammerkrieg ergibt. Ja, C kann das. Es sieht nur umständlicher aus als das 'rst 0' in Assembler.

Dafür sieht in Assembler jede Berechnungs- und Logik-Aufgabe deutlich schlimmer aus als in C oder jeder anderen Hochsprache.

Wie gut man den Resetvektor anspringen kann ist schlicht kein Argument für oder gegen eine Programmiersprache. Wenn man das braucht aber eine Programmiersprache hat, die es nicht kann, linkt man die drei Zeilen Assembler händisch dazu.

"Oh nein, ich kann den Resetvektor nicht anspringen, da muss ich jetzt meinen TCP-Stack, das Webinterface und die Grafikengine in Assembler neu machen" sagt jedenfalls niemand, der mit seinem Produkt fertig werden will.

Stefan

Ich schrieb: "nicht ganz einwandfrei". Das bedeutet, daß ein Auftreten des Fehlers sehr unwahrscheinlich war. Bei der von mir mit Software versorgten Hardware gab es den Fehler nie.

Allerdings wurde nach einer Änderung der Hardware (RS232->USB) mir mitgeteilt, daß ich nun zusätzlich einen externen WatchDog triggern muß.

Der uC war eine Fujitsu Familie MB90590 oder ähnlich, LX 16Bit 16MHz. Bei einer neueren Familie MB90F345, LX 24MHz blieb das pauschal. Ganz aktuell sind Familien FX 56 MHz (5-7mal schneller). Damit bekam ich aber nichts zu tun, sondern leider mit Coldfire.

Diese 16Bit-uC von Fujitsu fanden wir ganz vorzüglich. Ich konnte da bei 24 MHz eine 32Bit-Wurzel ziehen in 19 us (Integer). Mit einem FX dürfte das in 4 us gehen. unsigned sqrtul_F(ulong X);

Wir haben privilegierte Geheimmenüs gehabt.

On 11.10.19 13:49, Johannes Bauer wrote: ...

In letzter Zeit habe ich eher das Problem, die Datenblätter zu lesen. Selbst das reference manual eines ziemlich simplen Cortex-M0+ (KL16

Anderes Beispiel: Die FM3 von Fujitsu->Spansion->Cypress haben ein SWD-Interface. Spannende Aufgabe, wenn man wirklich nichts anderes zu tun hat: Welche Typen der FM3-Serie hat *wirklich* ein SWD-Interface?

Die fünf, mit denen ich zu tun habe jedenfalls nicht...

Und dann war da noch das SPI des LPC2220(?), dessen zugeordneter CS-Pin nicht benötigt wird, aber nicht als GPIO verwendet werden kann, weil er zwingend auf "1" liegen muß, weil sonst das SPI nicht funktioniert, wie auf Seite hundertdrölfzig in einer Randnotiz beschrieben ist...

Kurz: Moderne Microcontroller sind nicht beherrschbar, weil zu komplex und die Hardware Abstraction Layer sind nicht nutzbar, weil buggy, was dazu führt, dass man doch wieder hunderte Seiten Doku lesen muss... ;-)

Falk

Am 12.10.2019 um 00:04 schrieb Falk Willberg:

Was ist so seltsam daran, daß sich ein SPI Slave nur angesprochen fühlen soll, wenn sein SS Pin aktiv ist? Und als Master eben dauerhaft auf high...

Wenn es ein einheitliches HAL gäbe, könnte man doch nicht so viele verschieden Controller auf den Markt werfen ;-)

DoDi

An das Mistding erinnere ich mich auch wieder. Hab mal ne Zusatzkarte zu einen ECB System entwickelt samt SW um die Bahnen für einen US Robot auf einem Reaktordeckel zu berechnen.

Ja, jetzt kommt die Erinnerung wieder voll hoch. :(

Aber der maulheldige Bauer auf dem Misthaufen oben auf dem Mount Stupid wird sowas nie begreifen.

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

Am 12.10.19 um 01:54 schrieb Wolfgang Allinger:

Ja, bei mir war's die Korngrößenbestimmung von Stahl per Ultraschallrückstreuung in einer Prüfmaschine für die innere Reaktorumhüllung.

Gerhard

Sicher auch nett :)

IIRC hab ich da irgendeine Verzögerung in die RDY Leitung einbauen müssen, danach funzte das Ding, auch einige NOP im eigenen Treiber waren notwendig. Hab das Teil mit FORTH und mit einem hp 1603(?) Logic State Analyzer debugged. Letztendlich wurde das System vom TÜV&RWE&MAN u.a.in Mülheim-Kärlich eingesetzt. War praktisch vor der Haustür von Hürth- Efferen (Krautkrämer).

Ich hab denen ne FORTH Oberfläche gebaut, mit denen sie dann selber die Geometrie des Deckels, samt seinen drölfundzighundert von Durchdringungskurven und Schallwinkel(Reflektionen) und daraus die Roboterposition und Koordinaten der Prüfkopfausrichtung zur Schweissnahtprüfung basteln konnten. War ne üble Mathematik, die haben da einem frischen Mathe Dr. mehrere Monate graue Haare beigebracht. Wir Ings. haben uns gekonnt geduckt :)

Jemand anderes hat dann die Transformierung zu der SM-Steuerung drangebastelt. Unterm Strich ein voller Erfolg. Der Robo rollerte mit Magnetrollen am Druckgefäß rum, aber Wände und Boden war nicht so schlimm, da wenig Anschlüsse. Aber der Deckel <seufz> hatte es in sich. Der Robo durfte auch nicht die Schleppkabel verknoten :) War alles sehr spannend.

Wurde später dann (nicht von mir) zu noch einer Number-Cruncher Karte für ne LSI11-03 weiterverwurstet, da die Datenmengen unbedingt auf DEC- Laufwerken abgeladen werden mussten.

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

Das glaube ich dir sofort, die Beschreibung klingt ziemlich übel.

Aber man muss das eben auch im Kontext seiner Zeit sehen. Der 8085 ist aus der Mitte der 70er Jahre, über 40 Jahre alt. Die Testmethoden und Entwicklung damals waren, mangels der Möglichkeiten, einfach deutlich rudimentärer als heute. Ähnliche Bugs wären bei einem heutigen SoC völlig inakzeptabel.

Ich habe mir zum Vergleich mal das Errata Sheet eines STM32F407 geholt, nur weil ich den Prozessor sehr gut kenne. Da ist *tonnenweise* Peripherie drin, u.A. eine FPU. Reference Manual 1749 Seiten lang. Architekturdokumentation geschätzt nochmal mindestens 1000 Seiten. ISA ist da noch nicht mit eingerechnet. Ein unglaublich komplexes Teil.

Errata Sheet: 41 Seiten. Mit so Sachen wie (um jetzt mal bei der FPU zu bleiben) wenn ein VDIV oder VSQRT genau 14 Zyklen nach Start durch ein iret unterbrochen wird, dann kommt da Murks raus. Der Tipp ist, wenigstens zwei Instruktionen (!) im ISR auszuführen, dann passiert das nicht. Oder ein Problem, das praktisch nicht auftritt, wenn man Hochsprachen-Code schreibt: "As of today, no compiler generates these particular instructions. This limitation can only occur with hand-written assembly code."

Was ich sagen will ist: Die SoCs von heute sind hundertfach, vielleicht sogar tausendfach komplexer als die vor 40 Jahren. Und trotzdem sind die Bugs signifikant geringer oder deren Impakt ist dokumentiert und umschiffbar. Insbesondere auf so Sachen, wie dass die dutzenden internen Clockdivider nach einem Reset halt bestimmte Werte haben müssen, darauf

Ganz ausdrücklich heißt das nicht, dass ich den Debuggingaufwand und die Workarounds von damals, wie du sie z.B. beschriebenen hast, geringschätze. Genau das Gegenteil ist der Fall, ich glaube dir 100%ig was für eine elendige Suche das gewesen sein muss und wie viel Ärger es einem beschert hat. Aber die Tipps von damals funktionieren auf einem modernen SoC unverändert anwenden zu wollen, wo sie schlicht nicht funktionieren *können* (Stichwort z.B. Supervisor/Usermode), ist halt völliger Quatsch.

Viele Grüße, Johannes

Hallo Hans-Peter,

Du schriebst am Sat, 12 Oct 2019 01:17:29 +0200:

Das ist deswegen unsinnig, weil der bei Benutzung als "GPIO", wenn schon vorgesehen, dann wenigstens elektrisch abgekoppelt und auf seinem Ruhepegel gehalten werden sollte. Schließlich ist das keine mißbräuchliche Verwendung, sondern eine vorgesehene Alternativnutzung.

Am 12.10.2019 um 21:10 schrieb Sieghard Schicktanz:

Vorgesehen ist dann anscheinend entweder GPIO oder SPI, nicht beides gleichzeitig. Wenn Dir das nicht gefällt, nimm was anderes oder beschwere Dich beim Hersteller so lange, bis er den Chip nach Deinen Vorstellungen ändert.

DoDi

Hallo Hans-Peter,

Du schriebst am Sun, 13 Oct 2019 08:36:20 +0200:

Wieso ist Dein Zitat so zerrupft?

Was halt schlecht ist und anscheinend auch der Dokumentation widersprach.

Nu beruhig' Dich mal wieder, wenn Du Dich oder Dir wichtiges angegriffen gefühlt hast, und lies die Vorpostings nochmal. _Ich_ hatte da kein Problem, nur die mir bekannte und übliche Verfahrensweise zu erklären versucht. Mit dem genannten Chip hab'ich nichts zu schaffen.