ich bin aktuell dabei, ein RC-Funktionsschiff zu modernisieren. Als neue Zentrale dient ein ESP32, der die Signale vom Empfänger auswertet.
Da ich im Rumpf und in den Aufbauten nicht hunderte einzelne Kabel für jeden kleinen Verbraucher vom ESP32 aus verlegen möchte, würde ich die Schaltaufgaben gerne dezentral über ein Bussystem (I2C) lösen. Geschaltet werden sollen primär LEDs (teilweise mit Blink-Mustern) und kleine Verbraucher wie Mini-Motoren. Ströme liegen meist unter 100mA, in Ausnahmen bei 200-300mA.
Mein aktueller Lösungsansatz:
Nach einiger Recherche bin ich bei der Kombination aus einem MCP23017 (als Port-Expander für den I2C-Bus) und nachgeschalteten ULN2803A Darlington-Arrays (als Leistungstreiber gegen Masse) gelandet. Für die paar Ausnahmen über 100mA würde ich diskrete Logic-Level MOSFETs an den MCP hängen.
Da ich jedoch nicht mehr ganz auf dem neuesten Stand bin, wollte ich die Runde fragen, ob dieses Setup heute noch Sinn macht oder ob man das moderner/eleganter lösen kann:
Gibt es mittlerweile "All-in-One"-Bausteine?
Gibt es empfehlenswerte I2C-ICs, die den Expander und eine Treiberstufe (bis z.B. 300mA) bereits in einem Chip vereinen, sodass ich mir das separate Darlington-Array sparen kann?
Die PWM/Servo-Frage:
Eigentlich brauche ich für die LEDs kein PWM. Wenn das Bussystem aber PWM-fähig wäre, könnte ich zukünftig auch dezentral Servos (z. B. für Kräne) darüber ansteuern. Wäre hier ein Umstieg auf einen PCA9685 (plus ULN2803A für die LEDs) die bessere Architektur, oder handle ich mir damit Nachteile bei der LED-Steuerung ein?
Ich programmiere den ESP32 in Python/MicroPython, falls das für die Chip-Wahl (Treiber-Verfügbarkeit) relevant ist.
Vielen Dank im Voraus für eure Einschätzungen und Tipps!
I2C-Bus war urspruenglich dazu gedacht, mehrere ICs auf einer Platine zu verbinden. Nicht ueber Platinengrenzen hinaus. Daher wuerde ich keinen I2C fuer soetwas verwenden, eher irgendwas Richtung RS232 - moeglichst nichts mit bidirektionalen Leitungen oder OpenCollector.
Da ich im Rumpf und in den Aufbauten nicht hunderte einzelne Kabel für
jeden kleinen Verbraucher vom ESP32 aus verlegen möchte, würde ich die
Schaltaufgaben gerne dezentral über ein Bussystem (I2C) lösen.
Bussystem ist schön und gut, aber es spart nichts an der Verkablung von Lämpchen, Motoren und dem anderen Schnickschnack. Dann bleibt noch die Stromversorgung, die je nach Verbraucher kräftig oder weniger kräftig ausgelegt werden muss.
Ausserdem ist I²C weit entfernt von fehlertolerant - eine Spannungsspitze zur falschen Zeit blockiert den Bus. Dafür gibt es zwar 'Reparaturmethoden', aber es muss erkannt werden und zwar, bevor du mit dem Modell einen Eisberg rammst.
Ich würde soweit wie möglich auf Standard aus dem RC Sortiment zurückgreifen. Und den ESP32 würde ich persönlich nochmal überlegen und doch auf einen Pico(2)W zurückgreifen - einfach, weil der schon so viele Ports hat.
Der Gedanke eines Bussystems im RC-Modell treibt mich auch schon geraume Zeit um. Ich habe zwar einen Modell-Lkw, aber auch hier fände ich die Aufteilung in verschiedene "Knoten" schön, z.B. einer im Chassis, einer im Fahrerhaus, einer hinten im Bereich der Rücklichter.
Natürlich erspart es nicht die End-Verdrahtung der einzelnen Lämpchen, aber es ist schon praktisch, wenn man trennbare Einheiten hat (z.B. Aufbauten oder Fahrerhaus), die nicht mit zig Adern mit der Zentrale verbunden sind. "Früher" hat man an dieser Stelle 37- oder 50polige Sub-D-Stecker verbaut, aber das ist ja sowas von 80ies...
Aus der Modellbauwelt kommen dazu auch Antworten, z.B. vor Jahren das System "Blauzahn" (heute ist das Projekt aufgegeben, schade) oder der "Kingbus" von Pistenking (den habe ich mir noch nicht genau angesehen)
Meistens aber wird eine zentrale Verdrahtung propagiert. Hunderte von mehr oder weniger intelligenten Modulen gibt es, Soundmodule, Fahrtregler, Auswerte-, Umschalt- und Funktionsbausteine... Alle halbe Jahre versucht sich wieder jemand an einem noch universelleren, mit noch mehr Ausgängen... Und alle versammeln sich mehr oder weniger an einem Ort im Modell, und von dort aus schlängeln sich die Leitungen zu jeden einzelnen Verbraucher und Servo.
Für den Wunsch nach Bussystem bleibt also Selbstbau.
Ich finde den I2C nicht ganz so verkehrt. Es sind ja im Modell doch nur Entfernungen von 1-2m zu überbrücken. Hat den Vorteil, daß der zentrale Controller quasi per "Broadcast" Befehle an die verteilten Knoten geben kann, und nicht per Daisychain wie bei RS232 oder RS485.
Kenne mich leider auch nicht so richtig aus - könnte man die Fehlertoleranz erhöhen, indem man als verteilte Knoten nicht Hardware-Bausteine verwendet, sondern wiederum kleine Controller, die Kommunikationsfehler besser ausbügeln?
Aber das ideale habe ich noch nicht gefunden. CAN wäre Overkill, SPI kenne ich nicht gut genug, und es gibt noch zig weitere Industrie-Busse... wer die Wahl hat hat die Qual.
Klar spart man sich nicht die Verkabelung an den LEDs bzw. Verbrauchern. Aber wenn ich z.b. ein Mast mit 10 Lampen habe und einen mini motor der das Radar dreht, dann wäre es schön wenn ich da nicht 12 Kabel ziehen müssen durchs Boot. Zusätzlich muss da ja dann auch ein Stecker dran, weil der Mast im Aufbau ist und angenommen werden kann. Es können in einem Boot schnell mal 40-50 LEDs geben. Das wird dann schnell wild. Die Spannung ist übrigens überall gleich mit 6V.
Beim Bussystem bin ich offen. SPI mit Schieberegister habe ich auch schon mal angeschaut. Wäre auch ok. RS232 wäre Overkill, weil ich dann ja auch wieder ein Protokoll implementieren müsste.
Die kritischen Steuerungen des Boots bleiben natürlich im Standard. Also Lenkung und so wird nicht über den MC gemacht. Es geht nur um die Sonderfunktionen.
Generell geht es mir hier ja hauptsächlich um den Weg und das basteln. Im Studium habe ich mit humanioden Robotern gearbeitet und die Servos dafür waren im RS485 Bus. Ich fande das damals eine super schöne Lösung.
@Tom: Freut mich, dass ich nicht alleine bin mit der Idee.
Da ich im Rumpf und in den Aufbauten nicht hunderte einzelne Kabel für
jeden kleinen Verbraucher vom ESP32 aus verlegen möchte
Mein Gott, wie viele Lämpchen willst du denn einzeln steuern ?
Hunderte ist doch komplett unrealistisch, oder bekommt jedes Bullauge eine elektrisch verstellbare Jalousie und jeder der Titanic-Kabinen eine einzeln dimmbare Ambientebeleuchtung ?
Vergiss nicht, dass jeder CAN-Bus Endpunkt eine Platine braucht, das macht man ja im Auto auch nicht so.
Jeder Verbraucher hat erst mal Anschlüsse die NICHT CAN-Bus sprechen, sondern einfach Strom wollen. Das sind üblicherweise 2 Kabel, weniger werden es auch mit CAN nicht (dort zumindest 4: VCC, GND, CAN_H, CAN_L) und damit weniger. Es bringt nichts, mit CAN nun aus 2 Leitungen 4 zu machen, erst bei mehr als 4 Verbrauchern spart es Drähte.
Was willst du bei LED mit ULN Treibern, für ein Modell reichen doch 20mA satt, vielleicht mit Ausnahme des Flak-Scheinwerfers.
Zähle also realistisch deine Verbraucher, überleg welche Treiber du BRAUCHST (und ein Motor
Wenn alle Verbraucher und Treiber in voller Ausbaustufe bekannt sind, kannst du uberlegen ob du Portexpander brauchst, oder ob die LED nicht einfach eine Kette von WS2812 sein können und die L9110 nicht direkt an den ESP dürfen.
Und erst dann uberlegt man, welche Platinen den minimalen Aufwand erfordern, und ob es unbedingt CAN sein muss.
Klar spart man sich nicht die Verkabelung an den LEDs bzw. Verbrauchern.
Aber wenn ich z.b. ein Mast mit 10 Lampen habe und einen mini motor der
das Radar dreht, dann wäre es schön wenn ich da nicht 12 Kabel ziehen
müssen durchs Boot.
Der Aufwand kommt wohl eher auf die Größe des Boots an: Wenn der Slave nur 3cm vom Master entfernt ist, ist die Aktion ziemlich sinnfrei.
Wenn es darum geht, Aufbauten vom Rumpf zu trennen und dabei wenig Kabelverhau zu haben, ist es sinnvoll.
Aber I²C? Da kann man auch anderen einen Open-Collektor-Bus verwenden (z.B. UART oder SPI auf Open-Collektor; oder One-Wire).
Dazu setzt man ein "popeliges" Protokoll auf der UART-Schnittetelle um, damit die Slaves auch wissen, ob die Nachricht gültig und überhaupt für sie ist.
Als Slave kann man dann auch irgendwelche 8-Pinner verwenden.
Natürlich erspart es nicht die End-Verdrahtung der einzelnen Lämpchen,
aber es ist schon praktisch, wenn man trennbare Einheiten hat (z.B.
Aufbauten oder Fahrerhaus), die nicht mit zig Adern mit der Zentrale
verbunden sind. "Früher" hat man an dieser Stelle 37- oder 50polige
Sub-D-Stecker verbaut, aber das ist ja sowas von 80ies...
Wedico hatte damals eine mehrpolige Diodensteckervindung zwischen Zugmaschine und Auflieger.
Später hat sich irgendwer eine IR-Übertragungsstrecke in den Königsbolzen gebaut (erfordert dann eine eigene Stromversorgung im Auflieger).
I2C-Bus war urspruenglich dazu gedacht, mehrere ICs auf einer Platine zu
verbinden.
Das ist zwar grundsätzlich richtig aber es ist selbst im Professionellen Bereich nicht unüblich, dass I2C über die Platinengrenze hinweg benutzt wird. Dabei reden wir nur von wenigen Meter, nicht irgendwie 100m weiter. Die Entfernungen in einem RC-Modell sind überschaubar, I2C dürfte da über mehrere Platinen hinweg problemlos anwendbar sein. Ich selbst hab I2C im Fastmode über einen Meter Flachbandkabel gejagt, war gar kein Thema, völlig problemlos.
Matthias S. schrieb im Beitrag #8087226:
Bussystem ist schön und gut, aber es spart nichts an der Verkablung von
Lämpchen,
Im Grunde schon ein wenig: Du kannst alles dezentralisieren und so Kabel sparen da nur das Bus-System quer durchs Modell gezogen werden muss. u.a. das ist der Grund warum wir heutezutage drölfzig Steuergeräte im Auto haben und nicht alles irgendwo zentral sitzt. Man muss es natürlich klar durchdenken damit man wirklich einen Vorteil hat, ich denke das ist Ziel des Threads
Sebastian B. schrieb im Beitrag #8087213:
Wäre hier ein Umstieg auf einen PCA9685 (plus ULN2803A für die LEDs)
Ähm, was für LEDs willste da einsetzen? Die PCAs können, meine ich, 25mA pro IO. Sprichst du von Power-LEDs?
Danke für die Hilfe. Der TPIC2810 sieht schon mal ganz gut aus. Der kann nur wohl keine induktiven Lasten schalten wie es scheint. Würde da eine diode reichen?
Ich würde normale SMD LEDs schalten. Die haben so um die 20mA Vebrauch meines Wissens. Aber an einem Kanal können auch mehrere parallel hängen. Daher die 100mA Angabe als Richtwert.
Moin,
ich habe mit einem kleinen Treiber ATTiny’s zum I2C Slave gebaut. Das läuft sehr stabil. Die können Pins setzen und abfragen, Spannungen messen, PWM erzeugen und bedingt schalten. Getestet mit ATTiny 85 (8Pin), 84 (14Pin) und 2313 bzw 4313 (20Pin). Mit nur einer Anweisung könnte man einen Motor anschalten, bis eine Stromstärke erreicht ist oder Lampen zeitgesteuert schalten, oder... oder… oder....
Gruß
Carsten
Hallo
Natürlich kann man das mit dem I2C Bus machen. Ist leichter und einfache als mit CAN und SPI. Gerade der ESP32 DevBoard oder Super Mini geht super damit. Du brauchst zwar 4 Drähte und musst erst mal überlegen was du alles ansteuern willst. Du kannst auch eine Kombination aus allem machen. Die LEDs über Bus, Servo direkt und bleibe bei 5V oder 3,3V, das sind die Standart Spannungen bei diesen ICs. Wenn du es noch verrückter haben willst kannst du über Master/Slave z.B. mit Attiny machen. Da hst du Möglichkeiten wo du noch nicht dran gedacht hast. Also bei, Bus kann ich dir gern weiterhelfen aber in C, sonst kann ich den Pico (Zero) mit Python. Der geht aber nur als Master.
achim
Ich würde normale SMD LEDs schalten. Die haben so um die 20mA Vebrauch
meines Wissens.
Warum die 20mA Version und keine LowCurrents mit 2mA? Die Dinger sind auf jeden Fall auch mega Hell kann ich dir sagen. Grade bei Batteriebetrieb wäre das doch ein Thema, oder? Nur so als Anregung. ;)
Ich finde den I2C nicht ganz so verkehrt. Es sind ja im Modell doch nur
Entfernungen von 1-2m zu überbrücken.
Sehr ich auch so. Dabei ist praktisch, dass die Bausteine in der Regel
integrierte Entstörfilter haben.
Womit sie deutlich unempfindlicher sind als Schieberegister und SPI. Deswegen, und dank TPIC2810, ist I2C 1. Wahl. Für kleine LEDs gibt es auch Konstantstrom-Treiber, damit spart man die Vorwiderstände. Der IS31FL3265A ist besser lieferbar als die von NXP und hat 18 Ausgänge mit bis zu 60 mA und 40 Volt (LEDs schaltet man lieber in Reihe als parallel).
I2C-Bus war urspruenglich dazu gedacht, mehrere ICs auf einer Platine zu
verbinden. Nicht ueber Platinengrenzen hinaus.
Durchaus wurden in Fernsehgeräten mit I2C auch Informationen zwischen Platinen (Hauptplatine und Eingabeeinheit) verbunden. Das Modellboot wird schon nicht größer sein als so ein Fernsehgerät sein.
Daher wuerde ich keinen I2C fuer soetwas verwenden
Ich sehe da kein Problem. In der Praxis wurde die selbe Physik (OpenDrain mit Pullups) mit dem selben Pegel dann aber zigmillionenmal als PS/2 Tastatur- und Mausschnittstelle mit 2m (und mehr) Kabellänge verwendet.
Der TPIC2810 sieht schon mal ganz gut aus. Der kann nur wohl keine
induktiven Lasten schalten wie es scheint.
Kann er "im Prinzip" schon. Du musst lediglich beachten, dass du beim Abschalten keine Spannungsspitzen über 40V am Drain-Pin hast. Allerdings ist der Rdson mit 6 Ohm bei Zimmertemperatur dann doch recht hoch. Bei 100mA fallen da glatt 0,6 V ab und damit 0,6 W an. Das ist dann im DB knapp unter Power Dissipation abgehandelt. Aber zum Glück hat der Baustein eine Übertemperaturabschaltung... ;-)
Moin,
I2C-Bus war urspruenglich dazu gedacht, mehrere ICs auf einer Platine zu
verbinden. Nicht ueber Platinengrenzen hinaus. Daher wuerde ich keinen
I2C fuer soetwas verwenden, eher irgendwas Richtung RS232 - moeglichst
nichts mit bidirektionalen Leitungen oder OpenCollector.
Gruss
WK
Das kann ich so bestätigen! Der Inter-IC-Bus wurde für vollständige AV/TV Geräte entwickelt und war durchaus dazu gedacht verschiedene Baugruppen in einem Gerät zu verbinden.
Die meisten Umsetzungen scheitern nicht an Buslänge, sondern am richtigen Protokoll-Verständnis. So setzen viele eine feste Zeit für Clock Pulse und ACK Pulse-Delay ein ohne zu berücksichtigen, dass der Empfänger diese Signale absichtlich verzögern darf. Siehe Clock-Stretching und ACK-Stretching. Gerade bei langen Bussystemen ist es wichtig diese Techniken einzusetzen und damit den Bus von beiden Seiten zu stabilisieren.
Du gibst den Attiny2313 und Ati 26 an. Das sind verhältnismässig alte ICs. Es gibt aber auch neue und moderne ICs, z.B. den Attiny 1604 und den Attiny 3216. Diese sind als Slave sehr gut geeignet beim I2C Bus.
Ich persönlich würde das mit RS485 machen, statt RS232, alleine schon wegen den Pegeln. RS485 als 2-Draht braucht nur ein kleines IC und keine Ladungspumpe und ist ausgesprochen störungsresistent.
Ich würde es sogar wagen, von der Busstruktur abzuweichen und - in Grenzen - eine Baumstruktur aufzubauen. Jaja, darf man nicht. Auch nicht bei RS232 und auch nicht bei I2C.
Und dann kann man es gleich mit ModBus machen und hat ein stabiles Protokoll und kann auch z.B. Endschalter für die Ankerkette auslesen.
Es gibt genügend PICs mit unterschiedlicher Pinanzahl zur Auswahl.
Wenn man sich für eine Architektur entschieden hat, dann kann man sich überlegen, wie man Motoren ansteuert oder LEDs. Das ist aber der zweite Schritt.
Den Kern des Programms kann man dann problemlos jeweils um die Gegebenheiten erweitern. Das ist nur noch Register lesen/schreiben. Ob man dann einen Motor per PWM geschwindigkeitsregeln will ist dem ModBus egal. Einen µC hat jeder Knoten.
Edit sagt: Und natürlich kann der µC auch Servos ansteuern. Auch mit vorgegebenen Rampen.
Und nicht vergessen: Jeder Knoten braucht eine eigene Adresse. Also bei den PortExtendern schauen ob der Adressraum groß genug ist.
Da ich im Rumpf und in den Aufbauten nicht hunderte einzelne Kabel für
jeden kleinen Verbraucher vom ESP32 aus verlegen möchte, würde ich die
Schaltaufgaben gerne dezentral über ein Bussystem (I2C) lösen.
Für Deinen Anwendungsfall würde ich eher an 1-Wire als an I2C denken.
I2C würde ich nicht verwenden. Wenn da irgendwo Leitung geschaltet wird und Störungen auf den Bus überkoppeln, dann kann so ein Bus schon mal hängen bleiben. Das ist nicht gut.
Wenn das Modell so groß ist, dass ein verteiltes System mit Bus Sinn macht, dann würde ich eher auf LIN aufsetzen. Das kommt aus der Automobiltechnik, hat sich dort millionenfach bewährt und ist billig. Das ist im Prinzip ein Eindraht-UART mit 12/24V Pegeln. Und LIN selber ist so designt, dass die Slaves beispielsweise keine präzisen Taktquellen brauchen (muss ja billig sein) - die messen einfach das Sync-Byte am Anfang eines jeden Pakets aus.
Wie bei RS232 oder 485 braucht man Transceiver, aber da gibts auch noch besseres - sogenannte System Basis Chips, die Transceiver, den LDO für den Mikrocontroller (3.3 oder 5V), Reset und Wakeup integrieren.
Beispiel: OnSemi NCV7428
https://www.onsemi.com/products/interfaces/wired-transceivers-modems/ncv7428
Das kann im Grunde jeder Bus, dafür sollte man stets eine Strategie
haben.
Sehe ich anders. Bei UART/LIN/RS485 oder CAN gibt es maximal defekte Pakete, und weil dann die Prüfsummen nicht stimmen, werden die dann einfach weggeworfen. Wenn bei I2C mittendrin eine ungewollte Start- oder Stop-Condition auftaucht, dann sind die Folgen ernster. Ja, man kann die Slaves freitakten oder resetten, aber trotzdem. Andere Busse handhaben Störungen deutlich besser. Und bei CAN geht sogar vieles einfach in Hardware innerhalb des Controllers.
Wer nur einen Hammer hat, für den sieht auch eine Schraube wie ein Nagel aus. Dass die Schraube mit genügend Hammerschlägen auch tatsächlich reingeht, ist kein Grund dafür, nicht einen Schraubendreher zu verwenden.
Das "Problem" ist: Er findet I2C nicht optimal und veteidigt seinen Standpunkt nun mit allen dienlichen Argumenten. Sieh es so: Ihr müsst euch nicht einig werden.
Wer nur einen Hammer hat, für den sieht auch eine Schraube wie ein Nagel
aus.
Ich finde den Vergleich sehr unpassend. Hier geht es nicht darum, ein ungeeignetes Werkzeug zu benutzen. I2C ist für den Fall geeignet, daran gibt es nichts zu rütteln.
Das "Problem" ist: Er findet I2C nicht optimal und veteidigt seinen
Standpunkt nun mit allen dienlichen Argumenten. Sieh es so: Ihr müsst
euch nicht einig werden.
Sehe ich genauso. Ich denke in der Tat ähnlich, auch ich denke dass LIN oder CAN besser wäre aber ich weiß aus eigener Erfahrung dass bei diesen "Größen" wie beim Modellbau, auch I2C nicht zwingend ungeeignet ist. Daher finde auch ich seinen Vergleich mit dem Hammer und Schraube als eher ungeeignet.
Und ja, wir müssen uns nicht einig werden. Es genügt wenn jeder den Standpunkt des andere akzeptiert ;)
Also, das würde ja passen. Man muss sich nicht komplett an das Protokoll halten, sondern kann den Bus etwas missbrauchen.
Gut gefällt mir der Spannungsbereich, da kann man dann auch gleich die Knoten gut mitversorgen.
Interessant ist auch, dass es dafür gut integrierte Komplettlösungen gibt (Baugröße). Und es genügt ein schnöder USART.
Sowas wie der NCV7428 machts etwas einfacher und kompakter. Den Abschlusswiderständen nach ist wohl auch eine Stern/Baumstruktur umsetzbar. Ohne jetzt explizit danach gesucht zu haben.
Wenn ich das umsetzen müsste, dann würde ich wohl vom ModBus ablassen. Aber erst, nachdem ich zweimal drüber geschlafen hab. :-)
I2C-Bus war urspruenglich dazu gedacht, mehrere ICs auf einer Platine zu
verbinden. Nicht ueber Platinengrenzen hinaus. Daher wuerde ich keinen
I2C fuer soetwas verwenden,
Wenn man sich auf 400kHz begrenzt, geht das durchaus gut. Auch UARTs laufen mit 230kHz und 460kHz recht zuverlässig in moderat verseuchten Umgebung.
Die Infos waren aber super gut und haben mir sehr geholfen.
Ich habe mich jetzt entschieden den RS485 einzusetzen. Mit diesem hatte ich damals in der Robotik sehr gute Erfahrung gesammelt (Robotis Servos).
Ich bin auch vom ULN2803A weg, da der ja irgendwie "altmodisch" ist. Ich nutze jetzt ein TBD62083A als Ersatz. Zusätzlich wird ein ATTINY3226 als Zentrale.
Das ist jetzt sicherlich alles ein wenig "over the top". Aber hey, why not! So ist das ganze sehr universell einsetzbar. Auch außerhalb vom RC.
Anbei mein aktueller Schaltplan. Würde mich freuen, wenn da sich den mal einer anschauen kann. Ist mein erster Schaltplan, also seit etwas nachsichtig ;)
Du hast am Reset Eingang des Mikrocontroller eine (offene) Antenne fabriziert. Damit wirst du Störungen empfangen, die gelegentlich ungewollte Neustarts auslösen.
am Reset Eingang des Mikrocontroller eine (offene) Antenne
Ein 47nF Kondensator dicht zwischen Reset-Pin und GND-Pin hilft da
Sicher? Ich bin davon ausgegangen bei den neuen ATtiny wäre das sogar ungünstig. Der Pin ist ja zum programmieren da und ein Kondensator würde das verhindern.
Wunder.
Sebastian B. schrieb:
Ist mein erster Schaltplan
Nimm für GND das übliche GND-Symbol ⟘
Dann musst du nicht extra GND hinschreiben.
Interessanter Vorschlag!
Also, das würde ja passen.
Gut gefällt mir der Spannungsbereich, da kann man dann auch gleich die
Knoten gut mitversorgen.
Interessant ist auch, dass es dafür gut integrierte Komplettlösungen
gibt (Baugröße). Und es genügt ein schnöder USART.
Sowas wie der NCV7428 machts etwas einfacher und kompakter. Den
Abschlusswiderständen nach ist wohl auch eine Stern/Baumstruktur
umsetzbar.
Geht mir ganz genauso, das fand ich sehr interessant. Auch die Beschränkung auf 16 Slaves tut nicht weh, das müßte schon ein monströses Funktionsschiff sein, damit diese Grenze überschritten wäre.
Anbei mein aktueller Schaltplan. Würde mich freuen, wenn da sich den mal
einer anschauen kann. Ist mein erster Schaltplan, also seit etwas
nachsichtig ;)
Du hast beim RS485 Transceiver DE und #RE verbunden. Damit ist entweder der Sender oder der Empfänger aktiv. Kann man machen, kein Problem.
Es gibt aber noch eine andere Möglichkeit: #RE bleibt dauerhaft auf GND. Der Unterschied ist, dass Du jetzt jedes Byte, das Du sendest, auch wieder empfängst. Wenn Du also etwas anderes empfängst, als Du gesendet hast, weißt Du, das es ein Problem gegeben hat. Entweder hat noch ein anderer Teilnehmer versucht zu senden (dann kannst Du eine zufällige Zeit warten und es erneut versuchen), oder Du hast ein Kabelproblem oder ähnliches.
Bei LIN und CAN ist das übrigens das Standardverhalten, da wird immer das gesendete zurückgelesen. Es gibt kein Umschalten zwischen Senden und Empfangen, d.h. in diesem Punkt ist LIN einfacher zu handhaben.
Wenn Du jetzt noch nicht weißt, was Du willst, kannst Du eine Lötbrücke, einen 0 Ohm Widerstand oder einen Jumper vorsehen, so dass #RE entweder mit DE oder mit GND verbunden wird.
Natürlich erspart es nicht die End-Verdrahtung der einzelnen Lämpchen,
aber es ist schon praktisch, wenn man trennbare Einheiten hat (z.B.
Aufbauten oder Fahrerhaus), die nicht mit zig Adern mit der Zentrale
verbunden sind.
Lämpchen wird man heute wohl durch LEDs ersetzen und die gibt es integriert mit einem Controller, so dass man auch keine "End-Verdrahtung" mehr hat, sondern jede LED direkt auf dem seriellen Bus sitzt (WS2811, WS2812 u.ä.).
So, noch mein Senf zur Schaltung:
Ob das mit dem Reset so i.O. ist hab ich meine Zweifel. Aber wenns so im Datenblatt steht ...
Wie die Programmierung erfolgt weiß ich nicht bei den AVRs, steht auch im Datenblatt. Das sollte jedenfalls im Schaltplan erkennbar sein damit es auch auf die Platine kommt.
Die Rs für Bias genügen beim Master, also weg damit. Der R für die Terminierung kommt nur auf die letzte Platine, also den Jumper dafür weg und dann nur einmal bestücken.
Was am Stecker "Common" dranhängt weiß ich nicht. Wenn das Eingänge sind, dann wäre eine Schutzbeschaltung angebracht.
Die Spannungsversorgung würde am Eingang noch gut 10 µF oder so vertragen.
Wenn das Array_out LEDs treibt, dann sieh doch gleich Rs auf der Platine dafür vor. Ggf. kann dann ein 0R reingelötet werden.
Ich würde noch einen Resetgenerator vorsehen.
So, noch mein Senf zur Schaltung:
Ob das mit dem Reset so i.O. ist hab ich meine Zweifel. Aber wenns so im
Datenblatt steht ...
Wie die Programmierung erfolgt weiß ich nicht bei den AVRs, steht auch
im Datenblatt. Das sollte jedenfalls im Schaltplan erkennbar sein damit
es auch auf die Platine kommt.
Wie müsste das deiner Meinung nach sein?
Die Rs für Bias genügen beim Master, also weg damit. Der R für die
Terminierung kommt nur auf die letzte Platine, also den Jumper dafür weg
und dann nur einmal bestücken.
Die beiden für den bias werfe ich raus. Die Platine ist ja als Slave gedacht. Da ich flexibel bleiben will in der chain habe ich den Jumper eingebaut.
Was am Stecker "Common" dranhängt weiß ich nicht. Wenn das Eingänge
sind, dann wäre eine Schutzbeschaltung angebracht.
Das sind einfach erstmal die Pins rausgeführt. Ist noch nicht geplant was da dran soll.
Die Spannungsversorgung würde am Eingang noch gut 10 µF oder so
vertragen.
Da ist ja schon ein Kondensator dran. Oder was meinst du genau?
Wenn das Array_out LEDs treibt, dann sieh doch gleich Rs auf der Platine
dafür vor. Ggf. kann dann ein 0R reingelötet werden.
Auch hier will ich flexibel bleiben. 0R wäre eine Option. Aber das kostet Platz auf der Platine.
Da ich flexibel bleiben will in der chain habe ich den Jumper eingebaut.
Es wäre mir flexibel genug, die 120R nicht zu bestücken und nur einmal einzulöten. Leicht gepfuscht wäre das ein bedrahteter R den man mit zu den A/B Leitungen dazuklemmt. Ein Stecker/(Schraub-)Anschluss für A/B, GND 5V (12V ?) fehlt sowieso noch.
Auch hier will ich flexibel bleiben. 0R wäre eine Option. Aber das
kostet Platz auf der Platine.
Ja, dann hast du als Konsequenz eben keinen Platz für die Vorwiderstände für LEDs und kannst dann bedrahtete Rs an die LEDs löten. Wenn du das praktisch findest mach es genau so!
Naja, das muss schon hell sein. Sind ja Positionslichter ;)
Und der Suchscheinwerfer heißt nicht ohne Grund so.
Echte Positionslichter beziehen ihre Helligkeit aus dem vertikal stark eingeschränkten Winkelbereich. Zur Abdeckung des erforderlichen Horizontalwinkels werden dann mehrere LEDs kombiniert.
Suchscheinwerfer fokussieren sowohl horizontal als auch vertikal, d.h. du brauchst dafür LEDs mit kleinem Abstrahlwinkel und zusätzlich eine Linse zur Parallelisierung. Besonders effektvoll wirkt das zusammen mit etwas Nebel/Rauch.
Naja, das muss schon hell sein. Sind ja Positionslichter ;)
Und der Suchscheinwerfer heißt nicht ohne Grund so.
Echte Positionslichter beziehen ihre Helligkeit aus dem vertikal stark
eingeschränkten Winkelbereich. Zur Abdeckung des erforderlichen
Horizontalwinkels werden dann mehrere LEDs kombiniert.
Suchscheinwerfer fokussieren sowohl horizontal als auch vertikal, d.h.
du brauchst dafür LEDs mit kleinem Abstrahlwinkel und zusätzlich eine
Linse zur Parallelisierung. Besonders effektvoll wirkt das zusammen mit
etwas Nebel/Rauch.
War ja nur Spaß. Die 20mA hatte ich als Richtwert aus dem Datenblatt und gibt mir die Grenze nach oben. Die tatsächliche Helligkeit muss ich dann schauen wenn die verbaut sind.
Die 20mA hatte ich als Richtwert aus dem Datenblatt
Die 20mA-Angabe im Datenblatt ist kein Richtwert für irgendetwas, sondern ein Punkt auf der Kennlinie oder bei Messungen Bestandteil der Testbedingungen.
Es wäre mir flexibel genug, die 120R nicht zu bestücken und nur einmal
einzulöten. Leicht gepfuscht wäre das ein bedrahteter R den man mit zu
den A/B Leitungen dazuklemmt.
Das wäre ja wie damals mit den Koax-Netzwerken ;)
Hab jetzt mal die Variante mit dem Platz zum einlöten gewählt
