Solarthermie SunGo SXL - Versionsgeschichte

Chris T. Ludwig: /* Inhalt der "Nicht-EEPROM" Pakete */

2021-09-18T11:07:55Z

Inhalt der "Nicht-EEPROM" Pakete

← Nächstältere Version		Version vom 18. September 2021, 13:07 Uhr
Zeile 467:		Zeile 467:
	Datensatz aus dem Stick: 4F 04 03 01 2E 00 E6 00 25 01 C4 09 C4 09 C4 09 0D 01 DE 00 A2 FE 00 00 00 00 00 00 00 00 00 00 00 00 00 64 00 15 15 08 00 00 00 00 00 00 00 00 7D 01 00 00 00 00 01 00 00 00 00 00 00 00 00 00		Datensatz aus dem Stick: 4F 04 03 01 2E 00 E6 00 25 01 C4 09 C4 09 C4 09 0D 01 DE 00 A2 FE 00 00 00 00 00 00 00 00 00 00 00 00 00 64 00 15 15 08 00 00 00 00 00 00 00 00 7D 01 00 00 00 00 01 00 00 00 00 00 00 00 00 00

	Der ''''03 00'''' ist der ~~interessante~~. Beim Vergleich der Nutzdaten mit dem Speicherstickinhalt-Datensatz sieht man die Übereinstimmung des Aufbaus. SUPER! Dann kann man sich die Emulation des Stick sparen und durch sniffen und einem Selektorscan nach '03 00' hat man das gleiche Ergebnis!		Der ''''03 00'''' ist der Interessante. Beim Vergleich der Nutzdaten mit dem Speicherstickinhalt-Datensatz sieht man die Übereinstimmung des Aufbaus. SUPER! Dann kann man sich die Emulation des Stick sparen und durch sniffen und einem Selektorscan nach '03 00' hat man das gleiche Ergebnis!
	Das einzige Problem ist das fehlende ChipSelect zu diesen Datenpaketen.		Das einzige Problem ist das fehlende ChipSelect zu diesen Datenpaketen.

Chris T. Ludwig: /* Motivation */

2021-09-18T08:40:08Z

Motivation

← Nächstältere Version		Version vom 18. September 2021, 10:40 Uhr
Zeile 5:		Zeile 5:
	Die Artikel sind für mich eine schöne Quelle (gewesen) meine Informationen und Daten abzugleichen und die Sicherheit zu haben, dass so wie ich mir das Ganze vorstelle, es scheinbar funktioniert.		Die Artikel sind für mich eine schöne Quelle (gewesen) meine Informationen und Daten abzugleichen und die Sicherheit zu haben, dass so wie ich mir das Ganze vorstelle, es scheinbar funktioniert.
	Was durchaus erstaunlich ist. Denn bereits zu Beginn habe ich bei der Analyse des Datensticks im Datenblatt des AT45DB081D die Taktfrequenz bis zu 66 MHz gelesen.		Was durchaus erstaunlich ist. Denn bereits zu Beginn habe ich bei der Analyse des Datensticks im Datenblatt des AT45DB081D die Taktfrequenz bis zu 66 MHz gelesen.
	Sollte die SunGo diese Rate ausnutzen ist eine Emulation des Datensticks doch schon recht aufwendig und alle Mikrocontroller und RasPis dieser Welt als reine Softwareemulatoren ~~außen~~ vor. Aber dazu weiter unten mehr.		Sollte die SunGo diese Rate ausnutzen, ist eine Emulation des Datensticks doch schon recht aufwendig und alle Mikrocontroller und RasPis dieser Welt als reine Softwareemulatoren auszen vor. Aber dazu weiter unten mehr.

	==Allgemeines==		==Allgemeines==

Chris T. Ludwig: /* Datastick Analyse */

2021-04-16T18:24:40Z

Datastick Analyse

