KONNEKTING 16CH Binäreingang (potentialfrei) für Reed-Kontakte

[Masifi]

Ich glaube nicht das es sinnvoll ist, daran mechanische Schalter anzuschließen. Diese Schalter prellen und ich habe auch gelesen, dass es besser ist, größere Spannungen damit zu "schalten". Ich habe hier nur 3,3V oder 5V.

Werde die Eingänge gepulst auslesen, d.h. das ich nur alle 300-500ms die Sensoren versorge, drei Messungen starte (und vergleiche) und dann die Versorgung direkt wieder wegnehme -> Lebenszeit der Reed-Kontakte.

und dann kommen wohl noch vier S0-Schnittstellen, die man über die Suite zuschalten kann.

[Masifi]

Werde auch etwas an mitarbeit erwarten, alle komplett fertig machen kann/will ich nicht. Sollten so art Bausätze werden

[heckmannju]

Ich glaube nicht das es sinnvoll ist, daran mechanische Schalter anzuschließen. Diese Schalter prellen und ich habe auch gelesen, dass es besser ist, größere Spannungen damit zu "schalten". Ich habe hier nur 3,3V oder 5V.

Werde die Eingänge gepulst auslesen, d.h. das ich nur alle 300-500ms die Sensoren versorge, drei Messungen starte (und vergleiche) und dann die Versorgung direkt wieder wegnehme -> Lebenszeit der Reed-Kontakte.

und dann kommen wohl noch vier S0-Schnittstellen, die man über die Suite zuschalten kann.

Das prellen bekommt man doch einfach mit der. Debouncer lib Weg. man muss halt mehrmals abFragen.

[srom]

Masifi hatte es auch eher als Baussatz verstanden

[tuxedo]

Zum prellen:

Ein klassischer Reed-Kontakt ist auch "mechanisch". Der kann auch prellen, wenn auch nicht unbedingt so ausgeprägt wie ein "handbetätigter Schalter".

Zum Speichern:

Egal wie man's anstellt: Man sollte nur dann Werte in den Speicher schreiben wenn's notwendig wird. Und das ist für diese Art der Applikation "beim Busspannugsausfall".
Der KNX Transceiver hat hierfür extra einen Ausgang mit dem er das signalisiert. Gepuffert mit einem Elko hat der Mikrocontroller eigentlich noch genug Zeit um auf dieses Signal zu reagieren und die Daten fest im Speicher abzulegen. Bis dahin kann man die Daten eigentlich im RAM halten.
So machen das andere KNX Geräte auch.

Der EEPROM im 328p und auch im 32u4 hat Minimum 100.000 Schreibzyklen. Wenn man damit richtig umgeht (speichern bei Busspannugsausfall), ist das eigentlich super ausreichend und hält ewig.
Der SAMD21 hat einen internen Flash-Speicher den man mittlerweile recht einfach nutzen kann. Hier gibt es Minimum 25.000 Schreibzyklen. Eigentlich auch ausreichend wenn man's richtig macht (wer hat schon mehr als 25.000 Stromausfälle am KNX Gerät während seiner gedachten Lebenszeit ...?!)

Somit braucht man den externen Monster-Speicher nur dann, wenn man das SAVE-Signal nicht angeschlossen hat, oder ignoriert, oder einfach zu faul ist es "richtig" zu machen ;-)


[update]
Die 100.000 Schreibzyklen ist das, was Atmel zu 100% garantiert. Und die rechnen viel reserven mit ein. In der Realität ist deutlich mehr drin. Die AVR Freaks haben's ausprobiert:
http://www.avrfreaks.net/forum/eepro...wtopic&t=85029

[Masifi]

Ein klassischer Reed-Kontakt ist auch "mechanisch". Der kann auch prellen, wenn auch nicht unbedingt so ausgeprägt wie ein "handbetätigter Schalter".

Deshalb mache ich ja drei Messungen und vergleiche die.

Die 100.000 Schreibzyklen ist das, was Atmel zu 100% garantiert.

