MrData - in Anlehnung an MrMidi2 und den kommenden MrWave - ist ein
SD-Karten-Datenrekorder.
Features:
- Die 6 Analogeingänge des mega88 werden mit 10 Bit aufgezeichnet.
- Die Datenrate und Anzahl Kanäle sind über eine Datei auf der SD-Karte
"settings.txt" einstellbar.
- Eine LED zeigt den Betriebszustand an.
- Ein Taster zum Starten/Stoppen.
Schaltung:
- 1 ATmega88 @ 8MHz (intern oder Quarz, je nach eigenen Ansprüchen)
- 3 100nF (für Vcc und Aref, sowie für die SD-Karte)
- 3,3V-Versorgung
- 1 SD-Karte (Slot) (an SPI-Interface MISO, MOSI, SCK und SS)
- 1 LED mit Vorwiderstand (an PORTB0)
- 1 Taster (an PIND3)
Für die Analogeingänge (PORTC) noch Eingangsfilter (RC), je nach
Belieben.
MrData unterstützt vollen FAT16-Schreibzugriff.
Bedienung:
- SD-Karte mit FAT16 formatieren.
- settings.txt erstellen (Format unbedingt einhalten, Schreibweise,
Leerzeichen, alles!):
1
ch=6
2
overflow=7812
3
prescaler=13
ch=Anzahl aufzuzeichnender Kanäle.
overflow kommt direkt ins OCR1A-Register und prescaler in TCCR1B. Der
Prescaler des ADC ist bei 64 festgelegt.
- Karte in MrData einlegen und anschalten. MrData sollte mit der LED
zweimal blinken. Dauerblinken heißt Fehler!
- Eingänge anschließen.
- Taste drücken zum Aufzeichnen starten. Die LED leuchtet permanent.
- Erneut drücken zum Abspeichern. MrData erstellt Dateien mit Namen
MD001.TXT. Die Zahl wird immer hochgezählt.
- Karte kann entnommen werden. Am PC auswerten (z.B. Excel). MrData
schreibt eine Tabulator-formatierte Tabelle mit Dezimalzahlen. Die erste
Zahl ist eine fortlaufende Samplenummer. Dann kommen die Kanäle 1 bis
z.B. 6 in entsprechenden Spalten.
Hinweise:
- MrData wird nie Log-Dateien überschreiben. Er zählt die Nummer immer
ab der höchsten vorhandenen aufwärts.
- Die maximale Messrate wird etwa bei 40kByte/Sekunde liegen.
- Das maximale Messintervall liegt bei etwa 7,8 Sekunden (Timer 1
maximale Overflowzeit)
- Entfernen der Karte oder Spannungsverlust während einer Aufzeichnung
sorgen für Datenverlust der aktiven Aufzeichnung, da MrData die FAT und
den Rooteintrag erst beim Abschließen der Aufzeichnung schreibt.
- MrData schont die SD-Karte. Er schreibt nur Sektoren, wenn er muss.
Auch die FAT wird nur einmal geschrieben.
MrWave soll Wave-Dateien aufnehmen und abspielen. Das mit 16 Bit und am
besten 44100kHz und hochwertiger Audiohardware.
Muss dafür auch in Assembler arbeiten (sind ja nur ca. 180 CPU-Zyklen
pro 4 Byte Samples).
AVR Dragon besorgt - und debuggen klappt einwandfrei!
Cool, danke.
Das mit dem "Anzahl der Dateien" zählen ist zwar etwas grob, aber
einfach und effizient.
Ich habe mal versucht, die Dateinamen abzuchecken und danach den Namen
fürs nächste Logfile zu bestimmt, aber das wird ziemlich viel.
Sooo leicht mach ichs mir dann auch wieder nicht :-)
Er zählt nicht die Anzahl, sondern die höchste vorkommende Nummer.
Beispiel: Auf der Karte sind die Dateien:
MD001.TXT
MD002.TXT
MD003.TXT
SETTINGS.TXT
-> höchste Zahl im Namen nach Schema MDxxx.TXT = 3
-> nächste Datei = MD004.TXT
@ Simon Lehmayr
Dein Mr. Wave finde ich interessant. Bist du schon weiter? Hast du einen
AVR tauglichen Audio Codec gefunden? Ich hab auch lange gesucht, einst
den AD1845 eingsezt, dieser ist allerdings schon steinalt...
Wäre echt interessant, wenn du für Mr. Wave versuchen würdest einen
modernen DAC einzusetzen, wie einen von den CS Typen (CS4331 und
ähnliche).
Hier findest du eine Auflistung einer moderner DACs:
http://www.mikrocontroller.net/articles/ARM-MP3-Player
Einige davon könnten passen wenn der AVR wirklich nur abspielen soll.
Mit integrierten Verstärker wäre natürlich cool.
Den MAX9850 von maxim kann man im noninteger mode mit jeder freq
betreiben - daher gut geeignet.
Ich glaube du wirst Probleme bekommen mit 44100kHz samples von einer SD
Karte zu laden, ich hab sowas mal auf einen ARM gemacht und musste dafür
einen riesigen buffer anlegen damit der nicht immer aussetzer hatte.
Das Hauptproblem liegt meiner Meinung nach darin, die sehr hohe,
benötigte serielle Taktfrequenz für den DAC/ADC zu erzeugen. Die wollen
oftmals 32-256 x fs. Das geht nicht mit einem AVR.
Hallo Simon,
vielen Dank für die Bereitstellung dieses Projektes - genau so etwas
habe ich gesucht!
Trotzdem ein paar Fragen bevor ich losziehe und einen Mega88 kaufe (bin
Anfänger):
1. Wenn ich es richtig verstehe, kann man mit dem WinAVR-Compiler die
Quelltexte compilieren?
2. Ich sehe keinen Hinweis auf die Referenzspannungsquelle, nur das mit
10 Bit Auflösung geschrieben wird. Wäre es möglich, eine externe
Referenzspannung anzulegen? Was müsste ich denn im Programm dazu ändern
und vor allem wo?
3. Kann ich die 6 Eingänge auf 8 erweitern oder wäre es ein enormer
Aufwand?
Ich bedanke mich schon mal für die Antwort und hoffe, dass meine Fargen
nicht zu dumm sind ;)
Gruß,
Andreas
So - den Atmega88 hab ich gerade gekauft (den letzten - hihi).
Fehlt bloß noch eine Antwort auf meine Fragen, aber das kommt noch -
oder ;)
Grüße,
Andreas
Fly wrote:
> Das Hauptproblem liegt meiner Meinung nach darin, die sehr hohe,> benötigte serielle Taktfrequenz für den DAC/ADC zu erzeugen. Die wollen> oftmals 32-256 x fs. Das geht nicht mit einem AVR.
Da gibt es 2 Lösungen:
a) Eine DAC nehmen, der eine interne PLL hat, den Takt also selber
erzeugt
b) 2 Quarzoszillatoren + Teiler verwenden, um damit 256*44,1/48kHz zu
erzeugen und dann noch deren geteilte Werte. Alle üblichen Samplerates
basieren auf diesen beiden Grundfrequenzen. So ähnlich haben es auch die
ersten Soundkarten gemacht.
Danke Bendedikt
Kennst du einen ADC & DAC in einem (ich sag dem Codec / Soundport), der
eine interne PLL hat, respektive den man mit einem AVR und 44.1 kHz fs
betreiben kann.
Ich habe damals (2.5 Jahre)lange gesucht und nichts brauchbares
gefunden...
CoDec - mal sehn. Vorerst nehm ich einen standalone 16-Bit ADC-Chip
(habe mir als ADC-Versuchsobjekte den TI ADS8325, TI TLC4545/4541 und
den LT LTC1865 besorgt) und 16-Bit DACs (DAC Maxim MAX541 und TI
DAC8830/8831).
Die MMC/SD-Karten-Low-Level-Routinen stammen ursprünglich vom a.lp_mp3 -
Open Source Atmel AVR based MP3 Player - die FAT16 ist aber von mir.
Schreibperformance im Burst-Modus bei 4MHz SPI - im Schnitt 350kByte/sec
(1764kByte in genau 5 Sekunden - nicht mal in Assembler, das kommt
noch!) Die Leseperformance sollte noch besser sein!
@Andreas:
WinAVR nehm ich auch her. Zusammen mit dem AVR Studio 4 und AVR Dragon
zum Debuggen unschlagbar.
Referenz ist die Versorgungsspannung - zum Ändern im Code Zeile 374 in
main.c ändern (zu "ADMUX = 0;") - dann wird die Spannung am Pin 21
(AREF) verwendet.
Sorry - der mega8 hat bloß 6 ADC-Eingänge. Nimm einen anderen mega (z.B.
mega32, dann im 40 Pin PDIP), wenn du alle 8 willst.
Hallo Simon,
Danke für die schnelle Antwort!!
Bloß bitte noch eine Frage:
Jetzt habe ich es auch gesehen im Datenblatt des Mega88, dass die
SMD-version 8 AD-Wandler und meine Version 6 AD-Wandler hat - Ok.
Angenommen ich bin dann irganwann so weit, dass es überhaupt läuft und
kaufe mir dann einen anderen Controller mit 8 Wandlern.
Dann ist doch sicher im Programm auch wieder eine Änderung nötig, damit
die 8 Werte geschrieben werden?
Danke nochmals,
Andreas
Genial - danke!
Genau die Stelle habe ich eben gefunden und wollte nachfragen ob es
reicht :)
Ich falle Euch nicht weiter auf den Wecker, der Lötkolben dampft schon..
Schönen Tag wünscht,
Andreas
>Schreibperformance im Burst-Modus bei 4MHz SPI - im Schnitt 350kByte/sec>(1764kByte in genau 5 Sekunden - nicht mal in Assembler, das kommt>noch!) Die Leseperformance sollte noch besser sein!
Diesen Wert bezweifle ich hiermit offiziell.
Bei 4MHz SPI Speed kannst du maximal 500kByte/sec
schaffen. Im Idealfall. Also der Controller
braucht NULL Zeit um Daten aus dem Speicher zu holen.
Deine MMC/SD braucht scheinbar auch NULL Zeit
um die Daten zu speichern.
Gib uns doch mal nen Code für deinen ominösen
Burst Modus.
@holger
Du wolltest es so :-)
Die verwendete SD-Karte war eine Medion (intern SanDisk) 128MB.
Der Code ist allerdings "dumm", er liest den Startsektor aus der FAT und
dann erstellt er eine kontinuierliche Datei, ohne die freien Cluster zu
suchen. Weiterhin verwende ich das viel effektivere Kommando 25 der
SD-Karte.
Der Code benutzt den USART des mega168 als double-buffered SPI-Master ->
Effektiv!
Gestartet wird mit der IR-Fernbedienung Taste []+ (RC5 Code 0x3c)
Stoppt automatisch nach 1760kByte - dauert genau 5 Sekunden (Stoppuhr!)
Alle Sektoren werden korrekt mit dem im Code eingetragenen konstanten
Wert geschrieben (Hex-Editor!)
Habs natürlich nochmal nachgeprüft, bevor ichs hier poste.
Interessant sind für dich die Codestellen main.c:883-900 und
mmc.c:620-671 - da passiert das Highspeed-Schreiben!
Für ganz harte Zweifler kann ich mal einen Video drehen :-)
Drehbuch:
1. Dummydatei (MP3 oder was auch immer) auf Karte kopieren, damit Anfang
der Karte "Mülldaten" enthält.
2. Formatiere die Karte (Kamera-Zoom auf den Windows Formatier-Dialog).
3. Hexeditor auf Karte öffnen, Mülldaten zeigen (werden beim Format
nicht genullt).
4. Karte in Bastelaufbau stecken (Zoom auf den ATmega168) :-)
5. Anschalten.
6. Stoppuhr zücken und Fernbedienung []+ drücken (Im Hintergrund sieht
man das LCD vom Bastelaufbau).
7. Stoppuhr stoppen, wenn die 0001 (fertig) erscheint.
8. Karte in PC schieben, Datei im Hexeditor öffnen.
@holger
>Du wolltest es so :-)
Ja, genau das wollte ich ;)
Interessante Routinen, aber:
Gemessen ohne FAT Overhead, nur konstante Werte übergeben
ohne Werte aus irgendeinem Speicher zu holen.
Gemessen mit nur EINER Karte !
Da fehlt noch ein bisschen was. Wie schnell ist die Karte
bei SingleBlockWrite ? Nur zum vergleichen was deine Routinen denn
wirklich bringen. Und wie willst du CMD25 was ja Multiblock
Write bedeutet mit einem ATmega168 machen ?
Das Viech hat nur 1kB RAM. Zwei Blocks a 512 Bytes
bekommst du da einfach nicht rein. So ein klein
bisschen Stack und Variablen sind ja auch noch nötig.
Deine 350kByte/sec bei 4MHz SPI Speed sind experimentell und
bei näherem hinsehen auf Dauer nicht zu halten.
Dein härtester Kritiker
Holger
Genau. Experimenteller Versuchsaufbau. Diese Messung sollte nur die
Machbarkeit von MrWave ermitteln (Da brauch ich nämlich mindestens
176kByte/sec, besser das Doppelte, und das hab ich schon bei 8MHz
CPU-Clock).
Ich muss den mega sowieso auf 16-20 MHz fahren, damit er diese Rate mit
Daten aus einem Puffer schafft. Und Zeit hat, über SPI Analogwerte
einzulesen. Assembler muss ich evtl. auch noch nehmen (zumindest
inline-Assembler).
Zum Pufferverfahren:
Ich puffere nicht ganze Sektoren, sondern halte die Karte immer
schreibbereit. Puffer brauche ich nur, wenn die Karte gerade beschäftigt
ist. (D.h. ich schreibe Daten sofort an die Karte, benutze also den
512-Byte-Puffer in der SD-Karte!)
Ablauf:
- Karte zum Schreiben öffnen (CMD25, Sektorangabe).
- Wavedaten->Puffer->Karte (der Puffer wird sofort auf SPI geschrieben,
wenn die Karte bereit ist).
- Wenn 512 Bytes an Daten an die Karte geschrieben wurden, kommt der
CRC, Busy-Abwarten, neues Starttoken. In dieser Zeit läuft was in den
Puffer. Und der kann dann maximal 768 Bytes groß sein. Rest für globale
Vars und Stack. Hat bei mir immer gereicht.
- Wenn fertig, Sektor auffüllen und Karte abschließen (Stop Token).
Schau dir den Code von MrData an, der nimmt zwar nicht den
double-buffered USART-SPI oder das CMD25, arbeitet aber ebenfalls nach
diesem Puffer-Prinzip.
Interessante Idee. Allerdings funktioniert das ganze nur, wenn die Karte
nicht fragmentiert ist, bzw. immer alle Dateien auf der Karte immer auf
einmal gelöscht werden. Ansonsten gibt es Datenmüll.
> Und Zeit hat, über SPI Analogwerte>einzulesen. Assembler muss ich evtl. auch noch nehmen (zumindest>inline-Assembler).
SPI AD-Wandler ist doch perfekt. Statt die Werte mit dem
ATMega überhaupt zu lesen, leite doch einfach den SPI Ausgang
des AD-Wandlers direkt in den Eingang der SD Karte um wenn
du den AD-Wandler ausliest. Der ATMega gibt dann nur noch den
SPI Takt vor. Eine kleine Umschaltlogik müsste reichen um die
entsprechenden Pins im richtigen Moment zu verbinden/trennen.
Das wäre gut, wenn die Karte keine Dummy-CRCs, Starttoken und
Busy-Polling hätte (selbst im Blockwrite CMD25 sind die noch da) ...
während dieser Zeit kann ich nichts aufnehmen, also muss ich puffern.
Die SD-Karte kann einen echten Streammodus ohne Overhead (mit begrenztem
Datentakt), aber nur im MMC/SD-Kartenmodus (nicht SPI) :-(
2 kurze Fragen zur Formatierung der SD-Karte:
Wie klappt den die Fromatierung sicher? Unter WinXP bin ich mir nicht
sicher ob die Karte richtig formatiert wird.
Gibt es Unterschiede bei den SD-Karten? Mit welchen (Marke, Größe, etc.)
hat es bei euch funktioniert?
Gruß Claus
Formatierung unter XP schreibt nur FAT und Rootdir neu. Datenbereich
bleibt erhalten.
Karten sollten eigentlich alle gehen, wenn man die Schaltung mit 3,3V
betreibt (ich habe Sandisk, Transcend, Toshiba). Ich habe Probleme, wenn
ich bei 5V Versorgung Widerstände im einstelligen kOhm-Bereich als
Spannungsteiler für die SCK, CS und MOSI-Leitung nehme...
Die Schwierigkeiten bekomme ich nur, wenn die Versorgungsspannung der
SD-Karte nicht sauber ist. Sollte schon ein 3,3V-Spannungsregler sein.
Mit den Spannungsteilern habe ich dann keine Probleme.
Gruß Elektrikser
Update:
Es können jetzt auch serielle Daten geloggt werden:
Dazu muss man in setting.txt noch als 4. Parameter baud=9600 angeben,
wobei 9600 durch jede beliebige Baudrate ersetzt werden kann.
Die empfangenen Datenbytes werden asynchron als Hexzahlen zu den
Analogwerten aufgezeichnet, d.h. ohne Zeitstempel, jeweils in eigenen
Zeilen.
Meine GPS-Tools, um eine Sirf3-Maus (NMEA mit 4800 Baud) am RS232
auszuwerten und in Google Earth zu plotten.
Beschreibung:
nmeagen - Extrahiert aus der Logdatei MDxxx.TXT die NMEA-Strings
Anwendung: nmeagen n <Logdatei> (n steht für NMEA, alles andere führt
zur Extraktion der Analogdaten)
speedextract - Erzeugt ein KML-File mit der Geschwindigkeit in km/h als
Höhenprofil der Route
Anwendung: speedextract <NMEA-Datei>
Die Ausgabe landet auf dem stdout (Bildschirm).
convert.bat automatisiert den Prozess und startet auch gleich Google
Earth.
Anwendung: convert MDxxx.TXT MeineRoute.kml
settings.txt - Die Konfiguration für MrData
src - Die Quellcodes für Visual Studio
Neue Version für verbessertes Logging an RS232 - z.B. GPS-Mäuse!
settings.txt unterstützt jetzt neue Kommandos nach baud=xxxx:
1
binary=0 oder 1 (ASCII-binäres Logging der seriellen Daten in der Textdatei, z.B. GPS-NMEA-Strings; 0 bedeutet, dass alle chars in 2 Hexnibbles umgewandelt werden.)
2
send=<Hexstring> (Sendet den genannten Hexstring beim Anschalten über TxD)
3
cyclic=<Hexstring> (Sendet bei jedem Messzyklus den Hexstring über TxD)
Hexstring = 00FFAB12... (immer zwei Bytes sind eine Hexzahl). Der
Hexstring wird in ASCII-Chars konvertiert und gesendet.
Unterstützung für mega8,88,168 eingebaut. Wobei mega8 noch nicht
getestet ist.
Bugreport:
Es gibt einen Bug in meiner FAT16-Implementierung:
Beim Anlegen eines Fileentries im Rootdir an einer Sektorgrenze tritt
ein Fehler auf - LED blinkt und Fileentry wird nicht geschrieben.
Workaround: Immer Karte frisch formatieren und nicht mehr als 16 Files
aufzeichnen.
Sollten die so "verlorenen" Daten wichtig sein, kann man sie mit einem
Diskeditor wie dem TinyHexer retten, indem man in der FAT die Cluster
der letzten Datei zählt und einen Fileentry kopiert, und dann
Startcluster und Dateilänge anpasst.
Mit VC++ 6 kompilierte Tools, weil die VC++ 8 nicht laufen, wenn man
kein VC++ 8 installiert hat. Dabei hatte ich WIN32 i386 als
Targetarchitektur ausgewählt.
Der Filesystembug wurde jetzt endgültig beseitigt!
Beschreibung: Das Anlegen der 16. Datei nach dem Anschalten schlägt
fehl, weil die Sektorvariablen für das Rootdir nach der 16. (bzw.
Vielfache) Datei nicht stimmen (Überlauf beim Zählen der Fileeinträge in
den Rootdiresektoren).
Dieser Logger währ genau das was ich gerade suche! Super Projekt !
Aber hat hier jemand, MrData schon mit einem Mega32 zum laufen bekommen?
Ich bringe das ganze mit WinAVR nicht zum compilieren.
Verzeiht meine Unwissenheit ;-) Bin erst vor kurzem auf C umgestiegen.
Hallo hannes R,
bin gerade dabei, einen ähnlichen Logger auf Basis von MrData
aufzubauen. Als Basis dient mir der Mega32, daher sollte das schon
gehen. Die Plattform ist heute fertig geworden, wollte morgen mit dem
Portieren anfangen. Meld mich die Tage nochmal ... .
@Simon:
Danke für das klasse Projekt!
Werd meinen Code und die Schaltung hier posten, sobald alle läuft.
Gruß Marcus
Sicherung und Diode, gut so :-)
Wo die 3.3V letztendlich herkommen, ist ja eigentlich egal. Die
Stromaufnahme liegt wohl im 2-stelligen mA-Bereich (plus GPS-Maus)...
Es gibt auch günstige Zigarettenanzünderadapter mit einstellbarer
Spannung.
Ein Regler 12V->3.3V verbrät dann halt knapp 1 Watt. Da ist einer im
TO-220 dann zu nehmen.
Für die Stromsparer gibts noch Schaltwandler mit Diode und Spule.
Ich muss sowieso nochmal umbauen... Der IRU1010-33 ist niergends mehr
verfügbar....
Sonst noch vorschläge als ersatz?
Habe mal die Eagle-Datei mit hochgeladen. Vielleicht kann es noch jemand
gebrauchen.
Hallo,
erstmal danke Simon für das Veröffentlichen!
Vor 2 Tagen gesehen und gleich nachgebaut, echt klasse!
Etwas verwundert bin ich, dass die vorletzte Version bei mir
funktioniert, die allerletzte aber nicht, da geht die LED nicht mehr aus
durch das drücken des Tasters... Wo ist der Unterschied? (verwende
Mega88 mit den vorkompilierten .hex).
Da ich Modellflieger bin, werde ich das System wohl in diesem Bereich
einsetzen :-) Sowas wie Spannung uns Strom messen bietet sich ja an, GPS
ist dann Luxus.
Muss mich mal in den Code reinlesen, würde nämlich gerne noch
Frequenzmessung (Drehzahl) und Servosignal (1-2ms Signal) einlesen und
loggen. Sollte doch möglich sein!?
Bis dann
Grüße
Marc
Sebastian wrote:
> Hi Stefan,>> den LP 2950 ACZ-3.3 habe ich niergends gefunden! nur 3.0 kein 3.3. Woher> bekommst du den?
Beim freundlichen National Distributor (am liebsten verkauft er
allerdings 100er Stückzahlen - ist bei solchen Cent-Artikeln aber nicht
so das Problem...)
Hallo,
also das Kompilieren mit der neuesten WinAVR-Version hilft...
Bin auch schon kräftig am Erweitern.
Folgendes tut schon:
5 Servosignale einlesen
"Zeitangabe" vor jedem Datensatz
"Automatic-Mode"-Option, Logger aktiviert sich selbständig und legt
(auch optional) alle x-sekunden ein neues File an (Gedanke waren
Spannungsprobleme und Vibrationen im Modellflieger...)
Ein Pufferüberlauf am Seriellen Eingang führt nicht mehr zum Abbruch
sondern wird geloggt..
und einige Ablaufänderungen...
Noch nicht fertig:
Drehzahlmessung (max. 2 über ext Interrupts, reciht mir, mehr ginge wohl
auch)
Code hab ich gerade nicht da, kommt aber die Tage.
Eine kleine Dokumentation werd ich auch hier machen:
http://www.uni-stuttgart.de/akamodell/projekte/?p=132
Grüße
Marc
Hi Wilhelm,
zuerst habe ich versucht einem ATmega88 das beizubringen. Aber selbst
mit hoher Optimierung und 20MHz Takt war es zu zeitkritisch. Mehr RAM
zum Puffern wäre nötig. ADCs hatte ich auch keine geeigneten. Stereo
erfordert nämlich 2 davon (oder einen semi-automatischen 2-Channel). Und
ich habe nur eine freie SPI am Atmel.
Dann habe ich ein ARM7-Board (LCP2138@60MHz) genommen. Allerdings nie
externe ADCs angekoppelt. Der interne Wandler ist dafür sehr schnell
(aber nur 10 Bit). Dieses Projekt funktioniert auch. Im Anhang findest
du es.
Schließlich habe ich für ca. 40 Euro einen MP3-Festplatten-Rekorder mit
20GB bei ebay ergattert... damit ließ ich es dann gut sein :-)
Ich brauche nur Mono, dafür aber mit mind. 12 bit bei 44,1 kHz. Einen
Festplattenrecorder (Archos gmini 200) habe ich, der kommt aber aus
Platzgründen und wegen Erschütterungen nicht in Frage.
Danke für die schnelle Antwort und den Hinweis auf den ARM bzw. den
Quellcode.
Wilhelm
So,
die Erweiterungen für Modellbau haben einen stabilen Stand erreicht.
Analog, Servos, Drehzahl. Neue Optionen, Reihenfolge in settings.txt
egal...
Hier der Bericht:
http://www.uni-stuttgart.de/akamodell/projekte/?p=132
Grüße
Marc
Hallo Leute, hallo Simon,
super Projekt! Habs mal auf einen ATmega8 ausprobiert - und es läuft.
Es werden alle SD-Cards erkannt - super! Selbst jene welche die mit WIN
XP formatiert wurden. Bei anderen Projekten, muss man die Karten mit
Linux formatieren...
Irgendwie hab ich jetzt aber einen Knoten im Hirn, vielleicht könnt Ihr
mir ja helfen.. Normale Zeichen schreiben geht - auch zeichenstrings
schreiben geht.... ABER:
Zuerst mache ich eine AD-Wandlung...
1
ADMUX=KANAL;// Kanalauswahl
2
ADMUX|=(1<<REFS1)|(1<<REFS0);//Interne Referenzspannung aktiv
3
ADCSRA|=(1<<ADSC);//Wandlung starten...
4
while(ADCSRA&(1<<ADSC))//Wandlung abwarten
5
{;}
6
Wert=ADC;// Bei ATmega8 nur ADC
7
U=Wert*FAKTOR;// Spg.Wert berechnen
8
ADCSRA&=~(1<<ADEN);//ADC ausschalten...
Dann habe ich den gewünschten Wert in U. Wie kann ich den Wert auf die
Karte bringen? Ach ja: int16_t U;
Bei einem Display musste ich den Wert erst mit umwandeln...
Äh, MrData wandelt doch bereits ADC und speichert den dann auf Karte...
Aber vom Quellcode her müsst es doch tun... oder schreib deine eigene
Bin->Dec Funktion. Aus deinen kurzen Codestückchen kann ich sonst auch
nichts diagnostizieren.
Woher weißt du denn, dass U korrekt gesampelt wird? Kann der Fehler auch
im AD-Wandler sein? Taktvorteiler zu klein z.B.?
> Woher weißt du denn, dass U korrekt gesampelt wird? Kann der Fehler auch> im AD-Wandler sein? Taktvorteiler zu klein z.B.?
Die Wandlung passt, ich hab die gleiche AD-Wandlung früher schon mal
verwendet und auch auf einem LCD ausgegeben, da passt U.
Ich hab noch weiterprobiert - mit einer Var. a=88;
mmc_write_byte(a); -> Ausgabe auf Karte: X //also wird a als ASCII
interpretiert.
write_number_u32(a); -> Ausgabe: 88 hier passts.
Vielleicht liegts daran, dass ich nach der AD-Wandlung noch eine
Umrechnung mache. Ursprünglich waren es nur float Werte.
U = ADC * 0.0025;
Kann ich auch Float Werte abspeichern? Gibts da Routinen?
Ansonsten müsste ich wirklich wie beim Display die Fkt.
dtostrf(U_1,6,2,String); verwenden.
Im Ursprungscode wird ja nur der Wert von ADC abgespeichert oder?
-Also ohne Umrechnungen etc.
@Wolfgang: Das mit dem *0.0025 klappt wohl eher nicht - denn es sind ja
Integer-Zahlen (u16). Lass die Umrechnerei lieber dein
PC-Auswerteprogramm machen! In Excel geht das recht einfach...
Also: write_number_u32(ADC);
@Chris: unter Beitrag "GPS an mega8,88 oder 168" findest du
Schaltpläne (recht weit unten ist ein guter).
Hallo Simon,
> @Wolfgang: Das mit dem *0.0025 klappt wohl eher nicht - denn es sind ja> Integer-Zahlen (u16).
Wie gesagt, ursprünglich waren alles Floatwerte - also auch U.
> Lass die Umrechnerei lieber dein PC-Auswerteprogramm machen!> In Excel geht das recht einfach...> Also: write_number_u32(ADC);
Hab ich mir auch schon gedacht - werd´s vorerst mal so machen.
Wenn ich später die Werte noch auf meinem Display anzeigen möchte, werd
ich sowieso mehr speicher brauchen - vielleicht reicht mir dann der
ATmega168...
und der kann mir dann für´s Display die Werte in ASCII umwandeln und die
kann ich dann ja mit mmc_write_byte() ausgeben.
Sonst ist das wirklich gut gelungen - erkennt alle SD-Cards auf Anhieb.
Danke für´s posten. :))
--
Gruß
Wolfgang
Hallo,
da ich gern den Mr.Data nachbauen möchte, habe ich Schaltplan und Layout
zusammengestellt.
Ziel war es möglichst kompakt zu werden.
Auch sollte bei plötzlichen Spannungsverlust die "restlichen" Daten noch
auf die SD speicherbar sein -> deshalb die größe Pufferung und
Überwachung der Eingangsspannung.
Wäre net wenn jemand mal drüber schauen könnte bevor ich einige Platinen
machen lasse.
Gruß
Frank
Hallo Frank,
wo sind deine Erweiterungen (Spannungserkennung usw.) dokumentiert? Ich
vermisse die Bauteilwerte der Widerstände und Kondensatoren. Hast du
schon das Abspeichern der Werte bei fallender Betriebsspannung
implementiert?
Servus,
Helmut.
Hi,
eine fallende Spannung bzw. sofortigen Spannungsverlust will ich mit der
Messung R5/R6 und ADC5 umsetzen. Wenn die Reaktionszeit zu langsam ist,
habe ich noch die Erkennung über INT0 (Low-Pegel) als "Plan B".
Ein C für de Ubat Messung sollte ich evt. noch spendieren.
Die Bauteilwerte ist alle recht unkritisch bzw. auf die Bedingungen der
Messspannungen auszulegen.
SW-Änderungen werde ich nach erhalt der HW umsetzen.
Gruß
Frank
Hallo Frankie,
sieht schonmal gut aus.
Hier meine Notizen:
- der Pullup R und C am Reset ist bei AVRs nicht unbedingt erforderlich,
wenn man den mega88 oder 168 nimmt, sogar beim Debuggen hinderlich.
- die Werte aller Cs und Rs fehlen im Plan (siehe Helmuts Antwort).
- die Unterspannungserkennung solltest du über den Komparator des mega
machen (PD6,7) - hat einen eigenen Interrupt und du verschwendest keinen
ADC-Port.
- MrData kann auch die FAT nicht mehr aktualisieren (bei
Aufzeichnungsende), wenn die Spannung wegbricht (das dauert durchaus
eine Sekunde, bei größeren Aufzeichnungen) - allerdings sollte ScanDisk
die Daten immer noch retten können. Zusätzlich: Eine schreibende
SD-Karte frisst gut Strom. Vielleicht doch lieber einen GoldCAP 0,1F
oder mehr nehmen!
Kannst du die Pläne bitte als Eagle-Files posten?
Gruß,
Simon
Hi,
erstmal danke für Eure Mühe.
Ich habe den Schaltplan geändert:
- Die Unterspannung ist jetzt am Komparator (Schwelle 3,9V)
- 1F Gold-Cap im Eingang (damit nur noch max. 6V Eingangsspannung)
- Bauteilwerte ergänzt
Wenns so OK ist werd ich noch das Layout ändert.
Files werd ich (wenn alles fertig) natürlich posten.
Gruß
Frank
Hallo,
ich wurde auf diesen Thread in einer Antwort auf meine Frage hier
hingewiesen:
"Mikrokontroller fürs Speichern eines Datenflusses auf eine SD-Karte"
Beitrag "Mikrokontroller fürs Speichern eines Datenflusses auf eine SD-Karte"
Also, mein Anliegen besteht darin, einen Datenfluss auf eine SD-Karte zu
speichern. Die ADCs, die ATmega88 anbietet, reichen für unsere Zwecke
nicht aus, wir haben aber schon einen geigneten ADC, der die Daten als
Bitstream liefert. Wäre es dann möglich, diesen Stream mit Hilfe von
MrData <b> kontinuerlich </b> auf eine SD-Karte zu speichern?
Unsere bestehende Datenrate leigt bei 12 KByte/sec, wir brauchen aber
auch eine Peakrate von 40 KByte/sec auch mal speichern zu können. Wäre
hier vielleicht Atmega168 eine bessere Lösung?
Ansonsten vielen Dank für viel Mühe mit dem Projekt!!
Alexander.
Wenn binär gespeichert und das Suchen nach freien Clustern abgeschaltet
wird, sollte der mega88/168 (ist egal welcher) die 40kB/s schaffen.
20MHz Quarz und gut.
Statt dem ADC-Interrupt musst du dann halt einen Timer nehmen, der den
externen ADC abfragt und das Ergebnis in die Queue speichert.
Hallo,
ich habe mal ne wahrscheinlich echt blöde Frage. Was für Werte muß ich
eintragen wenn ich genau 1sek abfrage zyklus haben möchte?
overflow=?
prescaler=?
Bzw. wie rechne ich es denn aus? Formel?
Gruß
Harry
overflow=31249
prescaler=12
Prescaler ist damit 256 (man muss immer +8 nehmen, damit es funzt)
1+8 -> Prescaler 1
2+8 -> Prescaler 8
3+8 -> Prescaler 64
4+8 -> Prescaler 256
5+8 -> Prescaler 1024
Bei 8MHz ist dann die Rate:
8000000Hz/(256*(31249+1)) = 1Hz
Hallo
Ich möchte einen Datenlogger bauen, der Temperatur, Feuchtigkeit und
Beschleunigung misst und die ganzen Daten auf der SD-Karte mit
Dateisystem speichert. Die SD-Karte muss nur beschrieben werden, nicht
auslesen. Ich verwende den ATmega88p.
Die Sensorik abfragen ist kein Problem, aber das Beschreiben der
SD-Karte dafür umso mehr. Ich hab mir deinen MrData runtergeladen,
studiert und dabei festgestellt, dass ich null Durchblick habe, was du
da machst.
Gibt es keine einfachere Lösung, wenn ich nur schreiben möchte? Welche
Dateien benötige ich mindestens?
Und da mein Gerät batteriebetrieben ist, bin ich auf 1MHz Taktrate
gegangen (ext. Quarz). Ist das zu langsam?
Ich bin jetzt schon länger auf der Suche, vielleicht hat hier jemand
einen guten Rat für mich.
mfg Roman
Hallo Marc(s),
ich hoffe Du liest hier noch mit oder jemand anderes hat die Version von
Marc aufgebaut.
Ich würde gerne Deine Version des Loggers aufbauen, ebenfalls zum
Einsatz in Modellen. Dazu habe ich aber noch folgende Fragen:
1) Arbeitest Du mit 5V oder 3.3V Versorgungsspannung
2) Wenn 3.3V, verwendest Du Z-Dioden oder Spannungsteiler bei den
Servo-Eingängen/Drehzahl-Eingang?
3) Benutzt Du auch einen Optopkoppler bei der UART? Oder ist der über
über eine Z-Diode abgesichert?
4) Liefern die GPS-Empfänger RS232 oder TTL Pegel?
Mit den auf der von Dir genannten Homepage
(http://www.uni-stuttgart.de/akamodell/projekte/?p=132) stehenden
Informationen habe ich schon mal einen Schaltplan gezeichnet, da gibt es
ja schon ein paar kleine Unterschiede zum MrData. Desweiteren erwähnst
Du dort, dass eine Vorbereitung zum Anbinden an LogView mit Hilfe dieses
Forums geplant ist. Hat sich da ggf. schon etwas ergeben?
Danke und Grüße
Ralf
Hallo,
dieses Projekt interessiert mich und ich würde es gerne mal antesten
bevor ich das Material bestelle...
Leider habe ich gerade keinen entsprechenden Atmel da, aber es dürfte
doch kein Problem sein einen Mega16(16UP) zu verwenden, oder? Der ist
halt etwas Größer aber für nen Test wär der doch auch in Ordnung!
Wenn alles so klappt wie ich mir das vorstelle, würde ich gerne bei
meinem Nachbau einen Mega8 und eine micro-SD verwenden... Weiß einer von
euch, ob Micro-SD zu normalen SD-Karten Pinkompatibel sind?
Danke für dieses Projekt und eure Antworten, ho77bk
Hallo,
sorry, war länger nicht mehr hier...
Also, zu den Fragen:
@Ralf:
1) Arbeitest Du mit 5V oder 3.3V Versorgungsspannung
3,3
2) Wenn 3.3V, verwendest Du Z-Dioden oder Spannungsteiler bei den
Servo-Eingängen/Drehzahl-Eingang?
Ich habe es noch nie im "echten" Betrieb gehabt, deshalb nein. Bei einer
modifizierten Version habe ich jetzt einen Optokoppler dran (für einen
Servokanal)
3) Benutzt Du auch einen Optopkoppler bei der UART? Oder ist der über
über eine Z-Diode abgesichert?
Beim einzigen Einsatz bisher ist ein Pegelwandler mit drauf (MAX 3221E)
Oder TTL-GPS direkt
4) Liefern die GPS-Empfänger RS232 oder TTL Pegel?
s.o. meine liefern TTL... Bei Navilok-Modulen z.B. gibts beides..
Das mit Logview ist wieder eingeschlafen, da es anscheinen direkt keinen
Bedarf gab. Sollte aber relativ einfach zu machen sein, das Protokoll
liegt ja offen.
@ho77bk:
Das Projekt ist auf die ATMEGA 88er Baureihe ausgelegt.
Für einen 16er sind vermutlich einige Änderungen am Code nötig. (Falls
er alle nötigen Anschlüsse hat..)
Micro-SD ist voll kompatibel. Ich verwende die auch, wenn ich keinen
"echten" SD-Slot habe... Einfach die Adapter-Karte als Verbinder an die
Schaltung gelötet... ist ja quasi bei den meisten Micro-Karten dabei.
Grüße
Marc
P.S. Bei dringenden Fragen zur Modellbau-Version am besten die
Kontakt-Funktion auf der Akamodell-Seite verwenden. Hier schuaue ich nur
zufällig vorbei.
Hallo Marc,
die Sache mit dem ATmega16 hat sich erledigt! Ich hatte sowieso keinen
mit 3,3V da, so hab ich mir den 168 bestellt...
Bei der Belegung der Micro-SD muß ich dich korrigieren! Eine "normale"
SD hat 9 Pins eine Micro-SD nur 8! Bei der SD ist 2 mal Plus
rausgeführt, ich glaube die Pins 4 und 6
Gruß ho77bk
Hallo ho77bk,
auf jeden Fall funktioniert die SW von Marc auch auf einem ATmega168,
habe ich gestern getestet. Ich muss "nur" noch schauen, ob alle Eingänge
korrekt eingelesen werden.
Ich denke Marc meint, dass die MicroSD software mäßig kompatibel ist.
Auf jeden Fall kann ich bestätigen, dass eine MicroSD Karte läuft.
Grüße
Ralf
Hallo, ich habe ein Problem. Wenn ich, mit Hilfe von AVR Studio 4, über
Tools -> AVR Prog -> das Hex File für meinen Atmel 8 anwähle und dann
anschließend über Flash Programm wähle, bekomme ich die Fehlermeldung:
"Data in file does not fit into Flash. Proceed and program all words
that fit?" Was mache ich falsch? Kann ich nicht einfach das Hex file von
MrData2 nehemen? Mache ich beim aufspielen einen Fehler? Vielen Dank.
Ich habe es jetzt doch noch geschafft den atmega zu bespielen. Es war
einfach der falsche µC ausgewählt.
Jetzt habe ich eine weitere Frage. Wovon hängt die maximal mögliche
Abtastfrequenz bzw. Aufzeichnungsfrequenz ab?
Ich habe mit meinem Atmega 8L mit extrenem 3,6 ... MHz Quarz jetzt mal
mit den Werten Overflow und Prescaler rumgespielt und bin auf Overflow 8
und Prescaler 13 gekommen. Das müsste eine Aufzeichnungsfrequenz von
etwa 400 -600 Hz. Was kann ich machen damit ich mehr Daten einlesen und
abspeichern kann. Wenn ich mit dem Prescaler runter gehe oder den
overflow weiter runter setze geht MrData auf Störung.
Vielen Dank.
Hallo zusammen, super Thema hier bin gerade auch an diesem Projekt!!
Kann jemand die eagle files posten das würde mir ne Menge arbeit
abnehmen.
wenn nicht kann jemand bestätigen dass das Layout von Frankie vom
19.06.2008 20:25 geht und hat jemand genau das schonmal nachgebaut? wäre
super
MfG
habe das projekt erfolgreicheich auf einem mega8 getestet. funkt super.
für meine weiteres vorgehen bräuchte ich eine empfehlung. ich möchte den
datenrekorder mit gps kombinieren und zusätzlich ein lcd ansteuern und
ein paar daten ausgeben. welche atmega sollte ich hierfür verwenden?
mega8? mega88? mega168? oder gleich eine nummer größer mega32? mega644?
mfg
Hallo!
Ich nutze die Variante von MarcS verwendet, nur leider gibt es ein
Problem wenn ich länger aufnehme. Geplant ist der Logger um in einem
Auto mitzufahren und analoge Werte sowie GPS aufzunehmen. Das
funktioniert auch so weit.
Einen Tag durchgehend aufnehmen ist kein Problem, sobald er länger
aufnimmt werden die TXT-Files teilweise zerstöhrt. Ab und an wird sogar
das Filesystem der Speicherkarte beschädigt, dann hilft nur formatieren.
Die µSD Karte (1GB) wird jedes mal frisch in FAT formatiert eingesetzt,
Settings.txt habe ich keine drauf (die Settings hab ich fest
einprogrammiert). Hab euch mal je ein Messfile angehängt.
Zur Hardware: Nutze einen Atmega 88 in TQFP32 Bauform (brauche acht
AD's), Speicherkarte ist eine 1GB µSDHC von Transcend.
Den Bug vermute ich in der FAT.c/h oder MMC.c/h, klingt nach dem Fehler
den Simon Lehmayr am 27.06.2007 hier in diesem Thread gemeldet hat.
Könnt Ihr mir evtl weiterhelfen?
Grüße!
KobiP
Mir ist gerade folgendes aufgefallen: in den defekten Files wird ab
einer bestimmten Prosition über eine Million Nullzeichen (ASCII
Steuerzeichen) eingefügt. Kann jemand etwas damit anfangen?
Es wird immer komischer. Nach jeder Verwendung formatiere ich die
SD-Karte (keine Schnellformatierung). Trotzdem erscheinen immer wieder
Daten von vor der Formatierung. Das passiert aber nur wenn der Fehler
auftritt; läuft er fehlerfrei habe ich auch einwandfreie Daten
vorliegen.
Grüße!
Hallo zusammen,
ist ein cooles Projekt Respekt....
Ich versuche das gerade in meinen Mega8 zu bringen. Aber irgendwie habe
ich da ein Problem mit dem makefile...
Wenn ich mir hier für eins erstelle meckert der Compiler nur rum.
Hat jemand dafür vielleicht schon ein makefile das er zur Verfügung
stellen kann?
Gruß André
Hallo, unter Linux können mit dem Befehl dd die Daten seriell ausgelesen
werden aus der SD-Karte auch wenn kein Dateisystem vorliegt. Mit dd
könnten auch alle Bytes mit 0 oder 255 beschrieben werden. Bereits
beschriebene Sektoren könnte so erkannt werden mit Inhalten ungleich
dieser Werte. Somit würde mehr vom Programmspeicher für Anwendungen
übrig bleiben.
Gibt es für ein solches Beschreiben einen Programmcode?
MfG, Dieter
Andre H. schrieb:> ../../Logger/MrData/mmc.o: In function `MMC_cleanup':> D:\AVR\Logger\MrData/../../Logger/MrData/mmc.c:190: undefined reference to
`spi_io'
> D:\AVR\Logger\MrData/../../Logger/MrData/mmc.c:191: undefined reference to
`spi_io'
Nur ganz schnell:
hast Du in Deiner "makefile" in der SRC-Zeile auch -wie hier unten an 4.
Stelle- "spi.c" aufgeführt?
...
...
SRC = $(AVRLIB)/rprintf.c $(AVRLIB)/a2d.c $(AVRLIB)/lcd_4.c spi.c
sd_32.c $(TRG).c
...
Hallo Andre H.
Sorry!
Meine schnelle Bemerkung zu Deiner makefile kannst Du erst mal wieder
vergessen. Sie war einfach zu vorschnell. Ich habe gerade bemerkt, daß
Du ja mit diesem Projekt einen ganz anderen Makefile (-Generator)
benutzst als ich; daher meine Fehlbeurteilung. In meiner "spi.c" habe
ich übrigens KEINE Funktion "spi_io()", sondern dafür eine
"spi_Atmega8", aus einem ähnlichen Projekt.
Ich werde mich aber jetzt auch in dieses interessante Projekt mit
SCHNELLER Datensammlung auf SDCard einarbeiten mit dem entspr.
AVR-Compiler usw.
Gruß Roland
graffu schrieb:> `spi_io'>>>> Nur ganz schnell:> hast Du in Deiner "makefile" in der SRC-Zeile auch -wie hier unten an 4.> Stelle- "spi.c" aufgeführt?
Hallo,
ich habe heute das Projekt Mr. Data gefunden und muss sagen super
Projekt!
Jetzt habe ich auch die Aufgabe einen Datenlogger zu erstellen, der 2
Werte Loggt. Einen Analogwert eines Sensors und einen Digitalwert eines
Inkrementaldrehgebers. Schlussendlich soll nach jeweils sagen wir
beispielsweise 10 Impulsen die Summe der Digitalimpulse und den
Analogwert geloggt werden. Die Dateien sollen per USB vom Computer aus
erreichbar sein
sieht hier jemand eine Möglichkeit dies mit diesem Projekt als
Grundgerüst zu realisieren? und kann mir jemand dabei helfen?
MfG
Stefan
Habe jetzt den Logger nachgebaut und die Erste version des Codes
draufgebrannt... ab PD4 hängt ein Taster der mit Ground verbunden ist
(soweit richtig?)
SD karte eingerichtet mit settings etc..
Wen nich jetzt das Board anschalte, leuchtet 2 mal die Status Led und
geht dann aus, bei betätigen des Tasters passiert gar nichts... woran
könnte das liegen?
Hallo,
hab den ATMega mit 5 Volt laufen und daher 1,8k Widerstände an DI, CLK
und CS und benutzte eine SDHC von Sand Disk Jedoch bekomme ich immer das
Dauerblinken woran könnte das liegen?
Vielen Dank
Ghost
Hab ein ähnliches Problem. Habe den 88er mit 3,6 V laufen. Auf dem
Steckbrett hat die LED brav 2 mal geblink und war dann ruhig. Seit dem
ich es zusammengelötet habe Blink sie permanent durch.
Ich denke das hat mit Pin7(dat0) der Sd Karte zu tuen. ist irgendein
anderer Pin nicht angeschlossen Leuchtet die LED trotzdem Permanent. Ist
Dat0 nicht angeschlossen blinkt die led(Ist ja klar da die Sd karte
nicht erkannt werden kann)
hat da irgendeiner Rat???!?!
Danke
Hallo,
das Projekt ist durchaus noch lebendig, auf jeden Fall bei mir. Wenn ich
mal größere Datenmengen Loggen muss, wird es wieder ausgepackt und
umgestrickt.
Hier im Forum bin ich aber kaum noch aktiv, daher sind Anfragen hier
eher schlecht (Wenn es speziell um die Modellbau-Version geht).
Nur als Anhaltspunkte:
Seite des Modellbau-Loggers:
http://www.uni-stuttgart.de/akamodell/projekte/?p=132
Über den Laden bin ich im Zweifelsfall erreichbar:
http://www.akamodell.de/ (irgendein Hinweis auf das Projekt und die
Nachricht sollte an mich gehen :-)
Grüße und frohes Basteln auch in 2011!
Marc
Hallo MarcS
dein projekt mit dem Datenlogger ist super.
Aber ich habe ein stromsparproblem.
die SD karte zieht 50mA beim schreibvorgang.
wenn ich nun eine Schleife baue :
Hallo,
nettes Projekt.
Ich würd gern meine Daten an die alte Log-Datei anfügen und keine neue
machen, wie mache ich dass, ich steig durch den Code nicht ganz durch.
Meine Abstände zw dem schreiben auf die MMC sind größer, daher ist das
besser. (alle 2 Min, Stundenlang)
Ich baue auch noch an dem Projekt.
Ich logge auch nur alle 5 min.
Das Problem war der Stromverbrauch der Karte beim schreiben.
Ich schreibe jetzt immer 512 Bytes und dann schaltet die Karte ab -
wartet 5 min - und dann geht's von vorne los.
Warum willst du die Datei weiterschreiben ?
Willst du die Karte entfernen ?
Oder geht's dir auch nur die 5 min zu überbrücken ?
Sebastian
Um genau zu sein war schreibe ich UART-Logs mit, keine ADC-Werte.
Wenn ich aber nun alle 5 Minuten eine neue Datei erstelle habe ich bald
tausende von Dateien auf der MMC.
Es ist machbar, aber ich fände es schöner wenn ich zB pro Tag oder "pro
anschalten" nur eine Datei habe um die Daten besser auswerten zu können.
MfG
Na ja ich mach sowas ähnliches ich schreibe alle 5 Minuten temperatur
Werte auf die Karte. Ca 1 Monat pro Datei. Dann die nächste Datei.
Unterbrichst du deinen schreibvorgang immer wieder? Du Must den letzten
Punkt der Datei dir merken. Dann kannst du an diesem Sektor ansetzen.
Beim neuen schreiben wird immer wieder bei null begonnen. Das Must du
totlegen.
Ich unterbreche meinen schreibvorgang aber auch nicht.
Ich öffne die Datei
Lese die Werte
Schreibe
Lese
Schreibe
Lese
.....
Schliese die Datei 1x im Monat
Hallo
also ich bin noch nicht so fit in uC.
Würde aber gerne einen Atmega8 Datenlogger programmieren der mir Daten
in eine Datei schreibt.
Vll wenn das geht beschäftige ich mich auch mal mit dem lesen der SD.
Habe aber ehrlichgesagt nicht genug überblick um zu sehen welche minimum
an Programm ich benötige.
Also was ich schon weiß das ich Fat16 SPI und MMC benötige.
Hi.
Das ist jetzt aber sehr viel was du wissen willst. Hast du schon einmal
Daten zu Spannung eingelesen und dann seriel oder auf einem Display
ausgegeben ? Das solltest du getan haben um mit sd zu spielen ... Ich
habe so einen logger gebaut siehe Texte oben
Grüße
Sebastian
Xxlxx
Also Analogwerte einlesen ist kein Thema und auch ins EEProm schreiben
oder über UART zu schicken kenn ich mich aus. Nur wie ich die Daten auf
der SD-Karte ablegen muss. Wenn ich z.b. nur 2 Analogwerte und 4
Digitale Werte loggen will...
also mit solchen libs wie oben ist es nicht so eine große hexerei daten
auf einer sd karte zuspeichern.
gespeichter wird meistens mit einem funktionsaufruf bzw. dergleichen. um
die größe der karte das fat system us. muss man sich in der regel nicht
kümmern wenn man soeine lib einbindet.
das einzige auf das man achten muss, ist die speichergröße, welche beim
mega8, nicht besonders groß ist. deshalb kann man mega88 oder mega 168
verwenden, nur ganz wenige anpassen und hat dann genug speicher mit
einem 100% pinkompatiblen µc.
Habe halt noch Atmega8L8 hier zuhause liegen und ne 16MB Karte und hab
eben aus nem defekten Kartenleser noch den SD-Slot ausgelötet. Es geht
mir darum gerade mit einem aufruf von nem unterprogramm daten so wie ich
will auf die SD-Karte zu schreiben.
Guck dir mal den link von Beitrag 14.2. An. Sdkarte & Stromsparen.
Ganz unten hängt eine rar Datei. Ich gäbe damals das karten schreiben
mal zusammengefasst für Mega 88. Kann hier vom iPhone das rar file nicht
einsehen. Aber Teste das mal
Also hab mal in dem anderen Forum nachgesehen und auch gefunden. Der
nachteil ist aber das da kein Schaltplan dabei ist. Hab probiert im
Programm irgendwelche infos zu bekommen aber jetzt selbst nicht direkt
was gesehen.
Hi
Das ist richtig. Die sd Karte ist wie überall angeschlossen. Da gibt's
nicht viele Möglichkeiten. Die Pin sind am Ic vorgegeben. Dann ist nur
noch eine LED und ein temp Sensor am atmega. Also auch nix besonderes
... Ich guck mal nach dem Schaltbild ... Kann ich aber erst vom PVC
machen - nix iPhone :(
Grüße sebastian
Sebastian schrieb:> Kann ich aber erst vom PVC> machen - nix iPhone :(
Hi wollte mal fragen ob du zu dem Programm "SD_card_power_down.rar"
noch den passenden Schaltplan hast.
Habe noch rumprobiert und angeschlossen wie es immer angeschlossen wird
hat sich aber noch nichts getan.
Bin fexible. Ist ja jetzt erstmal en Testaufbau für die Kommunikation
mit der SD-Karte nachvollziehen zu können. Würde jetzt im mom auf 3,3V
arbeiten weil es sich halt anbietet.
dann wird gleich am anfang ein INIT auf die SD Karte gemacht ...
geht das init nicht wird ein Error erzeugt :
1
staticvoiderror(void){
2
do{
3
PORT_LED&=~PIN_LED;
4
delay_ms(50);
5
PORT_LED|=PIN_LED;
6
delay_ms(50);
7
}while(1);
8
}
die LED blinkt schnell ...
das solltest du erst einmal hinbekommen ...
bedenke das das program für einen ATMEGA88 ist. Bitte Ports usw
überprüfen. dieses Programm ist das minimale um auf eine karte zu
schreiben. alle power down sachen sind entfernt. alle 1Wire sensoren
auslesen sind entfernt. es ist nur das grundgerüst um "0x00" zu
schreiben. Bitte SD Karte mit FAT 16 formatieren ...
dann funktioniert die komunikation mit der karte nicht.
check mal alles
- 3,3Volt für alles
- Karte richtig angeschlossen
- karte fat 16
- karte ist im pc noch nutzbar?
- SPI.C prüfen auf atmega8 umstellen
hast du ein oszi?
dann könntest du mal schauen ob sich auf den datenleitungen der sd-karte
etwas tut?!
ansonsten kann es nicht mehr viel sein.
sd-karte versorgt?
date leitungen der sd-karte vertauscht (miso/mosi)?
probier mal ein blinki programm mit deinem µc, bei dem nur eine led
ein/aus geht, um beschaltungsfehler auszuschließen.
Also ich hab den Programmer abgezogen. Habs auf dem Steckbrett
aufgebaut. Hatte keine Kondensatoren drin. Hab diese aber jetzt
reingebaut und hilft immer noch nichts. Spannung stimmt auch... Oszi hab
ich verliehen. Aber die LED blinkt immer noch nicht. ist jetzt der
Atmega88.
Und bitte macht die weitere Fehlersuche privat per Telefon oder so.
Dieser Thread ist in der Codesammlung, da sollten solch banale Postings
nicht dabeisein. Ich bekomme sonst weiterhin bei jedem neuen Post eine
email geschickt.
Danke,
Helmut.
Wollte mal fragen ob jemand den Mr.Data noch benutzt und aktuelle Atmel
Studio Datein davon hat?
Ich bin zu doof den Code umzuschreiben, da prog_uchar nicht mehr
unterstützt wird.
Grüße