C tut weh!

[Klaus Butzmann]

Am 11.10.2019 um 13:34 schrieb Helmut Schellong:

On 10/11/2019 09:29, Johannes Bauer wrote: Auch bei aktuellen uC
funktioniert nicht immer alles makellos.

Bei uns wurde z.B. ein zusätzlicher externer WatchDog eingefßhrt. Der
interne war eben nicht ganz einwandfrei. RST wird von einem
BrownOut-IC betätigt.
Frag' mal Joerg dazu, - - - ich hole schonmal Popcorn

Butzo

 

[Johannes Bauer]

On 11.10.19 15:54, Klaus Butzmann wrote:

Bei uns wurde z.B. ein zusätzlicher externer WatchDog eingefßhrt. Der
interne war eben nicht ganz einwandfrei. RST wird von einem
BrownOut-IC betätigt.

Frag' mal Joerg dazu, - - - ich hole schonmal Popcorn

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

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Gerhard Hoffmann]

Am 11.10.19 um 17:31 schrieb Johannes Bauer:

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.

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

 

[Stefan Reuther]

Am 11.10.2019 um 11:34 schrieb MaWin:

"Stefan Reuther" <stefan.news@arcor.de> schrieb im Newsbeitrag
Was braucht man im richten Leben öfter, das Lösen von Rechen- oder
Logikaufgaben jedweder Art oder den Sprung an den Resetvektor?

Was ist das für eine bescheuerte Frage ?

Wenn eine Programmiersprache etwas nicht bietet was man braucht,
und man es auch nicht nachrüsten kann,
dann ist sie für manche Jobs einfach unbrauchbar.

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

 

[Helmut Schellong]

On 10/11/2019 13:49, Johannes Bauer wrote:

On 11.10.19 13:34, Helmut Schellong wrote:

Auch bei aktuellen uC funktioniert nicht immer alles makellos.

Bei uns wurde z.B. ein zusätzlicher externer WatchDog eingefßhrt> Der interne war eben nicht ganz einwandfrei.
RST wird von einem BrownOut-IC betätigt.

Hardware kann natĂźrlich immer Errata haben, aber ein nicht richtig
funktionierender WDT ist schon *richtig* Ăźbel. Das ist ja die *eine*
Komponente, die alles noch irgendwie retten soll, wenn in dem Rest Murks
passiert. Was war das denn fĂźr ein SoC?

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

Wenn ich mich nicht darauf verlassen kann, was mir im Datenblatt
garantiert wird (z.B. eben definierte Werte der Peripherie-Register und
dessen Zustand) dann habe ich da vermutlich noch ganz andere Probleme.

Es ist trotzdem schlicht auf einem modernen System unrealistisch,
lediglich in Software einen Reset ausfĂźhren zu wollen: Zum einen, dass
man mĂśglicherweise gar nicht die Privilegien dazu hat und an den
Reset-Vektor springen kann, wie man will und mag -- nur halt wegen
fehlender Berechtigungen das System nicht resetten darf. Zum anderen,
weil da im Hintergrund, parallel, dann z.B. noch irgendwo ein DMA wild
rumwurstelt oder der Interrupt-Controller "undefiniertet" konfiguriert ist.

Wir haben privilegierte GeheimmenĂźs gehabt.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm

 

[Falk Willberg]

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

Wenn ich mich nicht darauf verlassen kann, was mir im Datenblatt
garantiert wird

In letzter Zeit habe ich eher das Problem, die Datenblätter zu lesen.
Selbst das reference manual eines ziemlich simplen Cortex-M0+ (KL16
https://cache.freescale.com/files/microcontrollers/doc/ref_manual/KL16P80M48SF4RM.pdf)
umfasst 825 Seiten.

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
--
Microsoft ist aus einer Kooperation der Borg und der Ferengi
entstanden.
Leider arbeiten die Ferengi in der Entwicklungsabteilung und die Borg im
Marketing

 

[Hans-Peter Diettrich]

Am 12.10.2019 um 00:04 schrieb Falk Willberg:

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

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

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

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

DoDi

 

[Wolfgang Allinger]

On 11 Oct 19 at group /de/sci/electronics in article qnq907$flt$1@solani.org
<dk4xp@arcor.de> (Gerhard Hoffmann) wrote:

Am 11.10.19 um 17:31 schrieb Johannes Bauer:

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.

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!

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.

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.

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

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Gerhard Hoffmann]

Am 12.10.19 um 01:54 schrieb Wolfgang Allinger:

On 11 Oct 19 at group /de/sci/electronics in article qnq907$flt$1@solani.org
dk4xp@arcor.de> (Gerhard Hoffmann) wrote:


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!

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, bei mir war's die Korngrößenbestimmung von Stahl per
UltraschallrĂźckstreuung in einer PrĂźfmaschine fĂźr die
innere ReaktorumhĂźllung.

Gerhard

 

[Wolfgang Allinger]

On 12 Oct 19 at group /de/sci/electronics in article qnrirg$au6$1@solani.org
<dk4xp@arcor.de> (Gerhard Hoffmann) wrote:

Am 12.10.19 um 01:54 schrieb Wolfgang Allinger:

On 11 Oct 19 at group /de/sci/electronics in article
qnq907$flt$1@solani.org <dk4xp@arcor.de> (Gerhard Hoffmann) wrote:


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!

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, bei mir war's die Korngrößenbestimmung von Stahl per
Ultraschallrückstreuung in einer Prüfmaschine für die
innere Reaktorumhüllung.

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

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Johannes Bauer]

On 11.10.19 18:01, Gerhard Hoffmann wrote:

Am 11.10.19 um 17:31 schrieb Johannes Bauer:

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.

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!

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
*muss* ich mich verlassen kĂśnnen, sonst bin ich direkt im
Undefined-Behavior-Land. Das kann ich auch nicht mehr retten, indem ich
programmatisch da nochmal "doppelt hält besser" die Register erneut setze.

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

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Sieghard Schicktanz]

Hallo Hans-Peter,

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

Und dann war da noch das SPI des LPC2220(?), dessen zugeordneter CS-Pin
nicht benĂśtigt wird, aber nicht als GPIO verwendet werden kann, we
il er > zwingend auf "1" liegen muß, weil sonst das SPI nicht funktioniert
....
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. ..

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.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Hans-Peter Diettrich]

Am 12.10.2019 um 21:10 schrieb Sieghard Schicktanz:

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.

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

 

[Sieghard Schicktanz]

Hallo Hans-Peter,

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

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

Wieso ist Dein Zitat so zerrupft?

Vorgesehen ist dann anscheinend entweder GPIO oder SPI, nicht beides
gleichzeitig. Wenn Dir das nicht gefällt, nimm was anderes oder beschwere

Was halt schlecht ist und anscheinend auch der Dokumentation widersprach.

Dich beim Hersteller so lange, bis er den Chip nach Deinen Vorstellungen
ändert.

DoDi

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.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------