Deshalb möchte ich ja ein FRAM verbauen, das kann 10hoch14 = 1.000.000.000.000 Schreibzyklen. Das wäre nicht das Problem.
Natürlich kann man es auch über das Save-Signal machen, habe ich mir bis jetzt noch nicht angeschaut. In der Controllerplatine ist es vorgesehen, daher alles kein Problem.
tuxedo hast du dir das mal angeschaut, gemessen wie lange man Zeit hat nachdem das Save-Signal ausgelöst wurde !?

[tuxedo]

Nein, gemessen hab ich das noch nicht. Steht noch auf meiner ellenlangen ToDo Liste.

Beim Siemens BCU steht leider auch nix direktes im Datenblatt: http://www.opternus.com/uploads/medi...2012-05-30.pdf
--> "Signalization of bus voltage break-down"

Aber so gesehen KANN da auch nix direktes drin stehen. Denn es ist ja Aufgabe der dahinterliegenden Anwendung mit dem Signal passend umzugehen. Und wenn man dafür 20sek braucht (reine übertreibung), dann muss man auch dafür sorgen, dass man solange noch Strom hat.

Wenn man "SAVE" aber an einen Interrupt hängt, dann "könnte" der Kondensator der Siemens BCU schon ausreichen um die Spannung lange genug zu puffern. Bei der Verwendung von NCN und Co. muss man halt schauen wie lange man Strom hat bevor die Spannung wegfällt und ggf. einen dicken Elko auf die Platine packen um die Zeit zu überbrücken.

Freiwillige Tester bitte vortreten ;-)

[heckmannju]

Das wegspeichern von einem Long geht ca 10 ms. Wenn man 16 davon wegspeichern muss 160 ms. Bei 32 sind es 320 ms. Wieviel zeit hat man den in diesem Bus Power breakedown. Und wie sieht es aus wen die externe Versorgungsspannung wegbricht? Ich finde die Hardware Lösung mit den nvram besser.

[tuxedo]

Wenn das Device nur über den Bus gespeist wird, dann hast du keine externe Spannungsversorgung.

S0 ist mit dem Teil eh ein wenig "ungeschickt"... Grund:

Schau mal wie lange die S0 Impulse sind. Wenn man Wikipedia glauben schenken darf 30-70ms.
Diese I2C Port-Extender haben zwar ein Interrupt-Signal, aber nur für _alle_ Ports auf einmal.
Tritt der Interrupt auf, so musst du alle Ports abfragen und mit einem vorherigen Wert vergleichen. Erst dann weißt du welcher Port seinen Zustand geändert hat.
Da ist das "Risiko" hoch, dass du hier und da einen Impuls übersiehst. Aber das Thema hatten wir ja schon: https://knx-user-forum.de/forum/proj...t-zu-schreiben

Die 10ms waren übrigens "geschätzt". Gemessen hab ich das nicht. Aber zurück zu den Interrupts:
Da du keine 16 Interrupts hast, sind 16 S0 Zähl-Kanäle pro Gerät "unrealistisch". Ergo hast du auch nicht 16x 4 Bytes die du speichern musst.

Und zu den 4 Bytes an sich: Bist du dir sicher dass es 4 Bytes sein müssen?

uint32 geht, wenn ich mich nicht irre bis 4294967295 ...

Wenn du jetzt einen Zäher hast der 2000Impulse pro kWh erzeugt, dann wären das bei uint32:

4294967295 / 2000ImpProKwh = 2147483,6475 kWh ... Also 2,1Mrd. kWh ... Bei einem sparsamen Verbrauch von, sagen wir 3500kWh/Jahr, würde die Zahlvariable sagenhafte 613 Jahre lang ausreichen. So lange behälst du den Zähler eh nicht ;-)

Also kannst du das zu speichernde Datenaufkommen weiter reduzieren.

Aber alles in allem: Einen S0 Zähler (schon gar keinen für 16 Zähler) würde ich damit nicht realisieren.

[heckmannju]

Das Problem ist Alex es gibt keinen 3byte datentyp und 16bit sind halt zuwenig. An meiner pv Anlage kommen pro Jahr 10kwh runter...Und zur leistungsberechnung hatte ich gerne noch mindestens 2 bis 3 mal pro s0 die zeit. Außerdem weise keiner wieveil mehr Strom so ein einprom brennen braucht. Deswegen finde ich die Idee mit dem nvram so gut.

