Forum: Mikrocontroller und Digitale Elektronik AVR Daten an Excel übertragen


von Nick O. (lpt)


Lesenswert?

Hallo

Ich hatte vor Jahren (zu meinen Lehrzeiten) den Ersten Kontakt mit µC
Und das Assemblerprogrammieren auch ganz gut drauf gehabt.

Dann folgen ein paar Jahre des vergessen.
Und jetzt in meinem Studium hab ich Kontakt zu verschiedenen 
Programmiersprachen.

Und so ein mählich naht die Zeit der Projektarbeit.
Dafür möchte ich einen Datenlogger mit einem AVR Controller bauen.
Wahrscheinlich wird ein AT90S8535

Was ich genau machen will?
Ich will ein Messgerät bauen bei dem ich
8 Analoge Stromwerte von 0 bis 20mA bzw.
8 Spannungen von 0 bis 24V messen und Speicher kann.

Außerdem sollen noch 8 Digitale Signale gespeichert werden.
Die Zeitinterwalle sollen wählbar sein.
Und gespeichert werden soll auf dem RAM
Die Anzahl der Messwerte ist eigentlich von Excel begrenzt auf 65 536 je 
Kanal.
Daher sollte es eigentlich keine Speicherproblem im Controller geben

Nach erfolgreicher Messwertaufnahme will ich das Gerät mit einem PC 
verbinden und die Daten per Knopfdruck in eine Exceldatei übertragen.
Die Auswertung soll dann über VBA geschehen.
Soweit die Theorie.

Jetzt kommen aber meine Fragen.
Wie kann ich die Daten auf den PC bekommen?
Mit dem Controller die Daten Senden oder mit VBA auslesen?

Als Schnittelle dachte ich eigentlich an USB da Serieelleschnittstellen 
an Laptops so ein mählich aussterben.

Dazu hab ich was vom
USB Chip FT232BM
Gelesen, funktioniert das und was gibt es zu beachten?

Wie sieht das mit Treiber aus?

Und was sind eigentlich Deskriptoren und Enumertion?

Und jetzt eigentlich meine Wichtigste Frage.
Ist das eigentlich machbar?

Ich würde mich über euer Meinung freuen

mfg
LPT

von hans (Gast)


Lesenswert?

Bei den FTDI ist es unter Windows einfach, die laufen als
RS232 - USB Konverter. Damit hast du Treiber (von Windows oder
FTDI) die eine Serielle Schnittstelle bereitstellen (COMx).
Die wird in VBA wie jede andere Serielle Schnittstelle behandelt.
Für den µC ist es auch eine serielle Übertragung im RS232-Format.

In VBA einfach Kontakt aufnehmen (Echofunktion) und dann
die Daten abfragen (alsoz.B. Befehl Sende AD-Werte(Kanal3) Nr. 0-575).

Bei größeren Datenmengen ist RS232 der Flaschenhals.
Wenn möglich das senden auf Werte begrenzen also 10 Bit
AD-Werte als 2 Byte übertragen und im PC in Spannung/Strom
umrechnen und nicht mit Printf "U1: 2,654 V" senden.

Solche Benutzerfreundlichkeiten nur wenn es auch andere Benutzer
und ein Handbuch gibt.


gruß hans

von Ak T. (aktronik)


Lesenswert?

>Bei größeren Datenmengen ist RS232 der Flaschenhals.

Hmm,
wenn sich Nick Olaus sinnvoller Weise für den ATmega8535 entscheiden 
würde kann er bei 20 MHz mit bis zu 2.5 Mbps kommunizieren.
Die USB-Seriell-Wandler sind ja recht schnell.

MfG
Ak Tronik

von Urs (Gast)


Lesenswert?

...
> Wahrscheinlich wird ein AT90S8535
Der ist übrigens von Atmel als "obsolet" eingestuft.

> Ich will ein Messgerät bauen bei dem ich
> 8 Analoge Stromwerte von 0 bis 20mA bzw.
> 8 Spannungen von 0 bis 24V messen und Speicher kann.

>Außerdem sollen noch 8 Digitale Signale gespeichert werden.
...
> Und gespeichert werden soll auf dem RAM
> Die Anzahl der Messwerte ist eigentlich von Excel begrenzt auf 65 536 je
> Kanal.
> Daher sollte es eigentlich keine Speicherproblem im Controller geben

Das erstaunt mich jetzt aber, da der AT90s8535 nur 512 Bytes (nicht 
Kilobytes!) RAM hat.

