Forum: Mikrocontroller und Digitale Elektronik Atmega verliert Flashinhalt


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.
von Robert H. (kee4)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo zusammen,
ich habe ein Problem und dazu möchte ich euch befragen:

Ich habe eine größere Anzahl ATMEGA328 über einen Batchjob geflasht. 
Dabei wurde wohl beim Aufruf von AVRDUDE.exe in der Batchdatei der 
BitClock auf 1 gesetzt. Das heist ja 1uS "Verzögerung" beim Flashen.

Die Clock-Fuses die vor dem Flash programmiert werden, stehen auf
"int. RC 8MHz 6CK/14CK +65msec"

Bei 8MHz sollte die BitClock doch kleiner (8MHz * (1/4)) sein also 
kleiner
2 MHz. 2MHz = 0,5usec Bitclock 1 usec wäre größer.

Jetzt sind ein paar Controller ausgefallen. Das Produkt startete und 
während des Tests stellte es seinen Betrieb ein.
Der Bootloader macht beim Starten eine CRC-Prüfung des Flash, diese muss 
zu diesem Zeitpunkt iO gewesen sein, sonst wäre die Application nicht 
los gelaufen.
Eine Analyse ergab, dass einige Pages des Flash auf 0xFF stehen. Die 
Lock-Bits sind gesetzt, aber unser Bootloader bietet die Möglichkeit das 
Flash Pageweise zu lesen.

Fuses:
set lfuse=0xE2
set hfuse=0xCC
set efuse=0xFC
set lock=0x2C

Meine Fragen wären:
- Kennt jemand das Problem?
- kann das am "zu schnellem" Bit-Clock beim Flashen des FLASH liegen?
- die Controller die jetzt noch gehen, kann man sich drauf verlassen, 
dass der Inhalt nicht auch irgendwann umkippt
- Würde neu Flashen mit langsameren Bit-Clock das Problem lösen? Oder 
kann es sein dass das Flash dauerhaft geschädigt ist!

Zusatzinfo:
- Das Produkt läuft schon seit Jahren ohne Probleme.
- Vorher wurde aber mit STK500.exe geflasht und auch langsamer
- Programmer ist ein AVR MKII Clone (Diamex All AVR)
- Verify beim Flashen ist "on"
- Versorgung des Prüflings beim Flashen über Programmer an versorgten 
USB-Hub

Anbei auch die komplette Batchdatei!

zum Thema habe ich nur folgende Artikel gefunden:
Beitrag "Atmega 1284p verliert Programm" (nicht passend)
Beitrag "Atmega8 verliert Programmierung" (nicht passend)
Beitrag "Probleme mit AVRdude - Linux" (INFOS zum Bitclock)

Gruß und Danke allen schon mal
Robert Hoffmann
- KEE4 -

von Adam P. (adamap)


Bewertung
0 lesenswert
nicht lesenswert
Robert H. schrieb:
> Bei 8MHz sollte die BitClock doch kleiner (8MHz * (1/4)) sein also
> kleiner
> 2 MHz. 2MHz = 0,5usec Bitclock 1 usec wäre größer.

Aber das passt doch.
-B 1 entspricht ja 1 µs = 1MHz, das ist kleiner als 2MHz.

Beitrag #6346331 wurde vom Autor gelöscht.
von Arduino Fanboy D. (ufuf)


Bewertung
-2 lesenswert
nicht lesenswert
Robert H. schrieb:
> - kann das am "zu schnellem" Bit-Clock beim Flashen des FLASH liegen?
> - die Controller die jetzt noch gehen, kann man sich drauf verlassen,
> dass der Inhalt nicht auch irgendwann umkippt

Soweit mir bekannt ist für das Schreiben der interne Takt zuständig, 
nicht der ICSP Takt.
Bisher habe ich von noch keiner Methode gehört, wie man den Flash 
Speicher schwächen kann, außer durch Temperatur.



------


