Temperaturschreiber... PC Excel Kurve!

[Fighter-2]

Ja dann machen wir das so!

Gute Sache!

[Fighter-2]

Wie fängt man nun das ganze an?

Erstmal müsste man ja eine Verbindung zwischen Hauptcontroller und Speichercontroller herstellen, zusätzlich dann noch zwischen Speichercontroller und Speicher!

Wie wird die Komunikation den hergestellt? Gibt es dazu.. was zum nachlesen?

[Lordcyber]

Hallo,
wie ja schon bekannt ist habe ich das selbe Problem mit Tranportablen Daten.
Daher ja fand ich das mit SD CArd Klasse.
Da nun hier auf den 24LC256 umgeschwenkt wurde da das ja einfacher sein soll hab ich mir das auch überlegt.
Aber will ja nicht unnötig Kabel verlegen oder ganze Einheit abbauen.
Der Chip Kam mir irgendwie bekannt vor. Nach etwas Recherage kam ich drauf. Habe noch 2 FunCards hier aus alter Irdeto ZEit.
Daher könnte man die Daten nicht auf eine CARD AT90SC8515/24LC256 ( FUN 4 ) schreiben die dan rausziehen und am PC auslesen??
Danke.

[python_rocks]

Da nun hier auf den 24LC256 umgeschwenkt wurde da das ja einfacher sein soll hab ich mir das auch überlegt.
...
Aber will ja nicht unnötig Kabel verlegen oder ganze Einheit abbauen.

Hallo Lordcyber!

Der 24LC256 oder der M24512-WMW6 (mit 512 kBit Speicherplatz), sind beide I²C-Clients und könnten über ein sehr einfaches I²C-Protokoll beschrieben und ausgelesen werden. I²C sind zwei Leitungen an die alle I²C-Geräte gemeinsam angeschlossen werden. Ich persönlich hätte den ATmega8 und den 24LC256 direkt nebeneinander auf eine kleine Lochrasterplatine gesteckt. Also nichts mit langen Leitungen. Und an diese Platine einen kleinen dreipoligen Stecker (oder damit es stabiler wird ein sechspoliger Wannenstecker) zum Anschließen des mySmartUSB als USB-UART-Adapter verwendet. Der ATmega8 kostet keine 2 Euro und der 24LC256-I/P kostet bei Conrad 2,86 Euro. Wahrscheinlich lässt er sich wo anders um weniger Geld bekommen. Das waren meine Überlegungen zu diesem Thema.

AT90SC8515/24LC256 ( FUN 4 )

OK, dann lass mich mal darüber nachdenken.

Scheint nicht uninteressant zu sein. Allerdings (glaube ich irgendwo gelesen zu haben) werden diese Karten per I²C angesteuert. Oder war es doch 1-Wire?

Egal. Damit müsste man mehr Programmlogik in den Haupt-µC verlagern. Die Daten könnten also per I²C an die Karte übergeben werden. Die Karte müsste dann noch auf eine I²C-Echtzeituhr zugreifen und dann die Daten in den EEPROM schreiben. Wie sieht dann die Lösung aus, wenn ich später doch noch auf miniSD oder MMC als Speichermedien umsteigen möchte, da dort doch viel, viel mehr Speicherplatz zur Verfügung steht? Wenn ich alles über einen ATmega8 mache, dann tausche ich den EEPROM gegen einen Kartenslot. Mir scheint so eine Karte auch ein wenig groß. Aber alles hat seine Vorteile und Nachteile. Die ersten Nachteile an der Karte sind, dass man sich in die Programmierung von I²C als Slave einlesen muss und ich halte diese Karten für extrem überteuert.

Außerdem, wenn man von der Karte aus per I²C auf eine Echtzeituhr zugreifen möchte, dann wäre die Karte der I²C-Master. Das bedeutet, dass man die gesamte I²C-Lösung als "Multimaster" konzeptionieren muss. -- Das macht die Sache unter Bascom viel schwieriger. -- Das ist das KO-Argument. Die Karte zwingt mich in den I²C-Multimaster-Modus, sobald ich Daten von einer Echtzeituhr haben möchte. Außer ich hole die Daten von der Echtzeituhr bereits in den Haupt-µC. Also doch mehr Logik in den Haupt-µC verlagern. Gleichstand?