von willi (Gast)


Lesenswert?

übertrag die daten doch während der messung, mit ner baudrate von 
beispielsweise 115200 geht das recht fix. wie es der zufall will hab ich 
vor kurzer zeit genau so ein programm mit VB erstellt. falls interesse 
besteht: melden

von Nick O. (lpt)


Lesenswert?

Danke erst mal für die Infos.

Das der 8535 obsolet ist (das musste ich erst mal Google’n) also 
Veraltet ist hatte ich mir vielleicht gedacht aber das war der mit dem 
ich damals etwas gebastelt hab.

Bin natürlich für Controller Vorschläge offen da ich seit 5Jahre nicht 
mehr in der Thematik drin stecke.

Und Echtzeitübertragung will ich nicht weil der Datenlogger für den 
Flexiblen Einsatz gedacht ist.

Wird also nicht nur ein Projekt fürs Studium das danach in der Tonne 
landet.
Sondern es soll auch noch Alltagstauglich sein.
Ich will es schließlich auch auf Arbeit verwenden.

mfg
LPT

von Sven P. (Gast)


Lesenswert?

Der AT90Ssowieso ist obsolet, der Nachfolger ATMega8515 ist schon ok. 
Der hat vielleicht wenig internes RAM, dazu kommt aber der nach außen 
herausgeführte Speicherbus, mit dem externes SRAM angeklemmt werden 
kann.

von Nick O. (lpt)


Lesenswert?

Danke für den Tipp.

Ich werd mich mal etwas belesen.
könnt ihr mir etwas empfehlen.

Gibt es eigentlich eine Sammlung fertige Schaltungen?
Die Bücher die ich hab sind nämlich genauso alt wie mein wissen von den 
Atmel.

Ich hab mal etwas gesucht aber eine Übersichtstabelle der verschiedenen 
Typen finde ich nicht.
Gibt es da vielleicht einen Link.

mfg
LPT

von Sven P. (Gast)


Lesenswert?

Eine gute interaktive Vergleichstabelle haben die Leute von 
avrfreaks.net (wars .net?) zusammengebaut.

Schaltungs- und Anwendungsbeispiele hat Atmel als 'Application Notes' en 
masse auf der Homepage.

von Dirk W. (bastelator) Benutzerseite


Lesenswert?

Hallo LPT,

