Immer mal wieder denke ich mir, dass es keine schlechte Sache wäre, wenn man ein System aneinanderreihbarer, seriell auslesbarer Taster hätte. Dabei soll der Verkabelungs- und Programmieraufwand absolut minimal ausfallen, ähnlich den seriellen LEDs WS2812 u.ä. nur quasi umgekehrt. Aufbau: - auf Basis ATTiny 4MHz, Preis ca. 1,50€ - Verbindungen Plus, Ground, Data in, Data out - Taster verbindet weiteren Pin (Input-Mode mit "Soft"-Pullup) gegen Ground - beim letzten Tiny ist Data out auf Ground gelegt Protokoll ungefähr so, noch nicht völlig zuende gedacht: Initialisierung: a) Master-Controller sendet ein Byte "0" in den ersten Tiny "0" b) Tiny "0" registriert das als seine Adresse, erhöht den Wert um 1 und sendet das zum nächsten Tiny "1" c) Tiny "1" registriert das als seine Adresse, erhöht den Wert um 1 und sendet das zum nächsten Tiny "2" ... usw. Für "half duplex single wire soft serial" gibts fertige Projekte (Arduino). Falls der Tiny damit nicht klarkommt, kann man das ja nochmal neu andenken. Nutzung: Wenn an einem der Tinys der Taster gedrückt wird, sendet dieser seine Adresse an seinen Vorgänger, der das wiederum an seinen Vorgänger weiterreicht, irgendwann landet es beim Master. Ist der Tiny gerade selber mit einer Sendung beschäftigt, setzt er sein Data out auf high ("busy") und sein Kollege wartet solange. Die Bytes, die beim Master ankommen, repräsentieren damit die Nummer der gedrückten Taster. Man müsste mal genau durchrechnen, wie schnell sowas funktioneren könnte. Es sollte auch ein maßvolles Repetieren dauerhaft gedrückter Taster bzw. geschlossener Schalter möglich sein. Machbar? Oder gibts das schon?
Frank E. schrieb: > auf Basis ATTiny 4MHz, Preis ca. 1,50€ Eher auf Basis CH32V003, Preis ca. 20ct. Software ist aber RISCant.
Und wie willst du dem Master signalisieren, dass die Taste x losgelassen wurde?
:
Bearbeitet durch User
Helmut -. schrieb: > Und wie willst du dem Master signalisieren, dass die Taste > losgelassen > wurde? Indem der zughörige Tiny nicht mehr repetiert? Oder man legt fest, dass die Kette nur 127 Tinys umfassen darf. Dann signalisiert das erste Bit den Event (press = 1, release = 0)
:
Bearbeitet durch User
Frank E. schrieb: > Immer mal wieder denke ich mir, dass es keine schlechte Sache wäre, wenn > man ein System aneinanderreihbarer, seriell auslesbarer Taster hätte. Nunja, wenn man das Problem hat, eine große (variable) Anzahl von Tastern einzulesen, dann wäre das wohl ein vertretbarer Lösungsansatz. > - auf Basis ATTiny 4MHz, Preis ca. 1,50€ Finde den Fehler...
Frank E. schrieb: > - beim letzten Tiny ist Data out auf Ground gelegt Nicht wirklich eine gute Idee, einen Out auf Ground zu legen ;-)
Rainer W. schrieb: > Frank E. schrieb: >> - beim letzten Tiny ist Data out auf Ground gelegt > > Nicht wirklich eine gute Idee, einen Out auf Ground zu legen ;-) So für sich alleine ja. Ich meine aber, dass alle Pins immer inaktiv bzw. auf Input stehen und nur bei Bedarf jeweils kurz als Output aktiv werden.
Frank E. schrieb: > Machbar? Oder gibts das schon? KNX und schätzungsweise von jedem Befehlsgeräte-Hersteller, z.B.: https://www.eaton.com/de/de-de/catalog/industrial-control--drives--automation---sensors/SmartWire-DTintelligentwiringsystem.html https://de.wikipedia.org/wiki/AS-Interface Deine Idee hat allerdings den entscheidenden Vorteil, dass die Adressen gratis durch die Verdrahtung festgelegt sind. Bei Bus-System muss jeder Taster einzeln konfiguriert werden. Und es ist ohne Mehraufwand ein echtes kollisionsfreies Multi-Master System. Etwas robuster würde das, wenn du pro Element 2 RX und 2 TX spendierst. Dann wären Ausgänge immer Ausgang und Eingänge immer Eingang. Die Datenrichtung vom Master-Controller zu den Taster braucht man nicht nur zur Adress-Konfiguration. Man möchte ja auch Leuchttaster oder einzelne LEDs ansteuern. Außerdem braucht man sie zur Fehlersuche. Ein Kurzschluss auf einem Bus mit 100 Elementen kann leicht zum Albtraum werden. Hier gibt es auch das halb (wegen VCC+GND) geschenkt. Die Ausdehnung ist eher durch die Stromversorgung begrenzt als durch zu wenig Adress-Bits. Mit UARTs würde man 2 Byte senden, wobei das MSB die beiden Bytes unterscheidet. Aber ohne Quarz ist UART grenzwertig, man braucht eher eine Kodierung mit Taktrückgewinnung. Dann kann man genauso gut 17 Bit Worte senden.
Hm ... ich habe weiter recherchiert und ich glaube, es gibt da auch was Fertiges: DS2413. Es ist ein Onewire-Chip mit zwei GPIO, die als Input oder Output konfiguriert werden können. Als Breakout kostet eine um die 6,-, der nackte Chip ca. 3,-
:
Bearbeitet durch User
Ich werfe den mal in den Raum 24AA02UID-I/P-ND
ist eine USB-Tastatur nicht schon Seriell? oder die mit PS2 von früher? Es gibt auch als nur Num-Blocks, wenn es kleiner werden soll.
Andreas K. schrieb: > ist eine USB-Tastatur nicht schon Seriell? oder die mit PS2 von > früher? > Es gibt auch als nur Num-Blocks, wenn es kleiner werden soll. Es geht darum, Tasten räumlich zu verteilen und seriell auszulesen, um Kabelei einzusparen.
:
Bearbeitet durch User
Wenn Du pro Taste einen µC mit UART spendierst, kannst Du das ganze im selbstorganisierenden "daisy-chain"-Verfahren machen. Der Tx-Ausgang wird mit dem Rx-Eingang des nachfolgenden µC verbunden. Wenn weniger als 256 Taster verwendet werden, ist das ganze mit einem sehr primitiven Protokoll umsetzbar: Der einen Tastendruck erkennende µC sendet ein Byte mit dem Wert 1 an den nächsten µC. Jeder µC, der ein Byte empfängt, addiert 1 auf dessen Wert und sendet diesen an den nächsten µC. Am Ende der Kette kommt ein Byte an, das der Position des gedrückten Tasters in der Kette entspricht. Möchte man sowohl das Drücken als auch das Loslassen von Tastern übertragen, reduziert sich bei diesem Simpelverfahren die Anzahl der Tasten auf 128: Der einen Tastendruck erkennende µC sendet eine 1 an den nächsten µC, beim Loslassen sendet der µC hingegen 0x80 (128) an den nächsten µC. Auf empfangene Bytes wird wie gehabt vor dem Weiterreichen 1 addiert. Möchte man ein "Autorepeat-Feature" haben, bleibt es bei diesem Verfahren; der "wiederholende" µC sendet zyklisch seine "Taste-Gedrückt"-1 in die Kette; hier muss nur eine sinnvolle Wiederholrate festgelegt werden. Dieses Primitivverfahren setzt nur voraus, daß die UARTs der beteiligten µCs eine ausreichend genaue Taktquelle haben, damit es in der Übertragungskette zu keinen Fehlern kommt. Man kann natürlich auch ein komplexeres Protokoll als einzelne Bytes verwenden, dann entfällt die Mengenbeschränkung. Zur Verdrahtung werden drei Leitungen benötigt: Versorgungsspannung, Masse und eine Datenleitung.
Harald K. schrieb: > Wenn Du pro Taste einen µC mit UART spendierst, kannst Du das > ganze im > selbstorganisierenden "daisy-chain"-Verfahren machen. > Ok, deine Idee ist bestechend, weil a) die Initialisierung unnötig ist b) Datenleitungen RX/TX nicht in ihrer Funktion umgeschaltet werden müssen c) es genügt eine Soft-Serial mit RX und TX Etwas hakelig wird es evtl. mit der SoftSerial auf dem Tiny beim gleichzeitigen Eintreffen (RX) einer externen Sendung, wenn der MC gerade selber sendet (TX). Beim Takt sehe ich bei nicht allzu hohen Baudraten (MC nutzt aus Kostengründen nur den eingebauten RC-Oszillator) bis 9600 und nur einem Byte auch keine Probleme. Die Latenz bei 100 Tasten sollte (grob geschätzt) unter 0,5s bleiben.
Frank E. schrieb: > c) es genügt eine Soft-Serial mit RX und TX > > Etwas hakelig wird es evtl. mit der SoftSerial auf dem Tiny beim > gleichzeitigen Eintreffen (RX) einer externen Sendung, wenn der MC > gerade selber sendet (TX). Wieso SoftSerial? Es gibt genügend Controller mit Hardware UART. Beispielsweise PIC16F15213 für 36 Cent ab 25 Stück bei Digikey. Sollte alles haben, was Du brauchst. https://www.digikey.de/de/products/detail/microchip-technology/PIC16F15213-I-SN/12807336 Wenn es unbedingt AVR sein muss: Tiny 202 für 43 Cent. https://www.digikey.de/de/products/detail/microchip-technology/ATTINY202-SSNR/9554944 fchk
Frank E. schrieb: > Etwas hakelig wird es evtl. mit der SoftSerial auf dem Tiny beim > gleichzeitigen Eintreffen (RX) einer externen Sendung, wenn der MC > gerade selber sendet (TX). Wenn der µC eine SPI-Schnittstelle hat, könnte man die als sendende UART missbrauchen. Man muss es nur hinbekommen, zwei Bytes ohne Unterbrechung zu senden, im ersten Byte ist neben dem Startbit der Anfang des Nutzdatenbytes, im zweiten Byte ist der Rest des Nutzdatenbytes, ein etwaigee Parity-Bit und ein oder zwei Stopbits unterzubringen, der Rest wird mit 1 aufgefüllt und entspricht somit dem Ruhezustand auf der Leitung. Das dürfte die Last für eine empfangende Soft-UART reduzieren.
Ich würde bei Neuentwicklungen berücksichtigen, daß AVR in den vergangenen 10-20 Jahren (verglichen mit anderen) besonders teuer geworden sind, währen einige andere sogar billiger wurden.
Frank E. schrieb: > Machbar? Oder gibts das schon? Wie schnell soll das alles gehen? Was Anzahl Tasten? Leitungslängen? Umgebung? Davon hängt alles andere ab.
:
Bearbeitet durch User
Ich denke die adressierbaren LED Streifen leben hauptsächlich davon, dass es einen Anwendungsfall für einen Haufen von LEDs in einer Reihe gibt. Bei Tastern ist das deutlich weniger sinnvoll und wenn man ohnehin ein eigenes PCB (oder Kabel) für seine Taster benötigt ist die Matrix sehr einfach umzusetzen und günstiger.
Monk schrieb: > Ich würde bei Neuentwicklungen berücksichtigen, daß AVR in den > vergangenen 10-20 Jahren (verglichen mit anderen) besonders teuer > geworden sind, währen einige andere sogar billiger wurden. Nunja, die "klassischen" AVR8 sind wirklich ziemlich teuer geworden. Aber die modernen sind dann doch wieder einigermaßen günstig und in technischer Hinsicht deutlich besser als die Klassiker. Z.B.: (Mouser-Preise Einzelstück): Klassiker ATMEGA1284P-AUR : 6,65€ Modern AVR128DB48T-I/PT: 2,16€ Die sind vom Package, der Pinzahl und vom Speicher her in etwa gleich, der Moderne hat aber mehr Takt, einen effizienteren Befehlssatz, modernere und deutlich umfangreicherere Peripherie und einen größeren Betriebsspannungsbereich.
Ob S. schrieb: > Aber die modernen sind dann doch wieder einigermaßen günstig und in > technischer Hinsicht deutlich besser als die Klassiker. Ja, nur leider gibt es dazu weniger Doku auf Anfänger-Niveau. Deswegen habe ich sie nicht empfohlen.
Monk schrieb: > Ja, nur leider gibt es dazu weniger Doku auf Anfänger-Niveau. Irgendwann sollte jeder anfangen, Datenblätter zu lesen. Auf Dauer kommt man sowieso nicht drum herum. Schon wegen der bestmöglichen Anpassung auf die umgebende Hardware (oder auch andersrum). Und die Datenblätter der neueren AVR8 sind zwar nicht mehr ganz so schön übersichtlich wie die der Klassiker, aber immerhin auch noch im Wesentlichen vollständig. Nicht wie z.B. bei STM, wo man erstmal mindestens zwei, oft sogar drei bis sechs Dokumente zusammensuchen muss. Und dann vor insgesamt bis an die 10.000 Seiten Doku sitzt. Oder wie beim anderen Extrem Espressif, wo es nichtmal für Geld überhaupt eine vollständige Doku gibt.
Ob S. schrieb: > Und die Datenblätter der neueren AVR8 sind zwar nicht mehr ganz so schön > übersichtlich wie die der Klassiker, aber immerhin auch noch im > Wesentlichen vollständig. > Nicht wie z.B. bei STM Das stimmt wohl (beides)
Wie sähe denn so ein Code aus, zb für einen Attiny. Könnte ich gut für meine Modelleisenbahn verwenden.
LPC811,LPC812,LPC824 haben HW-UART und vor allem einen abgeglichenen internen 12MHz-Oszillator mit max. 1.5% über den gesamten Temperaturbereich. Man kann direkt UART betreiben ohne ext. Taktgeber. Kosten so 80ct @ >100Stk. Andererseits muss man sowieso mindestens 1..2 Kondensatoren bestücken, dann kann man auch gleich noch einen 3225 Quarz spendieren, gibt es für 5ct. (LCSC C70565) Edit: sehe gerade, der PIC16F15213, der von Frank vorgeschlagen wurde, hat auch nen kalibrierten Taktgeber. Dazu noch classic 5V. Dann wäre das mein Favorit.
:
Bearbeitet durch User
Für eine ähnliche anwendung habe ich überlegt, PMS150 als daisy-chained I/O zu benutzen. die notwendigkeit, jeden davon einzeln zu flashen hat mich davon abgehalten. Wenn man eine software baut, die den Chip als generischen frei konfigurierbaren billigst- OneWire/DaisyChain I/O mit UID nutzbar macht, könnte man sicher ein paar Rollen davon fertig geflasht vom hersteller bestellen. Ähnlich des Arduino Firmata beispiels. Könnte ich immer mal wieder gebrauchen, bus ähnlich wie WS2812, jeder pin konfigurierbar als PWM, Input, Output, Interrupt oder Touch-Input. Sleep-Mode wenn nichts auf dem Bus los ist.
Ich sehe bei den ganzen Varianten keine "Kabelersparnis". Und im etwaigen Fehlerfall hat man u.U. einen Totalverlust. "Overengineered Crap" wuerde man wohl dazu sagen. Ich habe mal einem E-Piano einen Midi-Out nachgeruestet. Weil es eine so schoene gewichtete Tastenmechanik hat. Dafuer waren 64 x 2 Tasten/Hallsensoren abzufragen. Der Gewinner war immer noch das simple Schieberegister. ;)
Flip B. schrieb: > Für eine ähnliche anwendung habe ich überlegt, PMS150 als daisy-chained > I/O zu benutzen. die notwendigkeit, jeden davon einzeln zu flashen hat > mich davon abgehalten. Flashen muss und kann natürlich auch im fertig aufgebauten Zustand und ohne extra Stecker funktionieren. Der STM32L031 z.B. startet immer erst den eingebauten Bootloader und wenn das Flash leer ist, kann man sofort per UART flashen. Die Umschaltung Bootloader / Programm könnte auch mit einer Fuse funktionieren; muss man mal suchen.
Bauform B. schrieb: > Flashen muss und kann natürlich auch im fertig aufgebauten Zustand und > ohne extra Stecker funktionieren. Danke für den Tipp. Ich glaube es sollte auch mit dem PY32F002A ( ca 8ct. ) funktionieren. Beim PMS150 braucht es mindestens CLK und SDA, das sind schon zu viele drähte. Bei Werkseitig eingebautem USART- Bootloader könnte man im Dasiy-Chain-Setup "Blind" flashen, also nur über TX, und dann flashen des zweiten evice über das erste etc.
Motopick schrieb: > Ich sehe bei den ganzen Varianten keine "Kabelersparnis". Das kann durchaus sein. > Und im etwaigen Fehlerfall hat man u.U. einen Totalverlust. Na ja, man sieht ja, bis wo es noch geht (im Falle UART) > "Overengineered Crap" wuerde man wohl dazu sagen. So drastisch würde ich es nicht ausdrücken. Als theoretische Überlegung und/oder praktische Fingerübung ist es auf jeden Fall interessant. Ob es tatsächlich so einen Verbreitungsgrad wie die "intelligenten" LEDs finden wird darf bezweifelt werden.
Moin, vielleicht kann man einen z.B. ATtiny 4313 über I2C ansprechen. Der hätte dann bis zu 15 Ein- oder Ausgänge, um eine Matrix zu bedienen und bräuchte für die Anbindung an den Master nur 2 Adern. Über die gleiche Anbindung lassen sich weitere Slave ansprechen. Opfert man eine 3. Ader für Interrupt, erspart man sich das Pollen. So etwas nutze ich für meinen Dimmer. Das läuft sehr stabil. Gruß Carsten
Carsten-Peter C. schrieb: > Moin, > vielleicht kann man einen z.B. ATtiny 4313 über I2C ansprechen. Wo siehst Du den Vorteil ggü. einem normalen IO Portexpander wie dem MCP23017?
Moin, das kommt darauf an, was man will. Sollen nur 16 Eingänge abgefragt werden oder eine Matrix? Braucht man eine Entprellung? Soll es Bedingungen geben, wie „frage einige Tasten nur zu bestimmten Zeiten ab“ oder nur bei langem Drücken? Soll etwas geloggt werden? Das müsste dann der Master regeln. Ist der Master immer eingeschaltet? Reichen die 3 zusätzlichen Adressen des Portexpanders? Sollen kurz aufeinander folgende Impulse gezählt werden? Der ATtiny ist sicherlich eine Alternative. Was sinnvoll ist, muss jeder selbst entscheiden. Gruß Carsten
Carsten-Peter C. schrieb: > vielleicht kann man einen z.B. ATtiny 4313 über I2C ansprechen. Der > hätte dann bis zu 15 Ein- oder Ausgänge, um eine Matrix zu bedienen und > bräuchte für die Anbindung an den Master nur 2 Adern. Über die gleiche > Anbindung lassen sich weitere Slave ansprechen. Da muss man sich aber um die Adressierung Gedanken machen. Eine Matrixanordnung ist sinnvoll, wenn die Taster alle relativ geballt auftreten; wenn man aber (aus welchen Gründen auch immer) z.B. Lichttaster in einem Haushalt in ein Bussystem überführen möchte, dann ist eine Matrix kaum praktikabel. Dann allerdings muss natürlich schaltungstechnisch mehr Aufwand getrieben werden, als einfach nur direkt Rx und Tx zweier µC über ein lange Leitung miteinander zu verbinden, irgendeine Art von Pegelwandler o.ä. ist da zur Störungsunterdrückung definitiv angesagt. Hier könnte man z.B. RS485/RS422-Pegelwandler einsetzen, dann sind zwar vier statt drei Adern nötig, aber da Kabel mit geraden Aderzahlen nicht völlig unbekannt sind, sollte auch das kein Problem darstellen. In erster Linie wollte ich mit meinem Beitrag das Grundkonzept des "Daisy-Chain"-Verfahrens zur selbstorganisierenden Adressierung demonstrieren. Ob herkömmliches Bussystem oder "Daisy-Chain", man will ja die verschiedenen Geräte auseinanderhalten können. Beim herkömmlichen Bussystem muss jedes Gerät eine individuelle Adresse erhalten, die man entweder per Software oder Schaltern festlegen muss. Das "Daisy-Chain"-Verfahren bietet den Vorteil, daß alle Geräte mit exakt derselben Software arbeiten können und keine Individualisierung erforderlich ist, da sich die Adresse durch die Position in der Kette ergibt. Nachteile des Verfahrens sind natürlich eine gewisse Trägheit bei vielen Geräten, die Störanfälligkeit (fällt ein Gerät in der Kette aus, sind alle Geräte dahinter nicht erreichbar) und die nötige Neuorganisation bei Änderungen der Kette. Die Kette durch Anhängen zu verlängern, ist kein Problem, aber zwischendrin neue Geräte einfügen bringt alles durcheinander.
Harald K. schrieb: > Da muss man sich aber um die Adressierung Gedanken machen. Bei meinem Treiber sind die Adressen frei wählbar. Es können also über 120 Slave’s adressiert werden. Der gesamte RAM- Bereich kann ausgelesen werden. Als erstes Byte nutze ich gerne ein „Status Byte“, das mir Auskunft gibt, ob und was gerade läuft. Du hast Recht, wenn die Taster ungünstig liegen, sind andere Schaltungen sicher besser. Gruß Carsten
Harald K. schrieb: > Nachteile des Verfahrens sind natürlich eine gewisse Trägheit bei vielen > Geräten, die Störanfälligkeit (fällt ein Gerät in der Kette aus, sind > alle Geräte dahinter nicht erreichbar) und die nötige Neuorganisation > bei Änderungen der Kette. Die Kette durch Anhängen zu verlängern, ist > kein Problem, aber zwischendrin neue Geräte einfügen bringt alles > durcheinander. Dazu möchte ich ein paar dinge hinzufügen: Trägheit: Durchlaufzeit durch den einzelnen Kettenteilnehmer kann auf ein Bruchteil einer Bitzeit reduziert werden, es muss nicht eine ganze Nachrichtenlänge abgewartet werden. Die Latenz in den Knoten kann so gegen 0 gehen, dann ist nur noch die Datenmenge relevant, bei der wie in jedem Bussystem sich die Buslast ergibt. Lediglich priorisierung a la CSMA wie bei CAN würde zusätzliche software erfordern. Bei kleinen Datenmengen oder wenn die Teilnehmer nur einige Bits im Datenpaket hinzufügen oder Modifizieren, ist der Durchsatz erheblich höher als an einem üblichen Bussystem im Polling-mode. Kollisionen gibt es prinzipbedingt bei der Punkt-zu punkt verdrahtung keine. Stau gibt es nur vor einem ggf langsameren Teilnehmer. Störanfälligkeit: Bei Paralellen Bussystemen kann ein ausfall eines Teilnehmers im Kurzschluss zum kompletten Busausfall führen. Daher sind die meisten Bustransceiver zumindest bei fehlender spannungsversorgung hochohmig. Im Ring-Bus müsste ein Transceiver im fehlerfall vorzugsweise durchleiten. Beim Ringförmigen Bus mit I/O pins kann der Bus Bidirektional funktionieren, so dass ein einzelner Ausfall sich nicht auf die Funktion auswirkt und sogar lokalisiert werden kann, ähnlich wie Ringleitungen in Wasser- und Energienetzen. Auch verdrahtungsfehler können dem Nutzer bequem angezeigt werden. Die Organisation ist vorteilhaft, will man chaos vorbeugen, so bekommt jeder Busteilnehmer ab werk eine UID (equ. MAC-Adresse), die häufig schon im µC vorhanden ist. Damit kann auch bei neuverdrahtung die Position der Busteilnehmer nachvollzogen werden.
:
Bearbeitet durch User
Carsten-Peter C. schrieb: > Bei meinem Treiber sind die Adressen frei wählbar. Ja, aber Du wirst sie irgendwie einstellen müssen. Einfach eine Handvoll Geräte mit der gleichen Firmware flashen, zusammenstöpseln und nutzen geht halt nicht. Wenn der µC eine vom Hersteller vorgesehene Seriennummer hat, kann man natürlich die verwenden und ein Verfahren à la MBus* verwenden, um die Geräte über den Bus zu finden und ihnen dann per Protokoll eindeutige Adressen zuzuweisen, aber das ist halt auch mehr Aufwand. > Es können also über 120 Slave’s adressiert werden. Bitte: Kein Apostroph-s für den Plural. Augenkrebs. *) MBus verwendet u.a. achtstellige BCD-Adressen, die mit einem Wildcardverfahren adressiert werden können. Als Wildcardzeichen dient F, was in einer BCD-Zahl nicht vorkommen kann. Die Geräte antworten auf eine Identifikationsanfrage im wesentlichen mit ihrer Adresse. Wird z.B. die Adresse 0******* angesprochen, antworten alle Geräte, deren Adresse mit 0 beginnt. Gibt es kein Gerät, so läuft ein Timeout ab, und es wird mit der nächsten Adresse (1*******) weitergemacht. Gibt es genau ein Gerät, ist das empfangene Telegramm formell in Ordnung. Gibt es mehrere Geräte, ergibt das eine Buskollision, die man am zerstörten Datenpaket, ungültiger Prüfsumme und gegebenenfalls auch UART-Fehlern wie Parity- oder Framingfehler erkennen kann. Im Falle einer Kollision wird die Wildcardadresse verfeinert, im folgenden Schritt wird die Adresse 00****** angesprochen und das Spiel wiederholt sich, solange, bis es keine Kollisionen mehr gibt. Auf diese Art und Weise lässt sich relativ schnell eine Liste aller achstelligen Adressen erstellen, das Verfahren ist erheblich schneller als jede der einhundert Millionen möglichen Adressen nacheinander auszuprobieren ... Um das ganze zu beschleunigen, bietet MBus noch eine zweite Adressierung mit nur einem Byte als Adresse; über die ausführlichen Adressen kann ein Gerät angesprochen und eine ein-Byte-Adresse eingestellt werden, die fortan zur Adressierung verwendet wird. Die Ein-Byte-Adressen werden in der MBus-Terminologie als "Primäradressen" und die achstelligen BCD-Adressen als "Sekundäradressen" oder auch "Id" bezeichnet. Man muss allerdings noch eine Möglichkeit haben, die Geräte identifizieren zu können, bei MBus-Zählern, die oft von verschiedenen Herstellern kommen, ist das an der Herstellerkennzeichnung (die auch im Identifikationstelegramm übertragen wird) oder auch dem Medium (Strom, Wasser etc.) oder gegebenenfalls dem individuellen Zählerstand möglich (den man am Gerät auf dem Display sehen kann). Bei einer Selbstbaulösung sind natürlich alle Geräte gleich, da braucht es etwas anderes, um sie individualisieren zu können.
Harald K. schrieb: > zweier µC über ein > lange Leitung miteinander zu verbinden Da würde ich definitiv einen ansatz wie KNX empfehlen. Ein lokaler 2-draht-bus mit Phantomspeisung und einfachsten Transceivern mit Logik-pegeln hätte schon was praktisches. Das würde die Leiterzahl zwischen Tastern von 3 auf 2 Reduzieren, und erlaubt ggf auch Baum/Sterntopologie
:
Bearbeitet durch User
Flip B. schrieb: > Dazu möchte ich ein paar dinge hinzufügen: > Trägheit: Durchlaufzeit durch den einzelnen Kettenteilnehmer kann auf > ein Bruchteil einer Bitzeit reduziert werden, es muss nicht eine ganze > Nachrichtenlänge abgewartet werden. Wenn das angedachte Protkoll mit increment des empfangenen Wertes realisiert werden soll, ist diese kurze Durchlaufzeit nicht realisiserbar.
Harald K. schrieb: > Ja, aber Du wirst sie irgendwie einstellen müssen. Einfach eine Handvoll > Geräte mit der gleichen Firmware flashen, zusammenstöpseln und nutzen > geht halt nicht. Genau das mache ich. Es funktioniert gut. .equ MySlaveAddress = 0xAE ;I2C Adresse Nur die Adressen müssen angepasst werden.
Harald A. schrieb: > Motopick schrieb: >> Ich sehe bei den ganzen Varianten keine "Kabelersparnis". > Das kann durchaus sein. Das koennte man einfach nachzaehlen. :) >> Und im etwaigen Fehlerfall hat man u.U. einen Totalverlust. > Na ja, man sieht ja, bis wo es noch geht (im Falle UART) Na ja, ich glaube schon in 10 Jahren, koennte man so einen (pseudo-)intelligenten Taster nicht mehr so einfach durch einen einfachen Bauteiltausch wieder funktionsfaehig machen. Weil ihm halt seine Firmware fehlt... Die von mir verwendeten Schieberegister, kann ich ohne grosse Muehe ersetzen. Und wie weit ein Signal kommt, mit einem einfachen Logikpruefstift feststellen. >> "Overengineered Crap" wuerde man wohl dazu sagen. > So drastisch würde ich es nicht ausdrücken. Als theoretische Überlegung > und/oder praktische Fingerübung ist es auf jeden Fall interessant. Ob es > tatsächlich so einen Verbreitungsgrad wie die "intelligenten" LEDs > finden wird darf bezweifelt werden. Aehnliches findet sich oft in Geraeten z.B. als Stromversorgung fuers Energiesparen im Standby. Ein SNT uebernimmt diese zentral wichtige Funktion. Funktioniert es nicht mehr, kann man das Geraet nicht mehr einschalten. Und was geht als erstes in diesen Geraeten kaputt? Es ist genau diese Standbystromversorgung. Gluecklicherweise haben findige Techniker aber entdeckt, dass mit einem einfachen Widerstand diese Spannung aus der Stromversorgung des Geraetes gezogen werden kann. Was das Standbynetzteil ueberfluessig macht, und das Geraet wieder funktioniert. Mochtest du ein Geraet wegwerfen muessen, weil ein Vollpfosten meinte, den Einschalter "serialisieren" zu muessen? Mein Midi-Out habe ich vor knapp 30 Jahren in das Piano versenkt. Ausfaelle gab es seit dem keine. Allerdings wuerde ich heute auf jede Platine mit Schieberegistern noch einen kleinen DSP per Taste verbauen. Das ging damals nur noch nicht in so klein und einfach. Das waere fuer mich heute auch nur eine Fingeruebung.
Carsten-Peter C. schrieb: > Harald K. schrieb: >> Ja, aber Du wirst sie irgendwie einstellen müssen. Einfach eine Handvoll >> Geräte mit der gleichen Firmware flashen, zusammenstöpseln und nutzen >> geht halt nicht. > > Genau das mache ich. Nein, genau das machst Du eben nicht. Du baust für jedes Gerät eine individuelle Firmware. > .equ MySlaveAddress = 0xAE ;I2C Adresse > Nur die Adressen müssen angepasst werden. Das ist was anderes als alle Geräte mit der gleichen (identischen!) Firware zu flashen.
Motopick schrieb: > Das koennte man einfach nachzaehlen. :) Wenn es fertig ist - bestimmt. > Mochtest du ein Geraet wegwerfen muessen, weil ein Vollpfosten > meinte, den Einschalter "serialisieren" zu muessen? Du meinst den „Vollpfosten“, der innerhalb der EU die Richtlinie 2009/125/EG einhalten musste und in anderen Ländern nicht und deshalb den genialen Bypass vorgesehen hat?
:
Bearbeitet durch User
Wie viele Tasten müssen den gleichzeitig drückbar sein? Wie wäre es den mit einem IR-Fernbedinungsprotokoll (ohne Modulierung)? Wäre mit zumindest mit drei Leitern lösbar (VCC, GND, Signal). Jeder Sender (Taster) prüft ob der "Bus" gerade frei ist (ähnlich CAN-Bus) und gibt bei Tastenstatusänderung sein Telegram aus.
Dieter W. schrieb: > Wenn das angedachte Protkoll mit increment des empfangenen Wertes > realisiert werden soll, ist diese kurze Durchlaufzeit nicht > realisiserbar. Doch. Es muß nur das niederwertigste Bit als erstes über die Leitung, dann ist ein Increment on the fly während des Weiterleitens machbar: Zum ersten empfangenen Bit wird 1 addiert, Ergebnis kann schon rausgeschickt werden; bei allen folgenden Bits wird der Übertrag der vorigen Addition addiert.
Gerald O. schrieb: > Jeder Sender (Taster) prüft ob der "Bus" gerade frei ist (ähnlich > CAN-Bus) und gibt bei Tastenstatusänderung sein Telegram aus. Dann muß aber auch jeder Taster sein Telegramm vorab kennen, braucht also eine vorprogrammierte Adresse und Kollisionen können trotzdem nicht ausgeschlossen werden, also muß jeder Taster während des Sendens auch mitlesen. Dann lieber gleich CAN, das ist robust und behandelt Kollisionen auf Protokollebene; außerdem funktionierts in beide Richtungen, damit könnte man die Adressvergabe zumindest halbautomatisieren, indem man einen Taster nach dem anderen an den Bus hängt, und der jeweils neue Taster dabei auf seine Zieladresse programmiert wird.
Ich hatte hier mal einen seriellen Bus vorgestellt: Beitrag "mehrere MC seriell über Datenbus verbinden (1Draht)" Der Vorteil gegenüber einer UART ist, daß die Synchronisation bei jedem Bit neu erfolgt. Somit sind bis 15% Taktfehler zulässig. Die Slaves kann man parallel (1-Draht, 2-Draht) oder hintereinander schalten. Für die Adreßvergabe bei Parallelschaltung kann man auch eine 1-Wire Seriennummer verwenden (z.B. DS2401).
Interessanter Beitrag, vor allem wegen diverser Bauteile, die hier so aufgebracht werden. Die o.g. Puya-Controller P32Fxxx gibt es auch als Variante mit CAN. CAN-Transceiver habe ich soeben nachgeschaut, geht ab ca. 20ct bei lcsc.com los. Dazu sind die Puya-Controller auch noch 5V-tauglich, was gut zu den günstigen CAN-Transceivern passt, welche eben nur 5V können. D.h. man kann heutzutage einen kompletten CAN-Knoten inkl. Quarz für ca. 1€ Bauteile-Aufwand hinbekommen, ohne dass man riesige Stückzahlen benötigen würde. CAN-Adresse müsste dann aus der Controller-ID gebildet werden um im Nachhinein vom Master eingelernt werden (und hoffen, dass da keine doppelte dabei ist, wenn man auf 29bit reduziert). Ober eben daisy-chain, was dann wieder eine korrespondierende Ader mehr bedeuten würde.
Carsten-Peter C. schrieb: > Moin, > vielleicht kann man einen z.B. ATtiny 4313 über I2C ansprechen. Der > hätte dann bis zu 15 Ein- oder Ausgänge, um eine Matrix zu bedienen und > bräuchte für die Anbindung an den Master nur 2 Adern. Über die gleiche > Anbindung lassen sich weitere Slave ansprechen. Opfert man eine 3. Ader > für Interrupt, erspart man sich das Pollen. So etwas nutze ich für > meinen Dimmer. Das läuft sehr stabil. > Gruß > Carsten Allerdings sind Schieberegister und I2C Eingangsbausteine schon erfunden.
Michi S. schrieb: > Dieter W. schrieb: >> Wenn das angedachte Protkoll mit increment des empfangenen Wertes >> realisiert werden soll, ist diese kurze Durchlaufzeit nicht >> realisiserbar. > > Doch. Es muß nur das niederwertigste Bit als erstes über die Leitung, > dann ist ein Increment on the fly während des Weiterleitens machbar: Zum > ersten empfangenen Bit wird 1 addiert, Ergebnis kann schon rausgeschickt > werden; bei allen folgenden Bits wird der Übertrag der vorigen Addition > addiert. Das geht aber natürlich nur mit bitbanging, UART oder SPI Hardware kann man nicht on the fly mit einzelnen Bits füttern.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.