mikrocontroller.net

Forum: Projekte & Code ARM Cortex-M3/4/7 Faulthandler


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:
Angehängte Dateien:

Bewertung
4 lesenswert
nicht lesenswert
Da wollte ich doch mal mein Faulthandlerbeispielcode veröffentlichen.
Nach etwas aufräumen und GPLv3 Lizensieren gibts das jetzt hier als 
Download.
Eine pdf mit Vortragsfolien liegt auch bei (ja ich hab darüber mal einen 
Vortrag gehalten).

Ausführbar direkt auf einem STM32F4xx Discovery auf dem UART3 mit 
115200Baud und SWO (über ST-Link).

Was kann das jetzt?
- sämtliche Faulthandler registrieren und den div0 Trap aktivieren.
- die Faulthandler geben dann einen Registerdump auf dem UART aus und 
die Adresse des Fehleruftretens
- bei div0 und udf wird ein mini Disassembly ausgeführt um die udf 
Nummer und div Register zu sehen
- die Handler nutzen ein eigenes mini printf, weil das System printf 
nicht mehr vertraunswürdig ist, da es ja den Heap nutzt.
- den printf STDO auf SWO umbiegen und ausgeben

Wenn noch was fehlt, dann wünscht euch was.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> und GPLv3 Lizensieren

GPL3 ist ungünstig für µC code, oder willst Du die Verwendung in 
kommerziellen Projekten kategorisch ausschließen?

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Verwendung in kommerziellen Projekten kategorisch ausschließen

Seit wann darf man GPL3-lizensierten Code nicht in kommerziellen 
Projekten nutzen?

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Er meinte ja nichts von "darf man nicht", sondern es geht ihm wohl ums 
Copyleft bei Änderungen.
Wer z.B. einen anderen UART print im Faulthandler nutzt ändert 
zwangsweise den Code und muss ihn damit wieder unter der GPLv3 
veröffentlichen.
Code veröffentlichen ist in kommerziellen Produkten nicht so gerne 
gesehen.
(Closed Source)

Aber alles was aus meinem Bastelkeller kommt ist sowieso nicht 
kommerziell und bekommt daher GPLv3.
Das ist und bleibt freie Software ;)

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> sondern es geht ihm wohl ums Copyleft bei Änderungen.

Ich wusste schon, was er meint. Trotzdem ist die Folgerung, man schließe 
damit kommerzielle Projekte kategorisch aus, einfach falsch. Aber das 
ist ein anderes Thema und damit offtopic.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Wer z.B. einen anderen UART print im Faulthandler nutzt ändert
> zwangsweise den Code und muss ihn damit wieder unter der GPLv3
> veröffentlichen.

Nicht nur wer ihn ändert, wer diesen Handler so wie er ist nur in seiner 
Firmware einbaut muß damit schon seine komplette Firmware unter GPL3 
veröffentlichen.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:

> Nicht nur wer ihn ändert, wer diesen Handler so wie er ist nur in seiner
> Firmware einbaut muß damit schon seine komplette Firmware unter GPL3
> veröffentlichen.

Oder wie bei Qt unter einer anderen Lizenz kaufen - wenn der Autor sich 
darauf einläßt. Oh, das kostet dann ja Geld?

Gegenfrage: welches Interesse sollte man eigentlich haben, seinen Code 
unentgeltlich kommerziellen Parteien zur Verfügung zu stellen, die dafür 
weder Geld noch andere Projektsourcen zurückgeben?

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
> Gegenfrage: welches Interesse sollte man eigentlich haben, seinen Code
> unentgeltlich kommerziellen Parteien zur Verfügung zu stellen, die dafür
> weder Geld noch andere Projektsourcen zurückgeben?

Kommt auf den Einzelfall an. Es soll auch Leute geben die teilen ihr 
Wissen einfach so, Gegenleistung ist dann allein die Gewissheit daß dem 
Empfänger damit geholfen ist und manchmal reicht das. Hab ich auch schon 
das eine oder andere mal gemacht.