← Nächstältere Version		Version vom 16. April 2021, 20:24 Uhr
Zeile 292:		Zeile 292:
	#Ausgang 5 1 Byte Prozent		#Ausgang 5 1 Byte Prozent
	#Ausgang 6 1 Byte Prozent		#Ausgang 6 1 Byte Prozent
	#Fehler 8 Byte ~~bis Speicher~~		#Fehler (0D) X Byte
	#Fehler		#Fehler (0D) X Byte
	#Speicher		#Fehler (0E) Y Byte X+X+Y = 8
	#Dummy 2 Byte 00 00		#Speicher (07)
	#Dummy 2 Byte 00 00		#Dummy (00) 2 Byte 00 00
			#Dummy (00) 2 Byte 00 00
	#Speicher (15) 2 Byte Little Endian uint16		#Speicher (15) 2 Byte Little Endian uint16
	#Dummy 2 Byte 00 00		#Dummy (00) 2 Byte 00 00
	#Dummy 2 Byte 00 00		#Dummy (00) 2 Byte 00 00
	#Funktion aktiv 2 Byte Little Endian uint16		#Funktion aktiv (11) 2 Byte Little Endian uint16
	#Funktion aktiv 2 Byte Little Endian uint16		#Funktion aktiv (12) 2 Byte Little Endian uint16
			AB Byte 60 gibt es keinen Hinweis mehr im Typ 0301
	#Volumenstrom 2 Byte Little Endian uint16		#Volumenstrom 2 Byte Little Endian uint16
	#Dummy 2 Byte 00 00		#Dummy 2 Byte 00 00
	#Dummy 2 Byte 00 00		#Dummy 2 Byte 00 00
			#(Checksumme ?) 2 Byte

	<div class="toccolours mw-collapsible mw-collapsed" style="width:1000px; overflow:auto;">		<div class="toccolours mw-collapsible mw-collapsed" style="width:1000px; overflow:auto;">

Chris T. Ludwig: /* Steuerung Analyse */

2021-04-11T06:25:45Z

Steuerung Analyse

← Nächstältere Version		Version vom 11. April 2021, 08:25 Uhr
Zeile 410:		Zeile 410:
	*Pause 88ms		*Pause 88ms

	1:kleines Paket (AB): 320us: AA 55 55 AA 02 00 (P970us) 1100us: 17AA (P67us) 1033us:16AA gesamt:3491us dann Abstand 46ms		DPA_1:"kleines" Paket (AB): 320us: AA 55 55 AA 02 00 (P970us) 1100us: 17AA (P67us) 1033us:16AA gesamt:3491us dann Abstand 46ms
	Pause: 50ms		Pause: 50ms
	2:großes Paket (CD) 320us: AA 55 55 AA 01 00 (P290us) 3787us: 64 Byte (10P=592us) gesamt:4387us
			DPA_2:"großes" Paket (CD) 320us: AA 55 55 AA 01 00 (P290us) 3787us: 64 Byte (10P=592us) gesamt:4387us

	Vor dem CS (Periodendauer: 1000ms) kommt immer noch ein weiteres Doppelpaket dazwischen		Vor dem CS (Periodendauer: 1000ms) kommt immer noch ein weiteres Doppelpaket dazwischen
	0s: DPA (+DPB+EEPROM-Abfrage in der 145,6ms Lücke)		*0s: DPA (+DPB+EEPROM-Abfrage in der 145,6ms Lücke)
	200ms: DPA		*200ms: DPA
	400ms: DPA		*400ms: DPA
	600ms: DPA		*600ms: DPA
	800ms: DPA		*800ms: DPA
	1000ms: next Cycle		*1000ms: next Cycle

Chris T. Ludwig: /* Verdeutlichung */

2021-04-11T05:15:36Z

Verdeutlichung

← Nächstältere Version		Version vom 11. April 2021, 07:15 Uhr
Zeile 879:		Zeile 879:

	[[Datei:Sungo Gesamtpakete Timing.png\|800px]]		[[Datei:Sungo Gesamtpakete Timing.png\|800px]]

			[[Datei:Sungo Gesamtpakete Tabelle.png\|500px]]

	===Emulator-Mode===		===Emulator-Mode===

Chris T. Ludwig: /* Verdeutlichung */

2021-04-11T05:09:47Z

Verdeutlichung

← Nächstältere Version		Version vom 11. April 2021, 07:09 Uhr
Zeile 877:		Zeile 877:

	Grob gesagt haben wir im Sekundentakt (bietet sich durch das EEPROM-CS an) insgesamt x Pakete einzulesen, in den Puffer zu schreiben und seriell auszugeben.		Grob gesagt haben wir im Sekundentakt (bietet sich durch das EEPROM-CS an) insgesamt x Pakete einzulesen, in den Puffer zu schreiben und seriell auszugeben.

			[[Datei:Sungo Gesamtpakete Timing.png\|800px]]

	===Emulator-Mode===		===Emulator-Mode===

Chris T. Ludwig: /* Sniffing-Mode */

2021-04-10T06:12:05Z

Sniffing-Mode

