Datenlogger auf ARDUINO- Basis

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    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!

    • Ulrich wrote:

      Erlaubt das OpenLog-Modul zur Laufzeit auch weitere neue Files anzulegen?
      Ja, natürlich.
      Sogar mit Unterverzeichnissen.
      Hier ein Codeschnipsel

      BASCOM Source Code

      1. sTxt = "Datei.CSV"' beliebiger Name und Erweiterung wichtig 8.3
      2. Clear_RS232 ' löscht den seriellen Buffer, kann eventuell auch unterbleiben
      3. Print "append " ; sTxt ' mit append wird entweder an das bestehende File angehangen oder dieses File auch neu erstellt
      4. fX = RS_Input( "<")' wartet auf Antwort von Openlog, wenn "<" dann wird 1 zurückgegeben
      5. If fX = 1 Then' Openlog empfangsbereit, Datenübertragung beginnt
      6. Print "Deine Daten....."
      7. Print
      8. Clear_RS232 ' löscht den seriellen Buffer, kann eventuell auch unterbleiben
      9. Print "{026}{026}{026}";' Datenübertragung beenden, File schließen
      10. fX = RS_Input( "~>")' OpenLog hat den Abbruch zur Kenntnis genommen
      11. Print "sync"' Startet SYNC im Openlog-Modul
      12. End If
      Display All
      So kann entweder in der Folge in die bestehende aber auch eine neue Datei geschrieben werden.

    • @Zitronenfalter

      mit dieser ausführlichen Hilfe habe ich mal deinen Codeschnipsel etwas nach meinem Verständnis ergänzt. Anstelle von "Append" könnte man also auch "new" verwenden. Jedoch wodurch ist die Tilde beim größer Zeichen (~>) definiert?

      Gruß
      Ulrich

      BASCOM Source Code

      1. '(
      2. BASCOM-Quellcode
      4. nachdem alle Tagesdaten auf der SD_Card im file Dat-1.csv gelandet sind, soll mit
      5. dem zweiten Tag auch ein neues Files Dat-2 erstellt werden.
      7. ')
      9. '********zweiter Tag **************************************************************
      11. Print "{026}{026}{026}"; ' vorherige Datenübertragung beenden, File schließen
      12. Do ' warten auf Antwort von Openlog, dann wird 1 zurückgegeben
      13. Fx = Rs_input( "~>")
      14. Loop Until Fx = 1 'OpenLog hat Abbruch erkannt....
      15. '........und befindet sich nun im Befehls-Modus
      17. Print "sync" 'schreibt eventuellen Rest des 512 Bytes Buffer
      18. Stxt = "230923.CSV" 'beliebiger Name und Erweiterung wichtig 8.3
      19. Print "new" ; Stxt 'neues File erstellen
      21. Do
      22. Fx = Rs_input( "<") ' wartet auf Antwort von Openlog, wenn "<" dann wird 1 zurückgegeben
      23. Loop Until Fx = 1
      25. Print "neue Tagesdaten....."
      27. '********dritter Tag **************************************************************
      28. '
      29. Print "{026}{026}{026}"; ' vorherige Datenübertragung beenden, File schließen
      30. Do ' wartetn auf Antwort von Openlog, dann wird 1 zurückgegeben
      31. Fx = Rs_input( "~>")
      32. Loop Until Fx = 1 'OpenLog quittiert den Abbruch....
      33. '........und ist nun im Befehls-Modus
      35. Print "sync" 'schreibt eventuellen Rest des 512 Bytes Buffer
      36. Stxt = "240923.CSV" 'beliebiger Name und Erweiterung wichtig 8.3
      37. Print "new" ; Stxt 'neues File erstellen
      39. Do
      40. Fx = Rs_input( "<") ' wartet auf Antwort von Openlog, wenn "<" dann wird 1 zurückgegeben
      41. Loop Until Fx = 1
      43. Print "neue Tagesdaten....."
      45. ' usw.....
      Display All

    • Ulrich wrote:

      Anstelle von "Append" könnte man also auch "new" verwenden.
      Ich denke, dass "NEW" nur die Datei erzeugt aber dann danach erst mit "APPEND" in die Datei geschrieben werden kann.
      "APPEND" wiederum öffnet die vorhandene Datei oder legt diese eben an wenn die Datei noch nicht existiert und öffnet diese dann (im Prinzip ein kombiniertes "NEW"+"APPEND").
      Weil nur nach "APPEND" kommt es überhaupt zur Daten-Eingabeaufforderung "<", nach "NEW" kommt wohl keine Dateineingabeaufforderung somit wird man da ewig warten und im ungünstigsten Fall der weitere Ablauf blockiert werden.

      Um überhaupt derartige Befehle abgeben zu können, muss sich das Modul ja auch im Befehlsempfangmodus (Config Mode 2=Command Prompt) befinden welcher wiederum durch die Ausgabe von ">" signalisiert wird.

      Ulrich wrote:

      Jedoch wodurch ist die Tilde beim größer Zeichen (~>) definiert?
      Das sind einfach zwei Zeichen die das Modul hintereinander sendet, zuerst die Tilde welche signalisiert, dass der Datenempfangsmodus vom Modul beendet wurde und dann das ">" welches anzeigt, dass wieder Befehle empfangen werden können.
      Also alles was jetzt wieder gesendet wird sind Befehle und keine Daten mehr.
      Je nach Einstellung von VERBOSE in der Config werden dann entweder aussagekräftige Fehlermeldungen oder einfach ein "!" welches dann als "!>" ausgegeben wird (da ist dann auch wieder das ">" Zeichen.

      Weil du in deinem Code das "RS_INPUT" verwendest lege ich den Code dazu hier auch noch bei:

      BASCOM Source Code

      1. '(
      2. ##############################################################################
      3. #
      4. # RS_Input
      5. # Liest die RS232-Schnittstelle aus, wertet das Ergebnis aus und
      6. # gibt dieses zurueck
      7. #
      8. # Parameter: Der Suchstring
      9. #
      10. # HINWEIS : Die Variable iCOunt wird in einem (hier 16ms Timer-IRQ) alle 16ms erhöht
      11. # Das kann man sicher auch ohne IRQ ich hatte aber in der aktuellen Anwendung einen
      12. # verfügbar ;-)
      13. #
      14. # Rueckgabe: =0 bei Zeitablauf oder nicht erhalten
      15. # =1 wenn der Suchstring empfangen wurde
      16. #
      17. ##############################################################################
      18. ')
      19. Function RS_Input(ByVal pResult As String * 20) As Byte
      20. Local fA As Byte
      21. Local fS As String * 50
      22. Local fR As Byte
      24. fR = 0
      25. iCount = 0
      26. fS = ""
      27. Waitms 100
      28. Do
      29. If IsCharWaiting() = 1 Then
      30. fA = WaitKey()
      31. If fA >= 10 Then
      32. fS = fS + Chr(fA)
      33. End If
      34. If Instr(fS , pResult) <> 0 Then
      35. fR = 1
      36. End If
      37. End If
      38. Loop Until iCount > MS_208 Or fR = 1
      39. RS_Input = fR
      40. End Function
      Display All

    • @Zitronenfalter

      Deinen Hinweis bzgl. new und append werde ich gleich berücksichtigen. Auch der Schnipsel mit Ischarwaiting ist schon abgespeichert.

      Jedoch entstammen meine Daten für den Logger einer ADC-Messung, wieder mal Temperatur a_48_7237538e , mit Datum und Uhrzeit.
      Auch wichtig: das Semikolon nach den 3-fachen Abbruch-Zeichen: Print "{026}{026}{026}"; hätte ich fast vergessen.
      Meine Frage zur Tilde hatte den Hintergrund, dass es im aktuellen OpenLog.pdf im Lexikon nicht vorhanden ist.

      Zitronenfalter wrote:

      Um überhaupt derartige Befehle abgeben zu können, muss sich das Modul ja auch im Befehlsempfangmodus (Config Mode 2=Command Prompt) befinden welcher wiederum durch die Ausgabe von ">" signalisiert wird.
      Stellt sich denn der Befehlsempfangmodus nicht schon durch die 3-fachen Abbruch-Zeichen ein, das hatte ich so verstanden?

      Gruß
      Ulrich

    • Ulrich wrote:

      Stellt sich denn der Befehlsempfangmodus nicht schon durch die 3-fachen Abbruch-Zeichen ein
      Das mag so sein.
      Wenn du aber ohnehin in eigene Dateien speichern möchtest, muss das Modul im Command Prompt Modus sein.
      Dieser kann durch die CONFIG.TXT auch eingestellt werden (die Zeile lautet dann "9600,26,3,2,0,0,0,100,60" ohne Anführungszeichen)
      Logmodus (0-3, Fehlermeldungen (0=kurz, 1=lang, Echo (0=aus, 1=ein)
      Nachdem die Config einmal gelesen wurde "merkt" sich das Modul auch diese Einstellungen und legt z.B. auf einer neuen SD-Karte auch diese Einstellungen an indem dort die CONFIG.TXT mit eben diesen Daten neu angelegt wird wenn die Datei nicht existiert.
      Die Datei kann natürlich auch am PC-vorgeschrieben werden.

      Wenn das Modul schon beim Einschalten im Command-Mode ist, braucht man dann nicht jedes mal das dreifach ESCAPE senden sondern sendet immer gleich die Befehle.
      Um sicher zu gehen dass nichts im seriellen Buffer ist was die Auswertung beeinflussen könnte (z.B. vorherige Fehlermeldungen) sollte man den Buffer eben auch immer vorher löschen.
      So sendet das Modul nach dem Einschalten ja auch schon was.

    • @Zitronenfalter

      Ich verstehe deinen Post#25 derart, dass man das Modul via Config.Txt schon in den Command-Modus versetzen sollte, damit man nach Powerup als erste Handlung den eigenen und ersten Filenamen sogleich einstellen kann, ohne das 3-fache Escape.

      Dann wird somit auch nach dieser erstmaligen Filenamen-Einstellung auf den Datenempfangs-Modus umgeschaltet, wenn das entsprechende Procedere aus Post#21 befolgt.

      Für alle darauf folgenden zur Laufzeit neu zu erstellenden Files gilt dann jedoch wieder das 3-fache Escape zum Aufruf des Command-Modus mit den weiteren Filenamen-Einstellungen, nach Post#21 Schnipsel.

      Der diesbezügliche Inhalt (rot, groß) der Config.txt Datei (9600,26,3,2,0,0,0,100,60) gilt somit nur für diePowerup-Phase .

      Habe ich das richtig interpretiert? a_27_b277ca12

      Gruß
      Ulrich

    • Ulrich wrote:

      Habe ich das richtig interpretiert?
      Nicht ganz

      Ulrich wrote:

      Der diesbezügliche Inhalt (rot, groß) der Config.txt Datei (9600,26,3,2,0,0,0,100,60) gilt somit nur für die Powerup-Phase
      Nein, die wird beim Einschalten ausgewertet und gilt über die gesamte Laufzeit, könnte aber im Command-Mode über den Befehl "SET" auch wieder (auch da dann dauerhaft bis zur nächsten Änderung verändert werden (über den Befehl "SET" wird auch die "CONFIG.TXT" geändert!)

      Ulrich wrote:

      Für alle darauf folgenden zur Laufzeit neu zu erstellenden Files gilt dann jedoch wieder das 3-fache Escape zum Aufruf des Command-Modus
      Nein das Modul wird nach dem Einschalten sofort in den Command-Modus versetzt, legt keine eigene LOG-Datei an und erwartet Befehle.
      Einer dieser Befehle ist dann z.B. "APPEND" nach welchem in die so geöffnete Datei Daten geschrieben werden (eben so lange bis dass der Vorgang durch die ESCAPE-Sequenz (Standard 3x Chr 26) wieder abgebrochen wird.Der Ablauf ist in etwa so:
      • Das Modul wird aktiviert, das Modul liest seine "Config.txt", und verhält sich entsprechend, im Beispiel geht es dann sofort in den Command-Mode,und sendet "12>" zurück
      • Der Befehl "APPEND XYZ.TXT" wird zum Modul gesendet, das Modul legt die Datei "XYZ.TXT" an wenn die noch nicht vorhanden ist und/oder öffnet in der Folge diese und sendet "<" zurück weil es nun auf zu schreibende Daten wartet
      • Es kommen Daten, diese schreibt das Modul in die geöffnete Datei (auch vermeintliche Befehlssequenzen werden einfach geschrieben und nicht ausgewertet!)
      • Es wird zum Modul die ESCAPE-Sequenz gesendet (Standard 3x Chr 26), das Modul schließt die Datei und sendet die Tilde "~" und geht in den Command-Modus zurück welches durch Senden von ">" angezeigt wird.
        Diese ESCAPE-Sequenz dient hier einfach dazu eben zwischen Eingabe- und Befehls-Modus zu wechseln (woher sollte das Modul sonst wissen, das jetzt keine Daten sondern Befehle kommen.'
        Es ist daher auch wichtig, dass im Datenstrom niemals diese Sequenz als Daten vorkommt weil dann die Datenübermittlung abgebrochen wird und auch wieder der Befehls-Modus aktiviert wird der mit den dann noch immer eintreffenden Daten nichts anfangen können wird und entsprechend Fehlermeldungen absetzen wird.
      • Nach dem Empfang der ESCAPE-Sequenz erwartet das Modul wieder Befehlssequenzen welche die bekannten Befehle sein können (also wieder ein APPEND aber auch alle anderen Befehle)

    • @Zitronenfalter

      Zunächst einmal ganz herzlichen Dank für deine Mühe die OpenLog-Details einem "Blinden" ausführlich darzulegen.

      Auch wenn man lesen kann und alle Befehle gesehen hat, so ist doch immer noch eine Menge an Trial and Error Versuchen erforderlich, um sich sicher zu sein, dass alles auch wie gewollt funktioniert.

      Für diese deine Vorarbeit gebührt dir allergrößter Respekt.

      Ich muss auch zugeben, dass ich das Bascom-Kommando fX = RS_Input( "<") erst als solches erkannt habe, nachdem ich dein Programmteil aus Post#23 gesehen hatte.

      Aber ich denke, mit deinem quasi Pseudocode aus Post#27 sowie auch mit den Programmschnipseln sollte es nun kein Problem mehr sein, zur Laufzeit neue files anzulegen und zu beschreiben.

      Darüber werde ich dann berichten.

      Gruß
      Ulrich

    • @Zitronenfalter

      Habe mir ein kleines Testprogramm erstellt, mit welchem die Rückgabe-Zeichen des OpenLog Moduls auf Hterm ausgegeben werden.
      Ich sehe allerdings nur die 1 und die 2 (Dez 49,50) als Rückgabezeichen und keine weitere Zeichen wie „<“ oder „>“ (Dez 60,62) die doch laut Tutorial zu erwarten wären.
      An dieser Stelle hänge ich jetzt fest und erkenne die Ursache noch nicht. Wo ist der Fehler?

      Anbei das kleine Programm sowie die Hterm-Ausgabe der Zeichen.

      BASCOM Source Code

      1. 'Test-Programm mit OpenLog Modul Kommunikation
      3. $regfile = "m2560def.dat"
      4. $crystal = 15875949 '!anstatt 16MHz hat Resonator hat nur 15,875MHz
      5. $hwstack = 200
      6. $swstack = 400
      7. $framesize = 400
      8. '$sim
      9. Disable Jtag
      11. Dim Fa(10) As Byte
      12. Dim I As Byte
      14. 'Declare Function Rs_input(byval Presult As String * 20) As Byte
      16. Config Com4 = 38400 , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
      17. Open "Com4:" For Binary As #3 'Daten-Output zum OpenLog
      19. Config Com3 = 38400 , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
      20. Open "Com3:" For Binary As #2 'Daten-Input vom Openlog, Quittungen
      22. Config Serialin2 = Buffered , Size = 200
      24. Enable Interrupts
      26. Config Com1 = 38400 , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
      27. Open "Com1:" For Binary As #1 'Daten-Output zu Hterm
      29. Wait 2
      31. ' '**********************************************************************
      32. 'OpenLog :
      33. 'config.txt 38400,26,3,0,0,0,0 'Start-File auf SD-Card
      34. '*************************************************************************
      35. Print #3 , "{026}{026}{026}"; ' #3=Com4 fürs Senden an OpenLog
      37. I = 0
      38. Waitms 100
      39. Print #1,
      41. Do
      42. If Ischarwaiting(#2) = 1 Then '#2=Com3 für Empfang von OpenLog
      43. Incr I
      44. Fa(i) = Waitkey(#2) ' Fa(i) als Byte
      45. End If
      46. Loop Until I = 10 'Zahl 5 ist willkürlich
      49. For I = 1 To 10
      50. Print #1 , Fa(i) ' #1 für Datenausgabe zu Hterm
      51. Next
      52. Print #1,
      53. Print #1 , "________"
      55. End
      Display All
      Files

      • Hterm-Bild.JPG

        (70.34 kB, downloaded 18 times, last: )

    • Ulrich wrote:

      Wo ist der Fehler?
      Ich kann es nur vermuten.

      Aber welchen Firmwarestand hat das Modul?
      Die Beschreibung bezieht sich jedenfalls auf den letzten verfügbaren (IMHO 4.3).
      Das Updaten hatte allerdings nicht so einfach geklappt wie im Netz beschrieben wurde über die Arduino-IDE, ich hatte den ISP kurz herausgeführt und das HEX-File welches die Arduino-IDE erstellte mit BasCom und MKII übertragen.
      HIER ist übrigens (in englisch) das ganze Modul beschrieben (auch dessen Firmwareupdate).

      Weil mit der "aktuellen" (bzw. beschriebenen) Version "plaudert"das Modul schon beim Einschalten selbst im Modus 0=LOG-Modus (da kommt wohl ein "12<", während im Command-Mode ein "12>" kommt).

    • @Zitronenfalter

      Zitronenfalter wrote:

      ich hatte den ISP kurz herausgeführt und das HEX-File welches die Arduino-IDE erstellte mit BasCom und MKII übertragen.
      Das scheint dann die Möglichkeit und einen Versuch wert zu sein.

      Bei uns im Eckstein-shop gibt es zwei Preisvarianten dieser OpenLog-Module, einmal die etwas teueren von Sparkfun und dann die no- name Variante zum halben Preis. Letztere habe ich gerade im Einsatz, wobei auch meine Vermutung ist, dass diese vielleicht nicht alle Funktionen an Bord haben könnte.

      Habe mir jetzt die Variante von Sparkfun bestellt. Bei meiner no-name Variante versuche ich mal deine Vorgehenweise umzusetzen.

      Gruß
      Ulrich

    • Als Antwort auf meine Anfrage bei Eckstein bzgl. Firmware in Sparkfun-Produkten erhielt ich diese hier:

      danke für Ihre Kontaktaufnahme. Wir verkaufen natürlich die neuesten und originalen Sparfun-Produkte. Sparfun verlangt von seinen Kunden, dass sie die Software selbst herunterladen und aktualisieren. Um Ihre Frage zu beantworten, stellen wir Ihnen gerne die folgenden Link und Anleitungsbild zur Verfügung: learn.sparkfun.com/tutorials/openlog-hookup-guide

    • Leider hatte ich kein Glück mit der OpenLog_43.hex. Diese Datei wird im Explorer mit 74kB angezeigt, jedoch werden nur 27kB laut Bascom in der Chip geschoben.


      Vorgehensweise:

      ISP-Stecker an 328-Chip verdrahtet, Diamex Programmer

      Chip wird erkannt
      Buffer/Load from file/ (hier also OpenLog_43.hex)

      danach Chip/write Buffer to chip/

      anscheinend wird der Bufferinhalt in den Chip geschoben, denn der grüne Balken (unten im Fenster) läuft bis zum Ende durch.

      Modul wieder ins System gesteckt, Modul tot, keine LED leuchtet. a_166_29aea317

    • Ulrich wrote:

      Diese Datei wird im Explorer mit 74kB angezeigt, jedoch werden nur 27kB laut Bascom in der Chip geschoben.
      Das ist dem Format einer HEX-Datei geschuldet. Das ist ja eine reine Textdatei welche aus Steuer- und Nutzdaten in entsprechend vielen Zeilen besteht.
      Im Prinzip Steht da in einer Zeile der Adressbeginn, eine Anzahl (z.B. 16) von Daten, einer Prüfsumme und einem CRLF.
      Die Daten sind z.B. zweistellige HEX-Zahlen. Das bedeutet, dass chon für die Datenbytes doppelt soviel Platz in der HEX-Datei benötigt wird.
      Eine typische Zeile für 16 Bytes sieht so aus :100000000C9446000C947407189500001895000095CRLF was Adresse-Daten-Checksum entspricht.
      Also brauchen 16 Bytes tatsächlich 46 Byte.
      Bei den angegeben 27kB Daten ergibt das dann rund 75kByte Text.
      HIER ist das Format auch beschrieben.

      Also wenn Bascom nur 27kByte schreibt werden das wohl auch nur soviel sein, es würde mich sogar sehr wundern, wenn es BasCom gelingen würde, in ein 32kByte Flash mehr als 32kByte unterzubringen.

    • Hallo Community,

      wie kann man ein Hex-File in einen AVR328 unter Verwendung eines Diamex-Prommers (im Bild) rein programmieren?

      Wenn man Bascom aufruft, liegt zunächst eine blanke graue Oberfläche mit der Menue-Zeile vor, wobei die Symbol-Icons unter der Menue-Textzeile ausgegraut sind. Somit ist die Menue-Funktion :

      Buffer/ Load from File nicht erreichbar.

      Es muss zuvor mindestens ein $regfile = "m328pdef.dat" vorhanden sein, erst dann wird Buffer/Load from file freigegeben.

      Ohne diesen Hinweis bzgl. Zeile mit $regfile.... finde ich keine Möglichkeit ein *.hex file, welches erwiesener Maßen für einen 328er Chip ist, eben in einen solchen 328 Chip zu prommen.

      Ich habe aber gehört, dass es mit einem Prommer vom Typ MKII funktionieren soll, worin liegt der Unterschied?

      Hat jemand helfen?

      Gruß
      Ulrich
      Files

    • Ulrich wrote:

      wie kann man ein Hex-File in einen AVR328 unter Verwendung eines Diamex-Prommers (im Bild) rein programmieren?
      Der Programmer ist hierbei relativ egal. Er muss halt von Bascom unterstützt werden.

      Was du tun musst, wenn du nur das HEX-File zur Verfügung hast ist folgendes.

      1. Bascom starten
      2. Alle Quellcode-Fenster schließen.
      3. Ein neues Quellcode-Fenster öffnen mit Menu -> Datei -> 'Neu' (oder alternatic Ctrl-N).
      4. Ein kleines Programm erstellen für den Zielcontroller (Regfile, Stacks und leere Do Loop sollten reichen)
      5. Erstelltes BAS-Programm speichern.
      6. Programm compilieren (F7).
      7. In Werkzeugleiste (Toolbar) manuell Programmieren auswählen. Es öffnet sich das Programmer- mit dem aktuell compilierten Programm im Buffer.
      8. Im Menü -> Buffer -> 'Load from File' auswählen. Es öffnet sich eine Dateiauswahlbox.
      9. Dateityp '*.hex' und anschließend die gewünschte HEX-Datei auswählen, die gebrannt werden soll. Mit OK dann das Fenster schließen. Die Hex befindet sich nun im Buffer. (Erkennbar daran, dass sich die HEX-Anzeige ändert im Fenster)
      10. Jetzt muss der Buffer auf den Chip gebrannt werden. Dazu im Menu -> Chip -> 'Write Buffer into Chip' auswählen. Das geladene HEX-File wird nun in den Chip mit dem eingestellten Programmer gebrannt.
      Das erstellte Programm wird benötigt, um die Buffergröße (Programmierfenster) und den Controller (Chip-ID) korrekt einzustellen. Die Stackwerte haben keinen Einfluss und dienen nur dem Compiler, damit keine Fehlermeldungen ausgegeben werden.

      Viel Erfolg!

    • @Mitch64

      vielen Dank für diese genaue Beschreibung, wäre dies nicht auch was fürs Lexikon, oder habe ich es dort übersehen?

      So ähnlich hatte ich es aber auch schon versucht, jedoch Punkt 6 nicht ausgeführt.

      Der Hintergrund meiner Anfrage war das updaten von OpenLog-Modulen, die mit OpenLog_V43.hex upgedated werden können sollten.

      Bislang habe ich 3 solcher Module, 2 preiswerte (rechts im Bild) und eines original Sparkfun (links im Bild)

      Mit dem Sparkfun Modul funktioniert mein Mega2560 Programm so wie es soll, nämlich weitere Files zur Laufzeit anlegen. Da keines der preiswerten Module jedoch korrekt arbeitete, wollte ich bei einem ein update mit der bei Github verfügbaren OpenLog_V43.hex Datei durchführen. Nun zeigt sich mit dem Procedere entsprechend deiner Beschreibung, dass am Modul zumindest wieder die LED leuchtet, nur funktionieren tut es immer noch nicht, es gibt keine Daten heraus, aber das könnte auch andere Ursachen haben.

      Das zweite preiswerte Modul scheint auch zu spinnen, denn wenn ich dort in der Config.txt "verbose" freigebe, blinkt die LED rasend schnell und es werden pausenlos 121212..... ausgesendet.

      Werde mir wohl noch weitere Original Sparkfuns bestellen.

      Gruß
      Ulrich
      Files

    • Ulrich wrote:

      nur funktionieren tut es immer noch nicht,
      Ich würde vermuten, dass das HEX-File bei den Klones nicht passen wird (warum auch immer).
      Ich weiß zwar nicht warum man sich beim Nachmachen nicht an den Schaltplan und die Daten halten will aber wenn ich OpenLog draufschreibe erwarte ich eigentlich, dass sich auch der Klon genau so verhält.
      Da braucht nur der Quarz (oder die Art wie der Takt erzeugt wird) nicht stimmen und schon wird das nicht funktionieren. Genauso muss auch der idente Controler Verwendung finden (vom ATmega328 gibt es nicht nur verschiedene Bauformen sondern auch Unterarten.
      Mit dem HEX-File kann man nur solche Module flashen, die sich exakt an die Gegebenheiten des Originals halten (also gleiche Frequenz gleiche Ports usw.).
      Kannst du mal gute Fotos von beiden Modulen machen?