Autor: W.S. (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Nop schrieb:
> Gegenfrage: welches Interesse sollte man eigentlich haben, seinen Code
> unentgeltlich kommerziellen Parteien zur Verfügung zu stellen, die dafür
> weder Geld noch andere Projektsourcen zurückgeben?

Es ist die Hoffnung, daß der Betreffende daraus etwas lernt und ein 
besserer Ingenieur wird. Da ist ein wenig der Gedanke dabei, das Niveau 
der Zunft hochzuhalten. Von den Bildungsanstalten ist da nicht wirklich 
viel zu erwarten. Also muß es ja jemand den Neulingen nach deren 
Berufseinstieg beibringen.

Und da du partout nach schnöden materialistischen Beweggründen Ausschau 
hältst, sei es mal so gesagt: Da zumeist die Jüngeren noch weniger 
wissen als die Älteren, später aber den Älteren mal ihre Rente 
erwirtschaften sollen, ist es durchaus eine weise Voraussicht, den 
Jüngeren etwas beizubringen - damit sie ihren Beruf besser ausüben 
können und unsere hiesige Wirtschaft so gut es geht dasteht.


Aber mal zum eigentlichen Thema:

Der TO hat sein Projekt - soweit ich das sehe - zuvörderst darauf 
ausgerichtet, daß man über einen irgendwie angeschlossenen PC eine 
lesbare Aussage erhält, wenn ein Fault aufgetreten ist. Das ist schön, 
recht und gut. Aber es wird für den praktischen Einsatz des µC 
eigentlich nicht gebraucht, sindern eher für den Programmierer in der 
Entwicklung.

Ich mache es deshalb bei meinem Zeugs um einiges einfacher: Bei einem 
Fault wird dieser in einem Fehler-Merkwort vermerkt und dann wird die 
Firmware neu gestartet. Auf alle Fälle kriegt damit der µC eine Chance 
zum Wiederanlauf und/oder zum Einnehmen eines sicheren Zustandes (oder 
was man in der betr. Anwendung gerade für nötig hält). Da ist allemal 
besser als das alberne "B ." also das komplette Steckenbleiben in der 
Exception ohne Reaktionsmöglichkeit.

Das Ganze funktioniert jedoch nicht immer und so vermute ich, daß auch 
das Fault-Projekt des TO nicht immer funktioniert. Ein prominentes 
Beispiel ist das Überfahren der Chipgrenze eines angeschlossenen SDRAM 
(z.B. beim LPC4088 und anderer µC, die das gleiche SDRAM-Interface 
enthalten).

Wenn man hinter die letzte Adresse so eines SDRAM's schreibt, dann 
friert der µC sang- und klanglos ein, OHNE daß es irgend einen Fault 
gibt.

W.S.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo W.S. ;)

W.S. schrieb:
> Der TO hat sein Projekt - soweit ich das sehe - zuvörderst darauf
> ausgerichtet, daß man über einen irgendwie angeschlossenen PC eine
> lesbare Aussage erhält, wenn ein Fault aufgetreten ist. Das ist schön,
> recht und gut. Aber es wird für den praktischen Einsatz des µC
> eigentlich nicht gebraucht, sindern eher für den Programmierer in der
> Entwicklung.

Ja Richtig, beim Entwickeln des Programms wird das eher gebraucht.
Selbst beim Debuggen muss man den Fehler erstmal eingrenzen man stept 
über eine Funktion und der Debugger macht nix mehr.
Weil man im Hardfault steckt.
Dann kan mann natürlich immer weiter runter reinsteppen oder sich die 
Fault Ausgabe angucken welche die Adresse ausspuckt und auch direkt die 
Register anzeigt um zu sehen was die eingangsparameter waren.
Dann sieht man im ASM Listing schonmal inw elcher Funktion nachzusehen 
ist.
Jetzt könnt man zwar auch Breakpoints auf den Faulthandler legen, aber 
will man denn die kostbaren HW Breakpoints dafür verblasen?