← Nächstältere Version		Version vom 10. April 2021, 08:12 Uhr
Zeile 867:		Zeile 867:
	*Endlosschleife		*Endlosschleife

	Das Warten auf die Lücke kann man sich vermutlich sogar ganz sparen. Da die Bytesequenz 'AA 55 55 AA' einen Datensatz ankündigt kann man man ein SPI-Dauerlesen einrichten und warten bis die Startsequenz "vorbeikommt" und alle nachfolgenden Bytes in den Puffer schreiben. Ein Lücke, die dann länger als 10 ms ist gibt den Trigger zur Verarbeitung. Sollten die 10 ms zur Verarbeitung nicht ausreichen könnte man den EEPROM-SS als Trigger nehmen. Wenn also EEPROM-SS kommt, SPI anhalten und die ~~Verabeitung~~ starten. Dann hätte man 88 ms zur Verarbeitung, das sollte für den ersten Versuch reichen.		Das Warten auf die Lücke kann man sich vermutlich sogar ganz sparen. Da die Bytesequenz 'AA 55 55 AA' einen Datensatz ankündigt kann man man ein SPI-Dauerlesen einrichten und warten bis die Startsequenz "vorbeikommt" und alle nachfolgenden Bytes in den Puffer schreiben. Ein Lücke, die dann länger als 10 ms ist gibt den Trigger zur Verarbeitung. Sollten die 10 ms zur Verarbeitung nicht ausreichen könnte man den EEPROM-SS als Trigger nehmen. Wenn also EEPROM-SS kommt, SPI anhalten und die Verarbeitung starten. Dann hätte man 88 ms zur Verarbeitung, das sollte für den ersten Versuch reichen.

			=====Verdeutlichung=====

			Der ATmega soll als Interface zwischen dem SPI-Port der SunGoSXL und einer seriellen Verbindung (auch über SER2USB-Adapter an USB) eines Auswerte-Systems (Raspi, PC, ...) dienen.
			Dazu sind im Wesentlichen 2 Programmroutinen notwendig. Eine Sniffer-Routine, die die SPI-Daten aufnimmt und in einem Puffer ablegt und eine zweite Routine die regelmäßig (Sekundentakt?) die Pufferdaten über die serielle Schnittstelle weiterreicht. Die Aufnahme und Abgabe sind leicht zu implementieren, das passende Timing ist eine Herausforderung. Da ich keine Lust habe, das ganze in Assembler zu schreiben, da hätte ich ja die volle Kontrolle über die Timer und Interruptabläufe, wollte ich doch bei C bleiben. Das Problem sei kurz geschildert. Sobald man mehr als eine Library benutzt hat man kaum noch eine Kontrolle über die Nutzung der Hardwareresourcen eines Mikrocontrollers. Vorausgesetzt, die Libraries sind sauber implementiert wird aber durch das harmonische Nebeneinander automatisch eine Programm-Overhead (oft über 80%) erzeugt, der Echtzeitanwendungen das Leben schwer macht. Ein Methode, die ich schon praktiziert habe ist, den Code per C zu erzeugen und dann den daraus gewonnen Assembler-Code zu bereinigen. Das erspart das mühsame Assembler from the scratch.

			Also was ist zu tun?

			Grob gesagt haben wir im Sekundentakt (bietet sich durch das EEPROM-CS an) insgesamt x Pakete einzulesen, in den Puffer zu schreiben und seriell auszugeben.

	===Emulator-Mode===		===Emulator-Mode===

Chris T. Ludwig: /* Steuerung Analyse */

2021-04-10T05:42:43Z

Steuerung Analyse

← Nächstältere Version		Version vom 10. April 2021, 07:42 Uhr
Zeile 414:		Zeile 414:
	2:großes Paket (CD) 320us: AA 55 55 AA 01 00 (P290us) 3787us: 64 Byte (10P=592us) gesamt:4387us		2:großes Paket (CD) 320us: AA 55 55 AA 01 00 (P290us) 3787us: 64 Byte (10P=592us) gesamt:4387us

	Vor dem CS (~~Periodedauer~~: 1000ms) kommt immer noch ein weiteres Doppelpaket dazwischen		Vor dem CS (Periodendauer: 1000ms) kommt immer noch ein weiteres Doppelpaket dazwischen
	0s: DPA (+DPB+EEPROM-Abfrage in der 145,6ms Lücke)		0s: DPA (+DPB+EEPROM-Abfrage in der 145,6ms Lücke)
	200ms: DPA		200ms: DPA

Chris T. Ludwig: /* Initialisierung Datenstick */

2021-04-10T05:22:13Z

Initialisierung Datenstick

