Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Dirk]

Problem war dann aber auch gewesen, dass ich es mit der dem Bootloader beiligenden UART-Bibliothek noch nicht einmal geschafft habe, eine serielle Debug-Ausgabe zu bekommen. Hier habe ich bisher einfach aufgehört weiter nachzuforschen. Ich bin sicher dass es letztlich gehen würde.

Ich schau mir das bestimmt die Tage mal an. Das hat aber keine Priorität.
Vielleicht findet sich ja auch jemand der hier unterstützen möchte.

Baut man die Debug-Ausgaben ganz aus bekommt man den Bootloader auch noch kleiner ...was beim 328 eher noch das Problem sein könnte, dass der ja eh schon mit 32KByte FLash "klein ist" und man vll. die 4 KByte nicht hergeben mag.

Ich vermute auf <= 2kb werden wir das dadurch trotzdem nicht bekommen?

Der aktuelle Code vom Sensor ist 26.992 Bytes groß. Das sollte also auch in 28k rein passen.

Gruß
Dirk

[unimatrix]

helfe gerne mit ich hatte es nur wie gesagt zunächst liegenlassen.

Anbei die von mir angepasste Arduino.h (der 328p hat keinen PortA, ggf. liegt hier in meiner Anpassung schon der Fehler, die Portnummern machen mich wahnsinnig...), sowie das angepasste Makefile und das angepasste cc.h mit den neuen Portnummer. Alles andere hätte in der perfekten Welt eigentlich gleich bleiben können...

Ich habe es bisher NUR auf einem Panstamp getestet, da ich für meinen Arduino noch keine Funkmodule habe.

[Dirk]

Die Anpasungen hatte ich auch testweise schon gemacht. Sonst hat er für den Atmega328p nicht kompiliert. Mein Makefile ist aber etwas anders. Die Startadresse für den Bootloader bei 4k Bootsize sollte doch bei 0x7000 liegen?

Ich habe testweise auch mal alles Debugausgaben rauskommentiert. Da kommt man immer noch auf 3354 Bytes. Somit brauchen wir die 4k Bootloader.

Gruß
Dirk

[unimatrix]

7000 ist natürlich richtig. "Leider" gerade im Büro...komisch...das erklärt aber nicht warum bei mir nix ging. Hätte ja auch mit 6000 laufen müssen (also überhaupt laufen, UART ausgabe usw., auch wenn natürlich dann kein flashen ginge)

[Dirk]

Hallo zusammen,

mist, es hat mich einfach nicht losgelassen.
Aber ich kann den Sensor nun auch OTA flashen. 

Ich habe das Gitrepo von jabdoa2 mal auf die schnelle geforkt und hier die passenden Änderungen vorgenommen:
https://github.com/kc-GitHub/Asksin_OTA_Bootloader

Jetzt müsste man das Ganze nur noch etwas universeller bauen, dass man für verschiedene Setups nicht verschiedene Quellen braucht.

Was habe ich alles gemacht?

• Das Makefile an den Atmega328p angepasst. Incl. ein paar kleiner Erweiterungen wie Anzeige der Codegröße nach dem Kompilieren. Das kann aber noch schöner gemacht werden
• Die Portdefinitionen für den Atmega328p angepasst, und die Pins an dem die LED und das CC1101-Modul hängen
• Die Seriennummer im Bootloader angepaßt: (SEN0THPL02). Da die Seriennummer hier eh im Bootloader steht, würde ich dafür die Firmware des Sensors auch nochmal anpassen, dass dieses dann die Seriennummer vom Bootloader verwendet. Vielleicht werde ich  noch ein Flash-Tool bauen. Damit man den Bootloader flashen kann ohne den neu zu kompilieren und trotzdem eine eigene Seriennummer verwenden kann.
• Damit der Code in den 4k Bootloaderbereich des 328p passt, habe ich die Debuginfos etwas "verstümmelt". Man kann aber noch lesen was gemeint ist.
• Im covert.php habe ich für den Atmega328p die spm_pagesize auf 128 geändert. Hier muss man auch nochmal ran, um das Script universeller zu bauen.

Was mich etwas zur Verzweiflung gebracht hat: Wieso ist die hmid des Bootloaders fest auf AB:CD:EF eingestellt? Das hatte ich nämlich geändert und dann gemerkt das das so sein muss.

Gruß
Dirk

[micomat]

also wenn ihr mal soweit seid wäre ich gern bereit einen eurer Wunderkästen käuflich zu erwerben

[unimatrix]

Hi Dirk,

super dass du das durchgezogen hast. Ich gebe zu ich hatte beim letzten mal nicht den notwendigen Antrieb. Wenn man den CRC Check nutzen will muss man noch die CODE_LEN und den Parameter im sreg_cat anpassen.