Chris braucht nicht mehr Speicher als ein M24512-WMW6 zur Verfügung stellen kann. Und das Auslesen der Daten über einen kleinen Stecker ist auch nicht das Problem. Außerdem kann man die Schaltung (ATmega8 und M24512-WMW6) auf einer kleinen Lochrasterplatine unterbringen, die man mit einem Wannenstecker auf die Hauptplatine aufstecken kann. Somit könnte man dieses Teil sogar abstecken und zum Auslesen zum Computer bringen.

Aber jetzt habe ich den KO-Schlag für die Karte. ;-) -- Ich habe einen ATmega8 und ich habe einen 24LC256 mit dem ich eine Testschaltung aufbauen kann. Aber ich habe keine "CARD AT90SC8515/24LC256 ( FUN 4 )" mit der ich experimentieren kann. Ich habe auch keinen Slot für so eine Karte und glaube nicht, dass ich das Geld dafür ausgeben werde, nur um damit Tests machen zu können.

So nebenbei: Ich habe soeben die I²C-Echtzeituhr PCF8563 bei Segor gefunden: http://cgi.segor.de/user-cgi-bin/sid...o=1&Q=8563&M=1
Vielleicht kann man damit sogar etwas anfangen. Ich merke es mir zumindest schon mal vor.

Ich muss jetzt Schluss machen.

lg
Gerold
:-)

[python_rocks]

Hallo Lordcyber!

Meinen obigen Beitrag bitte nicht falsch verstehen. Ich schließe die Funcard als ideal Lösung für Chris aus. Aber du hast diese ja bereits. Ich weiß ja nicht wieviel Daten du sammeln möchtest. Aber für dich könnte das natürlich eine Lösung sein. Du müsstest dich aber in I²C als Slave einlesen. Außerdem weiß ich nicht mit was du programmierst. Von Chris weiß ich, dass er mit Bascom arbeitet. Dort ist I²C als Master sehr einfach. I²C als Slave muss man selber programmieren.

Welche Datenmenge kommt denn bei dir so zusammen? Was sind die Anforderungen?

lg
Gerold
:-)

[python_rocks]

Wie fängt man nun das ganze an? :)

Erstmal müsste man ja eine Verbindung zwischen Hauptcontroller und Speichercontroller herstellen, zusätzlich dann noch zwischen Speichercontroller und Speicher! ;)

Wie wird die Komunikation den hergestellt? :) Gibt es dazu.. was zum nachlesen? ;)

Hallo Chris!

Ich kann dir nur erzählen, wie ich die Sache angehen würde. Wie du an die Sache herangehen sollst, weiß ich nicht.

Ich würde mir zwei ATmega8 nehmen. Einen davon in mein Experimentierboard von Roland Walter und einen in mein (hoffendlich bald geliefertes) Pollin Experimentierboard. Auf dem Pollin Experimentierboard ist auch ein Sockel für einen EEPROM mit drauf. -- Lass mich mal im Schaltplan nachsehen ob der per I²C angesteuert werden kann. -- Ja, passt genau. Allerdings ist Adresse des EEPROM fest auf "000" gestellt. Aber damit kann man leben. :-)

Beide Experimentierboards haben einen MAX232 an Board und können somit über RS-232 an den Computer angeschlossen werden. So übertrage ich später Meldungen zum Debuggen der Programme zum Computer. Mehr brauche ich zum Debuggen nicht.

Als Erstes würde ich mich um das Ansprechen des EEPROMs per I²C kümmern.

Also würde ich ein paar Funktionen dafür schreiben, die das Ganze kapseln.

sub ee_erase(byval slave_address as byte)
   ... und hier stehen die Befehle zum Löschen des EEPROMs
end sub

function ee_first_free_address(byval slave_address as byte) as word
   ...hier wird herausgefunden bis zu welcher Adresse das EEPROM bereits beschrieben wurde.
      Die erste freie Adresse wird zurück gegeben.
end function

sub ee_write_temperature(byval slave_address as byte, byval temperature as word)
  ...
end sub

OK, ich halte mich kürzer. Ich würde mich also zuerst mal um die Kommunikation zwischen dem µC und dem EEPROM kümmern. Alle Prozeduren und Funktionen schreiben, die dafür notwendig sind dass das EEPROM gelöscht, ausgelesen und beschrieben werden kann.

Dann würde ich mich um die Kommunikation zwischen dem µC und dem Computer kümmern. Es muss ja per RS-232 eine Verbindung hergestellt werden können. Der Computer muss eine Anweisung erteilen und der µC muss darauf reagieren.