Robert H. schrieb:
> set lock=0x2C
Sagt das Datenblatt nicht dazu:
> Further programming and verification of the Flash and EEPROM
> is disabled in Parallel and Serial Programming mode. The Boot
> Lock bits and Fuse bits are locked in both Serial and Parallel
> Programming mode.

Damit ist dann diese aussage hinfällig, oder?
Robert H. schrieb:
> Eine Analyse ergab, dass einige Pages des Flash auf 0xFF stehen.

von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
danke schon mal für die Antworten.

AdamP) so seh ich es auch, die Geschwinigkeit liegt innerhalb der Specs
OliverSo)
> Specify the bit clock period for the JTAG interface or the ISP clock (JTAG ICE 
only)
+ Hier verstehe ich das sich "(JTAG ICE only)" auf "Specify the bit 
clock period for the JTAG interface" bezieht.
+ "or the ISP clock" bezieht sich für mich auf ISP-Programmer an der 
SPI-Schnittstelle

Richtig: Der DIAMEX ist ein "SPI-Programmer"

Gruß
KEE4

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Robert H. schrieb:
> - Versorgung des Prüflings beim Flashen über Programmer an versorgten
> USB-Hub
Wie gut und stabil ist diese Versorgung?

> Fuses:
> set efuse=0xFC
Ist der BrownOut bei den defekten Controllern noch aktiv?

> Eine Analyse ergab, dass einige Pages des Flash auf 0xFF stehen.
So wie dort?
https://electronics.stackexchange.com/questions/116607/avr-flash-memory-corruption

von Bürsti (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Ich glaube nicht, dass ganze Pages einfach so umkippen und sich selbst 
löschen.
Ich glaube eher, dass der Bootloader sie gelöscht hat.
Wie schwer ist es, den Bootloader an die Codestelle springen zu lassen, 
die Pages löscht? Welche Bedingungen sind nötig?
Sind noch Codefehler drin?
Ist Brownout an?

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Robert H. schrieb:
> OliverSo)
>> Specify the bit clock period for the JTAG interface or the ISP clock (JTAG ICE
> only)
> + Hier verstehe ich das sich "(JTAG ICE only)" auf "Specify the bit
> clock period for the JTAG interface" bezieht.
> + "or the ISP clock" bezieht sich für mich auf ISP-Programmer an der
> SPI-Schnittstelle

Ja, daher hatte ich meinen Beitrag dann auch wieder gelöscht.

Wenn allerdings das den Verify nach dem Programmieren erfolgreich 
durchlaufen hat, und der bootloader CRC auch noch durchläuft, dann 
irgendwann später aber einzelne Pages gelöscht sind, dann wäre der 
offensichtlichste Kandidat dafür eben jener bootloader. Herauszufinden, 
warum der das macht, ist jetzt dein Job.

Das du die Brown-out Fuse passend gesetzt und sonstige Probleme mit der 
Spannungsversorgung etc. ausgeschlossen hast, setzte ich jetzt einfach 
mal voraus.

https://electronics.stackexchange.com/questions/116607/avr-flash-memory-corruption

Oliver

: Bearbeitet durch User
von Rolf D. (rolfdegen)


Bewertung
2 lesenswert
nicht lesenswert
Hallo Robert

Hast du die Möglichkeit deine Applikation ohne Bootloader zu testen. 
Vielleicht ist es ja ein Fehler im Bootloader.

Gruß Rolf

von Rolf D. (rolfdegen)


Bewertung
0 lesenswert
nicht lesenswert

von Olaf (Gast)


Bewertung
2 lesenswert
nicht lesenswert
> Vielleicht ist es ja ein Fehler im Bootloader.

Das wuerde ich auch denken. Ich hatte vor vielen Jahre auch mal ein 
Problem mit einem MCS51 Derivat von Atmel. Das wurde gelegentlich mit zu 
geringer Spannung gestartet (Rueckspeisung eines Motors der bewegt wurde 
uns so als Generator lief). Darauf hat dann der Bootloader von Atmel der 
im Prozessor integriert ist gelegentlich zufaellig eine Page im Flash 
geloescht. Und das sogar wenn man den Resetpin dauerhaft auf Reset 
kurzgeschlossen hat.
Jetzt hast du natuerlich einen anderen controller aber immerhin auch von 
Atmel.