vielleicht kannst Du ja mit meiner Excel-Anbindung 
(http://www.bastelator.de/, ganz oben), die auf dem Forenbeitrag 
http://www.mikrocontroller.net/forum/read-4-194813.html basiert, etwas 
anfangen.

Gruß,
Dirk

von Oha (Gast)


Lesenswert?

>Ich hab mal etwas gesucht aber eine Übersichtstabelle der verschiedenen
Typen finde ich nicht. Gibt es da vielleicht einen Link.

Zwei linke Haende ? Dann lass es sein.
http://www.atmel.com/products/AVR/overview.asp
dort parametric product table
http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC

von Nick O. (lpt)


Lesenswert?

So ich hatte jetzt mal etwas Zeit mich zu belesen.
Leider dauert es bei mir mit den Englischen Seiten immer ein Weile.

Meine Grundidee ist noch die Gleiche aber die Daten werde ich wohl auf
einem EEPROM speichern müssen.
Als Controller hab ich mir den ATmega324 auserkoren.
Ist so wie ich es gelesen hab, der schnellste und größte Prozessor im 
DIP Gehäuse mit den meisten Möglichkeiten. Und ich denke mal die 
Eingänge brauche ich auch wenn ich auf Multiplexer verzichten will.

Ich weiß bloß noch nicht ob ich über SPI oder I2C den Speicher 
ansprechen soll.

So wie ich es rausgelesen hab ist SPI schneller aber I2C weiter 
verbreitet.
Was ist besser bzw. einfacher zu programmieren, auf zu bauen und 
Zuverlässiger?

Die reale Datenrate ist doch sowieso vom Prozessortakt und der Länge des 
Protokolls abhängig.
Und bei 20MHz CPU Takt recht uninteressant

Der EEPROM 24LC04B bzw. 08B hat 4 bzw. 8 Blöcke mit je 256kByt und ist 
für I2C
Der 25LC040 hat 512 Byt und ist für SPI.

Was hat das mit dem Blöcken auf sich?
Muss ich etwa jedes mal den gesamten Block beschreiben?
Und wie groß ist die maximale Serielle Speicheradresse die der µC 
ansprechen kann (16Bit???).

Ich würde mich über ein paar Antworten freuen.

mfg
LPT

von Robert K. (molch) Benutzerseite


Lesenswert?

Nick Olaus wrote:
> Der EEPROM 24LC04B bzw. 08B hat 4 bzw. 8 Blöcke mit je 256kByt und ist
> für I2C
> Der 25LC040 hat 512 Byt und ist für SPI.
>
> Was hat das mit dem Blöcken auf sich?
> Muss ich etwa jedes mal den gesamten Block beschreiben?
> Und wie groß ist die maximale Serielle Speicheradresse die der µC
> ansprechen kann (16Bit???).

Da SPI und I²C ja serielle Busse sind sollte die Adressbreite für den µC 
bei diesen EEPROMs egal sein. Du wirst ja dann die Adresse eh Bit für 
Bit über die selbe Leitung schicken.
Als Hinweis: Ich weiß ja nicht in welchem Maße du Daten loggen willst, 
aber son EEPROM hat nur ne begrenzte Zahl an Schreibzugriffen, also 
denkbar ungeeignet für sekündliches beschreiben.

Was ist einfacher: meines Wissens besitzt der Controller für beide Arten 
eine Hardwareschnittstelle (I²C nennt sich bei Atmel TWI) was die 
Programmierung schon recht einfach gestaltet.

Auf den Rest kann ich dir leider nicht Antworten,

MfG Robert

von Nick O. (lpt)


Lesenswert?

Robert K. wrote:
> Da SPI und I²C ja serielle Busse sind sollte die Adressbreite für den µC
> bei diesen EEPROMs egal sein. Du wirst ja dann die Adresse eh Bit für
> Bit über die selbe Leitung schicken.

Ja aber die Register im µC sind ja nur 8 bzw 16Bit oder kann ich die 
Adresse auch länger gestalten?

> Als Hinweis: Ich weiß ja nicht in welchem Maße du Daten loggen willst,
> aber son EEPROM hat nur ne begrenzte Zahl an Schreibzugriffen, also
> denkbar ungeeignet für sekündliches beschreiben.

Meinst Du mit Schreibzugriffen die Anzahl der Wiederbeschreibbarkeit.
So weit ich weiß liegt die bei etwa 10 000.
Also könnte ich Jahre lang jeden Tag den Speicher beschreiben und 
löschen.
Und in jedem Jahrzehnt ein mal den Speicher wechseln.

Aber Du hast Recht ich wollte erst ein RAM nehmen aber nach  2 Tagen 
suchen und lesen hab ich immer noch keins gefunden das 512 bzw. 1024Byt 
groß ist.
Das größte war glaube ich 128 und eine ganze Armader an RAM will ich aus 
Platzgründen nicht verschalten.

Was die Datenmenge angeht.
Es sollen je Datensatz bis zu 10Byt (falls ich alle 10Bit vom ADC 
auswerten will, werden es sogar 18Byt sein) gespeichert werden.
Die Zeit zwischen den Aufzeichnungen soll einstellbar sein.
Der schnellst Zeitinterwall müsste bei 10x pro sek. liegen.

Und die Anzahl der Datensätze ist halt von Excel auf 65536 begrenzt.
Da ich auf Felder verzichten will.

mfg
LPT

von Justus S. (jussa)


Lesenswert?

Robert K. wrote:

> Als Hinweis: Ich weiß ja nicht in welchem Maße du Daten loggen willst,
> aber son EEPROM hat nur ne begrenzte Zahl an Schreibzugriffen, also
> denkbar ungeeignet für sekündliches beschreiben.

aber er wird ja nicht sekündlich auf dieselbe Adresse zugreifen...er 
könnte 10000x den EEPROM vollknallen und auslesen, dann würde es 
Probleme geben...

btw was zur Hölle ist ein "mählich"??

von Robert K. (molch) Benutzerseite


Lesenswert?

Nick Olaus wrote:
> Ja aber die Register im µC sind ja nur 8 bzw 16Bit oder kann ich die
> Adresse auch länger gestalten?
>

Das stimmt, aber deswegen kannst du doch ein Byte nach dem anderen an 
das EEPROM senden welches die Adresse des zu beschreibenden Segements 
enthält. Oder reden wir hier aneinander vorbei?

> Meinst Du mit Schreibzugriffen die Anzahl der Wiederbeschreibbarkeit.
> So weit ich weiß liegt die bei etwa 10 000.
> Also könnte ich Jahre lang jeden Tag den Speicher beschreiben und
> löschen.
> Und in jedem Jahrzehnt ein mal den Speicher wechseln.

Wenn du einmal pro Tag schreibst mag das gehen, aber du sagst ja unten 
es gibt nen variables Zeitintervall mit dem Minimum von 10 Loggs pro 
Sekunde und da kommen schon paar Daten zusammen. Am Ende hast nur du die 
Übersicht wieviel es wirklich wird. Wollte dir nur den Denkanstoß geben 
das ein EEPROM nicht ewig lebt :-)