← Nächstältere Version		Version vom 10. April 2021, 07:22 Uhr
Zeile 332:		Zeile 332:
	===Initialisierung Datenstick===		===Initialisierung Datenstick===

	Der Vorgang wird durch den entsprechenden Menüeintrag aufgerufen. In der Übersicht erkennt man, dass der Initialisierungsprozess ca. 16 Sekunden dauert. Die Unterbrechnung am Anfang bis ca. 8 Sekunden hat die Ursache in der Reaktion auf die Meldung, dass der Stick bereits eine Kennung besitzt und ob wirklich neu geschrieben werden soll.		Der Vorgang wird durch den entsprechenden Menüeintrag aufgerufen. In der Übersicht erkennt man, dass der Initialisierungsprozess ca. 16 Sekunden dauert. Die Unterbrechnung am Anfang bis ca. 8 Sekunden hat die Ursache in der (User-)Reaktion auf die Meldung, dass der Stick bereits eine Kennung besitzt und ob wirklich neu geschrieben werden soll.

	[[Datei:Screenshot SunGo Datastick Initialisierung Overview.png\|600px]]		[[Datei:Screenshot SunGo Datastick Initialisierung Overview.png\|600px]]

Chris T. Ludwig: /* Vorbemerkungen */

2021-04-10T05:15:21Z

Vorbemerkungen

← Nächstältere Version		Version vom 10. April 2021, 07:15 Uhr
Zeile 24:		Zeile 24:
	Es ist doch sehr erstaunlich, dass durch einen fehlenden Stick am Steckplatz der Steuerung und damit fehlender Parameter z.B. des Log-Intervalls, die Steuerung freiwillig trotzdem Daten an den Stick sendet. Die Analyse der Kommunikation der SunGo über den MiniDIN-Port kommt erst später, sobald die Daten des Datensticks interpretierbar sind.		Es ist doch sehr erstaunlich, dass durch einen fehlenden Stick am Steckplatz der Steuerung und damit fehlender Parameter z.B. des Log-Intervalls, die Steuerung freiwillig trotzdem Daten an den Stick sendet. Die Analyse der Kommunikation der SunGo über den MiniDIN-Port kommt erst später, sobald die Daten des Datensticks interpretierbar sind.

	Ergänzung nach fortgeschrittener Entwicklung: Meine weiter oben dargestellten Bedenken haben sich eigentlich in Luft aufgelöst. Der Datenstick ist in sofern ein Sackgasse, da es nicht notwendig ist die SungoSXL zu bewegen den Datenstick zu beschreiben, da (alle) die notwendigen Daten zweimal auf dem SPI anliegen. Ein mögliche Erklärung ist schnell gefunden. An dem nach außen geführten SPI hängt intern wenigstens ein weiterer Client, dessen #CS (leider) nicht nach außen geführt ist. Somit kann man am MOSI die Daten mitlauschen. Für die Datenaufbereitung ist allerdings die Analyse der Datenspeicherung auf dem Datastick von (entscheidender) Bedeutung. Den (außen) fehlenden ChipSelect habe ich virtuell durch eine Timingroutine erzeugt. Ich gebe zu, dass mit meiner ~~derzeiten~~ Lösung, die zwar funktioniert, eigentlich nicht glücklich bin. Kurz gesagt, ich würde die Daten lieber schön nach jedem Paket in der Datenlücke per seriellem Interface an den PC übertragen. Dumm ist halt nur, dass man die Lücke nicht richtig findet. Da muss ich mir noch was ausdenken, aber dazu unten mehr.		Ergänzung nach fortgeschrittener Entwicklung: Meine weiter oben dargestellten Bedenken haben sich eigentlich in Luft aufgelöst. Der Datenstick ist in sofern ein Sackgasse, da es nicht notwendig ist die SungoSXL zu bewegen den Datenstick zu beschreiben, da (alle) die notwendigen Daten zweimal auf dem SPI anliegen. Ein mögliche Erklärung ist schnell gefunden. An dem nach außen geführten SPI hängt intern wenigstens ein weiterer Client, dessen #CS (leider) nicht nach außen geführt ist. Somit kann man am MOSI die Daten mitlauschen. Für die Datenaufbereitung ist allerdings die Analyse der Datenspeicherung auf dem Datastick von (entscheidender) Bedeutung. Den (außen) fehlenden ChipSelect habe ich virtuell durch eine Timingroutine erzeugt. Ich gebe zu, dass ich mit meiner derzeitigen Lösung, die zwar funktioniert, eigentlich nicht glücklich bin. Kurz gesagt, ich würde die Daten lieber schön nach jedem Paket in der Datenlücke per seriellem Interface an den PC übertragen. Dumm ist halt nur, dass man die Lücke nicht richtig findet. Da muss ich mir noch was ausdenken, aber dazu unten mehr.

	==Datastick Analyse==		==Datastick Analyse==