Hallo,
ich will den internen Temperatursensor eines Arduino Nano Clone (ATmega
328p) auslesen.
Habe 3 code snippets die aber alle sinnlose(?!) Werte ausgeben.
readTemperature1(): ~ 220
readTemperature2(): ~ -22
readTemperature3(): ~ -3,5
Hat jemand eine Idee was hier schief ist?
1
voidsetup(){
2
Serial.begin(19200);
3
Serial.println(F("Internal temperature sensor"));
4
}
5
6
voidloop(){
7
Serial.print(readTemperature1());
8
Serial.print(" ");
9
Serial.print(readTemperature2());
10
Serial.print(" ");
11
Serial.println(readTemperature3());
12
13
delay(1000);
14
}
15
16
longreadTemperature1(){
17
ADMUX|=B00001000;//We read A8 (Temp Sensor)
18
ADMUX|=B11000000;//(INTERNAL 1.1V Reference)
19
ADCSRA|=B11000000;//ADEN and ADSC equal to 1 (Start conversion)
20
21
while(bit_is_set(ADCSRA,ADSC));//Wait for conversion to end
22
longraw_temp=ADCL|(ADCH<<8);//Get analog read value
23
24
// f(x) = (raw - offset) / coeff
25
return(raw_temp-53)/1.22;
26
}
27
28
29
intreadTemperature2(){
30
ADMUX=0xC8;
31
ADCSRA|=_BV(ADSC);// start the conversion
32
while(bit_is_set(ADCSRA,ADSC));// ADSC is cleared when the conversion finishes
33
return(ADCL|(ADCH<<8))-342;// combine bytes & correct for temp offset (approximate)}
34
}
35
36
37
doublereadTemperature3(){
38
unsignedintwADC;
39
doublet;
40
// The internal temperature has to be used
41
// with the internal reference of 1.1V.
42
// Channel 8 can not be selected with
43
// the analogRead function yet.
44
// Set the internal reference and mux.
45
ADMUX=(_BV(REFS1)|_BV(REFS0)|_BV(MUX3));
46
ADCSRA|=_BV(ADEN);// enable the ADC
47
delay(20);// wait for voltages to become stable.
48
ADCSRA|=_BV(ADSC);// Start the ADC
49
// Detect end-of-conversion
50
while(bit_is_set(ADCSRA,ADSC));
51
// Reading register "ADCW" takes care of how to read ADCL and ADCH.
52
wADC=ADCW;
53
// The offset of 324.31 could be wrong. It is just an indication.
54
t=(wADC-324.31)/1.22;
55
// The returned temperature is in degrees Celsius.
Wenn du du dreimal völlig unterschiedliche Formeln auf den ADC Wert
ansetzt, kommen natürlich völlig unterschiedlicher Ergebnisse bei
heraus.
Prüfe doch erstmal, ob der ADC plausible Werte liefert. Also halbwegs
stabile zahlen (egal welcher Wert). Wenn du ihn dann mit einem Fön warm
machst, muss eine Änderung erkennbar sein.
Stefan ⛄ F. schrieb:> Wenn du du dreimal völlig unterschiedliche Formeln auf den ADC Wert> ansetzt
Diese Magic Numbers sehen hingebastelt aus.
Dietmar B. schrieb:> Habe 3 code snippets die aber alle sinnlose(?!) Werte ausgeben.
Den Abschnitt mit "The voltage sensitivity is approximately 1LSB/°C and
the accuracy of the temperature measurement is ±10°C using
manufacturing calibration values (TS_GAIN, TS_OFFSET)" im Kapitel 23.8
des Datenblatts hast du gesehen?
Und diese "Genauigkeit" von +-10°C erreicht er nur, wenn man die im µC
abgelegten Kalibrierdaten verwendet. Im Kapitel 23.8.1 des DB ist sogar
ein Stück Code, wie man an diese Kalibrierdaten kommt.
Stefan ⛄ F. schrieb:> Langer Rede, kurzer Sinn: Mit dem Temperatursensor kann man als> Anwendungsentwickler wenig nützliches anstellen.
Naja....
Aus deinem beschränkten Blickwinkel mag das stimmen.
Man kann anhand des internen Sensors "Kalabrierwerte" erzeugen.
Für den internen Osillator (OSCCAL) z.B. genauere Baudrate im
Außenbereich
Die Zeiten des WDT genauer bestimmen
Den Temperaturgang der Referenz Spannung kompensieren.
Wenn du meinst, man könnte damit nicht die Raumtemperatur "genau"
bestimmen, dann hast du recht. Aber auch nur dann.
Aber dafür ist er ja auch nicht auf dem Chip.
Der liefert einem die die Chip Temperatur.
Und das ist gut so.
EAF schrieb:> Für den internen Osillator (OSCCAL) z.B. genauere Baudrate im> Außenbereich> Die Zeiten des WDT genauer bestimmen
Ich habe mir die Sparerei nur einmal unnötigerweise angetan. Seither
nehme ich für alles, was definierte Zeiten braucht, einen externen
Taktgeber für 50 Cent.
> Den Temperaturgang der Referenz Spannung kompensieren.
Zum Thema Temperaturgang der 1,1V Referenz finden sich keinerlei Angaben
im DB. Nur die Angabe, dass die Referenz eben initial völlig ungenau
zwischen 1,0 und 1,2V leigen könnte.
Insofern kann ich mir nicht vorstellen, wie man da sinnvoll ohne
Klimaschrank und aufwendigen Abgleich was rausholen könnte.
Hallo,
die ±10°C und die Kalibrierthematik ist mir bewusst.
Mir geht es erst mal darum zu verstehen warum alle drei snippets ein
unrealistischen Wert liefern
readTemperature1(): ~ 220°C als Core/Die-Temperatur scheint mir viel zu
hoch zu sein bei einer max. zulässigen Aussentemperatur von 125°C laut
Datenblatt
readTemperature2(): ~ -22°C als Core/Die-Temperatur macht auch keinen
Sinn (in meiner Wohnung sind es ja schon +25°C)
readTemperature3(): ~ -3,5°C ... auch zu wenig
Ich wäre davon ausgegangen, dass bei +25°C Umgebungstemperatur ein Wert
von ~40°C rauskommt...
Dietmar B. schrieb:> Ich wäre davon ausgegangen, dass bei +25°C Umgebungstemperatur ein Wert> von ~40°C rauskommt...
Erfahrungsgemäß ist die Fehlpeilung durch Eigenerwärmung 5 bis 10°, bei
16MHz und wenig Last an den Pins.
Was dir auf jeden Fall fehlt ist eine kleine Wartezeit nach der
Umstellung auf interne Referenz.
Es dauert eben ein paar ms bis der Kondensator an ARef umgeladen ist.
Versuche doch erstmal mit den Rohwerten zu arbeiten.
Die Umrechnung auf °C ist ein anderes Kapitel.
Die beiden Bereiche lassen sich gut trennen einzeln testen.
Dietmar B. schrieb:> Mir geht es erst mal darum zu verstehen warum alle drei snippets ein> unrealistischen Wert liefern
Die ersten beiden sind eh Mumpitz, da die Reihenfolge beim Byte lesen
nicht definiert ist. Sie ist aber einzuhalten.
Entweder zwischen beiden Lesezugriffen ist ein Sequence-Point oder man
überläßt dem Compiler den Wortzugriff.
Die 3. ist zumindest logisch korrekt. Nur müssen noch die beiden
magischen Zahlen (Gain, Offset) stimmen.
Dietmar B. schrieb:> Mir geht es erst mal darum zu verstehen warum alle drei snippets ein> unrealistischen Wert liefern
Du solltest den AD-Wert auslesen und berichten, ob der stabil ist,
welcher es ist und ob er reproduzierbar auf ERwärmung reagiert. Und du
darfst natürlich das Datenblatt lesen und versuchen (wenigstens das!) es
zu verstehen.
DU willst ja schließlich diesen µC verwenden und im Datenblatt steht,
wie er sich verhält. Da hilft es nicht viel, sich irgendwo bei
irgendwelchen Bastlern einen Code herzukopieren.
Peter D. schrieb:> Nur müssen noch die beiden magischen Zahlen (Gain, Offset) stimmen.
Und die kann man aus den entsprechenden Registern aus dem Datenblatt
ablesen oder sich mit 2 Rohwerten bei 0*C und 100*C selber
"herzaubern"...
Dietmar B. schrieb:> Mir geht es erst mal darum zu verstehen warum alle drei snippets ein> unrealistischen Wert liefern
Erstmal musst du verstehen ob es am Sensor, am Auslesen oder an der
Rechnung liegt. Erst wenn der Sensor reproduzierbare und plausible
Rohwerte (z.B. bei gezielter Erwärmung) liefert, lohnt es sich, über die
Rechnung nachzudenken.
Dietmar B. schrieb:> readTemperature2(): ~ -22°C als Core/Die-Temperatur macht auch keinen> Sinn (in meiner Wohnung sind es ja schon +25°C)
Denke and die +/- 10%!
Und zwar 10% vom ADC Messwert, nicht 10% von Grad Celsius.
Lothar M. schrieb:> Und die kann man aus den entsprechenden Registern aus dem Datenblatt> ablesen
Nein.
Das geht nur bei der Automativ Variante.
Den wird er nicht auf seinem Nano haben.
Dietmar B. schrieb:> ich will den internen Temperatursensor eines Arduino Nano Clone (ATmega> 328p) auslesen.
Bei einem Clone kann man auch die Frage stellen, ob da ein echter Atmel
ATmega328P verbaut ist, der sich entsprechend Datenblatt verhält.
Sinter schrieb:> ob da ein echter Atmel> ATmega328P verbaut ist,
Soweit mir bekannt, gibt es keine "unechten"!
Es gibt wohl ähnliche, die sind aber sehr anders.
z.B. die Line mit den LGT8F328P und MD-328D
EAF schrieb:> Sinter schrieb:>> ob da ein echter Atmel>> ATmega328P verbaut ist,>> Soweit mir bekannt, gibt es keine "unechten"!>> Es gibt wohl ähnliche, die sind aber sehr anders.> z.B. die Line mit den LGT8F328P und MD-328D
Das mag schon sein, aber ob man einen 'Ähnlichen' bekommen hat, sieht
man meist nur beim genaueren hinschauen. Deshalb mein Hinweis.
Ich habe vor 18 Monaten mehrere 'WAVGAT Pro Mini ATMEGA328P 328 Mini
ATMEGA328 5V 16MHz' Boards bei AliExpress bestellt, und bekommen habe
ich Boards mit einem 'AVGA328P' (= LGT8F328P) Chip. Das habe ich aber
erst bemerkt, als ich die Boards mit einem Blink-Sketch getestet habe.
Weil die Blinkfrequenz 4 mal langsamer war, habe ich mir zuerst den
Quarz und dann die CPU genauer angeschaut. Und voilà, kein ATmega328P,
obwohl, soweit ich mich erinnere, auch die Produktfotos einen Atmel Chip
gezeigt haben.
Kurzes Update
Im Manual ist ja die Umrechung in °C schön beschrieben (cailb.png).
Problem 1:
Das HW-Manual (sig_row.png) scheint fehlerhaft zu sein, da TS_OFFSET und
"Device signature byte 2" an der gleiche Adresse (0x0002) liegen.
Problem 2:
Habe es mit 3 ATmega328P ausprobiert: Das TS_GAIN ist nicht gesetzt
(0xFF). Die Device Signatur stimmt aber 0x1E 0x95 0x0F = ATmega328P.
1
2
[00]:1E
3
[01]:B8
4
[02]:95
5
[03]:FF
6
[04]:0F
7
[05]:FF
8
[06]:FF
9
Devicesignature:1E950F
10
RCoscillatorcalibrationbyte:B8
Evtl. kann das ja mal jemand ausprobieren ob das TS_GAIN (addr.: 0x0003)
überhaupt irgendwo gesetzt ist...
> Im Manual ist ja die Umrechung in °C schön beschrieben (cailb.png).
Was ist das für ein 'Manual'? Im eben heruntergeladenen Datenblatt
'ATmega48A/PA/88A/PA/168A/PA/328/P' finde ich diese Formel nicht.
Signatur eines ATmega328P-PU von 1428:
S. Landolt schrieb:> Was ist das für ein 'Manual'? Im eben heruntergeladenen Datenblatt> 'ATmega48A/PA/88A/PA/168A/PA/328/P' finde ich diese Formel nicht.
Ach. die Trottels verwenden das Datenblatt des Automativen ATMega328P.
Das weicht in einigen Dingen ab, von dem Massenprodukt.
Aber das sagte ich schon.
Aber auf mich hört ja keiner.
Auch gerne in Wiederholung:
EAF schrieb:> Lothar M. schrieb:>> Und die kann man aus den entsprechenden Registern aus dem Datenblatt>> ablesen> Nein.> Das geht nur bei der Automativ Variante.> Den wird er nicht auf seinem Nano haben.
EAF schrieb:> die Trottels verwenden das Datenblatt des Automativen ATMega328P.
Weil laut TO auch ein solcher verbaut ist, denn
Dietmar B. schrieb:>>>>> eines Arduino Nano Clone (ATmega 328p)
Da sollte er doch wohl nochmal ganz genau schauen. Am besten ein Foto
von dem Ding machen...
Dietmar B. schrieb:> Das HW-Manual (sig_row.png) scheint fehlerhaft zu sein, da TS_OFFSET und> "Device signature byte 2" an der gleiche Adresse (0x0002) liegen.
Bei anderen µC finden sich diese Bytes wieder ganz woanders (siehe die
AN AVR123 https://www.microchip.com/en-us/application-notes/an8270).
Irgendwie sehr halbgar. Frag doch mal den FAE bei Atmel an mit Hinweis
auf diesen offensichtlichen Fehler im DB.
BTW:
Diese AN AVR123 heißt auf der nächsten Seite dann auf einmal AVR178 und
hat auch mindestens einen technischen Fehler:
1
For single ended conversions, the conversion result is:
2
Read ADC = VIN × 1023 / VREF
Eintausenddreiundzwanzig? Mann, das Zeug wird immer schrottiger...
Lothar M. schrieb:> EAF schrieb:>> die Trottels verwenden das Datenblatt des Automativen ATMega328P.> Weil laut TO auch ein solcher verbaut ist, denn> Dietmar B. schrieb:>>>>>> eines Arduino Nano Clone (ATmega 328p)> Da sollte er doch wohl nochmal ganz genau schauen. Am besten ein Foto> von dem Ding machen...
Ja, du bist/warst der Spender, der Zünder, der Nebelkerze.
Selbst jetzt nach Hinweis immer noch nicht einsichtig.
Ja, so geht das hier......
Merke:
Ihm hat einen Nano mit einem stinknormalen ATMega328P.
Nicht mit dem automativen ATMega328p!
Ist es jetzt angekommen.
Und nein!
Ihm sagt nirgendwo, dass er einen automativen ATMega verbaut hat.
Das gibt es nur in deiner Fantasie!
Dietmar B. schrieb:> Problem 2:> Habe es mit 3 ATmega328P ausprobiert: Das TS_GAIN ist nicht gesetzt
Offensichtlich erfolgt das nur in den automotiv AVRs.
Auch so eine Nebelkerze..
Lothar M. schrieb:> Seither> nehme ich für alles, was definierte Zeiten braucht, einen externen> Taktgeber für 50 Cent.
Natürlich kann man an einen automotiven Chip einen Quarz dran hängen.
Das geht auch einige Zeit, oder in manchen Anwendungen gut.
Aber wenn es auf Rüttelfestigkeit ankommt, ist ganz schnell Ende damit.
In der Ecke dürfte auch der Grund zu suchen sein, warum die
individuellen Kalibrierwerte im Werk ermittelt und im Chip abgelegt
werden.
Alleine dass dass der Hersteller sich an der Stelle einen solchen
Aufwand betreibt, straft den Stefan Lügen.
Stefan ⛄ F. schrieb:> Langer Rede, kurzer Sinn: Mit dem Temperatursensor kann man als> Anwendungsentwickler wenig nützliches anstellen.
EAF schrieb:> Natürlich kann man an einen automotiven Chip einen Quarz dran hängen.> Das geht auch einige Zeit, oder in manchen Anwendungen gut.> Aber wenn es auf Rüttelfestigkeit ankommt, ist ganz schnell Ende damit.
Lies mal
https://www.sitime.com/sites/default/files/gated/SiTime-MEMS-Timing-Improves-Motor-Control-Applications.pdf
und die AN10032 von SiTime. Dann machst du dir eher Sorgen, ob die
Lötstellen halten, als ob der MEMs-Taktgeber ausfällt.
> In der Ecke dürfte auch der Grund zu suchen sein, warum die individuellen> Kalibrierwerte im Werk ermittelt und im Chip abgelegt werden.
Nein, der Grund für das Ausmessen des Oszillators und das Ablegen der
Werte ist schlicht darin zu suchen, dass der RC-Oszillator ohne diese
Werte für ganz, ganz viele Fälle ungeeignet ist und nicht als
Verkaufsargument verwendet werden könnte. Und speziell im Automotive
Bereich ist der RC-Oszillator aber trotzdem noch ungeeignet, weil die
Kalibrierung nur bei Zimmertemperatur halbwegs passt.
> Alleine dass dass der Hersteller sich an der Stelle einen solchen> Aufwand betreibt, straft den Stefan Lügen.
Allein, dass der Hersteller an dieser Stelle für lausige +-10°C so einen
Aufwand treiben muss, stellt die Tauglichkeit in Frage.
EAF schrieb:> Ihm hat einen Nano mit einem stinknormalen ATMega328P.> Nicht mit dem automativen ATMega328p!
Also gut, es ist angekommen, die beiden kann man ja anhand der
Teilenummer und den Signature Bytes auch ganz einfach auseinander
halten... [/ironie]
Haben die denn einen an der sprichwörtlichen Klatsche?
Also hat sich der ganze Klimbim hier aufgelöst: es gibt keine
Kalibrierwerte, man muss sich die Magic Numbers selber ausknobeln. Und
natürlich passen keine Magic Codes von irgendwelchen anderen ATmega328.
Vorgehensweise wie beschrieben: die AD-Werte bei zwei möglichst
unterschiedlichen Temperaturen auslesen und Gain und Offset selber
berechnen. In diese Magic Numbers kann man dann auch gleich die
Umwandlung von AD-Incrementen nach °C einfließen lassen.
Lothar M. schrieb:>> In der Ecke dürfte auch der Grund zu suchen sein, warum die individuellen>> Kalibrierwerte im Werk ermittelt und im Chip abgelegt werden.> Nein, der Grund für das Ausmessen des Oszillators und das Ablegen der> Werte ist schlicht darin zu suchen, dass der RC-Oszillator ohne diese> Werte für ganz, ganz viele Fälle ungeeignet ist und nicht als> Verkaufsargument verwendet werden könnte. Und speziell im Automotive> Bereich ist der RC-Oszillator aber trotzdem noch ungeeignet, weil die> Kalibrierung nur bei Zimmertemperatur halbwegs passt.
Auch hier möchtest du mich nicht verstehen!
Es war von den Kalibrierwerten des Temperatursensors die Rede!
Und diese sind eben hilfreich um OSCCAL an die gerade herrschende
Temperatur anzupassen.
Lothar M. schrieb:> Vorgehensweise wie beschrieben: die AD-Werte bei zwei möglichst> unterschiedlichen Temperaturen auslesen und Gain und Offset selber> berechnen.
Richtig!
Die klassische 2 Punkt Kalibrierung (Geradengleichung) sollte
ausreichen.
Im schlimmsten Fall, legt man ein LookupTable an.
Übrigens:
Den Kalibrierwert, welcher angeblich im EEPROM gespeichert wird, habe
ich noch nie vorgefunden.
Aber auch noch nie danach gesucht.
Lothar M. schrieb:> Dann machst du dir eher Sorgen, ob die> Lötstellen halten, als ob der MEMs-Taktgeber ausfällt.
Womit du dann deine 50 Cent Lösung selbst konterkariert hast.
EAF schrieb:> Übrigens:> Den Kalibrierwert, welcher angeblich im EEPROM gespeichert wird, habe> ich noch nie vorgefunden.
Den musst laut Anleitung ja auch du selber bei der Inbetriebnahme dort
abspeichern und kannst ihn hinterher für diesen Controller wieder
auslesen:
"software calibration requires that a calibration value is measured and
stored in a register or EEPROM for each chip, AS A PART OF THE
PRODUCTION TEST."
> Auch hier möchtest du mich nicht verstehen!
Ich habe dich schon verstanden und ich kenne auch die AN AVR291, wo für
den ATmega32U4RC sogar 2 Temperatur-Kalibrierwerte abgelegt werden, um
zwischen 25°C und 85°C die Temperatur halbwegs genau bestimmen zu
können, damit der Oszillator wiederum nach diesem Schätzwert
nachgestellt werden kann.
EAF schrieb:> Lothar M. schrieb:>> Dann machst du dir eher Sorgen, ob die>> Lötstellen halten, als ob der MEMs-Taktgeber ausfällt.> Womit du dann deine 50 Cent Lösung selbst konterkariert hast.
Machen wirs einfach so: du nimmst den RC-Oszillator und ich den MEMS.
Und wir sind beide glücklich. Nur halt ich schneller, weil mein Takt
sofort passt.
Lothar M. schrieb:> Den musst laut Anleitung ja auch du selber bei der Inbetriebnahme dort> abspeichern und kannst ihn hinterher für diesen Controller wieder> auslesen:> "software calibration requires that a calibration value is measured and> stored in a register or EEPROM for each chip, AS A PART OF THE> PRODUCTION TEST."
So, und jetzt zeige ich dir mal, wie man einen Irrtum eingesteht!
S. Landolt schrieb:> Zur Klarstellung hier der betreffende Ausschnitt aus dem aktuellen> Datenblatt.
Den Post, bzw. das Bild habe ich quer gelesen und dabei fälschlicher
Weise angenommen dass der "PRODUCTION TEST" schon beim Chip Hersteller
stattfindet.
Das war offensichtlich ein Irrtum.
So, und jetzt vergleiche das bitte mit der Art und Weise, wie du hier
mit deinen Irrtümern umgegangen bist.
EAF schrieb:> Lothar M. schrieb:>> Den musst laut Anleitung ja auch du selber bei der Inbetriebnahme dort>> abspeichern und kannst ihn hinterher für diesen Controller wieder>> auslesen:>> "software calibration requires that a calibration value is measured and>> stored in a register or EEPROM for each chip, AS A PART OF THE>> PRODUCTION TEST.">> So, und jetzt zeige ich dir mal, wie man einen Irrtum eingesteht!> S. Landolt schrieb:>> Zur Klarstellung hier der betreffende Ausschnitt aus dem aktuellen>> Datenblatt.> Den Post, bzw. das Bild habe ich quer gelesen und dabei fälschlicher> Weise angenommen dass der "PRODUCTION TEST" schon beim Chip Hersteller> stattfindet.> Das war offensichtlich ein Irrtum.
Ja, das war ein Irrtum. Atmel/Microchip hat leider das Wort 'YOUR' vor
PRODUCTION TEST weggelassen. Das ist zwar nicht offensichtlich, aber für
mich aus dem Zusammenhang erkennbar. Die würden ihren internen Chip
Factory Kalibration Prozess sicherlich nicht so beschreiben.
Werden die Chips überhaupt vom Hersteller getestet, bevor sie in den
Verkauf gehen? Im Fernsehen hatten sie mal automatisierte
Sichtkontrollen (zwischen den Produktionsschritten) erwähnt, aber keine
Funktionstest.
Die würde "Factory test" heißen, nehme ich an.
Sinter schrieb:> Ja, das war ein Irrtum.
Ja, das war ein Irrtum.
Sinter schrieb:> Die würden ihren internen Chip> Factory Kalibration Prozess sicherlich nicht so beschreiben.
Das kann man nicht so sagen....
Denn ein EEPROM ist fix gelöscht, und damit wäre der Wert dann verloren.
Also doch eine gute Idee im Datenblatt zu sagen wie man ihn generiert.
Selbst wenn er ab Fabrik im EEPROM stehen würde, was er ja
offensichtlich nicht tut.
EAF schrieb:> So, und jetzt vergleiche das bitte mit der Art und Weise, wie du hier> mit deinen Irrtümern umgegangen bist.
Wenn das nicht reicht, was
ich schrieb:> EAF schrieb:>> Ihm hat einen Nano mit einem stinknormalen ATMega328P.>> Nicht mit dem automativen ATMega328p!> *Also gut, es ist angekommen*
dann erkläre ich hiermit wortreich und feierlich, dass ich auch nach
deinem Hinweis nicht erkannt habe, dass es zwei ATmega328P gibt, die man
nicht an der Signature, sondern nur am aufgestempelten Temperaturbereich
auseinander halten kann. Und das war auch der einzige Irrgang hier im
Thread.
> So, und jetzt zeige ich dir mal, wie man einen Irrtum eingesteht!
Du musst mir oder anderen nichts eingestehen. Ich hatte das nirgends
verlangt, sondern nur geschrieben, wie ich das Datenblatt des nunmehr
korrekt indentifizierten µC interpretiere.
Was für ein ehrenkäsiger Hickhack. Ich habe damit fertig.
Noch was zur Sache?
Stefan ⛄ F. schrieb:> Werden die Chips überhaupt vom Hersteller getestet, bevor sie in den> Verkauf gehen? Im Fernsehen hatten sie mal automatisierte> Sichtkontrollen (zwischen den Produktionsschritten) erwähnt, aber keine> Funktionstest.
Gehe mal als Annahme davon aus, dass ein ATMega168P identisch mit einem
ATMega328P ist.
Nur beim Test mit anderer Signatur versehen und beim ATMega168P der
defekte Teil des Speichers ausgeblendet wurde.
Scheint dir das realistisch zu sein?
EAF schrieb:> Scheint dir das realistisch zu sein?
Das hatten wir schon einmal bezüglich des STM32F103C8T6 diskutiert.
Ehrlich gesagt weiß ich nicht, was ich glauben soll. Ist das nicht zu
aufwändig? Und wenn eine Hälfte des Speichers schon ab Werk kaputt is,
wie vertrauenswürdig ist dann die andere Hälfte?
Ich habe zu wenig Ahnung, um das einzuschätzen.
Lothar M. schrieb:> ... dass ich auch nach deinem Hinweis nicht erkannt habe,> dass es zwei ATmega328P gibt, ....
Fein gemacht!
Lothar M. schrieb:> Du musst mir oder anderen nichts eingestehen. Ich hatte das nirgends> verlangt, ...
Ich verlange von mir selber, dass ich Irrtümer erkenne, spätestens wenn
man mich mit der Nase darauf stößt.
Dass ist die notwendige Basis um einen solchen Irrtum auch öffentlich
zugeben zu können.
Und nein, "mich" muss man nicht dazu auffordern Irrtümer zuzugeben. Das
mache "ich" automatisch, wenn die Einsicht mal ins Hirn getropft ist.
Irgendwelche Nebelkerzen, oder sonstige Abwehrstrategien, sind da völlig
fehl am Platze.
Stefan ⛄ F. schrieb:> Und wenn eine Hälfte des Speichers schon ab Werk kaputt is,> wie vertrauenswürdig ist dann die andere Hälfte?
So, dass er die Spezifikation einhält.
Dafür gibts ja den Test!
Thread beobachten
Seitenaufteilung abschalten