> Aber Du hast Recht ich wollte erst ein RAM nehmen aber nach  2 Tagen
> suchen und lesen hab ich immer noch keins gefunden das 512 bzw. 1024Byt
> groß ist.
> Das größte war glaube ich 128 und eine ganze Armader an RAM will ich aus
> Platzgründen nicht verschalten.

Ein Controller auf Basis wie der ATmega 325 haben einen 16Bit-Adressbus 
rausgeführt wie der von dir zuerst angedachte AT90S8535. Dafür sollte es 
doch definitiv größere RAMs geben oder irre ich da?
Könntest ja immer noch den interen RAM nutzen (beim ATmega 324 2K 
abzüglich das was dein Programm braucht). Müsstest den Controller 
natürlich dann mit einer Batterie stützen wenn du ihn zum Rechner 
transportierst.


@ Justus:
mählich => allmählich => nach und nach
So kenne ich das :)

von Michael U. (amiga)


Lesenswert?

Hallo,

ich habe jetzt nicht alles gelesen, aber meine "Datensammelstelle"
Beitrag "Sensoren mit RFM02/12, FOST02, HP03S (ASM)"

macht im Moment so: Daten werden in einen AT45DB161D geschrieben, 
ausgelesen wird dieser ab- und an mal per UART-FTDI232 mit 115200Baud. 
Gesendet wird als X-Modem, die Übertragung ist als .csv formatiert.

X-Modem, weil es einfach ist, 128Byte Blockgrößer auf einem AVR nicht 
stören und weil die Timeout-Zeit hoch genug ist, um auch mal eine Pause 
zwischen 2 Blöcken einzulegen, wenn gerade Sensordaten da sind.

Der AT45DB161D deshalb, weil er bezahlbar ist, es ihn von 4MBit bis 
64MBit gibt und weil die I/O 5V tolerant sind (selbst will er 
2,7...3,6V).

Gruß aus Berlin
Michael

von Nick O. (lpt)


Lesenswert?

@ Michael U.
So was in der Art will ich auch bauen.
Bloß halt ohne Funkstrecke.
Und die Signale die mitgeschrieben werden sollen, kommen aus einem 
Schaltschrank.

Als Endergebnis soll eine Vernünftige Auswertung stehen.
Ist erst das Ventil aufgefahren oder ist erst der Drück gefallen?
Hat der Antrieb über Endlage abgeschaltet?
Wie gut ist die Regelung abgestimmt und gibt es ein Schwingen von der 
Regelung?
Welche Störgrößen wirken wie Stark auf die Regelstrecke?
Oder warum kommen in unregelmäßigen Abstanden Fehlalarme?

Daher die Große Menge an Daten die aufgezeichnet werden soll.
Wie schon geschrieben werden wohl etwa 600 bis 700 KByt an Speicher 
benötigt.
512 Würden aber zur Not reichen.
Daher will ich erst gar nicht anfangen die Daten in 2K Stückchen auf dem 
Controller zu verteilen.

Zur Frage EEPROM oder RAM.
Wenn es hoch kommt (aber man weiß ja nie was vielleicht mal sein wird) 
werde ich den Datenlogger 1mal in der Woche benutzen und dann auch nur 
eine Messreihe aufnehmen.
Also auch nur 1 mal in der Woche den Speicher beschreiben bzw. Löschen.
Also wird die 10 000 erst nach Jahren erreicht.
Und der Vorteil beim EEPROM ist ja bekanntlich das die Daten nicht 
flüchtig sind.

Aber noch mal eine Frage zum Adressieren.
Im Controller muss man doch immer die genaue Adresse angeben.
Wenn man Daten Schreiben oder lesen will.
Reicht das beim Seriellen Speicher aus die Anfangsadresse anzugeben und 
dann die Daten hintereinander zu senden?
Und was geschieht wenn der Controller nach z.B. 1 Sekunde die nächsten 
10Byt speichern will?

mfg
LPT

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.