Noch ein Vorschlag zur Diskussion: Der Bootloader kann ja auch in den BL-Code Bereich schreiben. Da er nicht ganz 4K ausfüllt, ist im Flash an der oberen Grenze Platz für die Seriennummer. Der Bootloader könnte bei seinem ersten Start auf eine Magic Number prüfen (crc) und wenn diese nicht stimmt generiert er zufällig eine Seriennummer, packt diese ans obere Ende des Flash-Speichers, generiert die CRC und fertig. Die Seriennummer wird beim Einschalten ja über BidCos gesendet, so dass man sie dann leicht herausfindet. Diese könnte außerdem auch von der Applikation genutzt werden. So könnte man sich viele Devices mit dem identischen Hex-File flashen und hätte trotzdem unterschiedliche Seriennummern. (ggf. auch HMID mit abdecken)

[frank]

das eq3 flashtool erwartet aber bereits zum starten die sn.

[unimatrix]

ja, das ist klar. Man müsste sich die SN zunächst aus dem FHEM Log raussuchen, mit richtigem Log Level sieht man sie anhand der Message.

[Dirk]

also wenn ihr mal soweit seid wäre ich gern bereit einen eurer Wunderkästen käuflich zu erwerben

Ich setze dich mit auf die Liste der Sammelbestellung. Da gibt es die nächsten Tage eine Info zum weiteren Ablauf.

Wenn man den CRC Check nutzen will muss man noch die CODE_LEN und den Parameter im sreg_cat anpassen.

Das hatte ich mir schon gedacht. Das schalte ich bestimmt noch mit ein.

Noch ein Vorschlag zur Diskussion: Der Bootloader kann ja auch in den BL-Code Bereich schreiben. Da er nicht ganz 4K ausfüllt, ist im Flash an der oberen Grenze Platz für die Seriennummer.

Ich würde die gerne die Adresse / Seriennummer beim initialen Flashen mit übergeben.
Auch um Code für die Zufallsbestimmung, Magic Number Prüfung usw. zu sparen.
Mit den 4k vom 328 sind wir schon ziemlich knapp.

Wenn man den Quellcode mit Linux übersetzt kann man übrigens auch noch ein paar Bytes gegenüber WinAVR sparen.

Gruß
Dirk

[frank]

ja, das ist klar. Man müsste sich die SN zunächst aus dem FHEM Log raussuchen, mit richtigem Log Level sieht man sie anhand der Message.

wenn aber nur der bootloader drauf ist, gibt es ja noch kein log/funk.

[PeMue]

Aber ich kann den Sensor nun auch OTA flashen. 

Hallo Dirk,

sprich der Atmega hat nicht nur eine serielle Schnittstelle, sondern die serielle Schnittstelle zum Flashen läuft über Funk (und muss dann von fhem entsprechend über CUL o.ä. bedient werden)?

Wenn das läuft, ist das ziemlich cool. Hut ab!

Gruß PeMue

[unimatrix]

wenn aber nur der bootloader drauf ist, gibt es ja noch kein log/funk.

Wenns kein Funk gibt, wie kann man dann über Funk flashen? ... nein aber im ernst. Das erste was der Bootloader macht, ist, folgende Message zu senden

Code Auswählen Erweitern


14 00 00 10 23 25 B7 00 00 00 00 SERIAL_NUMBER


Diese kann man mitloggen und dann kennt man die zufällig generierte Nummer. Es wäre nur eine Möglichkeit. Man könnte dieses Verhalten einbauen und trotzdem die Möglichkeit belassen, die Seriennummer manuell festzulegen (durch bearbeiten des .bin-Files). "Vergisst" man die Vergabe der SN, dann hat der BL zumindest nicht die Standard-Seriennummer (die sich unter umständen mit einem anderen Device "beisst" sondern eine zufällig generierte.

[Dirk]

sprich der Atmega hat nicht nur eine serielle Schnittstelle, sondern die serielle Schnittstelle zum Flashen läuft über Funk (und muss dann von fhem entsprechend über CUL o.ä. bedient werden)?

Ja.

Wenn das läuft, ist das ziemlich cool. Hut ab!

Der Dank gilt den Autoren des Bootloaders. Ich habe diesen nur an den Atmega328p angepasst.

@unimatrix
Wieso verwendet der Bootloader und flash-ota eine Statische Adresse (ABCDEF) um das Device im Bootloader-Mode anzusprechen?
Normalerweise hat jedes Device eine unique Adresse?

Gruß
Dirk

[frank]

Das erste was der Bootloader macht, ist, folgende Message zu senden

danke, alles klar. war mir nicht aufgefallen. ich kannte es sonst nur beim setzen des pairingmodus, wenn die fw schon läuft.