W.S. schrieb:
> Ich mache es deshalb bei meinem Zeugs um einiges einfacher: Bei einem
> Fault wird dieser in einem Fehler-Merkwort vermerkt und dann wird die
> Firmware neu gestartet.

Wohin kommt das?
Meine Faulthandlerausgabe ließe sich auch abspeichern, aber das ist so 
universal möglich, dass ich da erstmal nichts einprogrammiert habe.
Im Flash bei den großen STM32 ist ungünstig, weil die mal eben 128k 
Pages haben. Bei kleinen STM32L4xx mit 2k pages kann man sich ein Round 
Robin bauen welcher die letzten Abstürze speichert.
Oder SD Karte oder EEPROM oder oder oder.
Daher hab ich das rausgelassen und jeden freigestellt ob er es 
abspeichern will oder nicht und wenn ja wohin.

Neustarten ist auch nicht immer super wenn der Fehler bestehen bleibt 
wegen nicht abgefangener Eingangfsparameter und das Gerät dann eine 
Dauerschleife fährt.
Dann doch liebern Alarmausgang setzen?
Wobei das jetzt auch nicht allgemeingültig ist und von Anwendungsfall zu 
Anwendungsfall abgewogen werden muss.
Da denkst du etwas zu sehr innerhalb deines Tellerrandes.

W.S. schrieb:
> Da ist allemal
> besser als das alberne "B ." also das komplette Steckenbleiben in der
> Exception ohne Reaktionsmöglichkeit.

Er reagiert doch?
Es gibt eine Funktion die erstmal alles in einen sicheren Zustand packt.
Ewiges neustarten was zum Zucken eines Motors führt oder ständiges auf 
und zu eines ventils ist eher ... doof.
Diese Funktion ließe sich ja auch so erweitern, dass diese befehle per 
UART empfängt für ein gewolltes Neustarten unter Aufsicht.

W.S. schrieb:
> Das Ganze funktioniert jedoch nicht immer und so vermute ich, daß auch
> das Fault-Projekt des TO nicht immer funktioniert. Ein prominentes
> Beispiel ist das Überfahren der Chipgrenze eines angeschlossenen SDRAM
> (z.B. beim LPC4088 und anderer µC, die das gleiche SDRAM-Interface
> enthalten).

Dann hast du die MPU nicht richtig benutzt?
Wo kein RAM ist wird per MPU gesperrt.
Dann gibts einen MemManageFault wenn du über das RAM Ende Zugreifst.
RAMs kommen ja glücklicherweise in 2^n Größen und so brauchts erstmal 
keine Subregions der MPU.
Das erinenrt mich daran, dass ich die MPU Funktionalität noch umbauen 
wollte.
Der soll sich mal automatisch die benötigten Subregions ausrechnen 
(optional).

W.S. schrieb:
> Wenn man hinter die letzte Adresse so eines SDRAM's schreibt, dann
> friert der µC sang- und klanglos ein, OHNE daß es irgend einen Fault
> gibt.

Kommt drauf an!
Die Adressleitungen wrappen, also wird der RAM wieder von vorne gelesen.
Was da steht wird dann ausgeführt.
zB kann er dann ausversehen einen IRQ Vektor der NVIC Tabelle als Befehl 
ausführen wollen.
Mit etwas Glück ist das dann eine undefined Instruction.
Damit man nicht Glück haben muss, sondern unter Garantie dies abfängt:
-> MPU, siehe ein Absatz drüber.

Und natürlich sind solche Faulthandler etwas nischig.
Ich nutz die gerne, mir bringts was, also Teile ich sie hier.

W.S. schrieb:
> Von den Bildungsanstalten ist da nicht wirklich
> viel zu erwarten. Also muß es ja jemand den Neulingen nach deren
> Berufseinstieg beibringen.

Ich war Tutor an der Uni und da gruselts einem ;)
Das bin ich jetzt ncht mehr, ich hab den Vertrag auslaufen lassen und 
bin komplett in die Industrie gewechselt.
Wenn man plagiatierende Studis nicht rauswerfen kann, weil der Rückhalt 
der Verwaltung fehlt und die einem auf der Nase rumtanzen können, dann 
bin ich raus.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:

> Es ist die Hoffnung, daß der Betreffende daraus etwas lernt und ein
> besserer Ingenieur wird.

Lernen kann er auch aus GPL-Software. Wenn er die nicht direkt einsetzen 
kann, lernt er daraus sogar mehr, als wenn er bloß copy/paste macht.

> Da ist allemal
> besser als das alberne "B ." also das komplette Steckenbleiben in der
> Exception ohne Reaktionsmöglichkeit.

Wieso, wenn man den Watchdog benutzt, was man in der Release-Variante 
ohnehin tun sollte, dann ist das äquivalent zu eiem sauberen Vollreset.


Mw E. schrieb:

> Wohin kommt das?

F4 hat ein 4K großes Backup-RAM, was batteriegepuffert sogar das 
Ausschalten des Gerätes überlebt. Das kann man hervorragend als 
Flash-Ersatz für Sachen wie Konfiguration und Fehlerzustände benutzen.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Mw E. schrieb:
>
>> Wohin kommt das?
>
> F4 hat ein 4K großes Backup-RAM, was batteriegepuffert sogar das
> Ausschalten des Gerätes überlebt. Das kann man hervorragend als
> Flash-Ersatz für Sachen wie Konfiguration und Fehlerzustände benutzen.

Ich meinte ja wo W.S. das bei sich speichert.

Bei mir jedenfalls nutze ich den Backupram meist nicht, weil ich eine 
externe RTC mit 3ppm TCXO nutze.
Daher hängt da auch kein VBAT dranne, dann nuckeln ja 2 Geräte an der 
Batterie.
Aber eine Überlegung ist es Wert.
Nur wenn da schon jemand Configs drinnen ablegt ists Essig mit Faults da 
reinlegen.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:

> Daher hängt da auch kein VBAT dranne, dann nuckeln ja 2 Geräte an der
> Batterie.

Die paar µA sind kaum der Rede wert - zumal im eingeschalteten Zustand 
das Backup-RAM ja nicht von VBAT, sondern von VCC gespeist wird. Man 
kann ja auch nur das Backup-RAM powern, die RTC aber abgeschaltet 
konfigurieren.

> Nur wenn da schon jemand Configs drinnen ablegt ists Essig mit Faults da
> reinlegen.

Nur, wenn die 4k schon komplett dafür verbraucht werden. Aber selbst 
dann hat man immer noch die Backup-Register, die man benutzen kann. Etwa 
die Register-Bytes fest für Fehlernummern allozieren, dann den 
jeweiligen Fehlercounter hochzählen und bei 255 kappen.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... oder, falls kostenmäßig möglich, man klemmt einen Goldcap über eine 
Schottky-Diode und Vorwiderstand an VCC und speist VBAT von da aus. Das 
langt auch locker für zwei Wochen ohne Saft.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal ins DB vom F407 gucken.
Backup SRAM ON, RTC OFF -> 5µA max.

DS3231 auf VBAT -> 3µ, aber 575µA Peaks zur Temperaturkompensation

CRC2032 hat 220mAh bei einer Last von max 10k.

Das sind dann nurnoch 3 Jahre Laufzeit, statt 8J.


Für Geräte die nicht immer laufen durchaus ein Einschnitt, aber wenn ich 
mal ne freie Minute habe kann ichs ja mal einbauen.
Klingt nämlich garnicht so abwegig.

Autor: Jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Mw E. schrieb:
>> sondern es geht ihm wohl ums Copyleft bei Änderungen.
>
> Ich wusste schon, was er meint. Trotzdem ist die Folgerung, man schließe
> damit kommerzielle Projekte kategorisch aus, einfach falsch. Aber das
> ist ein anderes Thema und damit offtopic.