Das mit dem Abtasten sollte auf jeden Fall mindestens alle 10 bis 15 ms Sekunden erfolgen sonst geht das nicht. Ich habe ohne konnekting bis jetzt 10 so Eingänge mit einem Uno hinbekommen. Die Daten schreibe ich allerdings auch seriell Weg mit 115200.

[Masifi]

S0 ist mit dem Teil eh ein wenig "ungeschickt"... Grund:

Du hast den Grund schön hergeleitet :-)
ABER, ich nutze für die S0-S3 nicht den I2C-Expander. Die S0-S3 Pins werden über einen Schalter(Luxus-Variante), den man über die Suite schalten kann, auf Int-Pins des SAMD(Timer-MODUL) gelegt und der sollte mit 30ms Signalen kein Problem haben.

Ich habe halt nur 4 S0 Schnittstellen eingeplant, weil ich denke, dass ist eine vernünftige Anzahl. Falls du mehr als 4 brauchst, kann ich dir eine Variante mit max 8 anbieten, aber das ist HW-Seitig das maximale was geht (Pin-Anzahl). Die SW dafür müsstest du aber auf dem SAMD selber anpassen.

[tuxedo]

heckmannju
Wozu brauchst du denn einen 3-byte Typ? Was hindert dich daran von den 4 byte uint32 einfach nur 3 byte in den EEPROM zu schreiben und beim rauslesen die 3 byte wieder in einen uint32 rein zu stecken?!

Außerdem weise keiner wieveil mehr Strom so ein einprom brennen braucht.

Ich kann leider nur erahnen was du damit meinst... Der EEPROM beim 32u4 ist "eingebaut". Den kannst du "strommäßig" auch nicht wegoptimieren.
Beim SAMD21 - wie hier in diesem Thread - hat einen eingebauten Flash-Speicher. Den kannst du auch nicht wegoptimieren oder abschalten. Der ist halt schon da...

Der NVRAM sitzt separat. Ich hab da noch keine Geschwindigkeitsmessung gemacht. Aber der Zugriff müsste theoretisch messbar langsamer sein als der interne Flash.

Kurzum: Wieso nicht verwenden was schon da ist?

Und hast du beim Uno auch mit I2C gearbeitet? Controller-eigene Pins lassen sich um längen schneller abfragen als über I2C.

@Masifi
Gut, ohne Port-Extender ist das natürlich möglich. Aber wie gesagt: 16x S0 über den PortExpander --> kostet zeit die man nicht unbedingt hat.

Alles in allem: Jedem das seine. Aber auf der einen Seite statt einem I2C PWM Controller zu nehmen alles mit dem SAMD (weil der das ja kann) erschlagen zu wollen (stichwort 9-ch dimmer), und auf der anderen Seite User-Daten unbedingt nicht im SAMD speichern (obwohl der das kann)... Da erschließt sich mir die Logik nicht unbedingt (naja, außer man ist spinnefeind mit dem SAVE Signal, weil elektrisch gesehen zu umständlich die Spannung zu überbrücken).

[Masifi]

Alles in allem: Jedem das seine. Aber auf der einen Seite statt einem I2C PWM Controller zu nehmen alles mit dem SAMD (weil der das ja kann) erschlagen zu wollen (stichwort 9-ch dimmer), und auf der anderen Seite User-Daten unbedingt nicht im SAMD speichern (obwohl der das kann)... Da erschließt sich mir die Logik nicht unbedingt (naja, außer man ist spinnefeind mit dem SAVE Signal, weil elektrisch gesehen zu umständlich die Spannung zu überbrücken).

das verstehe ich nicht !? was meinst du denn jetzt damit !?

[heckmannju]

Wenn das Device nur über den Bus gespeist wird, dann hast du keine externe Spannungsversorgung.

Auf dem ersten Bild sah ich eine 24v Klemme da dachte ich das man 24v braucht ist das so mastif?

[Masifi]

Auf dem ersten Bild sah ich eine 24v Klemme da dachte ich das man 24v braucht ist das so mastif?

ja in der ersten Version gab es die 24V noch als externe Versorgung. Für diesen 16Ch Binäreingang braucht man diese aber nicht mehr und daher wird das auch wieder rausfliegen.