Es macht keinen Unterschied, ob du per RS-232 und einem MAX232 an den µC fährst oder ob du später mit dem mySmartUSB direkt an RX und TX ran fährst.

Ein Befehl sollte mit RETURN ``chr(13)`` abgeschlossen werden. Denn dann kannst du im µC mit INPUT arbeiten um die Befehle zu empfangen. Siehe: http://halvar.at/elektronik/rs232/

Du könntest also z.B. über die UART den Befehl "READ ALL" schicken. Dieser wird von INPUT ausgelesen. Dann analysiert man den Befehl. Mit SELECT CASE kannst du auf verschiedene Befehle reagieren.

Bei "READ ALL" würdest du also per I²C den EEPROM von vorne bis hinten auslesen und jedes Byte über die UART an den Computer zurück schicken.

Bei "DELETE ALL" würdest du per I²C den EEPROM von vorne bis hinten mit 0xFF vollschreiben.

Wenn das Lesen, das Schreiben und die Kommunikation mit dem Computer hinhaut, dann kannst du dich um die Kommunikation mit dem Haupt-µC kümmern. Aber bevor du den Haupt-µC umprogrammierst, würde ich den zweiten ATmega8 als Ersatz dafür verwenden und zuerst das Programm auf diesem entwickeln. Erst wenn alles läuft und die Tests erfolgreich waren, dann würde ich die Funktionen für die Übertragung der Temperaturdaten in den Haupt-µC einbauen.

Die Kommunikation zwischen dem Haupt-µC und dem Speicher-µC könnte per SPI passieren. So lange kein weiteres Gerät am SPI-Bus hängt, genügen zwei Leitungen zwischen Haupt-µC und dem Speicher-µC dafür.

Links zu SPI mit Bascom:
- http://avrhelp.mcselec.com/index.html?config_spi.htm
- http://avrhelp.mcselec.com/index.html?spiin.htm
- http://avrhelp.mcselec.com/index.html?spiout.htm
- "spi-slave.bas" im Bascom-SAMPLES-Ordner.
- http://avrhelp.mcselec.com/index.htm...i_protocol.htm

Man schickt also die Temperatur, in ein Ticket verpackt, über den SPI-Bus vom Haup-µC zum Speicher-µC. Dieser analysiert das Ticket und ruft die zugehörige Prozedur auf, die sich darum kümmert, dass der neue Messwert an die richtige Stelle im EEPROM geschrieben wird (per I²C).

Über die UART können Befehle vom Computer kommen. Wird der Befehl zum Löschen des EEPROM gegeben, dann wird dieser gelöscht. Wird der Befehl zum Auslesen des EEPROM gegeben, dann liest der Speicher-µC die Daten vom EEPROM und gibt diese über die UART an den Computer zurück.

Wenn das alles mal im Renngerät läuft und getestet wurde, dann kann man sich Gedanken darüber mache, was noch super wäre und wie man dieses Logging aufpeppen könnte.

Jetzt mache ich mir ein Mittagessen. :-)

lg
Gerold
:-)

[python_rocks]

Hallo!

Ich traue mich meine Versuche gar nicht hier rein zu stellen. Da wird jetzt sicher einer sagen, was verzapft dieser Anfänger denn da für einen Blödsinn. :-| Es geht um das Auslesen und Beschreiben eines 24LC256 EEPROM.

Man wird unweigerlich merken, dass ich aus der GUI-Anwendungs-Programmierung komme und noch nicht lange mit den AVRs arbeite. Aber besser bringe ich es im Moment nicht zusammen. Irgendwie scheinen die Prozeduren und Funktionen im Bascom erschreckende Einschränkungen bez. Variablen zu haben. Keine Arrays, keine Overlays. Mit ``byval`` deklarierte Parameter lassen sich innerhalb der Funktion nicht bitweise verändern. Man muss sie vorher in eine andere Variable kopieren. Habe ich noch etwas übersehen? ;-)

$regfile = "M8def.dat"
$crystal = 8000000
$hwstack = 32
$swstack = 10
$framesize = 40
$baud = 38400


Declare Sub Eeprom_write_byte(_
   Byval Slave_address As Byte , Byval Data_address As Word , _
   Byval Value As Byte _
)
Declare Function Eeprom_read_byte(_
   Byval Slave_address As Byte , Byval Data_address As Word _
) As Byte