Ich finde die Frage, wie viele kommerzielle Projekte ein Umprogrammieren 
der Mikrocontroller zulassen (wollen oder überhaupt dürfen) und dem 
Nutzer eine Anleitung zum Ausführen des modifizierten Werks geben 
würden, viel interessanter.

Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Mw E. schrieb:
> Ich meinte ja wo W.S. das bei sich speichert.

Es ist doch völlig simpel. Wirklich.

Es wird im Startupcode aufgefangen und im normalen internen RAM 
abgespeichert und steht dann für main() zur Verfügung. Dort kann man 
dann entscheiden, was zu tun ist. Also ob man normal hochfährt oder ob 
man lieber auf irgend eine Art Not-Zustand geht. Das ist dann Sache der 
konkreten Firmware - woher soll ich denn wissen, was ich nächstes jahr 
programmieren werde?

Das ist übrigens auch ein Grund, weswegen ich bei den Kinetis MKE die 
Einstellregister für die Pinverwendung vermisse. Beim Wiederanlauf nach 
einem Fault müssen all diese Dinge ja wieder geregelt werden - und zwar 
aus einem unbestimmten Zustand heraus. Unser Freescale-Fan hier im Forum 
sieht das nicht ein, da er grundsätzlich davon ausgeht, daß er ja einen 
Kaltstart mit definiertem HW-Zustand vorfindet. Aber in solchem Falle 
gilt das überhaupt nicht.

Und das schiere Reset aus dem WD heraus macht auch nicht so glücklich, 
auch wenn man bei vielen µC herausfinden kann, woher der Reset denn kam.

Nun ja, bei vielen Anwendungen ist das alles wohl etwas weniger wichtig, 
aber ein Wiederanlauf ist mMn allemal besser als der 'B .'

W.S.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Das ist übrigens auch ein Grund, weswegen ich bei den Kinetis MKE die
> Einstellregister für die Pinverwendung vermisse. Beim Wiederanlauf nach
> einem Fault müssen all diese Dinge ja wieder geregelt werden

Was hat das eine mit dem anderen zu tun? Auch beim MKE ist die 
Verwendung der Pins für Peripheriefunktionen vollkommen eindeutig 
konfigurierbar. Nenn doch mal ein konkretes Beispiel das verdeutlicht 
worauf Du da jetzt eigentlich hinauswillst, was diesbezüglich beim einen 
geht und beim anderen nicht, vor allem im Zusammenhang mit dem 
Faulthandler von dem hier die Rede ist, ich seh da jetzt irgendwie nicht 
den Zusammenhang.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Was hat das eine mit dem anderen zu tun?

Na ALLES!
Stell dir vor, du hast eine projektspezifische Setup-Unit, die zumindest 
den Takt und die Pinverwendung aufsetzen soll. Und zwar aus einem 
BELIEBIG vergurkten Systemzustand heraus, wo man sich auf kein einziges 
Default verlassen kann. Eben weil Setup nicht nur nach HW-Reset, sondern 
auch nach einem Fault funktionieren soll. Das Einzige, was man dabei 
annehmen darf ist, daß es überhaupt einen Takt gibt und die CPU 
tatsächlich Befehle abarbeitet.

Jetzt Klaro?
Aber laß mal die weiteren Diskussionen darüber an diese Stelle, es wird 
sonst zu sehr O.T.

W.S.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Und zwar aus einem
> BELIEBIG vergurkten Systemzustand heraus,

in einem beliebig vergurkten Zustand lass ich ihn lieber einen Reset 
machen, dann weiß ich woran ich bin, oder wieviele Jahre lang soll man 
das debuggen bis man alle Eventualitäten abgefangen hat? Welchen Wert 
hat es irgendwas von dem halb-kaputten Zustand zu erhalten? Weg damit! 
Alles neu!

Da such ich doch lieber die Ursache des Fehlers und sorge dafür daß der 
gar nicht erst eintreten kann!