Olaf

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Rolf D. schrieb:
> Vielleicht ist es ja ein Fehler im Bootloader.

Ich würde im Bootloader einen Schutz einbauen, damit die SPM-Routine 
nicht versehentlich von einem wilden Pointer aufgerufen wird.
Z.B. ein Enable-Kommando schreibt ein 4 Byte-Pattern in dem RAM und die 
SPM-Routine prüft es. Wenn alle SPM-Aufrufe in einer Funktion erfolgen, 
kann man auch den SP prüfen, ob er genau diesen Level hat.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Beim EEPROm weiß ich mit Sicherheit, dass sogar Lesezugriffe den 
Speicherinhalt zerstören können, wenn die Versorgungsspannung instabil 
oder zu gering ist.

Da Flash Speicher vermutlich nicht viel anders funktioniert, kann ich 
mir vorstellen, dass Flash da ebenfalls empfindlich reagiert.

von Arduino Fanboy D. (ufuf)


Bewertung
-1 lesenswert
nicht lesenswert
Und ich weiß, dass es eine BOD Fuse gibt!
Ganz sicher!

Also:
Wer die BOD Fuse "ausblendet" WILL Probleme.

von N. M. (mani)


Bewertung
0 lesenswert
nicht lesenswert
Gerade was die Versorgungsspannung während des programmieren angeht 
kenne ich auch solche Fälle. Anderer uC Hersteller, aber gleiches 
Problem.

von Robert H. (kee4)


Bewertung
-2 lesenswert
nicht lesenswert
Arduino Fanboy D DANKE FÜR DIE QUALIFIZIERTEN BEITRÄGE!

Arduino Fanboy D. schrieb:

> Soweit mir bekannt ist für das Schreiben der interne Takt zuständig,
> nicht der ICSP Takt.
Aha: Daher darf BitClock maximal 1/4 der Oszillator-Frequenz sein!

>> set lock=0x2C
> Sagt das Datenblatt nicht dazu:
> Further programming and verification of the Flash and EEPROM is disabled
>> Damit ist dann diese aussage hinfällig, oder?
> Eine Analyse ergab, dass einige Pages des Flash auf 0xFF stehen.

Passiert mir auch ständig, dass ich antworte ohne alles verstanden zu 
haben:
Unser Bootloader bietet die Möglichkeit die Pages zu lesen

> Und ich weiß, dass es eine BOD Fuse gibt!
Ich auch
> Ganz sicher!
Da bin ich mir auch sicher
> Wer die BOD Fuse "ausblendet" WILL Probleme.
Ich will aber keine Probleme, deßwegen ist die "Extended Fuses" 0x2C und 
somit ist BrownOut auf 4.3V gesetzt!

DANKE FÜR DIE QUALIFIZIERTEN BEITRÄGE!

Mfg

: Bearbeitet durch User
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Robert H. schrieb:
> ist die "Extended Fuses" 0x2C und somit ist BrownOut auf 4.3V gesetzt!
Ich frage zur Sicherheit einfach nochmal: hast du das bei den korrupten 
Controllern kontrolliert?

von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Lothar,
vielen Dank für deine Antwort und für's Nachbohren!!!
In meiner Batchdatei wird zwar eine Variable gesetzt: set efuse=0xFC

Aber im Aufruf von AVRDude.exe wurde diese Variable nicht als Parammeter 
übergeben. Daher wurden bei allen Boards die Extended-Fuses nicht 
programmiert.

SUPER - Danke für die Hilfestellung - die hat uns weiter gebracht!

Allen anderen auch Danke die uns auf das Verhalten bei nicht 
eingeschalteten BrownOut hingewiesen haben. Das wäre unserer nächster 
Ansatzpunkt der Analyse gewesen.

Ursache war, die Batchdatei AVRDuder.bat wurde von einem ATM16 Projekt 
übernommen und der hat ja kein BrownOut.

