[zwei Kommunikationskanäle gleichzeitig in Software -> Kniffelig] -> Warum?
[...]
Hmmm, da kommt grad mein Hirn nicht mit was du meinst. Oder war das eh nicht in meine Richtung angemerkt? ...
Das bezog sich auf Dirks nicht ganz ernst gemeinten "Vorschlag", sowas mit 'nem Tiny4 umzusetzen (und alles was danach kam).
Ich ging von dem Konzept PC->UART->TWI->Aktoren-Treiber aus.
Der Tiny hat keine HW-Kommunikation, also müßte man beide in SW umsetzen. Das beide nicht gleichzeitig agieren können müssen, war damals nicht klar, also bin ich davon ausgegangen. TWI ist eine synchrone Kommunikation, die (jedes) gültigen Bits werden mit einer Clock-Leitung synchronisiert - und der Tiny ist als Master Chef über die Clock.
Die üblichen USB->TTL-Wandler wandeln nicht auf US(A)RT (universeller synchroner Reciever/Transmitter), sondern auf UART (...asynchroner...) - der Empfänger synchronosiert einmal auf das Startbit, und muß danach ein vorgegebenes Timing (Baudrate) einhalten. Der Tiny hat dafür einen Timer. Ich bin in dem verlinkten Beispiel da,als auf 4800Baud gekommen (mit 8fach Oversampling, das entspäche dem doubeled transmission speed des HW-UART (U2X-Bit)).
Warum kniffelig? Dirks TWI-Code und mein UART-Code würden zusammen schon fast den ganzen Flash belegen - wobei beide optimiert werden könnten. Mein Code sollte sich eigentlich auch auf zwei Rx quasi-gleichzeitig umstricken lassen, nur den schnutzigen Trick mit dem Paritätsbit kann ich nicht ein zweites mal anwenden. Das verXORren wird nämlich durch ein einziges SBI auf das Pin Bit des Reset realisiert.
Das ganze hat aber eigentlich nichts mehr mit Deinem Thema zu tun - es wurde ja mehrfach ein Controller mit Hardware-UART und Hardware-TWI/USI vorgeschlagen...
[TWI->jedes Haus/Straße als eigenen Slave anbinden] -> Ist eine Idee. Jedoch ist es mit den vorhandenen Gegebenheiten eher nicht so gut brauchbar. Jede Steuereinheit muss für sich autonom arbeiten können. Es besteht bereits ein PC-gesteuertes Beleuchtungssystem mit mehr als 50 Steuerkanälen für die Anlage mit Wettersimulation und Tag-Nachtzyklus. Aber da die Anlage sehr groß ist und bei einer zentralen Steuerung der Verkabelungsaufwand gigantisch wird, hatte ich die Idee pro Haus eine kleine Platine zu entwickeln die einzelne Fenster oder andere kleine Aktionseinlagen steuert und direkt im Gebäude untergebracht ist und nur ein oder maximal zwei Steuerleitungen von der zentralen "Umweltsteuerung" benötigt. Bedeutet, ich habe zwei Steuerleitungen quer durch die Anlage. Eine signalisiert mir den Beginn der Abenddämmerung und eine die Morgendämmerung. Alleine mit diesen beiden Steuerleitungen können die Platinen ihr jeweiliges Programm ablaufen lassen. Für Sonderanwendugne läuft ein programm auch ohne Unterbrechung durch...
hm...
Ich sehe folgende Möglichkeiten:
- jeder Aktor (Platine) ist autark, und steuert seine Aktoren (LEDs) entweder direkt oder über was auch immer selbständig an. Er erhält irgendwelche Signale (Dämmerung usw) über irgendwelche Leitungen (<-so hätte ich Dich jetzt verstanden). Zum aufspielen einer neuen "Animation", muß irgendeine (physische) Kommunikationsverbindung mit dem jeweiligen zusammengesteckt werden.
- jeder Aktor ist autark, aber zusätzlich über einen geeigneten Kommunikationsbus (TWI, UART (ggf DaisyChain)) an einen Master-Controller angebunden (Parametrisierung usw vom PC über den Master auf alle Slaves. Jeder Slave bekommt über irgendwelche Leitungen weitere Signale (Dämmerung etc...), die er mitauswertet <-- inkonsequent, deswegen...
- wie oben, aber die vom PC erzeugten(?) "Umweltdaten" werden an den Master-Controller übergeben, der sie über den bestehenden Bus an alle Slaves weiterreicht. damit haste nur noch einen 2draht-Bus (oder einen UART-Ring), und kannst es bei Egon Pimpelhuber regnen lassen, bei Marta Pfahl (Nachbarin) scheint die Sonne, und auf der Straße ist finsterste Nacht... Welche Autonomie Du jedem Aktor und dem Master einprogrammierst (Tag/Nacht-Wechsel zB), ist Deine Sache - ganz dumme Knoten kommen ohne Controller aus, intelligentere brauchen halt ein Sillizium-Hirn (insbesondere um den Master und den Bus zu entlasten (Schweißlicht, Anwesenheitssimulation usw).
...
Sehe ich nicht.
Hab mir zu Testzwecken so ein Teil über eBay besorgt. USB - TTL Umsetzer. Weiß jetzt nicht auf die Schnelle ob da ein TFTD oder CP2xxx arbeitet. Jedenfalls habe ich per PC eine LED darüber geschalten. Damit war für mich klar, die Kommunikation bekomm ich hin. PC seitig wird das mit Visual Studio realisiert...
Ausgangspunkt waren ja Dirks Bootloader, und ob man (Dirk) nich sowas wie'n Megaxxx als virtuellen ComPort bereitstellen könnte.
Meiner Meinung nach hat Dirk da zwei unterschiedliche "Systeme". Controller mit integrieter USB-Schnittstelle - zu den Dingern kann ich nichts sagen, und Controller, bei denen der Loader über einen externen USB-TTL-Wandler läuft (eben genau die von Dir genannten FTDI/CPblablub/wieauchimmer). Der Wandler ist also für den PC ein virtueller ComPort, und für den Controller ein ganz simpler UART.
Ich(!) finde es leichter ein Assembler-Programm zu schreiben, welches über UART kommuniziert, als auf dem PC ein dotnet-Programm, welches vernünftig auf den Comport zugreift (bei meinem Oszilloskop vor zich Jahren bekam ich bei dem Versuch der Echtzeitdarstellung irgendwann Probleme). Ihr könnt das sicher besser...
Aber die andere Seite von Thomas' Frage ist ja noch offen (wenn auch OT): mit welchen Aufwand muß man einen ATxxxUSB konfigurieren, daß der sich am PC als vcomport anmeldet? Im Controller selbst gibts dann sicher äquivalente Register/Bits/IRQs zum UDR, DataRecieved-IRQ, UDRE, ...
P.S. an Dirk (und auch an Manfred): Drannbleiben!
