Ankündigung

Einklappen
Keine Ankündigung bisher.

Frage: wie Konnekting auf Arduinos ohne EEPROM, zB Due?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #16
    This observation might be 3 years late, but although the Due (and other ARM boards) are screaming fast and have tons of I/O and memory, they consume about 30x as much current. That’s worth knowing if you’re intending to build a battery product. I’ve been comparing the Teensy products with the Mega Pro, and for my intentions it comes down to whether I can afford 30 mA drain on a standalone battery with the Teensy vs the 3-5 mA on a board like this. Add in a Zigbee module to your project, and you have potentially serious battery life issues.
    Quelle:
    https://www.sparkfun.com/products/retired/10744

    Kommentar


      #17
      Zitat von Eugenius Beitrag anzeigen
      Ich habe gerade nachgemessen:
      MEGA2560@5.0V = 60.4mA (Siemens BCU versucht noch mitzumachen, aber sehr instabil)
      32U4@3.3V = 11.5mA
      328P@3.3V = 5.2mA
      mein 328pb ist heute angekommen:

      328PB@3.3V 8MHz= 6.5mA

      Kommentar


        #18
        Hallo zusammen,

        das FRAM funktioniert am Arduino Due. Ich habe es zuerst am Nano getestet, da dieser auch mit 5V arbeitet und der Upload des Sketches schneller als beim Due geht.
        Ich wollte das FRAM mit dem lowByte der Adresse vollschreiben, aber meine ersten Versuche sind alle mißlungen: es kamen komische Sachen zurück.
        Ich hatte das Datenblatt des 256kbit-Exemplars da und nach dem sollte die Adressierung korrekt sein. Zuerst das MSB, dann LSB und im Anschluß das Datenbyte schicken.

        Irgendwann habe ich mir das Datenblatt des vorhanden 16kbit-FRAMs geladen und war doch ziemlich über die Adressierung erstaunt... Beim großen Chip ist die ID des ICs 0xA0. Über drei Pins kann man die Bits 1-3 setzen (gegen Vdd ziehen) und somit acht ICs am Bus betreiben. Bit 0 ist RW (0 = W, 1= R). Beim kleinen Chip sind die Adresspins NC. Intern ist er in acht Pages mit jeweils 256 Byte aufgebaut. Die Pages werden über die ID gewählt... Das erklärt dann auch, warum ein I2C-Scanner Geräte an 0x50-0x57 gefunden hat. Beim Arduino wird die Adresse als 7bit-Adresse angeben und dann um ein Bit nach links geschiftet, damit das LSB für RW gesetzt werden kann. Damit wird aus der Datenblattadresse b1010 = 0xA0 im Sketch 0x50 = b0101, die dann in der twi.c wieder richtig gemacht wird....
        Code:
          // build sla+w, slave device address + w bit
          twi_slarw = TW_WRITE;
          twi_slarw |= address << 1;
        Aus dem EEPROM-Beispiel von http://www.hobbytronics.co.uk/arduino-external-eeprom habe ich die Lese- und Schreib-Funktionen entsprechend angepaßt.
        Der Teil zum Anzeigen des Speicherinhaltes ist aus dem Beispiel der Adafruit-FRAM Library:

        Der ganze Test-Sketch:

        Code:
        #include <Wire.h>    
        
        #define FRAM1 0x50
        
        unsigned long timer;
        unsigned long timerdiff;
        word value;
        word a;
        void setup(void) {
            Serial.begin(115200);
            Wire.begin();
        
            timer = micros();
            for (a = 0; a < 2048; a++) {
                writeFRAM2KB(FRAM1, a, lowByte(a));
            }
            timerdiff = micros() - timer,
            Serial.print(F("\nDIFF random write: "));
            Serial.println(timerdiff, DEC);
        
            for (a = 0; a < 2048; a++) {
                value = readFRAM2KB(FRAM1, a);
                if ((a % 32) == 0) {
                    Serial.print("\n 0x"); Serial.print(a, HEX); Serial.print(": ");
                }
                Serial.print("0x");
                if (value < 0x10)
                    Serial.print('0');
                Serial.print(value, HEX); Serial.print(" ");
            }
            timer = micros();
        
            writeFRAM2KB(FRAM1, 2047, lowByte(2047));
            timerdiff = micros() - timer,
                Serial.print(F("\nDIFF: "));
            Serial.println(timerdiff, DEC);
        }
        
        void loop() {}
        
        void writeFRAM2KB(int deviceaddress, word eeaddress, byte data) {
            deviceaddress |= highByte(eeaddress);
            Wire.beginTransmission(deviceaddress);
            Wire.write(lowByte(eeaddress));
            Wire.write(data);
            Wire.endTransmission();
        }
        
        byte readFRAM2KB(int deviceaddress, word eeaddress) {
            deviceaddress |= highByte(eeaddress);
            Wire.beginTransmission(deviceaddress);
            Wire.write(lowByte(eeaddress));
            Wire.endTransmission();
            Wire.requestFrom(deviceaddress, 1);
            return Wire.read();
        }
        Das Beschreiben der 2 Kilobyte dauert 596msec bei 100kHz und 156msec bei 400kHz Busgeschwindigkeit. Auf dem Nano waren es 676msec und 200irgendwas.


        Jetzt muß Konnekting "nur" noch so umgeschrieben werden, daß zum Schreiben und Lesen optional diese beiden Funktionen genutzt werden könenn ;-)
        Wenn ich am Wochenende Zeit habe, werfe ich mal einen Blick in die Library. Vielleicht verstehe ich ja was.... :-]

        Anschluß des FRAM am Due:
        Code:
        Due:
        5v -- 30 Ohm -|- ZF 4,7 -|- GND
                      |          |
              FRAM   Vdd        Vss
        
        SDA -- SDA
        SCL -- SCL

        Gruß, Carsten
        Gruß, Carsten

        Kommentar


          #19
          Danke für die Rückmeldung. Das sieht vielversprechend aus. Ideal wäre es, wenn du daraus zwei Funktionen bastelst (update und read) die sich so verhalten wie man es von der bekannten EEPROM Lib gewohnt ist. Dann ist die Adaption auf Konnekting ein leichtes.

          Mit den Arduino Zero Entwicklern führe ich nebenbei schon eine Diskussion zum Thema "EEPROM lib die den internen Flash benutzt". Aber die stellen sich nach einem ersten Hoffnungsschimmer wieder quer... Argument: EEPROM ist antiquiert, und die ganzen "Anfänger" sollten lieber lernen mit dem Flash umzugehen.
          Dass das aber einiges an Overhead mitbringt wenn man doch nur ganz simpel Variablen im Speicher ablegen will, wollen die offenbar nicht einsehen.

          Kommentar


            #20
            Der Unterschied ist ja nur, daß man hier zusätzlich die Adresse des Chips angeben muß. Ich wollte das mit dem Demo_Sketch mal testen und habe in der KnxTools.h das "#include EEPROM.h" entfernt und in KnxTools.cpp eine neue Function hinzugefügt:
            Code:
            byte EEPROM_read(word eeaddress) {
                int deviceaddress = 0x50 | highByte(eeaddress);
                Wire.beginTransmission(deviceaddress);
                Wire.write(lowByte(eeaddress));
                Wire.endTransmission();
                Wire.requestFrom(deviceaddress, 1);
                return Wire.read();
            }
            Danach Alle "EEPROM.read" durch "EEPROM_read" ersetzt....
            Die Funktion MemoryUpdate sieht jetzt so aus:
            Code:
            void KnxTools::memoryUpdate(int index, byte data) {
            
            
                CONSOLEDEBUG(F("memUpdate: index="));
                CONSOLEDEBUG(index);
                CONSOLEDEBUG(F(" data=0x"));
                CONSOLEDEBUG(data, HEX);
                CONSOLEDEBUGLN(F(""));
            
                int deviceaddress = 0x50 |highByte(index);
                Wire.beginTransmission(deviceaddress);
                Wire.write(lowByte(index));
                Wire.write(data);
                Wire.endTransmission();
                
            
            //#ifdef ESP8266    
            //    CONSOLEDEBUGLN(F("ESP8266: EEPROM.update"));
            //    byte d = EEPROM.read(index);
            //    if (d != data) {
            //        EEPROM.write(index, data);
            //    }
            //#else
            //    EEPROM.update(index, data);
            //    //    delay(10); // really required?
            //#endif   
            //
            //    // EEPROM has been changed, reboot will be required
            //    _rebootRequired = true;
            
            }
            Solange ein ATmega328 gewählt wird, kompiliert das ganze (ohne Upload) . Stelle ich auf Due um, beginnen die Probleme:
            • Die Konnekting-Library ist nicht für die CPU-Architektur des Due: in library.properites geändert: architectures=avr, esp8266, sam
            • SoftwareSerial funktioniert nicht. In KnxTools.cpp geändert:
              //#include <SoftwareSerial.h>
              //SoftwareSerial knxToolsDebugSerial(10, 11); // RX, TX

              #define knxToolsDebugSerial Serial3
            • Die Funktion des Watchdogs wird beim Due mit Großbuchstaben geschrieben: WDT_Enable statt wdt_enable. Nützt aber nichts, weil der Parameter auch noch ein anderer ist. "WDTO_500MS" ist nicht definiert und einfach eine 1 eintragen hilft auch nicht:
              KnxTools.cpp:In member function 'void KnxTools::reboot()
              KnxTools.cpp:390:15: error: invalid conversion from 'int' to 'Wdt*' [-fpermissive]
              :WDT_Enable(1)
              KnxTools.cpp:390:15: error: too few arguments to function 'void WDT_Enable(Wdt*, uint32_t)
              chip.h:In file included from
              Arduino.h:from
              KnxTools.h:from
              KnxTools.cpp:from
              wdt.h:note declared here
              :extern void WDT_Enable( Wdt* pWDT, uint32_t dwMode )
            • Desweiteren gibt es Probleme mit dem HardwareSerial:
              KnxTpUart.cpp:120:36: error: no matching function for call to 'HardwareSerial::begin(int, UARTClass::UARTModes)
              :_serial.begin(19200, SERIAL_8E1)
              KnxTpUart.cpp:candidate is
              Arduino.h:In file included from
              KnxTpUart.h:from
              KnxTpUart.cpp:from
              HardwareSerial.h:begin(long unsigned int)
              :virtual void begin(unsigned long)
              HardwareSerial.h:note candidate expects 1 argument, 2 provided
              Error compiling libraries

            Bei den letzten beiden Punkten bin ich mit meinem Latein am Ende.


            Gruß, Carsten
            Gruß, Carsten

            Kommentar


              #21
              Zitat von tuxedo Beitrag anzeigen
              Mit den Arduino Zero Entwicklern führe ich nebenbei schon eine Diskussion zum Thema "EEPROM lib die den internen Flash benutzt". Aber die stellen sich nach einem ersten Hoffnungsschimmer wieder quer... Argument: EEPROM ist antiquiert, und die ganzen "Anfänger" sollten lieber lernen mit dem Flash umzugehen.
              Dass das aber einiges an Overhead mitbringt wenn man doch nur ganz simpel Variablen im Speicher ablegen will, wollen die offenbar nicht einsehen.
              Auf die Nutzung des Flashspeichers bin ich bei meiner Suche auch gestoßen. Aber wenn ich mich richtig erinnere, dann überlebt der Inhalt nicht den nächsten Upload eines Sketches. Und damit ist das für Konfigurationsdaten völlig unbrauchbar.
              Oder gibt es da inzwischen andere Möglichkeiten, bzw verhält sich der Zero anders?

              Gruß, Carsten

              Gruß, Carsten

              Kommentar


                #22
                Von der Produkseite des Arduino Zero:
                EEPROM
                Part of the Flash memory may be used as a non-volatile storage with some limitations, the lifetime of the typical flash memory is about 25K write-cycles, and unlike EEPROM, and it must be erased in pages before writing. The flash memory is erased when you upload a new sketch.
                Das macht den Flashspeicher vollkommen ungeeignet. Ich will doch beim Entwickeln nicht nach jedem neuen Upload auch gleich die Konfiguration neu einspielen müssen....

                tuxedo Mit Deiner Aussage zum Overhead spielst Du wahrscheinlich hierauf an: "must be erased in pages before writing". RAM hat der Zero genug, den alten Inhalt zwischenzuspeichern, aber es macht die ganze Sache ziemlich umständlich.

                Aus purer Faulheit würde ich zusätzlich einen EEPROM oder FRAM nehmen. Zumal man meistens sowieso eine zusätzliche Platine einsetzt, auf die der IC mit drauf kann.


                Gruß, Carsten
                Gruß, Carsten

                Kommentar


                  #23
                  Ist das beim internen Atmega328P EEPROM nicht auch der Fall, das bei einem neu flashen auch das interne EEPROM überschrieben wird !?
                  www.smart-mf.de | KNX-Klingel | GardenControl | OpenKNX-Wiki

                  Kommentar


                    #24
                    Kommt drauf an, ob das Fuse EESAVE gesetzt ist oder nicht

                    Kommentar


                      #25
                      Zitat von Northman Beitrag anzeigen
                      Der Unterschied ist ja nur, daß man hier zusätzlich die Adresse des Chips angeben muß. Ich wollte das mit dem Demo_Sketch mal testen und habe in der KnxTools.h das "#include EEPROM.h" entfernt und in KnxTools.cpp eine neue Function hinzugefügt:
                      Code:
                      byte EEPROM_read(word eeaddress) {
                      int deviceaddress = 0x50 | highByte(eeaddress);
                      Wire.beginTransmission(deviceaddress);
                      Wire.write(lowByte(eeaddress));
                      Wire.endTransmission();
                      Wire.requestFrom(deviceaddress, 1);
                      return Wire.read();
                      }
                      Danach Alle "EEPROM.read" durch "EEPROM_read" ersetzt....
                      Die Funktion MemoryUpdate sieht jetzt so aus:
                      Code:
                      void KnxTools::memoryUpdate(int index, byte data) {
                      
                      
                      CONSOLEDEBUG(F("memUpdate: index="));
                      CONSOLEDEBUG(index);
                      CONSOLEDEBUG(F(" data=0x"));
                      CONSOLEDEBUG(data, HEX);
                      CONSOLEDEBUGLN(F(""));
                      
                      int deviceaddress = 0x50 |highByte(index);
                      Wire.beginTransmission(deviceaddress);
                      Wire.write(lowByte(index));
                      Wire.write(data);
                      Wire.endTransmission();
                      
                      
                      //#ifdef ESP8266
                      // CONSOLEDEBUGLN(F("ESP8266: EEPROM.update"));
                      // byte d = EEPROM.read(index);
                      // if (d != data) {
                      // EEPROM.write(index, data);
                      // }
                      //#else
                      // EEPROM.update(index, data);
                      // // delay(10); // really required?
                      //#endif
                      //
                      // // EEPROM has been changed, reboot will be required
                      // _rebootRequired = true;
                      
                      }
                      Solange ein ATmega328 gewählt wird, kompiliert das ganze (ohne Upload) . Stelle ich auf Due um, beginnen die Probleme:
                      • Die Konnekting-Library ist nicht für die CPU-Architektur des Due: in library.properites geändert: architectures=avr, esp8266, sam
                      • Korrekt. "sam" steht dann da, wenn sam auch unterstützt wird. Bisher ist das halt nicht der Fall.

                      • SoftwareSerial funktioniert nicht. In KnxTools.cpp geändert:
                        //#include <SoftwareSerial.h>
                        //SoftwareSerial knxToolsDebugSerial(10, 11); // RX, TX

                        #define knxToolsDebugSerial Serial3
                      • Die Funktion des Watchdogs wird beim Due mit Großbuchstaben geschrieben: WDT_Enable statt wdt_enable. Nützt aber nichts, weil der Parameter auch noch ein anderer ist. "WDTO_500MS" ist nicht definiert und einfach eine 1 eintragen hilft auch nicht:
                        KnxTools.cpp:In member function 'void KnxTools::reboot()
                        KnxTools.cpp:390:15: error: invalid conversion from 'int' to 'Wdt*' [-fpermissive]
                        :WDT_Enable(1)
                        KnxTools.cpp:390:15: error: too few arguments to function 'void WDT_Enable(Wdt*, uint32_t)
                        chip.h:In file included from
                        Arduino.h:from
                        KnxTools.h:from
                        KnxTools.cpp:from
                        wdt.h:note declared here
                        :extern void WDT_Enable( Wdt* pWDT, uint32_t dwMode )
                      • Desweiteren gibt es Probleme mit dem HardwareSerial:
                        KnxTpUart.cpp:120:36: error: no matching function for call to 'HardwareSerial::begin(int, UARTClass::UARTModes)
                        :_serial.begin(19200, SERIAL_8E1)
                        KnxTpUart.cpp:candidate is
                        Arduino.h:In file included from
                        KnxTpUart.h:from
                        KnxTpUart.cpp:from
                        HardwareSerial.h:begin(long unsigned int)
                        :virtual void begin(unsigned long)
                        HardwareSerial.h:note candidate expects 1 argument, 2 provided
                        Error compiling libraries
                    Und da hast du dich nicht gewundert warum die Lib noch nicht für die sam-Plattform freigegeben wurde?

                    Ich fasse mal Lösungshinweise/vorschläge zusammen:

                    SoftwareSerial funktioniert nicht.
                    Das hat sich in beta4 dann erledigt. KONNEKTING hat dann keine Abhängigkeit mehr zu SoftSerial. Du gibt von außen dann nur noch über eine set() Methode ein Serialobjekt rein, und Konnekting bentzt das dann zum debuggen. Woher das dann kommt ist deine Sache. D.h. du kannst das prima auf dich anpassen.

                    Die Funktion des Watchdogs wird beim Due mit Großbuchstaben geschrieben
                    Der Watchdog ist als Reset des µC gedacht. Wenn sich der Due anders/besser resetten lässt, können wir das gerne über ein "#ifdef" einbauen.

                    Desweiteren gibt es Probleme mit dem HardwareSerial:
                    KnxTpUart.cpp:120:36: error: no matching function for call to 'HardwareSerial:
                    Hmm, kenn mich mit dem Due noch ncith so aus, aber da muss es doch auch ein HardwareSerial geben? Wie sonst kommt man da an desser serielle Schnittstelle?


                    Auf die Nutzung des Flashspeichers bin ich bei meiner Suche auch gestoßen. Aber wenn ich mich richtig erinnere, dann überlebt der Inhalt nicht den nächsten Upload eines Sketches. Und damit ist das für Konfigurationsdaten völlig unbrauchbar.
                    Oder gibt es da inzwischen andere Möglichkeiten, bzw verhält sich der Zero anders?
                    Das ist bei eigentlich allen µC so der default: Ein erneutes aufspielen der Firmware setzt den Speicher zurück.
                    Wenn du ein fertiges KNX Gerät nimmst, es zum Firmwareupdate an der Hersteller einschickst, dann musst du ebenfalls dessen Konfig neu einspielen. Ist aber mit der Suite ja ein Kinderspiel: Knopf am Gerät drücken, knopf in der Software drücken, kurz warten, fertig.

                    Mit anderen Fuses lässt sich das verhindern, ja, aber wenn die neue Firmeware neue Parameter mit sich bringt, dann kann sich das Gerät unvorhergesehen verhalten. Bei Simplen eingängen mag das noch egal sein, aber stell dir einen Schaltaktor vor, an dem ein Heizstab hängt der nicht länger als 30min laufen soll. Und durch das fehlende zurücksetzen des Speichers läuft der Ausgang nun nichtmehr 30min, sondern 30h... Das kann gefährlich werden.

                    Also generell: Finger weg vom pfusch am Speicher ;-)




                    Kommentar


                      #26
                      Ich habe mich nicht gewundert. Ich wollte es einfach ausprobieren. Mein Posting sollte nur meine Erfahrungen beschreiben :-)
                      Ich hatte mir schon gedacht, daß hier kein anderer einen Due einsetzt. Die Hoffnung war, daß es vielleicht durch kleine Änderungen doch funktioniert.

                      DebugSerial: da der Due vier HW-UARTs hat, ist die neue Methode natürlich besser.

                      Ich hatte schon gesucht, aber in der Nacht keine Softwareresetmethode für den Due gefunden und dann auch nicht mehr die Energie zum Weitersuchen gehabt.
                      Jetzt war ich ergfolgreich: Quelle #5 (Google hat mir diesmal nicht geholfen. Ich habe stumpf die Seiten des Arduino Due Forums durchblättert. Auf Seite 24 bin ich fündig geworden).
                      Es funktioniert in einem Testcode. Setup() wird wieder aufgerufen.

                      Wenn ich KnxTools.cpp so ändere, kompiliert zumindest "Demo_Sketch_Konnekting".
                      Code:
                      #ifdef ARDUINO_SAM_DUE
                          #define SYSRESETREQ    (1<<2)
                          #define VECTKEY        (0x05fa0000UL)
                          #define VECTKEY_MASK   (0x0000ffffUL)
                          #define AIRCR          (*(uint32_t*)0xe000ed0cUL) // fixed arch-defined address
                          #define REQUEST_EXTERNAL_RESET (AIRCR=(AIRCR&VECTKEY_MASK)|VECTKEY|SYSRESETREQ)
                      #endif
                      
                      [...]
                      
                      void KnxTools::reboot() {
                          Knx.end();
                      
                      #ifdef ESP8266
                          CONSOLEDEBUGLN("ESP8266 restart");
                          ESP.restart();
                      #endif
                      
                      #ifdef ARDUINO_SAM_DUE
                          CONSOLEDEBUGLN(F("SAM_DUE reset NOW"));
                          delay(500);
                          REQUEST_EXTERNAL_RESET;
                      #elif __AVR_ATmega328P__
                          // to overcome WDT infinite reboot-loop issue
                          // see: https://github.com/arduino/Arduino/issues/4492
                          CONSOLEDEBUGLN(F("software reset NOW"));
                          delay(500);
                          asm volatile ("  jmp 0");
                      #else
                          CONSOLEDEBUGLN(F("WDT reset NOW"));
                          wdt_enable(WDTO_500MS);
                          while (1) {
                          }
                      #endif
                      }
                      HardwareSerial:
                      Und wieder war das Internet hilfreich: http://forum.arduino.cc/index.php?topic=142753.0
                      Ein Ersetzen von allen Vorkommen von HardwareSerial durch UARTClass in KnxDevice.*, KnxTools.* und KnxTpUart.* läßt den Code fehlerfrei kompilieren (inkl. meiner Änderungen zum EEPROM und SoftwareSerial).
                      UARTClass ist für den ersten UART (Serial). Serial 1-3 sind USARTClass. Ich habe aber noch nicht rausbekommen, wie man die dann unterscheidet. Serial ist natürlich auch der Programmierport. Dort sollte die BCU nicht parallel hängen. Ergo konnte ich noch nicht testen, ob das auch "in echt" geht.

                      Ein Blick auf die Uhr sagt mir, daß der Computer jetzt erstmal wieder ruhen muß und ich eine Runden laufen gehe :-)


                      EEPROM:
                      Du hast ja Recht, aber wenn ich meine Parameter definiert habe und danach nur an der Logik arbeite, ist dieser zweite Schritt zum neuen Setzen der Parameter lästig :-)
                      Ich habe auf Anhieb nicht im Code gefunden, ob das schon drin ist: wird vielleicht die im Code definierte Device_ID/Revision gegen einen Wert im EEPROM geprüft und nur wenn der übereinstimmt, werden die Daten übernommen? Ansonsten sind sie ungültig und müssen neu programmiert werden.
                      So könnte man durch Ändern im Code vor dem nächsten Upload das Löschen des Speichers erzwingen. Das wäre sogar die einzige (Software-)Methode, wenn man wie ich einen externen Speicher einsetzt (OK: man könnte auch einen Lösch-Sketch nutzen...).
                      Ansonsten ein zusätzlicher Schalter an einem IO-Pin, den man in Setup abfragt und dann den Speicher löscht.


                      Gruß, Carsten
                      Gruß, Carsten

                      Kommentar


                        #27
                        Ich wollte es einfach ausprobieren.
                        Ach so, na dann.

                        Code:
                         
                         #ifdef ARDUINO_SAM_DUE     CONSOLEDEBUGLN(F("SAM_DUE reset NOW"));     delay(500);     REQUEST_EXTERNAL_RESET; #elif
                        Schaut gut aus. Werde ich bei Gelegenheit mal einbauen.

                        HardwareSerial:
                        Und wieder war das Internet hilfreich: http://forum.arduino.cc/index.php?topic=142753.0
                        Ein Ersetzen von allen Vorkommen von HardwareSerial durch UARTClass in KnxDevice.*, KnxTools.* und KnxTpUart.* läßt den Code fehlerfrei kompilieren (inkl. meiner Änderungen zum EEPROM und SoftwareSerial).
                        UARTClass ist für den ersten UART (Serial). Serial 1-3 sind USARTClass. Ich habe aber noch nicht rausbekommen, wie man die dann unterscheidet. Serial ist natürlich auch der Programmierport. Dort sollte die BCU nicht parallel hängen. Ergo konnte ich noch nicht testen, ob das auch "in echt" geht.
                        Das klingt auf's erste mal lesen "knifflig" und nach einigen "#ifdef" Anweisungen. Vom Gefühl her würd' ich sagen das muss noch eleganter gehen.

                        EEPROM:
                        Du hast ja Recht, aber wenn ich meine Parameter definiert habe und danach nur an der Logik arbeite, ist dieser zweite Schritt zum neuen Setzen der Parameter lästig :-)
                        Solange man am Gerät noch entwickelt, sollte man es auf dem Schreibtisch liegen haben. Ja, man muss da dann tatsächlich jedes mal den Programmierknopf drücken. Aber da wird einem schon nicht der Finger davon abfallen.

                        Ich habe auf Anhieb nicht im Code gefunden, ob das schon drin ist: wird vielleicht die im Code definierte Device_ID/Revision gegen einen Wert im EEPROM geprüft und nur wenn der übereinstimmt, werden die Daten übernommen? Ansonsten sind sie ungültig und müssen neu programmiert werden.
                        Für das final Release des jeweiligen Geräts wird mit device-id und revision gearbeitet. Aber du willst ja nicht während der Entwicklung mit jeder Änderung die Revision hochzählen? Das ist lästiger als jedes mal den Knopf drücken.

                        Device-ID und Revision sind tatsächlich dazu da, fertige Geräte un unterschiedlichen Versionen/Revisionen voneinander zu unterscheiden.

                        Im Code wird ein Flag gepflegt. Darin steht ob das Gerät auf Factory-Settings läuft oder nicht. Dieses Flag wird beim Start aus dem EEPROM geholt und gekippt, sobald eine physikalische Adresse parametrisiert wurde.

                        So könnte man durch Ändern im Code vor dem nächsten Upload das Löschen des Speichers erzwingen. Das wäre sogar die einzige (Software-)Methode, wenn man wie ich einen externen Speicher einsetzt (OK: man könnte auch einen Lösch-Sketch nutzen...).
                        Ansonsten ein zusätzlicher Schalter an einem IO-Pin, den man in Setup abfragt und dann den Speicher löscht.
                        Wie man das am besten mit einem externen EEPROM handhabt ist tatsächlich ein wenig tricky... Bis dato gab es das Problem nicht, dass der EEPROM Inhalt bestehen bleibt und der Sketch ggf. ein neuer ist, und das Factory-Setting-Flag wieder zurück gekippt werden muss.
                        Damit das geht, bzw. überhaupt überprüfbar ist, muss ich noch einbauen, dass Manufacturer, Device-ID und Revision noch im EEPROM gespeichert werden, so dass beim Start ein Abgleich mit dem Sketch gemacht werden kann.

                        Für die Entwicklung eines solchen Gerätes heißt das:

                        Man muss ggf. verdammt aufpassen dass man sich mit einem neuen Sketch und alten Daten im externen EEPROM nichts kaputt macht.
                        Für interne EEPROMs ist es nach wie vor unkritisch.
                        Und bei einem Revisions-Update wäre dann in Zukunft auf jeden Fall für beide Varianten (ext/int EEPROM) gesichert, dass der Speicher zurückgesetzt wird.

                        Ich nehm das mal insgesamt als Request für beta4 auf...

                        Kommentar


                          #28
                          Neues ticket für beta4 aufgemacht: https://github.com/KONNEKTING/Konnek...rary/issues/15

                          Kommentar


                            #29
                            Für Beta4 ist ein Funktionspointer angedacht, mit dem man der Lib von Außen Funktionen zum lesen und schreiben geben kann. Dann ist man völlig frei wie die Daten persistiert und gelesen werden. Du könntest dann sogar auf eine SD Karte speichern ;-)
                            steht das noch !?

                            In den SAMD21 mit Arduino eine EEPROM Emulation zu bekommen, ist gar nicht so trivial. Ein Arbeitskollege von mir ist gerade dabei es zu versuchen, ich hoffe er bekommt es hin.
                            www.smart-mf.de | KNX-Klingel | GardenControl | OpenKNX-Wiki

                            Kommentar


                              #30
                              Jepp, ist noch auf dem Plan.
                              Die EEPROM Emulation ist bei weitem nicht trivial, leider. Wieso und warum steht in einem der Links die ins Arduino Forum führebn die ich schon mind. 1x hier im Forum gepostet habe. Such's dir gerne bei gelegenheit nochmal raus.

                              Kommentar

                              • Lädt...
                                X