Unser 4-fach-Gang-Programmer wurde von STK500.exe (AVRStudio) auf 
AVRDude umgestellt, da Mikisoft nach 28 Tagen die Ausführung von 
STK500.exe unter WIN10 ohne irgend einen Hinweis unterbunden hat. Leider 
lässt sich AVRDude trotz aller Versuche auch nur einmal zweitgleich 
starten!
Wen es interssiert: Beitrag "STK500 aus AVRStudio unter WIN10 ging und jetzt plötzlich nicht mehr" und
Beitrag "Re: STK500 aus AVRStudio unter WIN10 ging und jetzt plötzlich nicht mehr"

DANKE Lothar
Danke allen
Gruß Robert

: Bearbeitet durch User
von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi

>Ursache war, die Batchdatei AVRDuder.bat wurde von einem ATM16 Projekt
>übernommen und der hat ja kein BrownOut.

Wenn du mit ATM16 den ATMega16 meinst. Der hat natürlich einen BOD.

MfG Spess

von Robert H. (kee4)


Bewertung
-1 lesenswert
nicht lesenswert
Hallo spess53,
Danke - hier waren die Finger schneller als der Kopf:
Ich meinte "hat keine ExtenedFuse für's BrownOut"
Danke

: Bearbeitet durch User
von Arduino Fanboy D. (ufuf)


Bewertung
-4 lesenswert
nicht lesenswert
Robert H. schrieb:
> DANKE FÜR DIE QUALIFIZIERTEN BEITRÄGE!
Gerne doch!

Robert H. schrieb:
> Aha: Daher darf BitClock maximal 1/4 der Oszillator-Frequenz sein!
Schaue Datenblatt, und du wirst sehen, dass beides Wahr ist.
1. Es gibt die klare von dir genannte Anforderung für den ISP Takt.
2. Flash benötigt den internen Taktgenerator.

Nachweis für Punkt 2:
http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf
Figure 9-1. Clock Distribution

Merke:
Verstelle den OSCAL Value auf absurde Werte und dein Flash+EEPROM 
schreiben wird versagen. Da kannst du so viele Quarze einbauen und 
nutzen, wie du willst.
Zu finden, da im Datenblatt, wo auch OSCAL und der Speicher erklärt 
wird.
(das findest du selber, wenn du die Augen aufmachst)




Robert H. schrieb:
> Passiert mir auch ständig, dass ich antworte ohne alles verstanden zu
> haben
Offensichtlich!
Selbst nach Hinweis auf die Böcke, welche du schießt, hältst du es für 
wichtiger über andere zu urteilen, als ins Datenblatt zu schauen, oder 
in dich zu gehen.
Das ist in gewisser Weise recht armselig, oder?


Robert H. schrieb:
> Ich will aber keine Probleme, deßwegen ist die "Extended Fuses" 0x2C und
> somit ist BrownOut auf 4.3V gesetzt!
....
> Daher wurden bei allen Boards die Extended-Fuses nicht
> programmiert.
Du siehst!
Aber: Immerhin ein Hauch von Einsicht.
Etwas spät, aber immerhin.

Robert H. schrieb:
> DANKE FÜR DIE QUALIFIZIERTEN BEITRÄGE!
Und ich danke dir dafür, dass du mir vor Augen geführt hast wie boniert 
und abgehoben du sein kannst.
Denn auf dieser Liste stehst du jetzt bei mir.
Auf der Liste derjenigen, die lieber erst den Boten töten, bevor sie 
sich den Problemen stellen.

Merke dir:
Die meisten, welche versucht haben mich zum Idioten abzustempeln, 
durften danach irgendwann feststellen, dass sie selber, die noch viel 
größeren sind.
In dem Punkt, hast du auch, eine feine Vorstellung abgeliefert.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> In dem Punkt, hast du auch, eine feine Vorstellung abgeliefert.
Eines zum Nachdenken: du hast zwar völlig Recht gehabt.
Aber der Witz ist: der Ton macht die Musik (ich weiß das, ich mache 
solche). Und wenn du dann falschen Ton anschlägst oder ihn zu derb 
anschlägst, dann hören die Leute halt einfach nicht mehr zu, auch wenn 
das Lied insgesamt noch erkennbar ist.
Ich habe mit knapp 30 Worten (von denen gut die Hälfte für blumige 
Umschreibungen herhalten mssten) genaus das bewirkt, was ich wollte: 
dass Robert H. mal kontrolliert, ob seine Annahme mit den programmierten 
Fuses schon passt.

