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.
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?
Bernd K. schrieb: > Verwendung in kommerziellen Projekten kategorisch ausschließen Seit wann darf man GPL3-lizensierten Code nicht in kommerziellen Projekten nutzen?
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 ;)
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.
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.
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?
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.
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.
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.
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.
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.
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.
... 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.
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.
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.
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.
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.
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.
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
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.
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
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.
W.S. schrieb: > mit Eagle und Keil Ja klar. Ich und Eagle und Keil. Als ob ich nichts besseres zu tun hätte.
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
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
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.