Arduino Asksin library

Begonnen von trilu, 06 August 2013, 10:02:17

Vorheriges Thema - Nächstes Thema

justme1968

v1 wird ab anfang september wieder lieferbar sein. für v2 gibt es noch keinen termin. warten lohnt sich höchstens dann wenn die resourcen von v2 reichen würden. v2 ist eine neue 'cpu' eventuell ist am anfang noch das ein oder andere problem mit der die zu erwarten.

du brauchst eine möglichkeit die dinger zu flashen. der panstick ist die einfachste aber nicht die einzige möglichkeit.

die gehäuse sind hmmm keine schönheit. aber ok. wichtig: es gibt keine öffnung für die externe antenne.

statt dem original rgb board schau dir das hier an: Link.

was den batteriebetrieb mit dem aktuellen hm sketch angeht: wenn ich es richtig verfolgt habe ist noch nichts in richtung stromspaaren und schlaf modus implementiert. d.h. zumindest mit der aktuellen version wird die batterie recht schnell leer gelutscht sein.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

trilu

#151
Hallo Zusammen,

und wieder ein Stückchen weiter...
Pairing sollte jetzt komplett funktionieren.

<- 1A 00 84 00 3F A6 5C 00 00 00 0A 80 02 50 53 30 30 30 30 30 30 30 31 00 04 01 01(l:27)(2797)
-> 10 01 A0 01 63 19 63 3F A6 5C 00 05 00 00 00 00 00(l:17)(3149)
   start config mode; channel: 0, peerAdr: 00 00 00, peerCnl: 0, parmLst: 0
<- 0A 01 80 02 3F A6 5C 63 19 63 00(l:11)(3180)

-> 13 02 A0 01 63 19 63 3F A6 5C 00 08 02 01 0A 63 0B 19 0C 63(l:20)(3694)
   write data: 02 01 0A 63 0B 19 0C 63
   new PairID: 63 19 63
<- 0A 02 80 02 3F A6 5C 63 19 63 00(l:11)(3725)

-> 0B 03 A0 01 63 19 63 3F A6 5C 00 06(l:12)(3997)
   config end
<- 0A 03 80 02 3F A6 5C 63 19 63 00(l:11)(4018)


-> 10 04 A0 01 63 19 63 3F A6 5C 00 04 00 00 00 00 00(l:17)(20996)
   config param request; channel: 0, peerAdr: 00 00 00, peerCnl: 0, parmLst: 0
<- 1A 01 A0 10 3F A6 5C 63 19 63 02 00 00 01 00 00 00 00 00 00 00 63 19 63 00 00 00(l:27)(21043)
-> 0A 01 80 02 63 19 63 3F A6 5C 00(l:11)(21155)
   ACK (21157)

-> 10 05 A0 01 63 19 63 3F A6 5C 01 04 00 00 00 00 01(l:17)(22016)
   config param request; channel: 1, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 02 A0 10 3F A6 5C 63 19 63 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00(l:27)(22065)
-> 0A 02 80 02 63 19 63 3F A6 5C 00(l:11)(22177)
   ACK (22177)

-> 0B 06 A0 01 63 19 63 3F A6 5C 01 03(l:12)(22810)
   config peer list request; channel: 1
<- 0E 03 A0 10 3F A6 5C 63 19 63 01 00 00 00 00(l:15)(22837)
-> 0A 03 80 02 63 19 63 3F A6 5C 00(l:11)(22962)
   ACK (22962)

-> 10 07 A0 01 63 19 63 3F A6 5C 02 04 00 00 00 00 01(l:17)(23232)
   config param request; channel: 2, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 04 A0 10 3F A6 5C 63 19 63 02 00 00 00 00 00 01 04 00 8C 07 32 00 32 00 00 00(l:27)(23347)
-> 0A 04 80 02 63 19 63 3F A6 5C 00(l:11)(23459)
   ACK (23461)

-> 0B 08 A0 01 63 19 63 3F A6 5C 02 03(l:12)(23726)
   config peer list request; channel: 2
<- 0E 05 A0 10 3F A6 5C 63 19 63 01 00 00 00 00(l:15)(23834)
-> 0A 05 80 02 63 19 63 3F A6 5C 00(l:11)(23959)
   ACK (23959)

-> 10 09 A0 01 63 19 63 3F A6 5C 03 04 00 00 00 00 01(l:17)(24229)
   config param request; channel: 3, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 06 A0 10 3F A6 5C 63 19 63 02 00 00 00 00 00 01 00 00 00 00 32 00 32 00 00 00(l:27)(24348)
-> 0A 06 80 02 63 19 63 3F A6 5C 00(l:11)(24461)
   ACK (24463)