> In dem Punkt, hast du auch, eine feine Vorstellung abgeliefert.
Glashaus...  ;-)

Wie auch immer, der grundlegende Mechanismus für korrumpiertes Flash und 
EEPROM ist reine Hardware, völlig unabhängig vom Code(!) oder Bootlader 
oder sonstwas, auch wenn das irgendwie immer angenommen wird:
irgendein Register/Flipflop im µC schaltet die Ladungspumpe ein, die zum 
Löschen des aktuellen Flash-Blocks bzw. der aktuellen EEPROM-Zelle 
benötigt wird. Normalerweise wird dieses Flipflop vom Ablauf der 
internen Programmierungs-FSM gesteuert.
Allerdings können diese beiden Flipflops natürlich durch äussere 
Zustände wie z.B. eine zu niedrige Spannung selber ihren Zustand ändern. 
Und beim BrownOut durch eine "langsam" fallende Versorgung passiert es, 
das irgendwann das Bit "umkippt", die restliche Spannung aber reicht, 
noch die Ladungspumpe zu starten, die dann so lange läuft, dass 
mindestens noch einzelne Bits im Flash/EEPROM auf '1' gelöscht werden 
("langsam" deshalb in Anführungszeichen, weil ja schon ein paar ms zum 
Löschen von Flash/EEPROM ausreichen). Und das passiert an der Stelle, an 
der der Schreibpointer aktuell steht. Blöderweise besteht der Pointer 
auch aus Flipflops, die ihrerseits wegen der fallenden Spannung 
irgendwie (am eheseten in Richtung '0', weil die Spannung ja sinkt) 
umkippen können. Das war dann auch der Grund, warum die EEPROM-Zelle an 
Adresse 0 am ehesten betroffen war.

Und weil das Ganze auch von irgendwelchen internen Fertigungstoleranzen 
abhängt, "funktionieren" ein paar µC auch ohne BOD problemlos, weil dann 
zwar das "Einschalt-Flipflop" umkippt, die Ladungspumpe aber wegen zu 
niedriger Spannung nicht mehr anläuft. Glück gehabt!

: Bearbeitet durch Moderator
von Dietrich L. (dietrichl)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Und weil das Ganze auch von irgendwelchen internen Fertigungstoleranzen
> abhängt, "funktionieren" ein paar µC auch ohne BOD problemlos, weil dann
> zwar das "Einschalt-Flipflop" umkippt, die Ladungspumpe aber wegen zu
> niedriger Spannung nicht mehr anläuft. Glück gehabt!

Ich würde eher sagen "Pech gehabt", denn dann merkt man das erst 
irgendwann später beim Bau weiterer Geräte oder anderen 
Umgebungsbedingungen oder oder oder...
Und dann denkt man an sowas kaum, denn "es hat ja die ganze Zeit 
funktioniert, es kann also kein grundsätzlicher Design-Fehler sein".

von Arduino Fanboy D. (ufuf)


Bewertung
-3 lesenswert
nicht lesenswert
Lothar M. schrieb:
> dann hören die Leute halt einfach nicht mehr zu,
Ein bisschen irre, heute?

Falls du es noch nicht bemerkt haben solltest:
Die "Leute"(einige) verachten mich!
1. Weil ich u.A. Arduino nutze
2. Weil ich Arduino im Namen habe
Die beiden Punkte scheinen in vielen Fällen ausreichend zu sein, um Häme 
und Dreck auszuschütten. Diejenigen hören nicht zu, weil sie viel zu 
sehr damit beschäftigt sind, mich zum Idioten abzustempeln.