Wenn ich nach nem Reset alles wieder komplett genau so initialisiere wie 
es sein muss ist alles wieder richtig. Ich versteh nicht was es für 
einen Einfluß haben soll wo genau nun die Handvoll Bits untergebracht 
sind mit denen die Funktionen der Pins konfiguriert werden, wen ich der 
Reihe nach die Peripherien wieder einschalte und initialisiere sind die 
hinterher alle wieder richtig.

: Bearbeitet durch User
Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Da such ich doch lieber die Ursache des Fehlers

kannst du vergessen. Bei Elektronik in störverseuchtem Gefilde suchst du 
bis zur Rente ohne was gefunden zu haben.

Und bei einem µC, der sich eben nicht systematisch wieder einrichten 
läßt (jedenfalls nicht mit überschaubarem Aufwand) bleibt tatsächlich 
nur der Reset. Oder ein anderer µC, der das besser kann.

Nun ja, Absturzbehandlung ist immer ein ekliges Thema.

W.S.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
W.S. schrieb:
> Und bei einem µC, der sich eben nicht systematisch wieder einrichten
> läßt (jedenfalls nicht mit überschaubarem Aufwand) bleibt tatsächlich
> nur der Reset.

"Systematisch einrichten"

Hör doch endlich auf! Der MKE lässt sich genauso systematisch (einfacher 
sogar) konfigurieren als die größeren und komplexeren Examplare, ich 
weiß nicht wie Du auf die Idee kommst der wäre nicht deterministisch 
oder was auch immer für ein Käse dir da vorschwebt, nur weil die besagte 
Konfiguration (sogar deutlich weniger Bits insgesamt) dort in anderen 
Registern stehen die anders heißen als bei den größeren Exemplaren aber 
genauso einer simplen Systematik folgen und unterm Strich exakt das 
selbe bewirken!

Das hab ich Dir in mehreren anderen Threads schon mehrfach und 
vollkommen erschöpfend erklärt! Denn im Gegensatz zu Dir verwende ich 
den schon jahrelang 8 Stunden am Tag und könnte Dir jedes einzelne Bit 
erklären! Du hingegen hast vor 2 Jahren mal 5 Minuten lang das Handbuch 
überflogen und ein Demo-Board unbenutzt in die Schublade gelegt und 
wirst seither nicht müde Aussagen darüber aus dem Bauch heraus zu 
treffen, unbeleckt von jeglicher praktischer Erfahrung mit dem Gerät!

Und außerdem hat das mit dem Thema in diesem Thread gar nichts zu tun, 
der MKE auf dem Du hier ständig ungefragt herumreitest ist ein extrem 
simpel gestrickter kleiner M0+ der alte 8-Bitter ersetzen soll und ne 
Peripherie hat die man von der Komplexität her (und auch von Flash- und 
RAM-Umfang her) am ehensten mit nem aufgebohrten ATMega vergleichen kann 
und für ähnlich komplexe Aufgaben verwendet wird und hier im Thread 
gehts aber um Hardfault-Handler von M3 und aufwärts und nicht darum wie 
bei irgendeinem der 1001 verschiedenen ARMs die es da draußen gibt 
zufällig die Konfig-Bits für das Pin-Multiplexing heißen und in welchen 
Registern die dort zu stehen belieben!

