Batterietester für NiMh und LiIon mit AVR-DOS Datenlogger

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Nach jetzt 25min Lauf und weniger als einer Sekunde Abweichung bleibt es bei OCR1A=1241 !
      Zwischendurch war der Mega2560 mal ein ganz klein wenig "führend" (wahrscheinlich war der Kaminofen da gerade etwas kälter), jetzt aber hängt er ca. eine viertel bis halbe Sekunde hinterher. Ist also +-0 und damit optimal.
    • laase schrieb:

      aber ist ocr1a nicht das "output compare register" für die PWM-Generierung?
      Kann ich damit auch den Timer dauerhaft "vorspannen",
      damit er schneller überläuft
      und einen Interrupt erzeugt?
      Ohne das Setzen weiterer Register?
      -Ja, unter anderem auch.
      -Nicht vorspannen, seine Endzahl vorgeben.
      -Klar er zählt jetzt 1240,1241,0,1...
      -Er setzt ein Flag. Ob das ein Interupt wird liegt an der Anwendung: Jetzt nötig, bei PWM eher blöd
      -Doch, die nötigen Register werden von der Config DCF gesetzt. Auch das Ocr1a, deshalb nach dem Config
    • Guten Morgen Michael, Guten Morgen Pluto,

      Resonator: die, dich ich bisher schon x mal verbaut (ich glaube, es war die CST(?)-Serie von Murata) hatten kein Metallgehäuse. Und man brauchte auch die externen ca. 18pF Kondensatoren nicht. Deshalb dachte ich, auf dem Mega2560 sei es eher kein Resonator. Aber klar, das Ding ist superklein. Gibt es vielleicht neuartige Quarze in sehr viel kleinerer Bauform? Günstiger und "schlechter" als die großen? Warum bauen die ausgerechnet auf den für anspruchsvollere Aufgaben gedachten/geeigneten Mega2560 solche schlechten Taktgeber, während auf den Unos, die bei geschätzt über 80% der User nur ein paar LED's oder "Neopixel" ansteuern, überall "richtige" Quarze sitzen? Auch auf den Boards, die man vor einigen Jahren für unter 2€ inkl. Porto kaufen konnte?! Gut, ganz viele Mega2560er gingen in die 3D-Drucker. Bei denen läuft keine exakte Uhr mit. Wenn die über Nacht eine Minute später mit dem Druck fertig werden, als es von Cura prognostiziert war, stört es keinen. Wie auch immer, ich werde wohl auch mal einen Temperaturtest machen müssen, wie es nach meiner OCR1A Kalibrierung im Bereich von 15 bis ca. 40°C aussieht.

      Endzahl von Timer1: ok, aber warum liegt die sooo niedrig? Wenn ich 16.000.000Hz durch 1024 teile (und das soll ja angebl mit Config DCF77 passieren), komme ich auf 15.625Hz. Jede Periode am Zählereingang ist also 64µs lang. Wenn der Zähler jetzt 15.625 Perioden davon "abzählt" (Überlauf nach 15.625 statt 65.536), ist genau eine Sekunde vergangen. Nach nur 1249 "Zählungen" sind es doch aber nur 79.9ms? Wo ist mein Denkfehler? Ich meine, ok, es funktioniert, aber ich würde doch gern verstehen warum ...
    • Das mit dem Dcf ist die bequeme Lösung da es alles mit einer Zeile bereitstellt. Seine eigendliche Aufgabe ist das Dcf Signal auszuwerten, dazu braucht es Zeitabstände weniger 100ms (um die 100ms von den 200ms Pulsen unterscheiden zu können.)Es gibt sicher elegantere Methoden aber das war das schnellste/einfachste. Wenn erstmal alles funktioniert kann das immer noch verschönert werden. Das muß es sogar wenn die Pins ausgehen oder das Timing kritisch wird.
    • ich habe bei mir jetzt einmal die vier Kanäle "erstellt": ich speichere sekündlich zwei Word-Variablen in zwei SRAM-Arrays, Spannung [mV] und Strom [mA] und das für jeweils vier Kanäle. Alle 128 Durchläufe (128s) überschreibe ich "kanalweise nacheinander" diese Arrays in vier Dateien auf die SD-Karte:

      BASCOM-Quellcode

      1. '...
      2. Config Date = Dmy , Separator = Dot
      3. Config Dcf77 = Pinc.7 , Timer = 1 , Timer1sec = 1 , Gosub = Sectic 'C.7 wird hier als Dummyeingang missbraucht (daran ist nichts angeschlossen)
      4. Ocr1a = 1241 'Dauerhaftes "Vorspannen" des Timers für Trimmzwecke 'war OHNE diese Zuweisung 1249
      5. '...
      6. Enable Interrupts
      7. '...
      8. gosub Version_u_SD_Anzeige
      9. Gosub Alte_zeit_aus_dem_eeprom_holen
      10. Gosub Neue_zeit_per_encoder_einstellen
      11. '...
      12. For i = 1 to 4
      13. Zellennummer(i) = 22110 + i
      14. next i
      15. Auffindspannung_mV(1) = 3055
      16. Auffindspannung_mV(2) = 3155
      17. Auffindspannung_mV(3) = 3255
      18. Auffindspannung_mV(4) = 3355
      19. gosub SD_ch1_Kopfschreiben
      20. gosub SD_ch2_Kopfschreiben
      21. gosub SD_ch3_Kopfschreiben
      22. gosub SD_ch4_Kopfschreiben
      23. Locate 4,1:lcd "headinfo written "
      24. Do
      25. Hierherzurueck:
      26. Istneuesekunde = 0
      27. 'Gosub Zeitweiterstellen 'das entfällt durch Config DCF77
      28. Gosub Wichtige_zeitkritische_sachen
      29. '...
      30. Gosub Superlangedauernde_einstellerei
      31. If Istneuesekunde = 1 Then Goto Hierherzurueck
      32. Waitms 500
      33. '...
      34. Loop
      35. end
      36. Wichtige_zeitkritische_sachen:
      37. '...
      38. 'Spannung und Strom sekündlich messen und ins SRAM speichern
      39. Sramsekunde = Sramsekunde + 1
      40. Adc_dummy_1 = 0 : Adc_dummy_2 = 0 : Adc_dummy_3 = 0 : Adc_dummy_4 = 0 : Adc_dummy_5 = 0 : Adc_dummy_6 = 0 : Adc_dummy_7 = 0 : Adc_dummy_8 = 0
      41. Portb.1 = 1
      42. Waitms 1
      43. Portb.1 = 0 'SCK missbrauchen, um die Einhaltung der 20ms zu prüfen
      44. For I = 1 To 16
      45. Adc_dummy_1 = Adc_dummy_1 + Getadc(0)
      46. Adc_dummy_2 = Adc_dummy_2 + Getadc(1)
      47. Adc_dummy_3 = Adc_dummy_3 + Getadc(2)
      48. Adc_dummy_4 = Adc_dummy_4 + Getadc(3)
      49. Adc_dummy_5 = Adc_dummy_5 + Getadc(4)
      50. Adc_dummy_6 = Adc_dummy_6 + Getadc(5)
      51. Adc_dummy_7 = Adc_dummy_7 + Getadc(6)
      52. Adc_dummy_8 = Adc_dummy_8 + Getadc(7)
      53. Waitus 450 '1.25ms - (8 * ca. 0.1ms) = 0.45ms Diesen Wert noch präzisieren um auf genau 16*1.25ms =20ms zu kommen!
      54. Next I
      55. 'die Wertebereiche von ADCdummy gehen jetzt bis 16*1023=16368, wenn voll ausgesteuert wurde.
      56. 'ich nehme hier aber mal nachvollziehbare Werte für den Test:
      57. 'Dim Kanalnummer As Byte
      58. Kanal1spannung(sramsekunde) = Sramsekunde + 3100
      59. Kanal1strom(sramsekunde) = Sramsekunde + 1100
      60. Kanal2spannung(sramsekunde) = Sramsekunde + 3200
      61. Kanal2strom(sramsekunde) = Sramsekunde + 1200
      62. Kanal3spannung(sramsekunde) = Sramsekunde + 3300
      63. Kanal3strom(sramsekunde) = Sramsekunde + 1300
      64. Kanal4spannung(sramsekunde) = Sramsekunde + 3400
      65. Kanal4strom(sramsekunde) = Sramsekunde + 1400
      66. '...
      67. Locate 2,1:Lcd Sramsekunde ; "/"; Speicherintervall ; " "
      68. If Sramsekunde >= Speicherintervall Then 'dann ist der Zeitpunkt zum "auf SD Wegspeichern" gekommen
      69. '4 Dateien nacheinander öffen, werte überschreiben und in Zeilen speichern
      70. Locate 4, 1:lcd "writing "
      71. gosub SD_ch1_schreiben
      72. gosub SD_ch2_schreiben
      73. gosub SD_ch3_schreiben
      74. gosub SD_ch4_schreiben
      75. Locate 4, 1:lcd "written "
      76. Sramsekunde = 0
      77. End If
      78. Locate 1 , 1 : Lcd Date$ ; " " ; Time$
      79. '...
      80. Return
      81. '...
      82. SD_ch1_schreiben:
      83. Str16 = Str(Zellennummer(1)) + ".csv"
      84. If Sd_card_ok = 1 Then
      85. Open Str16 For Append As #11
      86. Onboardled = 1
      87. for i = 1 to Speicherintervall
      88. write #11 , Kanal1spannung(i) , Kanal1strom(i)
      89. next i
      90. Close #11
      91. Onboardled = 0 'die LED wieder ausschalten
      92. End If
      93. Set Mmc_cs 'das deaktiviert die SD
      94. return
      95. SD_ch2_schreiben:
      96. Str16 = Str(Zellennummer(2)) + ".csv"
      97. If Sd_card_ok = 1 Then
      98. Open Str16 For Append As #12
      99. Onboardled = 1
      100. for i = 1 to Speicherintervall
      101. write #12 , Kanal2spannung(i) , Kanal2strom(i)
      102. next i
      103. Close #12
      104. Onboardled = 0 'die LED wieder ausschalten
      105. End If
      106. Set Mmc_cs 'das deaktiviert die SD
      107. return
      108. SD_ch3_schreiben:
      109. Str16 = Str(Zellennummer(3)) + ".csv"
      110. If Sd_card_ok = 1 Then
      111. Open Str16 For Append As #13
      112. Onboardled = 1
      113. for i = 1 to Speicherintervall
      114. write #13 , Kanal3spannung(i) , Kanal3strom(i)
      115. next i
      116. Close #13
      117. Onboardled = 0 'die LED wieder ausschalten
      118. End If
      119. Set Mmc_cs 'das deaktiviert die SD
      120. return
      121. SD_ch4_schreiben:
      122. Str16 = Str(Zellennummer(4)) + ".csv"
      123. If Sd_card_ok = 1 Then
      124. Open Str16 For Append As #14
      125. Onboardled = 1
      126. for i = 1 to Speicherintervall
      127. write #14 , Kanal4spannung(i) , Kanal4strom(i)
      128. next i
      129. Close #14
      130. Onboardled = 0 'die LED wieder ausschalten
      131. End If
      132. Set Mmc_cs 'das deaktiviert die SD
      133. return
      134. '...
      Alles anzeigen
      Die Dateien gehen sauber auf die SD-Karte (auch mit "echter Uhrzeit und Datum"!), hinter ein paar Kopfzeilen (Code dafür hier nicht dargestellt, ähnlich wie bei Riedleweg) kommen in jeder Datei die (ehemals sekündlichen) Wertepaare von Spannung,Strom (jeweils in mV und mA, also vier STellen) in Zeilen untereinander.
      Ich brauche zum Speichern aller vier Dateien etwa 520ms. Das finde ich relativ viel, hatte mit weniger gerechnet. Urspünglich wollte ich auch noch eine Sammlung bis jeweils zum Zeitpunkt 256s testen, aber das werde ich nun aber bleiben lassen, da das Umspeichern auf die SD dann allem Anschein nach länger als eine Sekunde dauern und die periodischen Messungen stören würde. Vielleicht gehe ich sogar noch runter auf nur 120s, das sind dann "echte" 2min; ich bin ja nicht an irgendwelche 2er Potenzen gebunden.
      Ich meine, ich will nicht meckern, es läuft ja alles gut, aber es braucht doch relativ lange Zeit um vier kleine (Text-)Dateien á ca. 1500 Byte zu schreiben. Habt ihr noch eine Idee, wie ich das schneller hinbekommen kann? Wo liegt der "Flaschenhals"? Kann man den SPI-Takt erhöhen? Oder ist das nicht ratsam für das AVR-DOS?
      Der Compiler meldet
      Stack start : 21FF hex
      Stack size : 96 hex
      S-Stacksize : 96 hex
      S-Stackstart : 216A hex
      Framesize : FA hex
      Framestart : 1FDA hex
      Space left : 4194 dec
      Die letzte Zeile gibt doch an, wieviel SRAM noch frei ist, richtig? Theoretisch könnte ich mit dem Mega2560 also noch etwa doppelt so viel wie 128x2x4 Words zwischenspeichern und bräuchte dann nicht so häufig auf die SD zugreifen, wenn das Einspeichern zB doppelt so schnell ginge.

      Ich bin gespannt auf eure Meinungen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von laase ()

    • ich habe mir die Option mit dem 32.768kHz Uhrenquarz übrigens noch einmal angeschaut: das Arduino Mega2560 Board hat die Pins Osc2 und Osc1 (PG.3 und PG.4) nicht beschaltet. SIe sind komplett "offen" und auch nicht rausgeführt. (Ist das auf den neuerdings auch günstig angebotenen "Mini MEGA 2560 Pro" vielleicht anders, weiß das jemand? Zumindest haben die interessanterweise einen "echten" 16MHz Quarz!)
      Wer natürlich trotzdem mit zwei Haar-Drähtchen dort einen Quarz anschließen möchte: wenn die Chip Markierung links oben ist, so sind es der dritte und der vierte Pin von links unten. Ich spare mir das aber, @Pluto25 hat mir ja gezeigt, wie ich die Uhrzeit trotz ungenauen 16MHz Quarzes (bzw Resonators) ausreichend trimmen kann.
    • Das öffnen und schließen braucht auch Zeit. Er hat genug Sram um sie offen zu lassen? Wie wärs den Wert nicht in Array zu sammeln sondern gleich in die Sd zu legen. Er sammelt dann in den SD Buffer und schreibt wenn er voll ist.
      Oder mit Flush. Diese Flush könnten dann einzeln nach je 2 min mit 30Sekunden Versatz aufgerufen werden. Damit schreibt er immer nur in eine Datei die er nicht zuerst Öffnen muß. Das benötigt aber zwingend eine Möglichkeit ihm zu sagen das die Sd entnommen werden soll, sonst wären die letzten Einträge unvollständig.
      Nicht zeitsparend aber sicherer wäre es die SD_chx_schreiben einzeln im 30 s Abstand aufzurufen.( je 1/4 Zeit)
      PS 1500Byte? Da muß er mit vier Sectoren rödeln. Den ersten einlesen um zu sehen wo es weitergeht ....
      (Bekannt? vom PC. Bei vielen kleine Dateien wird der beworbene Speed zum Schneckentempo. )
    • Hallo Pluto,

      Pluto25 schrieb:

      Er hat genug Sram um sie offen zu lassen?
      Davon gehe ich aus, weiß es aber letztlich auch nicht wirklich. Ich habe dem Atmega2560
      $hwstack = 150
      $swstack = 150
      $framesize = 250
      gegeben. Das finde ich "üppig", wüßte aber auch nicht, wo ich mehr bräuchte und wo ggf weniger.

      Pluto25 schrieb:

      Wie wärs den Wert nicht in Array zu sammeln sondern gleich in die Sd zu legen. Er sammelt dann in den SD Buffer und schreibt wenn er voll ist.
      Ich habe natürlich darüber nachgedacht. So macht @Riedleweg das ja auch. Bei mir wechseln aber die Kanäle mit den daran angeschlossenen Zellen sekündlich durch und ich müßte dann in einer Sekunde, jeweils nach dem Wertemessen vier Dateien nacheinander öffen, jeweils zwei Werte reinschreiben und wieder schließen. Da dachte ich an die begrenzte Schreibzyklenzahl der SD's und habe das verworfen. Daher die Sammlung im SRAM, bis eine gewisse "schreibwürdige Anzahl an Daten" vorhanden ist.
      Wie das mit dem "Buffer" läuft, wenn es sich um vier Dateien handelt, weiß ich nicht. Ich kann mir nicht vorstellen, daß der SD-Controller vier Buffer anlegt? Vielleicht habe ich das aber auch alles ganz falsch verstanden?
      Oder ist der "SD-Buffer" gar keine Sache, die vom SD-Controller angelegt wird, sondern vom AVR-DOS? Und würde dieses AVR-DOS dann vielleicht doch vier solcher Buffer anlegen, weil es schlau ist und mitdenkt? ;)
      Und ob nun AVR-DOS oder die Karte direkt, ich würde den Zeitpunkt des Schreibens gern "in der Hand haben", weil dabei wohl einiges mehr an Strom fließt (?) und das soll besser nicht "unkontrolliert" passieren.

      Pluto25 schrieb:

      Oder mit Flush. Diese Flush könnten dann einzeln nach je 2 min mit 30Sekunden Versatz aufgerufen werden. Damit schreibt er immer nur in eine Datei die er nicht zuerst Öffnen muß.
      Auch das mit dem Flush habe ich leider noch nicht 100%ig verstanden. Bei mir ist nur im Kopf hängengeblieben, daß man (wen auch immer) zwingt, die noch nicht auf die SD geschriebenen Daten JETZT sofort zu schreiben (und eben nicht mehr zu warten, bis eine genehme Anzahl vorhanden ist). Das würde aber doch auch bedingen, daß über Sekunden hinweg immer nur EINE der vier Dateien geöffnet ist? Dann müßten die Daten der anderen drei Kanäle doch aber solange auch irgendwo zwischengespeichert werden? Der Vorteil erschließt sich mir nicht ...

      Pluto25 schrieb:

      Nicht zeitsparend aber sicherer wäre es die SD_chx_schreiben einzeln im 30 s Abstand aufzurufen.( je 1/4 Zeit)
      Das kann ich natürlich machen. Nicht alle auf einmal in großer Zeitspanne, sondern immer nur eine Datei und dafür in kürzeren Abständen. Die Anzahl der Schreibzyklen bliebe dabei gleich. Danke, ich probiere das aus!

      Pluto25 schrieb:

      PS 1500Byte? Da muß er mit vier Sectoren rödeln. Den ersten einlesen um zu sehen wo es weitergeht ...
      Sollte ich die Schreibeinheiten lieber auf die Sektorgröße (512Byte) begrenzen? Oder "knapp drunter", also lieber zB 500Byte, um auf der sicheren Seite zu sein?
      Muß aber erst einmal prüfen, wieviel Zeilen bzw. Wertepaare das in der Realität sind.
      Andererseits hieße das ja auch wieder, letztlich mehr Schreibzugriffe zu haben. Dann wohl doch lieber mit mehr Sektoren "rödeln" lassen und "ihm" die Zeit zu geben, die er braucht, oder?

      Wo wird bei AVR-DOS eigentlich die SPI-Geschwindigkeit festgelegt?
      Laut Datenblatt kann ich mit dem Register SPCR (SPI-Control Register) und dort insbesondere mit den Bits 1, 0 – SPR1, SPR0 (SPI Clock Rate Select) den SPI-Takt beeinflussen. Ich probiere mal, mir das Register (bzw. den derzeitigen Status dieser Bits) anzeigen zu lassen.
    • Das SPCR-Byte lautet: 01011100. Demnach sind die Bits SPR1 und SPR0 Null.
      Das Register beinhaltet das Bit SPI2x, womit die Taktgeschwindigkeit noch einmal verdoppelt wird. Dieses Register lautete bei mir: 00000000, das letzte Bit (SPI2x) ist also auch 0; D.h. laut Datenblatt läuft das SPI derzeit mit fosc/4 (4MHz). Ich könnte den SPI-Takt noch auf fosc/2 verdoppeln, wenn ich hier das letzte Bit auf 1 setze.
      Verträgt das System (Das AVR-DOS, der CMOS-Chip zur Pegelwandlung und die SD-Karte selbst) auch 8MHz?
    • Habe mal weiter recherchiert: an den SD's liegt es schonmal nicht, deren Standard-Geschwindigkeit ist 25MHz. Die sind mit 4 oder 8MHz also allesamt "unterfordert".
      Der Pegelwandler Chip ist bei mir ein 74HC4050. 8MHz heißt 125ns Periodendauer. In dieser Zeit muß er einen LH-Übergang, eine H-Haltung, einen HL-Übergang und eine L-Haltung ausführen und das Signal soll noch annähernd rechteckig aussehen und nicht wie irgendein Spitzgebirge mit Rundkuppen. Angesichts einer "propagation delay time" von typisch 25ns, max aber 105ns und einer "transition time" (man könnte auch 'Flankensteilheit' dazu sagen) von typisch 19ns, max aber 95ns würde ich sagen, daß der Chip mit 4MHz schon recht gut "zu tun hat".
      Laut TI Logic Guide wären die Typen AHC, AC und noch einige weitere mehr als doppelt so schnell wie der HC und mit diesen wäre also eine Frequenzverdoppelung gut möglich. Ich will aber keine SMD-Chips auf dem Ramps 1.4 LCD-SD-Controller tauschen (außerdem finde ich auf die Schnelle keine AHC4050 oder AC4050 Chips; die heißen dann wahrscheinlich anders) und von daher belasse ich es also bei 4MHz.
    • SDs hatte ich mit FAT16 formatierten bisher immer erfolg, die grösseren formatiert Windows aber freiwillig nicht damit. Grösser 2 GB hab ich nie grossartig benutzt, ist ja verschwendung. Ich hab hier noch nen riesenschwung 32Mb bis 2Gb aufzubrauchen. Und ich fahre die Dinger mit Widerstands Spannungteiler an 5V, läuft sehr gut. Nur die Spannungsversorgung muss echt gut sein, SD karten können grad beim Init ganz schön was wegziehen Ich bin aber für das letzte Projekt auf 3,3V Systemspannung gegangen, ist das ne Option? Alle Komponenten können es ja eigentlich.

      Tobias
    • laase schrieb:

      Frequenzverdoppelung gut möglich
      Ausprobieren bei mir wollten manche SD's das nicht. Dem Avr macht das nichts und der Pegelwandler wird auch nicht brennen?

      laase schrieb:

      Sollte ich die Schreibeinheiten lieber auf die Sektorgröße (512Byte) begrenzen? Oder "knapp drunter", also lieber zB 500Byte, um auf der sicheren Seite zu sein?
      Am einfachsten die Datei offen lassen - AVR-Dos macht das dann schon. Bei jedem Öffnen muß er das Ende suchen um zu wissen ob der Sektor voll ist evt den letzten einlesen. Ideal von Zeitaufwand und Schreibhäufigkeit ist ihn immer genau voll zu haben. Wenn es das nun nicht selber darf müsste die Datei genau abgezählt werden: Header, Daten bis genau 512 dann Datei Öffnen/Schließen. Möglicherweise ist es klug genug zu wissen das dann kein Sektor gelesen werden muß.
      Flush schreibt alle geöffneten Dateien, wenn es nicht explizit eine gesagt bekommt (z.B. Flush #3)
      Ist der Strom zum Schreiben nennenswert? Gebraucht wird er irgendwann doch und dann mindestens doppelt soviel (Einlesen. auffüllen, zurückschreiben und einen neuen beginnen)

      PS Eine Csv sollte Klartext mit Trennern sein. Eine Endlosfolge bin Daten "verwirren" das Leseprogramm
    • Hi Tobias,
      nein, ob groß oder klein spielte bei meinen 5 Exemplaren von 250MB bis 32GB (SDHC) bisher keine Rolle.
      Auf den Ramps 1.4 LCD 2004 SD Encoder boards ist halt schon alles drauf, neben dem Pegelwandler auch schon ein Linearregler extra für die SD-Karte. Bei dem Preis und der kompakten Anordnung sinnvoller Elemente für ein fertiges Gerät konnte ich nicht widerstehen ...
      Den Mega2560 muß ich schon mit 5V versorgen, allein schon wegen des 2004 LCDs. Aber auch der 16MHz Quarz geht glaube ich nur mit 5V. Außerdem ists durch das Arduino board auch da schon vorgegeben. Auch zum Akkuladen brauche ich 5V, von daher habe ich über 3,3V nie wirklich nachgedacht.
      Aber jetzt wo Du es sagst: klar, 4,3V wäre noch gegangen, mit einstellbarem Regler: passt haargenau für's LCD, Läßt sich einfach aus den 5-5.5V "Power supply" generieren (und kappt dabei gleich auch noch ein paar Rippel) und auch das Runtersetzen auf 3.3V für die SD ist mit dem auf dem 2004 board verbauten Regler auch gut möglich.
      Zur Zeit läuft es bei mir aber so, daß ich aus den "verrippelten Power 5.5V" erst einmal auf 12V hochgehe (Versorgung der OPVs für die Konstantstromquellen und für die Gates der Mosfets) und von dort wieder runter (und geglättet) auf 5V (für das Mega2560 board, die Meßverstärker-OPVs, das 2004-SD-board und die Multiplexer). Das Mega2560 board "nimmt" zusammen mit dem LCD board ca. 100mA. Das können sowohl 5.5->12 Hochsetzer wie auch 7805 gut und ohne viel Rippel und Rauschen zu produzieren. 300mA kurzzeitig sind auch kein Problem, dann aber bitte nicht ausgerechnet dann, wenn gerade gemessen wird, weil die 12 und die 5V dann deutlich verrippelter sind.

      @Pluto25: Frequenzverdoppelung habe ich abgehakt, mache ich nicht mehr! Stattdessen werde ich wohl annähernd Deinen "verteile es" Tipp verwenden und nicht alle 2,x Sekunden vier Dateien auf einmal schreiben, sondern jede volle Minute nur zwei Dateien. Das erscheint mir nach allen pro's und con's noch am besten. Und jede Minute ist auch schön "rund" und stört von der Zeitdauer her auch nicht (ca. 250ms).
      Das mit dem Datei offenlassen klappt halt nicht, da ja vier Dateien durchwechseln müssen.
      Das mit den 512 Bytes zur Nutzung eines "vollen" Sektors auch nicht, da jede "Sekundenzeile" 11 Byte groß ist und ich dann nach "46,55" Sekunden speichern und eine Zeile gar unterteilen müßte. Dann doch lieber alle 60 Sekunden und nicht ganz byteoptimiert.
      Oder meintest Du, ich kann mehrere Stunden lang alle vier Dateien geöffnet lassen? Und dann zB alle 45s "flush #11 : flush #12 : flush #13 : flush #14" zu befehlen? Das wäre natürlich Spitze!


      Meine csv's sind genau so, wie Du empfiehlst! Drin steht zB die Zeile '3650,3998' . Es gibt lediglich einen Header mit 3-4 Zeilen oben, wo die Daten noch nicht diese Struktur haben. Und ganz zum Schluß (nach die zu testende Zelle "fertig" ist) wird jeweils noch die Zusammenfassung mit den Ergebnissen in die Datei gescheiben. Und der Druckstring, der direkt davor an den Zebra-Drucker gesendet wurde oder noch wird.
    • laase schrieb:

      Oder meintest Du, ich kann mehrere Stunden lang alle vier Dateien geöffnet lassen?
      Ja, für immer. Close nur beim abschalten oder zum SD ziehen. (So mein Gedanke, ich hab es nicht mit mehreren Dateien versuchen können (Sdram - not) ;(
      Vielleicht ein Versuch ohne Flush : Er wird nur schreiben wenn Daten reingekommen sind (nach dem messen). Das wird sich im Code gut timen lassen: Wert erfassen, umrechnen, ablegen, Lcd ändern, alles andere nicht spannungskritische, wieder messen ....
    • Hi Pluto,

      es hat nicht funktioniert. AVR-DOS ist offenbar nicht ohne Weiteres dafür geschaffen, vier demnächst zu schreibende Dateien gleichzeitig "offen zu halten". Eine ja, vier aber nein.

      Ich habe meinen Code vorerst so gelassen, wie er war und nur nach dem jeweiligen Schreiben der Kopfzeilen die 4x "Close #Channel" rausgenommen. EBenso das Setzen der /SS Leitung. Beim 128-sekündlichen Dateien Schreiben habe ich dann ebenfalls alle "Open #channel" (und "Close #Channel") herausgenommen. Er hätte hier nun alles in einem Rutsch aus dem SRAM in die ja vermeintlich noch geöffneten Dateien schreiben können.
      Für das Schließen habe ich eine Prozedur eingebaut, die auf den Taster des Rotary ENcoder reagiert, dann zunächst 4x "flush #Channel" ausführt, gefolgt von 4 x "Close #Channel". Danach auch noch /SS gesetzt. Auch jeweils ein paar 500ms Pausen dazwischen, damit auch alles sicher ausgeführt werden kann.

      -> Auf der Karte wurde nur eine Datei (die erste) angelegt. Der Name, das Erstellungsdatum, die Kopfzeilen und Daten in der Datei waren korrekt. Das für diese Datei bestimmte Datenpaket á 128Zeilen (je 9/11 Byte; zusammen 1408 Byte) wurde nachweislich auch in sehr kurzer Zeit auf die SD geschrieben (irgendwas unter 50ms). Es fehlten halt nur die drei restlichen Dateien. Sie wurden nicht einmal angelegt ...

      Ich bleibe daher wohl beim "Durchwechseln" der Dateien, jeweils mit einen Öffnen und schließen. Das funktioniert ja sehr gut, wenn auch angesichts von 4x 1408 Byte etwas langsam (zusammen knapp 500ms). Vielleicht gehe ich von den "für nichts guten" 128s auf 120s ("alle 2min") runter oder speichere alle 60s jeweils die Kanäle 1 und 3 und die nächsten 60s die Kanäle 2 und 4.

      Gegen zu häufiges Nutzen immer gleicher Speicherzellen der SD-Karte hilft doch bestimmt auch, nicht jedesmal alle Dateien der Karte zu löschen, wenn man sie zum PC transportiert, oder? Da die angelegten Dateien im Gegensatz zur Speicherkapazität verschwindend klein sind, würde ich denken, daß man einfach alle bis zum St.Nimmerleinstag drauf läßt? Dann sollten doch immer neue Zellen genutzt werden und die Erstzellen = "potenziellen Erst-Opfer-Zellen" werden so gut wie möglich geschont?
      Oder wird mit steigender Anzahl von Dateien im Hauptverzeichnis der Karte die Suche nach "den richtigen zum Weiterdrinschreiben" dann immer länger dauern und ich riskiere, irgendwann deutlich mehr als 500ms für's Weiterschreiben von vier Dateien ansetzen zu müssen?
    • Danke Michael!
      Das mit der längeren Suche und der Auswirkung auf die Speicherzeit mehrerer zu öffnender und "weiterzuschreibender" Dateien muß ich nochmal prüfen.

      @Pluto25: ich habe die vesetzte Speicherung (bei Sekunde 60 die Dateien 1 und 3, bei Sekunde 120 die Dateien 2 und 4) umgesetzt. Hierfür den Sekundenzähler für die 1 und 3 von Bginn an auf 60 "vorgespannt".
      Es funktiniert gut und die beiden Dateien werden minütlich in nur 175ms (statt vorher vier in knapp 500ms) geschrieben. So lasse ich es jetzt, wenn nicht die von Michael prophezeite längere Suchzeit sich noch merklich auswirkt.