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

[Eugenius]

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

[Eugenius]

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

[Northman]

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....

  // 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:

#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:

Due:
5v -- 30 Ohm -|- ZF 4,7 -|- GND
              |          |
      FRAM   Vdd        Vss

SDA -- SDA
SCL -- SCL

Gruß, Carsten

[tuxedo]

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.

[Northman]

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:

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:

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

[Northman]

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

[Northman]

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

[Masifi]

Ist das beim internen Atmega328P EEPROM nicht auch der Fall, das bei einem neu flashen auch das interne EEPROM überschrieben wird !?

[h2oundco]

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

[tuxedo]

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:

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:

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