: Bearbeitet durch User
Autor: W.S. (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Hör doch endlich auf!

Genau DAS hab ich dir schon vor langem nahegelegt und tue es hiermit 
noch einmal ausdrücklichst. Ich teile deine Ansicht in diesem 
speziellen Punkt NICHT und du wirst mich auch nicht zu irgendwas 
überreden können, denn ich mache meine Einschätzungen selbst und ich 
treffe auch meine Entscheidungen selbst.

Ein finaler Vorschlag meinerseits: Mach einfach ein nettes 
Minimalprojekt mit Eagle und Keil und poste dies hier. Das würde 
vielleicht manchem helfen.

W.S.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> mit Eagle und Keil

Ja klar. Ich und Eagle und Keil. Als ob ich nichts besseres zu tun 
hätte.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Jetzt mal mein finaler Vorschlag an dich W.S. :
Einfach mal den Rand halten!

Du plärrst hier andauernd das Forum zu mit deinen falschen Ansichten und 
Aussagen und zwingst es Leuten gradezu auf.
Belehren lässt du dich nicht obwohl andauernd Leute gegen deinen 
Dünnpfiff gegensteuern. Jedesmal kommste aufs neue mit demselben Murks.
Du bist einfach nur borniert und ein Geisterfahrer auf der Autobahn.

Alleine mit deinem Magic Number Code diskreditierst du dich selbst wenn 
es um irgendwelche Bereiche zu Codedesign oder Programmarchitektur geht.

: Bearbeitet durch User
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Es ist doch in P&C immer wieder dasselbe:

Jemand stellt ein Projekt auf die Beine, dann kommt W.S. und sagt: 
"Alles Scheiße. Mach es anders! Und zwar so, wie ich es mir vorstelle! 
Am besten sieht es so aus wie meine Lernbetty!".

@W.S. Jeder hat die Freiheit, es so zu machen, wie er will. Er hat 
sogar die Freiheit, es so zu machen, wie Du es nicht willst. Damit 
musst Du leben.

Wenn Du ein Programm haben möchtest, das sich an Deine Vorstellungen 
hält, dann schreib es selber!

Das willst Du gar nicht? Achso, Du möchtest die Programme, über die Du 
hier dauernd mit "Weisheiten" aus den 80ern des letzten Jahrtausends 
herziehst, gar nicht nutzen, nur ein wenig stänkern?!? Geh spazieren... 
oder Golf spielen. Das beruhigt.

: Bearbeitet durch Moderator
Autor: W.S. (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Frank M. schrieb:
> Jemand stellt ein Projekt auf die Beine, dann kommt W.S. und sagt:
> "Alles Scheiße.

Nö.

Hab ich nie gesagt und nicht einmal gedacht.

Und der ganze Rest ist ein Haufen von Unterstellungen und hysterischem 
Geschrei - und zwar von all denen, die hier den Rest dieses Threads 
kaputtmachen wollen.

Ich nicht. Ich hab nur dargelegt, daß und wie ich es standardmäßig etwas 
einfacher mache. Damit soll lediglich der Wiederanlauf geregelt werden, 
was natürlich deutlich weniger Funktionalität ist als das, was 
hiervorgestellt worden ist. Ist aber auch weniger Maschinencode dafür 
nötig.

Das ist kein Grund für euch alle, hier derart ausfällig zu werden. Reißt 
euch mal zusammen und verkneift euch bittesehr persönliche Anfeindungen! 
Würdet ihr euch auch derart daneben benehmen, wenn wir uns am 
Konferenztisch gegenüber säßen?

W.S.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Wenn mir so ein bornierter Gegenüber sitzt, der zu jeder Sitzung 
denselben Müll erzählt auch wenn schon x mal widerlegt.
Ja dann bekommt er von mir genauso Klartext zu hören.

So, jetzt zügel dich mal und Spam das Forum hier nicht so zu mit deinen 
verquerten Ansichten, die vorne und hinten falsch sind.

Du scheinst garnicht zu merken, dass du da in einer Parallelwelt hockst.
Dir wurde jetzt hier im Forum auch schon mehrmals daregelgt, das du auch 
keine Ahnung von C hast, aber so tust wie der größte Programmierer aller 
Zeiten mit den allerbesten Ratschlägen.

Bist du aber nicht, also sei mal leise.

W.S. schrieb:
> und zwar von all denen, die hier den Rest dieses Threads
> kaputtmachen wollen.
Fass dir da mal ganz doll an die eigene Nase.
Überleg mal wer hier mit den Kinetis angefangen hat?

Bernd und nop haben bisher zum Thema beigetragen, du nicht.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Würdet ihr euch auch derart daneben benehmen, wenn wir uns am
> Konferenztisch gegenüber säßen?

Ja. Denn wie Du hier in P&C insbesondere die STM32-Projekte kommentierst 
und runtermachst, ist unter aller Kanone.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.