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
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
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
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 ?
Also pro Byte 3,3 ms und ein Long (aus 4 Byte) wären also 13,2 ms müssten eingeplant werden, korrekt?
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!
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 ;-)
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.
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 ?
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.
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.
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.
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
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" :)
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.
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.
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
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.
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?
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.
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 ?
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.
IMG_3475.jpeg
(230 KB)
IMG_3476.jpeg
(420 KB)