-> 0B 0A A0 01 63 19 63 3F A6 5C 03 03(l:12)(24727)
   config peer list request; channel: 3
<- 0E 07 A0 10 3F A6 5C 63 19 63 01 00 00 00 00(l:15)(24836)
-> 0A 07 80 02 63 19 63 3F A6 5C 00(l:11)(24961)
   ACK (24961)

-> 10 0B A0 01 63 19 63 3F A6 5C 04 04 00 00 00 00 01(l:17)(25231)
   config param request; channel: 4, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 08 A0 10 3F A6 5C 63 19 63 02 11 29 05 1D 00 38 00 05 60 00 08 05 1D 00 11 31(l:27)(25348)
-> 0A 08 80 02 63 19 63 3F A6 5C 00(l:11)(25460)
   ACK (25462)

-> 10 0B A0 01 63 19 63 3F A6 5C 04 04 00 00 00 00 01(l:17)(26454)
   config param request; channel: 4, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 09 A0 10 3F A6 5C 63 19 63 02 00 28 05 1D 00 2B 00 05 5F 00 00 05 1D 00 04 31(l:27)(26501)
-> 0A 09 80 02 63 19 63 3F A6 5C 00(l:11)(26615)
   ACK (26615)

-> 10 0B A0 01 63 19 63 3F A6 5C 04 04 00 00 00 00 01(l:17)(27602)
   config param request; channel: 4, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 0A A0 10 3F A6 5C 63 19 63 02 11 29 05 1D 00 1E 00 05 5F 00 42 05 1D 00 37 31(l:27)(27650)
-> 0A 0A 80 02 63 19 63 3F A6 5C 00(l:11)(27764)
   ACK (27764)

-> 10 0B A0 01 63 19 63 3F A6 5C 04 04 00 00 00 00 01(l:17)(28753)
   config param request; channel: 4, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 0B A0 10 3F A6 5C 63 19 63 02 11 29 05 1D 05 5F 00 13 05 1D 00 05 1D 00 2A 31(l:27)(28801)
-> 0A 0B 80 02 63 19 63 3F A6 5C 00(l:11)(28913)
   ACK (28915)

-> 10 0B A0 01 63 19 63 3F A6 5C 04 04 00 00 00 00 01(l:17)(29902)
   config param request; channel: 4, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 0C A0 10 3F A6 5C 63 19 63 02 11 29 05 1D 05 5F 00 05 60 00 1D 05 1D 00 1D 31(l:27)(29949)
-> 0A 0C 80 02 63 19 63 3F A6 5C 00(l:11)(30064)
   ACK (30064)

-> 0B 0C A0 01 63 19 63 3F A6 5C 04 03(l:12)(31047)
   config peer list request; channel: 4
<- 0E 0D A0 10 3F A6 5C 63 19 63 01 00 00 00 00(l:15)(31074)
-> 0A 0D 80 02 63 19 63 3F A6 5C 00(l:11)(31199)
   ACK (31199)


Ich bin mal auf deine Idee bzgl. der Register gespannt :-)

Die Arduino's haben nicht wirklich viel RAM. Um genau zu sein, hat der atmega 328 genau 2kb RAM.
So ein Array - uint8_t stor[1][1][1][255] - belegt also schon mal 255 bytes, das ganze für 4 Channel wäre 1KB.
Das wäre auch die max. Größe mit der meine Library derzeit noch läuft. Vielleicht kann ich da noch ein wenig
optimieren, aber viel geht bestimmt nicht mehr.

Vielleicht brauchen wir sowas, wie eine direkte EEprom Adressierung und dazu ein Bit-Array indem wir
beschriebene Adressen markieren.
Bei 512 Byte EEprom hätten wir dann eine Speichernutzung von 64 Byte. Damit hätten wir dann was im Speicher
um die beschriebenen EEprom Adressen zu finden und die eigentlichen Werte ziehen wir aus dem EEprom.

Zusätzlich gibts dann noch ein Array für die variablen Dinge, die als Statuswert geschickt werden müssen.

Viele Grüße

Horst


Dirk

Das klingt ja schon mal gut.
Ich würde die Register aber direkt ins EEprom schreiben und daraus lesen. Hierfür muss das nicht über eine RAM-Variable laufen.
Dann muss man auch nicht sicherstellen, dass die Variablen im Ram bei einem plötzlichem Spannungsausfall erst ins EEprom gesichert werden müssen.
Der Mega328 hat zwar nur 1KB EEprom, den RAM kann man dann aber für andere Sachen benutzen.
Und für mehr, dann wie gesagt ein externes EEprom.

Gruß
Dirk

martinp876

Hi,