Es ist eigentlich ganz richtig, den hier manchmal herrschenden Ton zu 
kritisieren. Aber es scheint mir etwas irrational, jetzt bei mir (in 
diesem Thread) damit anzufangen.
Sicherlich gab es vorher schon, in diesem Forum, tausende von 
(verpassten) Gelegenheiten.

Nett, dass auch du auf mich einschlägst.
Aber das Jahre lange einschlagen, auf mich(und Andere), eben solche 
langen  Jahre unkommentiert lässt. Aber besser spät als nie... denn der 
Ton, hier im Forum, könnte wirklich noch "netter" werden.
Da liegt noch viel Arbeit vor dir.

Lothar M. schrieb:
> Glashaus...  ;-)
Ich denke, so als Moderator, sitzt du in deinem eigenen Glashaus.

Lothar M. schrieb:
> Ich habe mit knapp 30 Worten (von denen gut die Hälfte für blumige
> Umschreibungen herhalten mssten) genaus das bewirkt, was ich wollte:
> dass Robert H. mal kontrolliert, ob seine Annahme mit den programmierten
> Fuses schon passt.
Leute, welche sich gerade von ihrer bornierten Seite zeigen, Zucker in 
den Arsch zu blasen, ist sicherlich nicht meine Rolle hier.
Das überlasse ich gerne dir/anderen.


Merke:
Ich bin verantwortlich, für das, was ich sage.
Nicht für das, was deine Wahrnehmung daraus macht.



Lothar M. schrieb:
> du hast zwar völlig Recht gehabt.
Danke für die Anerkennung.

