Hallo in die Runde, Irgendwo hatte ich mal gelesen, dass das Schreiben 3 ms rum ungefähr dauern soll. Bei meinen Messungen dauert eine Long Zahl aber nur 20 us und ein Byte 10 us. CH 1 ist der Trigger CH 2 eine LED für den Schreibzyklus Hat jemand eine Idee oder Erklärung dafür? Danke schon mal.
Angehängte Dateien:
-
IMG_3475.jpeg
230 KB -
IMG_3476.jpeg
420 KB
Daniel E. schrieb: > Irgendwo hatte ich mal gelesen, Irgendwo? Ich meine mal irgendwo gelesen zu haben, dass das Datenblatt des betreffenden µC dafür zuständig ist. Irgendwo gilt also nicht.
Arduino F. schrieb: > Daniel E. schrieb: >> Irgendwo hatte ich mal gelesen, > > Irgendwo? > Ich meine mal irgendwo gelesen zu haben, dass das Datenblatt des > betreffenden µC dafür zuständig ist. > Irgendwo gilt also nicht. Datenblatt Seite 22 sagt 3,3 ms von der CPU in den EEPROM oder hab ich was falsch verstanden?
Da steht aber auch, dass das schreiben noch lange nicht abgeschlossen ist, wenn dein Programm zurückkehrt. Deine Messung ist also unvollständig > The user should poll the EEPE bit before starting the read operation. If a > write operation is in progress, it is > neither possible to read the EEPROM, nor to change the EEAR Register Das gilt natürlich auch für die nächste Schreiboperation
Arduino F. schrieb: > Da steht aber auch, dass das schreiben noch lange nicht abgeschlossen > ist, wenn dein Programm zurückkehrt. > Deine Messung ist also unvollständig > >> The user should poll the EEPE bit before starting the read operation. If a >> write operation is in progress, it is >> neither possible to read the EEPROM, nor to change the EEAR Register > > Das gilt natürlich auch für die nächste Schreiboperation 1. Um das EEPE Bit zu Pollen müsste meine Main Loop ja fast leer sein oder die Messung wäre falsch… sehe ich das richtig ? 2. Also pro Byte 3,3 ms und ein Long (aus 4 Byte) wären also 13,2 ms müssten eingeplant werden, korrekt? Dankeschön 👍
Würde ja auch bedeuten, dass ich vor der nächsten Zahl schreiben erst die Info brauche, ob die Zahl schon fertig geschrieben ist ? Bin grad bissl verdatellelt, da ich bisher der Annahme war, darum kümmert sich der Compiler ? Danke
Daniel E. schrieb: > Bin grad bissl verdatellelt, da ich bisher der Annahme war, darum > kümmert sich der Compiler ? Der Compiler kümmert sich nicht um Schreibzugriffe ins EEPROM.
Daniel E. schrieb: > Würde ja auch bedeuten, dass ich vor der nächsten Zahl schreiben erst > die Info brauche, ob die Zahl schon fertig geschrieben ist ? Das machen die Funktionen der lib-c, wenn man sie denn richtig nutzt. > Bin grad bissl verdatellelt, da ich bisher der Annahme war, darum > kümmert sich der Compiler ? Welchen nutzt du? Ach so, jetzt sehe ich es. Arduino. Mit welchem genauen Typ? Aber so ein "Screenshot" ist eine FRECHHEIT! Häng den Quelltext einfach als Anhang an!
Daniel E. schrieb: > darum kümmert sich der Compiler ? Woher sollte der die Zeitbedingungen kennen? Compiler lesen (noch) keine Datenblätter, dafür ist der Entwickler zuständig. EDIT: zu lange mit dem Abschicken getrödelt, es wurde alles Wichtige bereits gesagt.
:
Bearbeitet durch User
Daniel E. schrieb: > Bin grad bissl verdatellelt, da ich bisher der Annahme war, darum > kümmert sich der Compiler ? Die Lib tut das! Aber die wartet nach dem schreiben nicht bis fertig. Sondern sie wartet vor dem lesen oder schreiben, bis fertig. Da kommt auch deine Fehlmessung her.
1 | #include <Streaming.h> // die Lib findest du selber ;-) |
2 | Print &cout = Serial; // cout Emulation für "Arme" |
3 | |
4 | void EEPROM_write(unsigned int uiAddress, unsigned char ucData) |
5 | {
|
6 | /* Wait for completion of previous write */
|
7 | while(EECR & (1 << EEPE)); |
8 | /* Set up address and Data Registers */
|
9 | EEAR = uiAddress; |
10 | EEDR = ucData; |
11 | /* Write logical one to EEMPE */
|
12 | EECR |= (1 << EEMPE); |
13 | /* Start eeprom write by setting EEPE */
|
14 | EECR |= (1 << EEPE); |
15 | /* Wait for completion of previous write */
|
16 | while(EECR & (1 << EEPE)); |
17 | }
|
18 | |
19 | void setup() |
20 | {
|
21 | Serial.begin(9600); |
22 | cout << F("Start: ") << F(__FILE__) << endl; |
23 | |
24 | unsigned long start = micros(); |
25 | EEPROM_write(42, 'x'); |
26 | cout << (micros() - start) << endl; |
27 | }
|
28 | |
29 | void loop() |
30 | {
|
31 | |
32 | }
|
Sagt 3416 Also 3,4ms wie es in meinem Datenblatt steht. Und nicht 3,3ms wie in deinem
:
Bearbeitet durch User
Angehängte Dateien:
-
2024-05-19_22-40.png
47 KB
Ich kriege zum verrecken nicht heraus, ob Arduino nach jedem Schreibzugriff wartet, oder erst vor dem nächsten Schreibzugriff. Wo ist denn der Quelltext davon? Finde ich nicht. Sonst fällt mir das Suchen eigentlich immer leicht.
Angehängte Dateien:
Steve van de Grens schrieb: > Wo ist denn der Quelltext davon? Finde ich nicht. Einfach zu finden... https://github.com/vancegroup-mirrors/avr-libc/blob/06cc6ff5e6120b36f1b246871728addee58d3f87/avr-libc/libc/misc/eewr_byte.S Steve van de Grens schrieb: > Ich kriege zum verrecken nicht heraus, ob Arduino nach jedem > Schreibzugriff wartet, oder erst vor dem nächsten Schreibzugriff. Natürlich wird davor geprüft und gewartet
:
Bearbeitet durch User
Steve van de Grens schrieb: > Ich kriege zum verrecken nicht heraus, ob Arduino nach jedem > Schreibzugriff wartet, oder erst vor dem nächsten Schreibzugriff. In den meisten Fällen ist es doch absolut sinnlos, hinterher darauf zu warten, dass der EEPROM Schreibzugriff abgeschlossen wird. Nachdem der Controller die Daten übergeben hat, kann er sich besser anderen Dingen zuwenden. Einzig in einer Schaltung, wo der uC sich selber den Strom abdreht, muss er warten, bis das EEPROM fertig ist.
:
Bearbeitet durch User
Arduino F. schrieb: > Einfach zu finden... Danke. Mein Fehler war, dass ich nur in C(++) Quelltexten gesucht habe. > Natürlich wird davor geprüft und gewartet Ja, offensichtlich. Wenn man also nur einen einzelnen Schreibzugriff macht und dessen Zeit misst, sieht man von den erwarteten 3,3 ms nichts.
:
Bearbeitet durch User
Rainer W. schrieb: > In den meisten Fällen ist es doch absolut sinnlos, hinterher darauf zu > warten, dass der EEPROM Schreibzugriff abgeschlossen wird. Solange du immer nur 1 einzelnes Byte schreibst, ja. Aber das würde ich nicht zu "den meisten Fällen" zählen. Solche wie der TO hier, er schreibt einen Wert der aus mehreren Bytes besteht, kommen sicher häufiger vor. Egal, grundsätzlich ist das Prüfen des Completion-Bits direkt vor dem nächsten Schreibvorgang sinnvoller. So kann er die Zeit, die er "hinterher" warten müsste ggfs. sinnvoller nutzen und nicht in einer Busy-Loop warten, bis das nächste Byte zur Verfügung steht.
> Einzig in einer Schaltung, wo der uC sich selber den Strom abdreht, muss > er warten, bis das EEPROM fertig ist. Guten morgen an alle. Danke für die Rückmeldung. Das Strom abdrehen ist genau mein Anwendungsfall. Ein Unterspannungskomparator geht auf einen Interrupt Eingang und soll sichern, wenn Spannung weg. Für die Kapazitätsauslegung wollte ich wissen, wenn das Schreiben fertig ist. Sind das grob für eine Long Zahl dann die 4x 3,4 ms ? Danke und schönen Pfingstmontag.
>> Natürlich wird davor geprüft und gewartet > Warum, wenn abgewartet wird, wird dann meine LED mehrfach AN/ AUS gesetzt? Steh da grad etwas auf dem Schlauch. Danke
900ss schrieb: > Solange du immer nur 1 einzelnes Byte schreibst, ja. Aber das würde ich > nicht zu "den meisten Fällen" zählen. Quatsch - auch wenn man mehrere Bytes schreiben will, ist es sinnlos, NACH jedem Byte zu warten, dass der EEPROM-Schreibvorgang beendet ist. Da kann der Controller lieber sinnvolle Dinge tun und dann auch schon das nächste Byte bereit legen. In 3.4ms kann er einen Haufen nützlicheres Zeugs tun, als Däumchen drehend auf ein Ready-Bit zu warten, jedenfalls wenn der Programmierer in das Lage ist, die anstehenden Aufgaben passend zu strukturieren. Du hast es richtig erkannt - warum widersprichst du dir also selbst.
:
Bearbeitet durch User
Daniel E. schrieb: > Sind das grob für eine Long Zahl dann die 4x 3,4 ms ? Nach dem letzten Zugriff wird es nie länger als 3,4 ms dauern. Danach kommt kein weiterer Schreibzugriff mehr, also kann es nicht länger dauern.
Daniel E. schrieb: > Das Strom abdrehen ist genau mein Anwendungsfall. > ... > Sind das grob für eine Long Zahl dann die 4x 3,4 ms ? Salamischeibe - warum schreibst du nicht gleich, dass es um Dimensionierung für Stromausfall geht? Steve van de Grens schrieb: > Danach kommt kein weiterer Schreibzugriff mehr, also kann es nicht länger > dauern. Die Schlussfolgerung ist falsch. Wenn vorher zufällig ein Schreibzugriff lief, muss der abgewartet werden. In diesem Worst-Case kann es sogar passieren, dass man 5x 3,4ms warten musst. Beim Stromausfall musst du gucken, dass du den möglichst an einer Stelle in der Spannungsversorgung detektierst, die vor dem Speicherelko liegt und davon entkoppelt ist, um eine möglichst große Vorwarnzeit zu erreichen. Außerdem ist eine Prüfsumme für den EEPROM-Inhalt nicht die schlechteste Idee, damit du sicher sein kannst, dass die Daten vollständig geschrieben wurden.
:
Bearbeitet durch User
> Quatsch - auch wenn man mehrere Bytes schreiben will, ist es sinnlos, > NACH jedem Byte zu warten, dass der EEPROM-Schreibvorgang beendet ist. > Da kann der Controller lieber sinnvolle Dinge tun und dann auch schon > das nächste Byte bereit legen. Kann er die nächsten Bytes alle unmittelbar direkt hintereinander legen oder muss er warten, bis das erste fertig geschrieben ist ? Ich Frage wegen dem An/ Aus/ an / aus in meiner eeprom Routine. Danke.
Daniel E. schrieb: > Kann er die nächsten Bytes alle unmittelbar direkt hintereinander legen > oder muss er warten, bis das erste fertig geschrieben ist ? Die Arduino EEPROM Klasse wartet, wenn nötig, vor jedem Schreibzugriff. Also ja, du kannst unmittelbar nacheinander ins EEPROM schreiben. Aber sie wartet nicht nach dem (letzten) Schreibzugriff. Deswegen darfst du nicht sofort danach die Stromversorgung unterbrechen. Das haben wir doch gerade geklärt!
:
Bearbeitet durch User
Werden wohl mal ein Testprogramm schreiben, um das noch besser zu verstehen… Wird das EEPE bit damit nach jedem Schreibvorgang behandelt, also bei Long 4x gesetzt nach jedem Byte schreiben ? Danke
Deine Frage ist unklar. Was meinst du mit "behandelt" und wer setzt was? Schau doch ins Datenblatt, da ist beschrieben, was der Chip macht. Und den Link zum Arduino Quellcode (Assembler) haben wir ja auch bekommen. Das siehst du, was er vor jedem Schreibzugriff macht.
The user should poll the EEPE bit before starting the read operation. If a write operation is in progress, it is neither possible to read the EEPROM, nor to change the EEAR Register Das gilt natürlich auch für die nächste Schreiboperation Das meine ich damit ..
Rainer W. schrieb: > Quatsch - auch wenn man mehrere Bytes schreiben will, ist es sinnlos, > NACH jedem Byte zu warten, dass der EEPROM-Schreibvorgang beendet ist. Ach? Genau das hab ich doch beschrieben/gemeint. Aber du hast sicher nur die Hälfte gelesen und dann auf deine freundliche Art gleich losge- "quatscht" :) 900ss schrieb: > Egal, grundsätzlich ist das Prüfen des Completion-Bits direkt vor dem > nächsten Schreibvorgang sinnvoller. So kann er die Zeit, die er > "hinterher" warten müsste ggfs. sinnvoller nutzen und nicht in einer > Busy-Loop warten, bis das nächste Byte zur Verfügung steht.
:
Bearbeitet durch User
Daniel E. schrieb: > Werden wohl mal ein Testprogramm schreiben, um das noch besser zu > verstehen… Am meisten würde zum Verstehen helfen, wenn du dir das Datenblatt des Controllers nimmst und dir eigene EEprom-Routinen schreibst. Danach hast du sicher vollständig verstanden, wie es funktioniert. Du kannst ja auch in Arduino die Register so ansprechen, als wenn du Arduino nicht hattest sondern "nur" die AVR GCC Toolchain. Dieses "Vorgekaute" versteckt halt sehr viel, was dir aber eigentlich helfen würde. Wenn man versteht was passiert ist das "Vorgekaute" natürlich sinnvoll und hilfreich.
:
Bearbeitet durch User
Daniel E. schrieb: > Warum, wenn abgewartet wird, wird dann meine LED mehrfach AN/ AUS > gesetzt? > > Steh da grad etwas auf dem Schlauch. Weil du Mist misst. Oder die Rechnung ohne den Wirt machst. Klarer: Du verwendest EEPROM.put() EEPROM.put() verwendet intern EEPROM.update() Und EEPROM.update() prüft bevor es schreibt, ob sich die Daten unterscheiden. Bei gleichen Daten wird nicht geschrieben, also kehrt es auch sofort zurück. Also in dem Fall ist nix mit 3,4 ms
Ist eigentlich schon jemandem aufgefallen, daß der Code, der da im Eröffnungsscreenshot steht, eine ISR zu sein scheint? Und das Ding hat den ... merkwürdigen Namen EXT_ISR_6, was soll das sein?
Harald K. schrieb: > Ist eigentlich schon jemandem aufgefallen, daß der Code, der da im > Eröffnungsscreenshot steht, eine ISR zu sein scheint? Ja! Schien mir aber keine besondere Relevanz zu haben...
Harald K. schrieb: > Ist eigentlich schon jemandem aufgefallen, daß der Code, der da im > Eröffnungsscreenshot steht, eine ISR zu sein scheint? Mir sind da hauptsächlich Aliasing Effekte wegen fehlendem Filter aufgefallen ;-) Arduino F. schrieb: > Ja! > Schien mir aber keine besondere Relevanz zu haben... Normalerweise will man den µC nicht über etliche Millisekunden in einer ISR einsperren.
:
Bearbeitet durch User
Rainer W. schrieb: > Normalerweise will man den µC nicht über etliche Millisekunden in einer > ISR einsperren. Kann schon sein! Hat aber nix mit den beschriebenen Effekten zu tun. Am Rande: Zudem ist nicht alles ISR, wo Interrupt dran steht.
Arduino F. schrieb: > Am Rande: > Zudem ist nicht alles ISR, wo Interrupt dran steht. Kann natürlich sein. Das da oben dient dann der "code obfuscation", oder was?
1 | void EXT_ISR_6() //Interrupt |
2 | {
|
3 | ... etc.pp. |
Harald K. schrieb: > Das da oben dient dann der "code obfuscation", oder > was? Woher soll ich das wissen? Ich schätze eher, dass das alles eher mit Fantasie zu tun hat. Die ganze Frage scheint in die Richtung zu gehen. Dabei ist die Realität doch recht klar. Klar im Datenblatt. Klar im Code. Und leicht zu bestätigen, siehe: Beitrag "Re: Arduino Nano EEPROM schreiben Zeitdauer" In diesem Fall gibt es keine Chance das Datenblatt in Frege zu stellen. Wenn dann nur in der Fantasie. Und wenn Fantasie auf die Realität trifft, kann das durchaus wie Obfuscation aussehen, ist aber eher Selbsttäuschung. Wissenslücken mit bunten Bildern ausgemalt. Auch ist es schon mal so, dass Kommentare stehen bleiben, auch wenn sich der Kontext geändert hat. Hier, kann das keine ISR sein, vielleicht eine Funktion, welche von einer ISR aufgerufen wird, ok. Davon ist aber nichts zu sehen. Der Grund: void EXT_ISR_6() Ist eine normale Funktion. Es fehlen alle Attribute, welche eine ISR benötigt. ISR(EXT_ISR_6) so sieht der Kopf einer ISR mit allen nötigen Attributen aus. Wobei der m328p keinen solchen Vector hat.
Harald K. schrieb: > Kann natürlich sein. Das da oben dient dann der "code obfuscation", oder > was? [...] Jepp. Löst sich sehr wahrscheinlich dann auf, wenn man den Kontext vollständig kennt. Könnte z.B. (einer der) tatsächlich ausgeführten Routinen sein, die über einen Selektor (einer Statemachine) oder Funktionszeiger aus der eigentlichen ISR angesprungen werden. Beides ist ein recht übliches Konstrukt. Obfuskativ ist sicher nur die Benamsung und Kommentierung. Aber: In einem offensichtlichen Troll-Posting ist das ja auch kaum anders erwartbar. Irgendwie müssen ja falsche Fährten gelegt werden, sonst wird der Thread viel zu kurz...
Wir sollten uns aber soweit einig sein, daß dann der Name dieser Funktion maximal schwachsinnig gewählt ist, oder?
Harald K. schrieb: > daß dann der Name dieser Funktion Nicht nur das... Auch die Idee einen externen Komparator zu verwenden, obwohl der m328p schon einen eingebaut hat, ist arg seltsam. Aber das sind alles nur Nebelkerzen oder Nebenkriegsschauplätze die mit dem eigentlichen Problem (schreiben zu schnell) nix zu tun haben.
Harald K. schrieb: > Wir sollten uns aber soweit einig sein, daß dann der Name dieser > Funktion maximal schwachsinnig gewählt ist, oder? Natürlich. Was du nicht erkannt hast: Das ist absichtlich gemacht worden, einzig zum Zwecke der Irreführung mit dem Endziel, den Thread möglichst lang werden zu lassen.
Arduino F. schrieb: > Ob S. schrieb: >> Das ist absichtlich gemacht worden > Och nöö, das möchte ich nicht glauben. Mit dem reinen Glauben ist das so eine Sache... Wissen ist viel besser. Und Wissen läßt sich oft einfach aus eine Analyse des Bekannten extrahieren...
Ob S. schrieb: > Und Wissen läßt sich oft einfach aus eine > Analyse des Bekannten extrahieren... Das mit dem "einfach" glaube ich dir so einfach nicht nicht. Eine Kohärenz lässt sich manchmal leicht finden. Die Kausalitäten zu finden ist manchmal deutlich schwieriger. Dann erst wird es mit dem Wissen auch was. Menschen sind nicht so leicht zu durchschauen. Das macht aber nichts, denn dafür gibts ja Plattitüden und Vorurteile, die gleichen Wissen und Kausalität liebend gerne aus.
Huch, soviel Gedanken zum Thema, auch dass der Nano einen internen Komparator hat, welchen ich nicht genommen habe, weil ich die Pins für was anderes gebraucht habe … Ja, das ist eine ISR die aufgerufen wird, weil die Ladung im Elko begrenzt ist und ich nicht ewig warten kann zumal das Display auch etliche ms in der Main zu werkeln hat. Ist da bitte was schlimmes dran und was soll das mit Troll Post ? Danke an alle.
Daniel E. schrieb: > welchen ich nicht genommen habe, weil ich die Pins für > was anderes gebraucht habe Wenn du den externen abklemmst, wird 1 Pin frei Daniel E. schrieb: > und was soll das mit Troll Post ? Indizien sind schon da, aber ich mag daran noch nicht glauben. Selbst wenn man allwissend wäre, kann man hier ertreten werden.
Daniel E. schrieb: > Ja, das ist eine ISR die aufgerufen wird, Wie soll das gehen, mit der falschen Funktionssignatur und einem falschen Namen? Was hast Du sonst noch verschwiegen?
Harald K. schrieb: > Wie soll das gehen, mit der falschen Funktionssignatur und einem > falschen Namen? https://www.arduino.cc/reference/de/language/functions/external-interrupts/attachinterrupt/ Oder auch: https://github.com/NicoHood/PinChangeInterrupt
Arduino F. schrieb: > ... > Oder auch: > ... Hattest Du nicht gerade das hier geschrieben? Arduino F. schrieb: > Hier, kann das keine ISR sein, vielleicht eine Funktion, welche von > einer ISR aufgerufen wird, ok. Davon ist aber nichts zu sehen. Magst Du Dich entscheiden?
Harald K. schrieb: > Magst Du Dich entscheiden? Warum? > vielleicht eine Funktion, welche von > einer ISR aufgerufen wird, ok. Trifft doch exakt auf diese Fälle zu. Ohne weiteren Kontext des TO gibts keine weitere Entscheidung meinerseits.
:
Bearbeitet durch User
Harald K. schrieb: > Was hast Du sonst noch verschwiegen? Nix. Ist doch inzw. alles klar. Problem geklärt. Warum sollte da noch was fehlen?
Daniel E. schrieb: > Sind das grob für eine Long Zahl dann die 4x 3,4 ms ? Wenn man den Bereich im Eeprom vorher schon löscht, dauert danach jedes Byte statt 3,4ms nur 1,8ms. Den Flash-Speicher zu beschreiben könnte sogar noch schneller sein. Das dauert zwar etwas länger als ein einzelnes Eeprom-Byte, dafür bekommt man in der Zeit eine ganze Seite geschrieben. HTH. LG, Sebastian
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.