bin im rückstand mit meiner Ankündigung.
für mich ist klar, dass die Daten direkt aus dem EEPROM gelesen werden müssen - sonst steigt der Overhead noch weiter.
Aber auch dort muss er komprimiert werden - und somit braucht es eine "access-struktur". Die wird bei der Kompilierung festgelegt und steht quasi im Code.
Ich gehe davon aus, dass man sich einen code je Anwendung compiliert und diesen dann auf den PS laden kann. Damit ist die Funktion festgelegt. Andere Funktion: anderen Code auf PS laden.

So jetzt hoffe ich auch einen sauberen Code zu liefern, der das hält, was ich verspreche.

Gruss Martin

trilu

mach dir mal keinen stress! ich brauch ja auch noch zeit um die anderen funktionen zu integrieren.
und dann auch noch um zu optimieren, ich lerne ja pausenlos beim coden dazu :-)))

martinp876

nun, jetzt habe ich wenigstens angefangen.
das Konzept für das erste Interface zum FHEM-register-schreiben/lesen nimmt formen an.

Zum 2. interface, register im code nutzen
- unterstützt der Compiler bitfields?
- wie lange ist ein pointer? 26bit?

Gruss Martin

trilu

#156
na, du fragst fragen :-)
soweit ich weiß sind pointer im avr compiler vom typ integer - also 16 bit
wenn du sowas meinst:
typedef struct {
  byte b1 : 1;
  byte b2 : 1;
  byte b3 : 1;
  byte b4 : 1;
  byte b5 : 1;
  byte b6 : 1;
  byte b7 : 1;
  byte b8 : 1;
} EightBitfield;

dann ja, das unterstützt der avr c compiler.

ich hab mal in den sketch ein weiteres blatt eingebaut, nennt sich register.h -
wäre klasse wenn wir dort die struktur des speichers abbilden können.

anbei ein neues update, habe noch einen fehler in der empfangsroutine entdeckt.
sollte jetzt stabiler sein und das aussetzen des empfangs nach einer längeren zeit sollte
der vergangenheit angehören...

viele grüße
trilu

betateilchen

irgendwie hab ich den Faden verloren :(
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

trilu

@betateilchen
faden wieder gefunden? :-)))

trilu

#159
und mal wieder ein kleines update.
die empfangsfunktion basiert jetzt komplett auf interrupt. das macht es in zukunft leichter die stromsparmodi zu verwenden.
ansonsten habe ich ein wenig aufgeräumt und viele der texte ins progmem geschickt. so das jetzt noch etwa 1k ram frei ist.

anfangs hatte ich öfter das problem das sich nach längeren standby zeiten das empfangsteil weg gehängt hat, das sollte jetzt auch behoben sein.

ich fahre jetzt am sonntag für eine woche in die türkei, d.h. in der zeit wird sich von meiner seite nicht viel tun.
nach meinem urlaub bastle ich weiter und implementiere weitere funktionen und befehle.
viele grüße
horst

betateilchen

schönen Urlaub :)

Vielleicht komme ich am Wochenende mal dazu, den Faden zu suchen und wiederzufinden. Und wenn Du dann zurück bist, fahre ich in Urlaub *g*
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

trilu

Das heisst du kommst aus Bayern oder hast keine Kinder :)

betateilchen

oder ich bin so alt, dass ich mich um Schulferien nicht mehr kümmern muss :)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

trilu

so urlaub beendet - jetzt kanns hier wieder etwas weiter gehen.
ich habe mir so meine gedanken gemacht wie man den speicher aufteilen könnte und habe dazu auch einige ideen. was mir fehlt ist die info was alles in List0 rein kommt.
mein verständnis war bisher das da nur 4 adressen drin stehen, also 02, 0A, 0B und 0C
jetzt habe ich bei einem dimmer gesehen, das es zwei weitere gibt 15 mit dem wert ff und 16 ebenfalls mit dem wert ff.
könnt ihr mal bitte bei euren HM geräten schauen was in List0 steht und hier posten. List0 mit geräteangabe...

mmatt

Meinst Du diese Angaben ?
Habe leider nur die beiden Geräte.

model HM-LC-Bl1PBU-FM
RegL_00:
02:01 0A:F1 0B:10 0C:34 15:FF 00:00
2013-09-10 07:07:55

model HM-LC-Dim1TPBU-FM
RegL_00:   
02:01 0A:F1 0B:10 0C:34 15:FF 16:FF 00:00
2013-04-18 08:52:35

Gruss Martin
- FHEM 5.5 auf RPI REV.2
- CUL V3 868MHz
- CUL_HM: HM-LC-Dim1TPBU-FM/HM-LC-Swl1PBU-FM/HM-LC-Sw1-BA-PCB/HB-UW-Sen-THPL-O/HM-SEN-MDIR-SM