von S. Landolt (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Sommerloch, also sage ich auch mal etwas.

Wir haben uns alle nicht mit Ruhm bekleckert, dabei war es so 
offensichtlich; ein einfaches CTRL F auf das zweifelhafte efuse in der 
gezeigten Batch-Datei hätte genügt. Und Robert H. sollte das Prozedere 
des Qualitätsmanagements überdenken (lassen).

an ufuf:
Nicht das "Arduino", sondern das "Fanboy" war für mich Alten anfangs 
etwas befremdlich, aber das hat sich schon lange gelegt (und wer weiß, 
was andere mit "Landolt" assoziieren).

Dass die Umgangsformen hier im Forum stark zu wünschen übrig lassen, 
diese Meinung teilen wohl die meisten - es ist leider der Rest, der sich 
offenbar dabei wohl fühlt.

von Fred F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. Landolt schrieb:
> und wer weiß, was andere mit "Landolt" assoziieren

Ich assoziiere damit Packet und TNC. Liege ich damit richtig?

von Arduino Fanboy D. (ufuf)


Bewertung
-4 lesenswert
nicht lesenswert
S. Landolt schrieb:
> Nicht das "Arduino", sondern das "Fanboy" ...
Die Kombination ist die blanke, beabsichtigte, Provokation in Reinform.

von S. Landolt (Gast)


Bewertung
4 lesenswert
nicht lesenswert
Provozieren und sich dann in der Opferrolle gefallen - vertane 
Lebenszeit, und nicht gerade förderlich für ein gedeihliches 
Miteinander.

von Empirischer Ermittler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. Landolt schrieb:
> Provozieren und sich dann in der Opferrolle gefallen - vertane
> Lebenszeit, und nicht gerade förderlich für ein gedeihliches
> Miteinander.

Hier sind schon ein paar hochgradig Gestörte unterwegs. Die ziehen jedes 
positive Signal auf "Low"

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
S. Landolt schrieb:
> Provozieren und sich dann in der Opferrolle gefallen - vertane
> Lebenszeit, und nicht gerade förderlich für ein gedeihliches
> Miteinander.
Naja....
Wenn Du das meinst, hast Du natürlich vollkommen recht.
Meine Sicht auf die Angelegenheit ist eine leicht andere.

Hier: Beitrag "Re: Arduino Mega hängt wenn String nicht global definiert ist"

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Die "Leute"(einige) verachten mich!
> 1. Weil ich u.A. Arduino nutze
> 2. Weil ich Arduino im Namen habe

Das ist mir egal. Ich mag nicht, dass du andere Leute oder gerne auch 
mal die Allgemeinheit beleidigst.

> Leute, welche sich gerade von ihrer bornierten Seite zeigen, Zucker
> in den Arsch zu blasen, ist sicherlich nicht meine Rolle hier.

Genau solche Ausdrucksweisen meine ich. Damit beleidigst du jeden, der 
es liest, also auch mich. Das mag ich bei dir nicht.

Eigentlich ist das schade, denn du bist ja kein Dummkopf. Und wenn du 
mal gut gelaunt bist, dann auch durchaus hilfsbereit und nett.

By the way: wo wir alle über die Umgangsformen in diesem Forum stöhnen: 
Draußen auf der Straße geht es seit Corona noch viel schlimmer zu. Im 
Vergleich dazu ist das Forum auf einem guten Weg der Besserung.

: Bearbeitet durch User
von Empirischer Ermittler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Arduino Fanboy D. schrieb:
>> Die "Leute"(einige) verachten mich!
>> 1. Weil ich u.A. Arduino nutze
>> 2. Weil ich Arduino im Namen habe
>
> Das ist mir egal. Ich mag nicht, dass du andere Leute oder gerne auch
> mal die Allgemeinheit beleidigst.
>
>> Leute, welche sich gerade von ihrer bornierten Seite zeigen, Zucker
>> in den Arsch zu blasen, ist sicherlich nicht meine Rolle hier.

Haushaltstip zur rechten Zeit:

Wenn man jemandem Zucker in den Arsch blasen will, sollte man keinen 
Würfelzucker verwenden. Er könnte sich verkanten.

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
S. Landolt schrieb:

> und wer weiß,
> was andere mit "Landolt" assoziieren

Ich weiß nicht, was andere damit assoziieren, aber ich kann dir sagen, 
was ich damit assoziiere:

1. Pedant der alten Garde. Nix vertrauen, was was nicht selber am 
lebenden Objekt gemessen/überprüft wurde. Guuut!

2. Pedant der alten Garde. Keinesfalls offensichtliche geistige 
Schwächen des Peers bemängeln. (Vermutlicher Hintergrund: Könnte ja mal 
Geschäftspartner werden...). Schleeecht! (Jedenfalls in einem Forum, in 
der Praxis des Geschäftes handele ich natürlich ebenso)

Und meine Meinung zu 2. kann ich auch begründen: Wenn offensichtlicher 
Bullshit verzapft wird, muss der sehr deutlich gebrandmarkt werden. 
Sonst erkennt das im allgemeinen Rauschen eines Forums nur noch der 
Wissende als Solchen. Und der braucht keine Hilfe, Hilfe brauchen die, 
die keine Ahnung haben und deswegen auch nicht den nötigen Eigen-Filter, 
um offensichtlichen Bullshit selbstständig identifizieren zu können.

von Arduino Fanboy D. (ufuf)


Bewertung
-3 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Genau solche Ausdrucksweisen meine ich.
Hat sicherlich seine Gründe, dass du dich davon gerne angesprochen 
fühlen möchtest. Ist wohl ein tiefes inneres Bedürfnis, welches 
befriedigt werden will.
Nicht wahr, nicht?

Aber stimmt schon:
Hacke auf mir rum!
Dann ist das Bedürfnis befriedigt, und du kannst die anderen vielleicht 
eher in Ruhe lassen.

Also weiter so!

Immerhin bist sogar du mittlerweile etwas vorsichtiger geworden, mit 
deiner Arduinobasherei.
Riecht noch nicht nach Einsicht, aber immerhin....
Ja, du warst wirklich ein harter Brocken.
Waren einige Demütigungen/Demontagen nötig, um dir die Grenzen für deine 
Hochnäsigkeit aufzuzeigen.
Du hast also alles Recht, auf mich sauer zu sein.

von Oszimilian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen

Ich möchten mich hiermit für den LachFLASH meines Lebens bedanken!!!

Grüße

Oszimilian

von Baul (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sach ma Oszimilian...

bann den weg

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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