ich hatte mir beim Chinesen einen SD-Cardreader zugelegt, leider hatte der Händler eine falsche Produktbeschreibung hinterlegt und reagiert nicht auf spezifische Anfragen dazu. Aber ich habe herausgefunden, dass der Reader ein Clone von dem Wemos SD Shield ist und konnte es zum laufen bringen.
Angeschlossen habe ich die Karte an meinen Nano Clone wie folgt:
SD Shield - Nano
D5 (CLK) - D13
D6 (MISO) - D12
D7 (MOSI) - D11
D8 (CS) - D8 (im Sketch definiert)
Ich kriege den Reader auch angesprochen und kann damit lesen und schreiben, allerdings sind die verwendeten Libs sehr Resourcenhungrig und belegen alleine gut 40% vom Ram, ohne hatte ich ca. 32% belegt und mit sind es gut 71%.
Kennt einer eine schlankere Lib, mit der ich Speicher sparen kann und die ich (im besten Falle) auch via SPI mit dem Reader nutzen kann? Oder gibt es relativ einfache Alternativen zu den Libs?
Schade, dann werde ich es als Übergangslösung nutzen, bis ich den Eeprom vom Nextion (1024 Bytes) nutzen kann (Mühsam ernährt sich das Eichhörnchen ;)). Sollen an sich nur ein paar Werte gepeichert werden, die beim Neustart abgerufen werden sollen.
Der Pro Mini hat auch nicht mehr SRAM als der Nano?
Für 'ein paar Werte' wäre vll. FRam ein Blick wert.
Gibt's in DIP mit 4kb(it) und in SOP8 mit 256kb(it) - Das sind dann die I²C-Versionen, DIe auf eBay rumgeistern.
Gibt die Steine aber auch in SPI und Parallel.
Gibt's als Modul/Shield/SMD-Bauteil im Gurt.
Achtung: Die Angabe ist in k-BIT (nicht in Byte !!) - die DIP-Variante hat somit 512 BYTE Speicherplatz - Diese aber dafür beliebig schnell und beliebig oft, die Vorteile von EEprom (Datenerhalt bei Spannungsverlust) und RAM (verschleißfrei, schnell, beliebig oft) gemixt.
allerdings sind die verwendeten Libs sehr Resourcenhungrig und belegen alleine gut 40% vom Ram
Wenn du das FAT32 Dateisystem einer SD Karte verwenden willst, führt kein Weg am RAM-Bedarf vorbei:
Brauchst mindestens 512 Byte für den aktuellen Daten"sektor" und nochmal 512 Byte für den Sektor des Dateiverzeichnis.
Eine SD-Card "roh", also ohne Dateisystem, zu verwenden, halte ich aber für am falschen Ende gespart.
"Ein paar Werte über Spannungsausfall/Reset zu rettten" ist aber eher EEPROM ( oder FRAM ) - Aufgabe
Für 'ein paar Werte' wäre vll. FRam ein Blick wert.
Gibt's in DIP mit 4kb(it) und in SOP8 mit 256kb(it) - Das sind dann die I²C-Versionen, DIe auf eBay rumgeistern.
Gibt die Steine aber auch in SPI und Parallel.
Gibt's als Modul/Shield/SMD-Bauteil im Gurt.
Achtung: Die Angabe ist in k-BIT (nicht in Byte !!) - die DIP-Variante hat somit 512 BYTE Speicherplatz - Diese aber dafür beliebig schnell und beliebig oft, die Vorteile von EEprom (Datenerhalt bei Spannungsverlust) und RAM (verschleißfrei, schnell, beliebig oft) gemixt.
MfG
Ja mit FRAM hab ich auch schon geliebäugelt, wollte anfangs den EEPROM des RTC-Shield austauschen, da das Display selber einen RTC hat, hab ich das verworfen. Den EEPROM des Displays könnte ich theoretisch auch austauschen, nur habe ich bisher keine 1024 KB Byte Steine gefunden, oder ist es auch möglich einen kleineren Baustein verwenden?
Das ist das Display, falls von Belang.
michael_x:
Wenn du das FAT32 Dateisystem einer SD Karte verwenden willst, führt kein Weg am RAM-Bedarf vorbei:
Brauchst mindestens 512 Byte für den aktuellen Daten"sektor" und nochmal 512 Byte für den Sektor des Dateiverzeichnis.
Eine SD-Card "roh", also ohne Dateisystem, zu verwenden, halte ich aber für am falschen Ende gespart.
"Ein paar Werte über Spannungsausfall/Reset zu rettten" ist aber eher EEPROM ( oder FRAM ) - Aufgabe
FAT16 wäre auch nicht dramatisch, die Karte die ich dafür über habe, ist 2GB groß, aber dass wird es wahrscheinlich auch nicht reißen.
Ist übrigens für meinen Ergometer und am liebsten würde ich zukünftig eine gewisse Historie speichern und am PC auslesen, z.B. als CSV oder so. Aber will ich das wirklich?
Ist der Umfang der Daten tatsächlich so groß, dass Du auf einer SD-Karte speichern musst? Genügt nicht vielleicht auch das EEPROM?
Gruß
Gregor
Wahrscheinlich nicht, aber ich bin mit meinen Spinnereien/Ideen noch nicht am Ende. Ist dann mit den Ressourcen wohl eine Grenze erreicht...
Schade ist auch dass der SD-Slot auf dem Display nur für die Firmware genutzt werden kann. Ich schau mir mal die EEPROM Funktionen vom Nextion an, in den nächsten Tagen darf ich eh noch keinen Sport machen, also mehr Denksport
Die 256kb(it) FRam haben eben 256kb = 32kB(yte) - Davon kannst Du 8 an einen Bus hängen = 256kB(yte).
Die sind aber SMD und meine bisherigen Künste waren noch nicht ausreichend, daß Das erfolgreich zusammen gekommen wäre - allerdings auch nur stiefmütterlich dran gegangen ... habe halt viele 'Messer in den Säuen stecken'.
Anzusprechen wie ein I²C-EEprom, Tommy hatte hier - oder im Nachbar-Universum - eine FRam-Lib vorgestellt - meine, mit Der hatte ich auch schon gespielt.
Diesen 32KB FRAM hatte ich z.B. auch grade gefunden, die Größe sollte reichen, muss mich dann halt mit der Datenmenge zurückhalten oder clever verarbeiten. Die Platine kann ich ohne Platzprobleme unterkriegen.
Tommy56:
Achtung, das sind 32 KBit, also 4 KByte.
Die Lib ist in diesem Thread. Bis zum Ende anschauen.
Gruß Tommy
Wie kommst du auf 4KB? Der FRAM, den ich verlinkt habe, wird als 256Kbit / 32KByte beworben, also wenn die Beschreibung dort und auch bei anderen Shops nicht komplett falsch ist, sollten es doch 32 KB sein?!
Die Lib, bzw. den Thread schau ich mir an und teste es wenn der FRAM hier ist, danke!
Habe mir für ein kleines Projekt einfach einen externen Logger gebaut.
Also einen Nano mit SD-Shield. Angesteuert über SoftwareSerial.
Kostet nur 4 Pins (2 + Spannungsversorgung) und kaum Speicher oder RAM. Da ich ohnehin schon SoftwareSerial verwende, kaum ein Unterschied.
Vielleicht wäre das ja eine optionale und schlanke Lösung.
TriB:
Habe mir für ein kleines Projekt einfach einen externen Logger gebaut.
Also einen Nano mit SD-Shield. Angesteuert über SoftwareSerial.
Kostet nur 4 Pins (2 + Spannungsversorgung) und kaum Speicher oder RAM. Da ich ohnehin schon SoftwareSerial verwende, kaum ein Unterschied.
Vielleicht wäre das ja eine optionale und schlanke Lösung.
Hi,
hört sich interessant an, allerdings habe ich keinen Platz für einen 2. Nano im Gehäuse. Da das ganze auf Akku läuft und die Schaltung jetzt schon zu viel zieht, muss es bei der vorhandenen Hardware bleiben.
SoftwareSerial nutze ich bereits zur Kommunikation mit dem Display, also wird der RAM/Speicher davon auch nicht viel mehr belastet. Wie sieht denn deine Lösung aus, vielleicht kann ich das mit der jetzigen Hardware auch umsetzen?
Der Aufbau ist denkbar einfach!
Habe ein Board mit einem ATmega328 mit ISP Schnittstelle, damit ich diesen auch programmieren kann.
Dort sind ja 6 Pins herausgeführt, wovon Pin 11 & 12 für SoftwareSerial und GND & 5V für die Versorgung genutzt werden können.
Dann muss die andere SoftwareSerial beendet werden, da nur eine zeitgleich funktioniert und ich sende ein Zeichen an den Logger, der das korrekt beantwortet, sofern dieser eben angesteckt ist:
(BT ist die SoftwareSerial Schnittstelle zu einem Bluetooth-Modul)
Der Logger an sich erstellt bei jedem start eine neue Datei und schreibt alles was er empfängt dort hinein. Außer dem Steuerzeichen "#", darauf antwortet er dann mit "$". Das waren die einzigen beiden Zeichen, die ich in meiner Kommunikation nicht verwende
Den Code kann ich mal bereinigen und zur Verfügung stellen. Ist aber kein Hexenwerk!;
Logger.end();
BT.begin(WIBAUD);
}
(*BT ist die SoftwareSerial Schnittstelle zu einem Bluetooth-Modul*)
Der Logger an sich erstellt bei jedem start eine neue Datei und schreibt alles was er empfängt dort hinein. Außer dem Steuerzeichen "#", darauf antwortet er dann mit "$". Das waren die einzigen beiden Zeichen, die ich in meiner Kommunikation nicht verwende :)
Den Code kann ich mal bereinigen und zur Verfügung stellen. Ist aber kein Hexenwerk!
TriB:
Der Aufbau ist denkbar einfach!
Habe ein Board mit einem ATmega328 mit ISP Schnittstelle, damit ich diesen auch programmieren kann.
Dort sind ja 6 Pins herausgeführt, wovon Pin 11 & 12 für SoftwareSerial und GND & 5V für die Versorgung genutzt werden können.
Dann muss die andere SoftwareSerial beendet werden, da nur eine zeitgleich funktioniert und ich sende ein Zeichen an den Logger, der das korrekt beantwortet, sofern dieser eben angesteckt ist:
(*BT ist die SoftwareSerial Schnittstelle zu einem Bluetooth-Modul*)
Der Logger an sich erstellt bei jedem start eine neue Datei und schreibt alles was er empfängt dort hinein. Außer dem Steuerzeichen "#", darauf antwortet er dann mit "$". Das waren die einzigen beiden Zeichen, die ich in meiner Kommunikation nicht verwende :)
Den Code kann ich mal bereinigen und zur Verfügung stellen. Ist aber kein Hexenwerk!
Die Idee greif ich vielleicht später mal auf, für das Projekt greif ich auf den 32KB FRAM zurück, der ist heute angekommen. Zumindest muss ich mich in das Thema erstmal einlesen und zurechtfinden
Danke trotzdem für den Denkanstoß! :);
Logger.end();
BT.begin(WIBAUD);
}
(*BT ist die SoftwareSerial Schnittstelle zu einem Bluetooth-Modul*)
Der Logger an sich erstellt bei jedem start eine neue Datei und schreibt alles was er empfängt dort hinein. Außer dem Steuerzeichen "#", darauf antwortet er dann mit "$". Das waren die einzigen beiden Zeichen, die ich in meiner Kommunikation nicht verwende :)
Den Code kann ich mal bereinigen und zur Verfügung stellen. Ist aber kein Hexenwerk!
Die Idee greif ich vielleicht später mal auf, für das Projekt greif ich auf den 32KB FRAM zurück, der ist heute angekommen. Zumindest muss ich mich in das Thema erstmal einlesen und zurechtfinden
Ist dann mit den Ressourcen wohl eine Grenze erreicht...