'TWI (I²C)
$lib "i2c_twi.lbx"       'Hardware TWI einschalten
Config Scl = Portc.5
Config Sda = Portc.4
Const Slave_address = &B10100000
Config Twi = 400000
I2cinit


'TEST --------------------

Dim W As Word
Dim Bt As Byte


For W = 0 To 200
   Bt = W
   Call Eeprom_Write_byte(slave_address , W , Bt)
   Print "written:" ; Bt
Next W

For W = 200 To 0 Step -1
   Bt = Eeprom_Read_byte(slave_address , W)
   Print "read:" ; Bt
Next W

'TEST --------------------


End



Sub Eeprom_write_byte(_
   Byval Slave_address As Byte , Byval Data_address As Word , _
   Byval Value As Byte _
)

   Local Slave_w As Byte
   Local Slave_r As Byte
   Local Addr_high As Byte
   Local Addr_low As Byte

   Slave_w = Slave_address And &B11111110
   Slave_r = Slave_address Or &B00000001

   Addr_high = High(data_address)
   Addr_low = Low(data_address)

   I2cstart
   I2cwbyte Slave_w
   I2cwbyte Addr_high
   I2cwbyte Addr_low
   I2cwbyte Value
   I2cstop

   Waitms 5

End Sub


Function Eeprom_Read_byte(_
   Byval Slave_address As Byte , Byval Data_address As Word _
) As Byte

   Local Slave_w As Byte
   Local Slave_r As Byte
   Local Addr_high As Byte
   Local Addr_low As Byte
   Local Retval As Byte

   Slave_w = Slave_address And &B11111110
   Slave_r = Slave_address Or &B00000001

   Addr_high = High(data_address)
   Addr_low = Low(data_address)

   I2cstart
   I2cwbyte Slave_w
   I2cwbyte Addr_high
   I2cwbyte Addr_low
   I2cstart
   I2cwbyte Slave_r
   I2crbyte Retval , Nack
   I2cstop

   Eeprom_Read_byte = Retval

End Function

@Chris:
Das Beschreiben und Auslesen des EEPROM funktioniert schon mal.

lg
Gerold
:-)

[Lordcyber]

Hallo Lordcyber!

Meinen obigen Beitrag bitte nicht falsch verstehen. Ich schließe die Funcard als ideal Lösung für Chris aus. Aber du hast diese ja bereits. Ich weiß ja nicht wieviel Daten du sammeln möchtest. Aber für dich könnte das natürlich eine Lösung sein. Du müsstest dich aber in I²C als Slave einlesen. Außerdem weiß ich nicht mit was du programmierst. Von Chris weiß ich, dass er mit Bascom arbeitet. Dort ist I²C als Master sehr einfach. I²C als Slave muss man selber programmieren.

Welche Datenmenge kommt denn bei dir so zusammen? Was sind die Anforderungen?

lg
Gerold

Hallo,
Arbeite ebenfalls mit Bascom.
DS1307 ist bei mir mit dabei. Kernstück Atmega 2561
Wird ein Steuerkomputer für meien Meerwasserbecken.
Daten sind:
2X Temparatur DS1631 alle 5 min mit Zeit
Leitwert alle 5 min
Zeit der Nachfüllung
Menge der NAchfüllungen
Ph Wert alle 5 min.
Da ich keine Lust habe den jeden Tag auszulesen währe das mit einem Großen Speicher Ideal. Denke mal so jeden bis alle 2 Monate
Soll alles in Excel ausgewertet werden.
Wie gesagt Kabel verbindung wegen entfernung zu groß.
Überlege gerade wie es mit AVR-DOS dafür aussieht.
Danke

[python_rocks]

Überlege gerade wie es mit AVR-DOS dafür aussieht.

Hallo Lordcyber!

Bei deinem µC dürfte AVR-DOS funktionieren. Und für nicht-kommerzielle Anwendungen ist AVR-DOS gratis.

- http://www.mcselec.com/index.php?opt...d=20&Itemid=41
- http://members.aon.at/voegel/

Soll alles in Excel ausgewertet werden.

Ideal wäre es, die Daten im CSV-Format abzuspeichern. Dieses Format kann Excel direkt öffnen.

mfg
Gerold
:-)

[Lordcyber]

Habe dan mal neuen Thread gemacht. Damit nicht alles hier landet.
Weil ja noch mehr unklarheiten sind.