Hallo erstmal :-) Ich beabsichtige Bus-gesteuerte Module zu erstellen. Von diesen Modulen sollten >100 ansteuerbar sein. Nun dachte ich mir, dass ich es vielleicht so realisieren kann, dass ich einfach einige Module parallel betreibe und an diese jeweils in Reihe weitere Module hänge. Die Daten sollen vom PC gesendet werden. Das "Kaskadieren" (in Reihe) sollte laut dieser Beschreibung funktionieren: https://de.wikipedia.org/wiki/Serial_Peripheral_Interface siehe Bild 1 Wenn ich es richtig verstanden habe, dann werden die Daten einfach ausgewertet und wenn man nicht der Empfänger ist werden diese weitergeleitet. Dazu meine erste Frage: Wie viele kann ich in Reihe hängen (kaskadieren) ? Dann sollten welche parallel angeschlosse werden. Das dürfte ja eigentlich rein empfangstechnisch funktionieren, problematisch wird es aber wenn die Module antworten müssen (z.B. fehlerhaft empfangen), denn dann kommt es zu Kollisionen. Ist das so überhaupt möglich (evtl. ohne das der Slave antwortet)? Vielleicht hilft es etwas genauer zu erklären, was ich überhaupt will: Ich möchte vom PC Daten an Module senden, welche diese dann auswerten. Der erste Teil soll die Adresse sein und der zweite Teil die Daten. Stimmt die Adresse nicht überein, dann sollen diese einfach an das dahinter hängende Modul weitergereicht werden. Stimmt die Adresse sollen die Daten (eine Zahl) auf einer 7-Segment-Anzeige dargestellt werden. Der Hintergrund ist, dass man eine "Stückliste" an ein Regal schickt und die Fächer selber zeigen wie viel vom jeweiligen Fach gebraucht wird. Für die Module würde ich gerne den ATTiny 2313 verwenden. Ich habe noch nie mit einem Mikrokontroller gearbeitet, deswegen wollte ich vorher mal fragen ob mein Vorhaben so realisierbar ist. Vielen Dank.
Ich würde an deiner Stelle I²C benutzen. Dort kannst du jeden Teilnehmer einzeln adressieren, und nur der adressierte antwortet. SPI wird bei vielen Teilnehmern immer langsamer.
@Christian R. (holle) >Ich beabsichtige Bus-gesteuerte Module zu erstellen. Von diesen Modulen >sollten >100 ansteuerbar sein. Hmm, der 1001 selbstgestrickte Bus? >Nun dachte ich mir, dass ich es vielleicht so realisieren kann, dass ich >einfach einige Module parallel betreibe und an diese jeweils in Reihe >weitere Module hänge. Warum nicht alles direkt und parallel an den Bus? >Das "Kaskadieren" (in Reihe) sollte laut dieser Beschreibung >funktionieren: >https://de.wikipedia.org/wiki/Serial_Peripheral_Interface >siehe Bild 1 Naja, SPI-Busse können zwar kaskadierte Slaves nutzen, im Normalfall sind die aber NICHT kaskadiert. Also wie auf der Seite oben eine Sternverbindung. Und einen SPI-Bus mit 100 Teilnehmern hab ich noch nie gesehen. Theoretisch möglich, praktisch eher unsinnig. Denn dann wird der Verdrahtungs- und Signalaufwand sehr hoch, man braucht 100 Slave Select Signale. Busse mit vielen (ca. >10) Teilnehmern nutzen "in band addressing", sprich, der angesprochene Teilnehmer dekodiert die Adresse aus den Busdaten, es gibt kein extra Hardwaresignal dafür. Wie z.B. I2C, CAN, Ethernet, etc. >Wenn ich es richtig verstanden habe, dann werden die Daten einfach >ausgewertet und wenn man nicht der Empfänger ist werden diese >weitergeleitet. Im Prinzip ja. >Dazu meine erste Frage: Wie viele kann ich in Reihe hängen (kaskadieren) >? Siehe oben. >Dann sollten welche parallel angeschlosse werden. Das dürfte ja >eigentlich rein empfangstechnisch funktionieren, problematisch wird es >aber wenn die Module antworten müssen (z.B. fehlerhaft empfangen), denn >dann kommt es zu Kollisionen. Nö. SPI hat keine Kollisionen. Denn es gibt nur einen Master und nur einen Takt, auf den hören alle synchron. >Vielleicht hilft es etwas genauer zu erklären, was ich überhaupt will: Wäre sinnvoll. >Ich möchte vom PC Daten an Module senden, welche diese dann auswerten. Ach was? >Der erste Teil soll die Adresse sein und der zweite Teil die Daten. >Stimmt die Adresse nicht überein, dann sollen diese einfach an das >dahinter hängende Modul weitergereicht werden. Stimmt die Adresse sollen >die Daten (eine Zahl) auf einer 7-Segment-Anzeige dargestellt werden. Die 1001 LED-Steuerung. Wurde schon erfunden, nennt sich DMX512 und kann bis zu 512 Kanäle/Bus ansprechen. Real aber eher deutlich weniger als 512 Geräte/Bus (meistens hat ein Gerät mehrere logische Kanäle/Adressen) >Der Hintergrund ist, dass man eine "Stückliste" an ein Regal schickt und >die Fächer selber zeigen wie viel vom jeweiligen Fach gebraucht wird. Naja, ist trotzdem nur eine "dumme" Anzeige. >Für die Module würde ich gerne den ATTiny 2313 verwenden. Eben das spricht für einen einfachen Bus ala DMX512. Aber auch dort würde man vermutlich mehrere Anzeigen an einen Mikrocontroller hängen, damit der sich nicht langweilt. Und wenn die räumlichen Abstände nicht zu groß sind, ist das auch besser, man braucht weniger Busteilnehmer. >Ich habe noch nie mit einem Mikrokontroller gearbeitet, deswegen wollte >ich vorher mal fragen ob mein Vorhaben so realisierbar ist. Im Prinzip ja, für einen Anfänger ab schon viel Holz.
@Jörg W. (dl8dtl) (Moderator) >Ich würde an deiner Stelle I²C benutzen. Dort kannst du jeden Teilnehmer >einzeln adressieren, und nur der adressierte antwortet. Ja, aber nicht wenn das Ganze über mehrere Dutzend Meter verteilt ist. >SPI wird bei vielen Teilnehmern immer langsamer. Nö.
Christian R. schrieb: > Ich habe noch nie mit einem Mikrokontroller gearbeitet, deswegen wollte > ich vorher mal fragen ob mein Vorhaben so realisierbar ist. Und wieso will ein blutiger Anfänger direkt mal seinen eigenen kleinen Bus erfinden und beschäftigt sich nicht erst mal mit bekannter und dokumentierter Materie? Diese Idee ist, und ich halte mich hier extrem zurück, sub-intelligent. Denn egal ob deine Idee gut oder schlecht ist, du kannst sie doch sowieso nicht umsetzen. Also was solls dann?
:
Bearbeitet durch User
Man muss aber sagen, dass dieser Anfänger nicht ganz dumm sein kann, denn er hat nachgefragt bevor er begonnen hat, drauf los zu basteln. Oft sehen wir hier ja das Umgedrehte: Der Anfänger überlegt sich eine Lösung zu seinem Problem, läuft auf ein Hindernis auf und fragt erst dann nach ob seine Lösung überhaupt sinn macht.
M. K. schrieb: > Man muss aber sagen, dass dieser Anfänger nicht ganz dumm sein kann, > denn er hat nachgefragt bevor er begonnen hat, drauf los zu basteln. > Oft sehen wir hier ja das Umgedrehte: Der Anfänger überlegt sich eine > Lösung zu seinem Problem, läuft auf ein Hindernis auf und fragt erst > dann nach ob seine Lösung überhaupt sinn macht. Unsinn. So läuft das doch immer. Nichts können aber im Forum über das ultra komplexe Projekt quatschen. Außerdem: > Denn egal ob deine Idee gut oder schlecht ist, du kannst sie doch > sowieso nicht umsetzen. Also was solls dann?
Falk B. schrieb: > @Jörg W. (dl8dtl) (Moderator) > >>Ich würde an deiner Stelle I²C benutzen. Dort kannst du jeden Teilnehmer >>einzeln adressieren, und nur der adressierte antwortet. > > Ja, aber nicht wenn das Ganze über mehrere Dutzend Meter verteilt ist. Auch da gibt es Tricks. Beispielsweise aktive Pullups oder gleich Bus-Translator auf 12V Diff-Twisted Pair. Ist sicher nicht der ideale Einsatzzweck von I2C, aber hier tatsächlich ganz gut geeignet, denn: Billig und einfach anzusprechen und Hardware ist ebenfalls spottbillig verfügbar. Technisch am schönsten ist natürlich sowas wie Ethernet oder CAN, aber für ein paar 7-segmenter gleich ein solchen Protokoll ? Och nöö Gruß, Simon
Falk B. schrieb: > @Jörg W. (dl8dtl) (Moderator) > >>Ich würde an deiner Stelle I²C benutzen. Dort kannst du jeden Teilnehmer >>einzeln adressieren, und nur der adressierte antwortet. > > Ja, aber nicht wenn das Ganze über mehrere Dutzend Meter verteilt ist. I²C kann man praktisch beliebig langsam machen. Aber ich würde dir Recht geben, DMX ist sinnvoller. >>SPI wird bei vielen Teilnehmern immer langsamer. > > Nö. Wenn man viele kaskadiert (so wie angedacht), dann muss man zum Erreichen des Nten Teilnehmers erst (N-1) · 8 Bit durchtakten. Sowas macht man gelegentlich, wenn die Slaves einfache 74595 sind.
:
Bearbeitet durch Moderator
Ich stelle mir gerade so ein Regal vor, 8 Fächer nebeneinander, 8 Fächer übereinander. Mit SPI sind das pro Reihe (also 8 Anzeigen) ein Chipselect und ein Schieberegister pro Ziffer. Oder einen Mikrocontroller pro Reihe. Finde ich jetzt als Ansatz nicht soo bescheuert. Allerdings verschiebt sich das Problem dann trotzdem darauf, die richtige Reihe im richtigen Regal anzusprechen - und da braucht man ein richtiges Bussystem, weil das räumlich getrennt ist. Hängt vom Lager ab, was da geeignet ist.
M. K. schrieb: > Man muss aber sagen, dass dieser Anfänger nicht ganz dumm sein kann, > denn er hat nachgefragt bevor er begonnen hat, drauf los zu basteln. > Oft sehen wir hier ja das Umgedrehte: Der Anfänger überlegt sich eine > Lösung zu seinem Problem, läuft auf ein Hindernis auf und fragt erst > dann nach ob seine Lösung überhaupt sinn macht. Nein, das wäre zu einfach. Er fragt, wie er über sein Hindernis drüber kommt, überzeugt davon, dass das ja ein Klacks ist. Die Antwortenden wundern sich zunächst, weil die Frage schon keinen Sinn macht. Dann versuchen sie rauszufinden, was er eigentlich ursprünglich will und, ihn davon zu überzeugen, dass sein Ansatz nix taugt, was aber nicht gelingt.
Rolf M. schrieb: > Nein, das wäre zu einfach. Er fragt, wie er über sein Hindernis drüber > kommt, überzeugt davon, dass das ja ein Klacks ist. Die Antwortenden > wundern sich zunächst, weil die Frage schon keinen Sinn macht. Dann > versuchen sie rauszufinden, was er eigentlich ursprünglich will und, ihn > davon zu überzeugen, dass sein Ansatz nix taugt, was aber nicht gelingt. Jetzt mal halblang. Außer der ersten Frage kam doch nichts mehr. Er wird seinen Ansatz schon noch überdenken. Spätestens dann, wenn er mit der Implementierung beginnt. Es ist einfach notwendig, auch mal in eine falsche Richtung zu denken und zu gehen. Wer sich selber Denkverbote auferlegt, der kommt nie voran. Dadurch lernt man dazu.
Cyblord -. schrieb: > Und wieso will ein blutiger Anfänger direkt mal seinen eigenen kleinen Deine Einschätzung ist FALSCH. Er ist ein Anfänger aber NOCH nicht blutig. Phrasendrescher.
Name: schrieb: > Rolf M. schrieb: >> Nein, das wäre zu einfach. Er fragt, wie er über sein Hindernis drüber >> kommt, überzeugt davon, dass das ja ein Klacks ist. Die Antwortenden >> wundern sich zunächst, weil die Frage schon keinen Sinn macht. Dann >> versuchen sie rauszufinden, was er eigentlich ursprünglich will und, ihn >> davon zu überzeugen, dass sein Ansatz nix taugt, was aber nicht gelingt. > > Jetzt mal halblang. Außer der ersten Frage kam doch nichts mehr. Ich hatte das gar nicht mal auf den TO bezogen, sondern nur meine allgemeinen Erfahrungen aus dem Forum geschildert. Name: schrieb: > Es ist einfach notwendig, auch mal in eine falsche Richtung zu denken > und zu gehen. Es ist aber auch notwendig, irgendwann zu erkennen, dass es die falsche Richtung ist. Und es ist notwendig, die Richtung dann auch zu korrigieren. Sonst kommt man nämlich auch nicht voran. > Wer sich selber Denkverbote auferlegt, der kommt nie voran. > Dadurch lernt man dazu. Wobei man vieles, aber nicht zwingend alles mal selber falsch gemacht haben muss, um zu lernen.
Christian R. schrieb: > Ich beabsichtige Bus-gesteuerte Module zu erstellen. Von diesen Modulen > sollten >100 ansteuerbar sein. Dafür gibt es bereits bewährte Lösungen, z.B. RS-485. Noch einfacher ist natürlich CAN, z.B. ATmega16M1. Christian R. schrieb: > Für die Module würde ich gerne den ATTiny 2313 verwenden. SPI und AVRs stehen so ziemlich auf Kriegsfuß, insbesondere, wenn der Slave auch senden soll. Sichere Datenübertragung ist damit ein Horror. Erst einige neuere AVRs haben Interrupt-Level und gepuffertes SPI. Und der ATtiny2313 hat gar kein SPI sondern nur ne USI-Krücke.
Wenn Du sowas wirklich selber machen willst und Zeit und Elan dafür hast, ... Ich würde Dir Uart statt SPI empfehlen. 1) µC mit 1 Uart und genügend IO-Pins für 7-Seg-Anzeige + ggf. Adressschalter auswählen, 7-Seg + Adresschalter etc. zum laufen bringen (Hallo-Welt LED ist halt ein Segment) 2) Uart RX zum laufen bringen. Als Inverter einen HC-14 mit 1k Serienwiderstand am Eingang. Wenn Du nun eine '5' sendest, sollten die LEDs eine '5' anzeigen. 3) Uart TX zum laufen bringen : Einfach alles was reinkommt auch rauspusten, im RX-Interrupt. Als Sender-Inverter reicht ebenfalls ein HC14 mit 1k Ausgangswiderstand. Das reicht auch, um am PC zurück zu lesen, notfalls vorläufig mit 5V-Versorgungspannung arbeiten. 4) Adressierung. Egal wie Du Dir die gedacht hast, realisiere die. Und zeige an Deinem Modul nur dann die Zahl an, wenn sie "an das Board" gesendet wurde. 5) Wenn ein Board läuft, dann mache Dir ein paar Boards mit je 2 4-poligen Steckern A (Eingang) und B(Ausgang)
1 | A B |
2 | Pin1 5V 5V |
3 | Pin2 Rx Tx |
4 | Pin3 K K |
5 | Pin4 GND GND |
K steht hier für Kurzschluss, einfach durchverbinden. Du kannst jetzt alle Boards hintereinander schalten und ausprobieren. Wenn Du am letzten Board an Stecker B Pin2 mit Pin3 verbindest, läuft das Signal auch zurück zum PC. 6) Längen optimieren Wenn das soweit läuft, dann kannst Du (mit 2 Schaltungsänderungen, also vorher fragen!), beliebig lange Ketten solcher Module aufbauen. Mit etwa 10m zwischen 2 Modulen und Baudraten bis 115200. Du must dabei jedoch die Versorgungsspannung sichergestellen, d.h. Zwischeneinspeisungen, sehr dicke Kabel oder z.B. 12V und Schaltregler auf jedem Modul. Da Du alles, was Du sendest, am Ende auch wieder empfängst, weisst Du, ob die Kette OK ist und ob alle die richtigen Daten bekommen haben. Der Begriff ist Daisy Chain, Eine Kette von Gänseblümchen.
Erst mal sorry für die späte Antwort. Warum sind manche gleich so aggro? Ich habe doch lediglich etwas gefragt. Es wäre schön, wenn das sachlich bleiben würde. Danke. Zum Thema "Anfänger und komplexes Projekt" : Ja, ich bin ein Anfänger, aber das war sicher jeder einmal. Dass ich gleich so ein großes Projekt machen will ist meiner Schule (Elektrotechniker) geschuldet. Ich muss eine Projektarbeit machen, und da wird der Prüfer von einem einfachen Blinklicht sicher nicht beeindruckt sein. Zum Thema MISO/MOSI: Da ich einen akuten Portmangel habe und ich MISO/MOSI eh frei lassen wollte, weil der yC darüber beschrieben wird (Upgrade-Möglichkeit erhalten) lag es nah erstmal zu versuchen den Bus darüber laufen zu lassen. Laut Wiki kann man damit bis in den MHz-Bereich, was eine recht hohe Geschwindigkeit gewährleistet. Mein Plan ist nun, dass ich "Verteiler" erstelle, welche für jede "Regal-Etage" (Zeile) verwendet wird. Diese lesen den ersten Teil der Adresse und geben das Paket in den Horizontalen Zweig weiter, oder halt an den nächsten Verteiler. Die Module lesen nun den zweiten Teil der Adresse und werten die Daten aus, oder geben das Paket weiter an das nächste Modul. Nun, ich rechne das mal aus (bitte korrigiert mich wenn ich hier einen Fehler mache). Ich übertreibe extra etwas, um den Grenzfall ermitteln zu können. Mal angenommen, ich hätte ein Monster-Regal mit 60 "Zeilen" und 250 "Spalten" (also 15k Fächer). Im ungünstigsten Fall muss das letzte Modul angesprochen werden. Das Datenpaket besteht nun z.B. aus: - 4x Start-Bit - 6x Bit für vertikale Adresse - 8x Bit für horizontale Adresse - 4x Bit für Prüfsumme - 4x Stop-Bit ________ 26 Bit (also 26 Takte je Datenpaket). Ich rechne nun mit 40 Takte, um Zeit für das Verarbeiten zu haben (ich übertreibe es ja gerade). Im ungünstigsten Fall muss das Paket 60 * durch die Verteiler laufen, und danach nochmal 250 * durch die Module. 310 * 40 Takte = 12400 Takte. Wenn ich noch eine Antwort vom Slave zum Master berücksichtige muss ich die Zeit * 2 nehmen (OK, das Paket wäre kürzer, aber egal...) Somit sind 24800 Takte nötig, um ein Paket an die ungünstigste Stelle zu schicken. Im günstigsten Fall wären es: 40 Takte * 2 (eine Weiterleitung vom Verteiler zum Modul) = 80 Takte Somit habe ich einen Mittelwert von 6240 Takte je Paket. Nun gehe ich wieder vom schlimmsten Fall aus, nämlich dass JEDES Fach ein Paket erhält. Das wären dann 15000 Fächer * 6240 Takte = 93,6 Millionen Takte. Bei einer Frequenz von 1 MHz wären somit 1,5 Minuten nötig, was in der Tat sehr lange wäre. Im Normalfall kann man aber eher davon ausgehen dass vielleicht 100 Fächer benötigt werden, dann sind das nur 624000 Takte, was bei 1 MHz nur 0,6 Sekunden sind (bei einem gleich langen Datenpaket). Ich denke das man bei einer Taktfrequenz von 1 MHz eine ausreichende Geschwindigkeit erreicht. Damit nun niemand denkt, dass ich "unbelehrbar" bin, was ich gerade geschrieben habe soll nur erklären, WARUM ich diesen Ansatz verfolgt habe (da ich dafür ja gleich Kritik geerntet habe). Das mit dem UART muss ich mir mal ansehen. Vielen Dank dafür, achs. Da habe ich mir anscheinend einen ordentlichen Klotz ans Bein gebunden.
Zu deinen Berechnungen: Busse synchron oder Punkt zu Punkt haben komische Eigenschaften, die nicht sofort einleuchten. In Kürze: egal, du bist immer in etwa 2 x 15k x 4 Byte fertig, also etwa 1s für alle, Wenn ein Telegramm weitergeleitet werden muss, kann schon das nächste empfangen werden. Zur Übung überleg dir, du hättest nur 3 x 3 Module, aber mit 100m Kabel dazwischen.
Da komme ich nicht so ganz mit... Wenn ich das nächste Paket los schicke, während das vorherige noch unterwegs ist und dann ein Übertragungsfehler passiert (CheckSum stimmt nicht), was ist dann? Der Slave sagt "Paket fehlerhaft, bitte nochmal schicken" und der Master schickt dann das letzte Paket nochmal (aber das vorherige war Fehlerhaft). Wo ist denn da nun mein Gedankenfehler? o_0
Mal es auf für 3 x 3 und Takte die Telegramme durch. Es gibt kein "synchron" und "weiterleiten" gleichzeitig. Und "Antwort" bei SPI ist (auch ohne weiterleiten) noch ein Kapitel für sich.
Christian R. schrieb: > Laut Wiki kann man damit bis in den MHz-Bereich Dann bist du aber schnell bei Leitungen, die "elektrisch lang" sind und folglich ganz anders behandelt werden wollen als ein kurzes Stück Draht. Solch eine Leitung will auf beiden Seiten mit ihrem Wellenwiderstand abgeschlossen werden, damit die Reflektionen nicht das Signal zu sehr stören. Da kommst du dann mit einem bewährten Bussystem (Beispiele wurden ja einige genannt) deutlich besser.
In der realen Welt werden aber Deine SPI-Signale nicht ungestört die 100m Kabel passieren. SPI benutzt man daher nur innerhalb eines Gerätes. Für die rauhe Außenwelt nimmt man jedoch Busse mit differentiellen Signalen und Interfaces mit Mehrfachabtastung eines Bits. Sehr komfortabel ist dabei der CAN-Bus. Er macht schon in Hardware die Arbitrierung, Frameerkennung, CRC-Check und Retry.
Christian R. schrieb: > Warum sind manche gleich so aggro? Willkommen hier im Forum. > Ich muss eine Projektarbeit machen, und da wird der Prüfer von einem > einfachen Blinklicht sicher nicht beeindruckt sein. Das ist eine Frage des Verkaufsarguments. :-) > Laut Wiki kann man damit bis in den MHz-Bereich, was eine recht hohe > Geschwindigkeit gewährleistet. Vergiss das mal ganz schnell, wenn du dir auch nur ein bisschen Kabellänge vorstellst. Je länger die Leitung, desto mehr Spannungsabfall über der Länge (Widerstandsbelag in Ω/m), bis das Signal nicht mehr ankommt, und desto schlechter die Signalqualität, bis das Signal nicht mehr erkannt wird. Da brauchst du Bustreiber (Verstärker) und anderes Zeugs, was dir möglicherweise in die Programmierpins pfuscht. Das ist dann nicht mehr ganz trivial (aber eher einfach lösbar). > Mein Plan ist nun, dass ich "Verteiler" erstelle, welche für jede > "Regal-Etage" (Zeile) verwendet wird. Gute Idee: Großes Problem in kleinere Probleme zerteilen. Und wenn du schon dabei bist, kannst du dir die gesamte Adressierung von Verteiler zu Anzeigen schenken, weil jeder Verteiler nur eine kleine Anzahl von Anzeigen ansteuert. Mit einfachen Schieberegistern an jeder Anzeige ist das Problem ohne Programmierung gelöst. > Ich übertreibe extra etwas, um den Grenzfall ermitteln zu können. > Mal angenommen, ich hätte ein Monster-Regal mit 60 "Zeilen" und 250 > "Spalten" (also 15k Fächer). Dann hättest du im einfachsten Fall 60 Adressen (eine pro Modul) und pro Modul 250 Anzeigen (wenn die zweistellig sind, 16 Bit pro Anzeige). Das heißt, jeder Verteiler taktet grundsätzlich 4000 Bits (500 Bytes) raus, wenn er eine Anzeige aktualisieren möchte. Kein Multiplex nötig. Die Werte selbst musst du nichtmal im Verteiler speichern, denn theoretisch kannst du den SPI-Bus auch als Ring schalten und für jedes Update einmal im Kreis takten. Damit skaliert das auch auf unendlich viele Anzeigen pro Zeile (bzw. bis dir ein Update zu lange dauert) und ist flexibel genug für unterschiedliche Regalgeometrien (unten und oben ist Großgerät mit 4 Fächern, in der Mitte ist Kleinkram mit 20, 40 und 60 Fächern pro Zeile). Nachtrag: Wenn du je zwei Zeilen kombinierst, hast du auch die Kabelverschwendung reduziert. :-D > Im ungünstigsten Fall muss das letzte Modul angesprochen werden. > Das Datenpaket besteht nun z.B. aus: > - 4x Start-Bit > - 6x Bit für vertikale Adresse > - 8x Bit für horizontale Adresse > - 4x Bit für Prüfsumme > - 4x Stop-Bit Besser: Alles in Bytes (je 1 Byte für Command, Zeile, Spalte, Wert, Checksum). Das macht die Verarbeitung schneller und vor allem einfacher. > Wenn ich noch eine Antwort vom Slave zum Master berücksichtige muss ich > die Zeit * 2 nehmen (OK, das Paket wäre kürzer, aber egal...) Bei SPI gibt es prinzipiell kein "Senden" und "Empfangen". Beides läuft gleichzeitig (naturgemäß muss der Empfänger aber erstmal wissen, was er senden soll, bevor er senden kann, aber das ist erstmal nebensächlich). > Nun gehe ich wieder vom schlimmsten Fall aus, > nämlich dass JEDES Fach ein Paket erhält. Solche Fälle kann man optimieren (1 Byte Command, 1 Byte Zeile, N Byte Daten, 1 Byte Checksum). Außerdem kann man komprimieren. > Das mit dem UART muss ich mir mal ansehen. Vielen Dank dafür, achs. Zumindest für die Verteiler würde ich ein richtiges Bussystem anvisieren. Die einzelnen Anzeigen würde ich dagegen aus praktischen Gründen (250 Controller programmieren macht keinen Spaß) "dumm" machen wollen. Also Spannungsregler+Schieberegister+Bustreiber+Anzeige, mehr muss da nicht rauf. > Da habe ich mir anscheinend einen ordentlichen Klotz ans Bein gebunden. Viel Lötarbeit, etwas Programmierung, ein gutes Stück Gehirnschmalz. Wie du selbst festgestellt hast, ist eine Minute/Update nicht sinnvoll, also musst du da optimieren. Solche Überschläge kenne ich als Bierdeckelrechnungen und die sind oft genug Anstoß für gute Ideen. :-)
:
Bearbeitet durch User
Nachdem ich nun nochmal einiges über die verschiedenen Bus-Systeme gelesen habe bin ich zu folgendem Schluss gekommen: - CAN-Bus ist ungeeignet, da dieser nur für kurze Distanzen gedacht ist (< 2m). Zudem ist das dann keine Low-Cost-Lösung mehr. - MISO/MOSI würde theoretisch gehen, da die Signale ja mit jedem Modul aufgearbeitet werden würden, aber da ist das gleiche Problem mit der kurzen Distanz. Die Taktrate müsste dermaßen runtergeschraubt werden, dass eine Übertragung an viele Teilnehmer einfach viel zu lange dauern würde. - RS-485 scheint noch am besten geeignet zu sein (danke Peter). Die Distanz kann je nach Taktrate bis zu 500 m betragen. Für mein Vorhaben reichen aber auch schon 10 Meter, wo man Datenraten von 10 Mbit/s erreichen kann. Aber selbst bei einer Distanz von 500 m erreicht man noch Datenraten von 100 kbit/s. Das ist mehr als ausreichend. Zudem werden alle Teilnehmer parallel angesprochen, was die Geschwindigkeit zur Nebensache werden lässt. Der Nachteil dabei ist, dass max. 32 Teilnehmer möglich sind. Das kann ich aber wieder umgehen indem ich "Verteiler" bastle, welche die Daten empfangen, den ersten Teil der Adresse auswertern und wenn es die eigene Adresse ist, dann werden die an 32 weitere Teilnehmer gesendet. Somit sind > 1000 Teilnehmer möglich, was völlig ausreichend ist. Ist mein Projekt so nun realisierbar?
Christian R. schrieb: > Nachdem ich nun nochmal einiges über die verschiedenen Bus-Systeme > gelesen habe bin ich zu folgendem Schluss gekommen: Oder eher Fehlschluß? > - CAN-Bus ist ungeeignet, da dieser nur für kurze Distanzen gedacht ist > (< 2m). Zudem ist das dann keine Low-Cost-Lösung mehr. Unfug! CAN geht je nach Datenrate bis mehrere hundert Meter! https://de.wikipedia.org/wiki/Controller_Area_Network#Maximale_%C3%9Cbertragungsrate_und_Leitungsl%C3%A4nge Das war ja wohl GAR NICHTS! > - MISO/MOSI würde theoretisch gehen, da die Signale ja mit jedem Modul > aufgearbeitet werden würden, aber da ist das gleiche Problem mit der > kurzen Distanz. Die Taktrate müsste dermaßen runtergeschraubt werden, > dass eine Übertragung an viele Teilnehmer einfach viel zu lange dauern > würde. Auch Käse. Selbst mit einfachen 5V CMOS Pegeln kommt man viele Meter, mitdifferentiellen Pegeln ala RS422 Dutzende Meter. > - RS-485 scheint noch am besten geeignet zu sein (danke Peter). RS485 ist ein elektrischer Standard, die logische Ebene ist eine ganz andere Frage. Man kann SPI mit MISO/MOSI etc. auch per RS485 machen. > Der Nachteil dabei ist, dass max. 32 Teilnehmer möglich sind. Schon wieder falsch. Es gibt Empfänger mit erhöhtem Eingangswiderstand, da kann man bis zu 128 oder gar 256 Empfänger an einen physischen Bus klemmen. > Ist mein Projekt so nun realisierbar? Du hast verdammt schlecht recherchiert und nix kapiert. Glückwunsch!
Christian R. schrieb: > Ist mein Projekt so nun realisierbar? Ja. Wobei Die Umsetzer, also der 2-Ebenen-Betrieb nicht trivial ist. Einfacher und robuster (Programmierung, Fehlersuche) ist die Punkt-Zu-Punkt-Verbindung. Machst Du Halb-Duplex mit je 2 Leitungen oder Voll-Duplex mit je 4?
Moin, Christian R. schrieb: > Ist mein Projekt so nun realisierbar? Nein. Never. Ever. Da geht voll in die Hose. Da bin ich mir ziemlich sicher. Mach irgendwas anderes, nicht so (raeumlich) umfangreiches als "Projektarbeit". Das soll ja auch irgendwann mal fertig werden. Wenn du noch nie mit einem µController gearbeitet hast, dann mach' erstmal was Simpleres, wo nur eine ueberschaubare Anzahl von Problemen auf dich zukommt. Gruss WK
Wenn du keine Erfahrung mit Signalübertragung auf langen Leitungen hast, wirst du ernsthafte Probleme bekommen. Informiere Dich ggf. zu den Begriffen "Wellenwiderstand", "Leitungskapazität" und "Terminierung". Ich würde vermeiden, 100 Geräte zu verketten, da bei einem einzigen Defekt alle Geräte dahinter auch betroffen sind. Wesentlich sinnvoller scheint mir eine Sternförmige Infrastruktur, eventuell mit mehreren Ebenen. I²C klingt einfach, vor allem weil es dazu fix und fertige Repeater und Multiplexer gibt. Aber I²C ist nur für kurze Leitungen gedacht. Bei mehr als 2 Metern muss man auch hier wieder die Regeln für lange Leitungen berücksichtigen. Wenn Du Dich zu dem Thema einliest wirst du merken, dass die Ausgangstreiber der I²C Busteilnehmer gar nicht gut zu korrekter Terminierung passen. I² kann man zwar beliebig langsam takten, aber die Signale müssen dennoch eine gewisse Flankensteilheit haben, die du mit langen Leitungen nicht einhalten kannst. Mit hohem Zusatzaufwand kann man das alles in den Griff bekommen, aber ich halte das für Quatsch, denn es gibt ja längst RS485 und CAN. Diese beiden Bus-Systeme sind Kandidaten, die Du Dir mal anschauen solltest (nachdem Du die Theorie der Signalübertragung auf langen Leitungen zumindest ungefähr verstanden hast). Das oben genannte DMX basiert übrigens auf RS485. RS485 Schnittstellenmodule bekommst du bei Aliexpress für etwa einen Euro pro Stück. Daran kannst du jeden beliebigen Mikrocontroller anschließen.
Falk B. schrieb: > Du hast verdammt schlecht recherchiert und nix kapiert. Glückwunsch! Das war zwar nicht nett, aber Recht hat er.
Korrektur: > Wesentlich sinnvoller scheint mir eine Sternförmige Infrastruktur, > eventuell mit mehreren Ebenen. Sternförmige Infrastruktur oder Bus, eventuell mit mehrere Ebenen
M. K. schrieb: > Der Anfänger überlegt sich eine > Lösung zu seinem Problem, läuft auf ein Hindernis auf und fragt erst > dann nach ob seine Lösung überhaupt sinn macht. In der Regel wird er wohl eher vom Forum darauf aufmerksam gemacht, dass seine Lösung kaum Sinn macht :-) Peter D. schrieb: > Dafür gibt es bereits bewährte Lösungen, z.B. RS-485. Noch einfacher ist > natürlich CAN, z.B. ATmega16M1. CAN kenne ich jetzt nicht so, aber da scheint mir ein gehöriger Software-Overhead nötig. Deshalb würde ich mit RS-485 beginnen. Literatur findet sich ja genug... Wir hatten vor langer Zeit ein Projekt, wo ca. 40 Rechnereinschübe(keine PC's natürlich) verteilt auf 3 Schaltschränke über RS-485 kommunizieren mußten. Das war nicht nur nervenaufreibend sondern auch extrem schwer zu testen! Deshalb empfehle ich dem TO, erst mal einen "kleinen" Bus auszuprobieren. Wenn das mit meinetwegen 10 Slaves gut läuft, dann kann man ja überlegen, was für die Projektarbeit noch drangestrickt werden muss...wenn es denn muss... Gruß Rainer und viel Erfolg!
Vielen Dank für die Antworten. Ein "anderes Projekt" aussuchen kann ich nicht mehr, da ich den Projektauftrag bereits ausfüllen und abgeben musste. Mein Dozent meint jedoch dass es ausreichend ist wenn ich ein paar Module anspreche, ohne Verteiler/Router. Die RS485 Treiber habe ich bereits letzte Woche bei Aliexpress bestellt. Nun habe ich aber noch ein anderes Problem: Mein Dozent meint, dass die interne Clock zu ungenau ist und ich ein Quarz verwenden sollte. Da ich nun aber schon alle Ports verplant habe würde ich gerne noch die MISO/MOSI/USCK belegen. Diese brauche ich ja, um den yC zu programmieren, aber wenn ich das richtig verstanden habe kann ich die wohl einfach als IOs benutzen, denn wenn ich Reset auf GND lege (was mein Programmer ja selber macht) wird der Programmiermodus "erzwungen". Stimmt das soweit, oder sperre ich mich aus wenn ich diese Ports als IOs verwende? Und bitte erspart mir solche Kommentare wie "du weisst ja gar nichts". Wenn ich alles wüsste würde ich das Projekt einfach fertig stellen und ich wäre gar nicht hier. Off Topic: Sachliche Kommentare wie "geht nicht, weil..." sind erwünscht, aber Kommentare wie "Oder eher Fehlschluß?" oder "Du hast verdammt schlecht recherchiert und nix kapiert. Glückwunsch!" nerven einfach nur. Es ist schön, dass manche hier anscheind als Ingenieur geboren wurden, aber es gibt auch Menschen die sowas erst lernen müssen.
Christian R. schrieb: > Mein Dozent meint, dass die interne Clock zu ungenau ist und > ich ein Quarz verwenden sollte. Für RS485 ist das der Fall. Die Ungenauigkeit spielt eher keine Rolle (kann man rauskalibirieren), aber der interne Takt ist nicht langzeitstabil und vergleichsweise stark temperaturabhängig. Christian R. schrieb: > Da ich nun aber schon alle Ports verplant habe > würde ich gerne noch die MISO/MOSI/USCK belegen. Das kannst du machen, solange du sicherstellst, dass (a) die restliche Schaltung den Programmer nicht verwirrt und (b) die Signale vom Programmer die restliche Schaltung nicht verwirren. Das heißt vor allem, dass du die an MISO-MOSI-USCK angeschlossenen Chips deaktivierst (also /CE auf High oder so), wenn der Programmer arbeitet und dass die Spannungen kompatibel sind. Ein 5V-Programmer macht einen 3,3V-Baustein kaputt. Und einen 5V-Baustein auch, wenn der Baustein kein Vcc hat, aber 5V auf den Datenleitungen sieht. Gilt auch umgekehrt für den Programmer. Der sollte das besser auch überleben. > Diese brauche ich ja, um den yC zu programmieren, Bitte schreibe µC oder uC. Alles andere ist falsch. Christian R. schrieb: > Und bitte erspart mir solche Kommentare wie "du weisst ja gar nichts". Gewöhn dich dran. Es ist nicht hilfreich, aber hier nunmal üblich - dieses Forum ist kein Kuschelparadies. Davon abgesehen ist es ja auch wahr.
S. R. schrieb: > Gewöhn dich dran. Es ist nicht hilfreich, aber hier nunmal üblich - > dieses Forum ist kein Kuschelparadies. Davon abgesehen ist es ja auch > wahr. Um Gottes Willen! Du willst dieses arme Geschöpf doch nicht etwa mit der häßlichen Realität konfrontieren? Und vielleicht sogar mit seinen eigenen Defiziten? Was bist du nur für ein grausamer Mensch! https://de.wikipedia.org/wiki/Kritikkompetenz https://de.wikipedia.org/wiki/Generation_Snowflake
Christian R. schrieb: > Mein Dozent meint jedoch dass es ausreichend ist wenn ich ein paar > Module anspreche, ohne Verteiler/Router. > Die RS485 Treiber habe ich bereits letzte Woche bei Aliexpress bestellt. > > Nun habe ich aber noch ein anderes Problem: > Mein Dozent meint, dass die interne Clock zu ungenau ist und ich ein > Quarz verwenden sollte. Da ich nun aber schon alle Ports verplant habe > würde ich gerne noch die MISO/MOSI/USCK belegen. Diese brauche ich ja, > um den yC zu programmieren, aber wenn ich das richtig verstanden habe > kann ich die wohl einfach als IOs benutzen, denn wenn ich Reset auf GND > lege (was mein Programmer ja selber macht) wird der Programmiermodus > "erzwungen". > Stimmt das soweit, oder sperre ich mich aus wenn ich diese Ports als IOs > verwende? Wenn Du ernsthaft 2 RS485 Treiber auf das Board pappen willst, also genügend Platz hast, dann solltest Du bei den IO-Ports nicht sparen. Nimm einen µC der genügend IO/Rechenleistung/Speicher-Reserve hat und bring das auf einem doppelt so großen Bord zum Laufen. Deine Lernkurve ist recht steil, wenn Du erstmal ein Board vor Dir hast. In einem späteren Schritt kannst Du (z.b. mit Charliplexing und verschiedenen Dual-Use-Tricks) meist die Pinzahl erheblich senken. Wenn Du das alles sofort machst, ist dieser nächste Schritt nicht notwendig aber der erste wird nie fertig.
Christian R. schrieb: > Da ich nun aber schon alle Ports verplant habe > würde ich gerne noch die MISO/MOSI/USCK belegen. Diese brauche ich ja, > um den yC zu programmieren, aber wenn ich das richtig verstanden habe > kann ich die wohl einfach als IOs benutzen, denn wenn ich Reset auf GND > lege (was mein Programmer ja selber macht) wird der Programmiermodus > "erzwungen". Ja, aber du musst bedenken, dass deine Schaltung dann immer parallel dazu dran hängt, oder du musst sie zum Programmieren abtrennen. S. R. schrieb: >> Diese brauche ich ja, um den yC zu programmieren, > > Bitte schreibe µC oder uC. Alles andere ist falsch. yC ist auch nicht "falscher" als uC. Christian R. schrieb: > Und bitte erspart mir solche Kommentare wie "du weisst ja gar nichts". > Wenn ich alles wüsste würde ich das Projekt einfach fertig stellen und > ich wäre gar nicht hier. Eigentlich gehört zu so einer Arbeit aber auch, dass man selber recherchiert und sich nicht alles von einem Forum vorkauen lässt. Christian R. schrieb: > Off Topic: > Sachliche Kommentare wie "geht nicht, weil..." sind erwünscht, aber > Kommentare wie "Oder eher Fehlschluß?" oder "Du hast verdammt schlecht > recherchiert und nix kapiert. Glückwunsch!" nerven einfach nur. > Es ist schön, dass manche hier anscheind als Ingenieur geboren wurden, > aber es gibt auch Menschen die sowas erst lernen müssen. Du hast geschrieben, du hättest recherchiert und dabei rausgefunden, das CAN dafür nicht geht, weil er angeblich nur <2m weit reicht. Das ist ziemlicher Blödsinn. Wenn du solche schlecht recherchierten falschen Behauptungen hier postest, musst du halt auch mit den Antworten klar kommen.
Rainer V. schrieb: > CAN kenne ich jetzt nicht so, aber da scheint mir ein gehöriger > Software-Overhead nötig. Deshalb würde ich mit RS-485 beginnen. Das genaue Gegenteil ist richtig. Bei CAN macht alles die Hardware, Du brauchst Dich um nichts zu kümmern. Du stellst einfach Nachrichten in den Sendepuffer bzw. liest sie aus dem Empfangspuffer. Die Hardware kümmert sich um den ganzen Rest. RS-485 benutzt dagegen nur die popelige UART, die sich um gar nichts kümmert, außer Bits raus bzw. reinschieben. Das Paritätsbit der UART kannst Du in der Pfeife rauchen, das ist zur Übertragungssicherung völlig unbrauchbar. Je nach Qualität der Datensicherung und Arbitrierung sind daher RS-485 Libs mehrere kB groß (>10kB sind nicht ungewöhnlich). Rainer V. schrieb: > Wir hatten vor langer Zeit ein Projekt, wo ca. 40 Rechnereinschübe(keine > PC's natürlich) verteilt auf 3 Schaltschränke über RS-485 kommunizieren > mußten. Das war nicht nur nervenaufreibend sondern auch extrem schwer zu > testen! Genau meine Rede, zuverlässiges RS-485 ist extrem aufwendig in der Softwareschicht. Meiner Meinung nach, für Anfänger ungeeignet. Insbesondere, wenn die Zeit knapp ist.
:
Bearbeitet durch User
Peter D. schrieb: > Je nach Qualität der Datensicherung und Arbitrierung sind daher RS-485 > Libs mehrere kB groß (>100kB sind nicht ungewöhnlich). So ein Krampf. Mehr als eine UART, ein GPIO und vielleicht ein CRC ist nicht nötig. Wenn überhaupt, viele µC unterstützen RS485 in Hardware. Das sind ein paar hundert Zeilen Code, wenn überhaupt. BTDT. Peter D. schrieb: > Genau meine Rede, zuverlässiges RS-485 ist extrem aufwendig in der > Softwareschicht. Ohje... Bevor das Gekläffe der CAN-Fanboys losgeht: Gegen CAN habe ich gar nichts, und mein Beitrag bezieht sich nicht darauf. Ich stelle auch nicht in Abrede, dass CAN eine Lösung für das Problem sein kann.
Ohje schrieb: > Mehr als eine UART, ein GPIO und vielleicht ein CRC ist nicht nötig. > Wenn überhaupt, viele µC unterstützen RS485 in Hardware. > Das sind ein paar hundert Zeilen Code, wenn überhaupt. Das reicht aber halt nicht damit sich mehrere Teilnehmer zuverlässig unterhalten können. Es gibt ja noch andere RS485 basierte Protokolle als CAN, z.B. Profibus. Ist aber nicht unbedingt einfacher. Nur es hat halt einen Grund warum man da oben drauf derart klobige Protokolle setzt und wer mit nichts anfängt ist schnell am dazubastlen von immer mehr Mechanismen so dass es schnell weniger Aufwand gewesen wäre auf etwas fertiges zu setzen.
Es gibt viele ausgereifte und zuverlässige RS-232 Libs, in denen oft >10 Mannjahre Entwicklung stecken. Nur ist es für einen Programmieranfänger nicht gerade einfach, komplexe Fremdlibs in ein Projekt einzubinden, zu verstehen und zum Laufen zu bringen. CAN hat dagegen den Charme, daß man es bare metal verwenden kann und es dann schon zuverlässig funktioniert. CAN-MCs sind auch nicht teuer, z.B. PIC18F25K83: 1,73€ bei Farnell.
Die ursprüngliche Idee des TE hört sich schwer nach Modbus an. Ein Mega-Schieberegister ;-)
Rolf M. schrieb: >>> Diese brauche ich ja, um den yC zu programmieren, >> Bitte schreibe µC oder uC. Alles andere ist falsch. > yC ist auch nicht "falscher" als uC. Im Gegensatz zu "y" ist "u" ein durchaus üblicher Ersatz für "µ", falls letzteres nicht vorhanden oder gewünscht ist.
S. R. schrieb: > Das kannst du machen, solange du sicherstellst, dass (a) die restliche > Schaltung den Programmer nicht verwirrt und (b) die Signale vom > Programmer die restliche Schaltung nicht verwirren. Ich werde den µC sockeln und zum programmieren herausnehmen. Rolf M. schrieb: > Du hast geschrieben, du hättest recherchiert und dabei rausgefunden, das > CAN dafür nicht geht, weil er angeblich nur <2m weit reicht. Das ist > ziemlicher Blödsinn. Wenn du solche schlecht recherchierten falschen > Behauptungen hier postest, musst du halt auch mit den Antworten klar > kommen. Ich finde den Link mit den 2 Metern nicht mehr, aber hier ist sogar von 0,4 Meter die Rede (Stichleitung): https://www.kmpdrivetrain.com/general/basics-can-bus/ Da ich anfangs davon ausgegangen bin, dass ich ein Kabel bis zum Regal lege und von da aus die Fächer per Stichleitung verbunden werden wären die 2 Meter nicht ausreichend gewesen. OK, man hätte das Kabel auch "Slalom" verlegen können und somit die Stichleitungen kürzer halten können, aber als ich das gelesen hatte war CAN für mich schon aus dem Rennen, auch weil CAN keine Low-Cost-Lösung mehr ist. Und selbst wenn ich mich verlesen hätte (2m statt 2km), dann kann man auch sachlich darauf hinweisen, anstatt gleich beleidigend zu werden. A. S. schrieb: > Wenn Du ernsthaft 2 RS485 Treiber auf das Board pappen willst, also > genügend Platz hast, dann solltest Du bei den IO-Ports nicht sparen. Ich möchte nur einen Max485 je Modul verbauen. Lediglich die Router hätten 2 Stück bekommen, aber die fallen ja nun komplett weg. A. S. schrieb: > Nimm einen µC der genügend IO/Rechenleistung/Speicher-Reserve hat und > bring das auf einem doppelt so großen Bord zum Laufen. > > Deine Lernkurve ist recht steil, wenn Du erstmal ein Board vor Dir hast. > > In einem späteren Schritt kannst Du (z.b. mit Charliplexing und > verschiedenen Dual-Use-Tricks) meist die Pinzahl erheblich senken. Wenn > Du das alles sofort machst, ist dieser nächste Schritt nicht notwendig > aber der erste wird nie fertig. Dein Argument ist nachvollziehbar, aber zum einen habe ich bereits 25 ATtiny2313 hier liegen und zum anderen soll es ja auch nicht "zu einfach" werden. Mein Dozent sagt zum Thema "Aufwand" nur: Es soll einem Techniker würdig sein. OK, das mit dem BUS habe ich unterschätzt, aber die Doppelbelegung (DIP-Schalter zum Adresse abfragen und 2x 7-Segment-Anzeige habe ich bereits entworfen (muss ich halt noch programmieren) und komme mit den Ports hin. Das Problem war nur, dass nun noch ein Quarz dazu kommt, aber wenn ich MISO/MOSI/USCK doppelt belegen kann komme ich wieder mit meinen Ports aus. Peter D. schrieb: > Bei CAN macht alles die Hardware, Du > brauchst Dich um nichts zu kümmern. Du stellst einfach Nachrichten in > den Sendepuffer bzw. liest sie aus dem Empfangspuffer. Die Hardware > kümmert sich um den ganzen Rest. > RS-485 benutzt dagegen nur die popelige UART, die sich um gar nichts > kümmert, außer Bits raus bzw. reinschieben. Das Paritätsbit der UART > kannst Du in der Pfeife rauchen, das ist zur Übertragungssicherung > völlig unbrauchbar. > Je nach Qualität der Datensicherung und Arbitrierung sind daher RS-485 > Libs mehrere kB groß (>10kB sind nicht ungewöhnlich). Das spricht in der Tat für den CAN-Bus. Genau so etwas meinte ich mit "sachliche" Kommentare. Danke. Mein Problem ist nun jedoch dass ich den Projektauftrag schon abgegeben habe (das musste ich wegen der Frist). Ich muss das also per RS485 schaffen oder ich kann mit Puntabzügen rechnen. Cyblord -. schrieb: > Ohje schrieb: >> Mehr als eine UART, ein GPIO und vielleicht ein CRC ist nicht nötig. >> Wenn überhaupt, viele µC unterstützen RS485 in Hardware. >> Das sind ein paar hundert Zeilen Code, wenn überhaupt. > > Das reicht aber halt nicht damit sich mehrere Teilnehmer zuverlässig > unterhalten können. Zählt ein Acc als Kommunikation? Mein Plan ist, dass das Paket vom PC an die Module gesendet wird. Jeder empfängt die Daten, aber NUR der Teilnehmer, der die Adresse hat antwortet. Kommt keine Antwort ist es halt ein "Time out". Das sollte doch nicht so komplex sein, oder? Habe gerade mal nachgesehen was die CAN-Treiber kosten... Verdammt, die bekommt man bei Aliexpress für < 1 Euro. Die kosten zwar knapp 7x so viel wie die RS485-Treiber, aber das wäre sicher trotzdem noch als Low-Cost durchgegangen. Sollte ich es mit dem RS485 nicht realisieren können werde ich auf CAN zurück kommen (auch wenn es mich Punkte kostet). @falk Fühlst du dich besser, wenn du einen ernst gemeinten Thread durch sinnlose Kommentare durch spam versaust? Welchen Teil von "Es nervt" hast du nicht verstanden? Sei bitte so gut und unterlasse weitere Kommentare. Du bist besser und schlauer als ich, ich bin doof, stinke und sehe scheiße aus. Nun, wo das geklärt ist könnten wir vielleicht sachlich fortfahren. Danke.
Christian R. schrieb: > Ich finde den Link mit den 2 Metern nicht mehr, aber hier ist sogar von > 0,4 Meter die Rede (Stichleitung): Aha! Es geht also um Stichleitungen, nicht um die Buslänge. Das ist natürlich was anderes. > Da ich anfangs davon ausgegangen bin, dass ich ein Kabel bis zum Regal > lege und von da aus die Fächer per Stichleitung verbunden werden wären > die 2 Meter nicht ausreichend gewesen. > OK, man hätte das Kabel auch "Slalom" verlegen können und somit die > Stichleitungen kürzer halten können, aber als ich das gelesen hatte war > CAN für mich schon aus dem Rennen, Lange Stichleitungen sind nicht nur bei CAN ein Problem.
Christian R. schrieb: > Ich werde den µC sockeln und zum programmieren herausnehmen. Noch so ein Käse. Der Rest der Welt macht das schon seit 20 Jahren nicht mehr und freut sich über die Fähigkeit von ISP (In System Programming). > Ich finde den Link mit den 2 Metern nicht mehr, aber hier ist sogar von > 0,4 Meter die Rede (Stichleitung): > https://www.kmpdrivetrain.com/general/basics-can-bus/ Mein Gott, du bist mir ja ein Experte. Selbst in dem Bild sieht ein Blinder den Unterschied zwischen der STICHleitung und der normalen Leitungslänge! > Da ich anfangs davon ausgegangen bin, dass ich ein Kabel bis zum Regal > lege und von da aus die Fächer per Stichleitung verbunden werden wären > die 2 Meter nicht ausreichend gewesen. Flasches Konzeüt. Aber das scheint deine Kernkompetenz zu sein. > OK, man hätte das Kabel auch "Slalom" verlegen können und somit die > Stichleitungen kürzer halten können, AHA!
Peter D. schrieb: > SPI und AVRs stehen so ziemlich auf Kriegsfuß, insbesondere, wenn der > Slave auch senden soll. Sichere Datenübertragung ist damit ein Horror. Was sind denn die konkreten Probleme mit AVR und SPI?
:
Bearbeitet durch User
900ss D. schrieb: > Was sind denn die konkreten Probleme mit AVR und SPI? Der Master muß nach jedem Byte eine Gedenkpause einlegen, damit der Slave garantiert das nächste Byte in das Senderegister schreiben kann. Und wenn der Slave noch andere Sachen machen soll, außer SPI, kann diese Pause ziemlich lang werden.
Peter D. schrieb: > Und wenn der Slave noch andere Sachen machen soll, außer SPI, kann diese > Pause ziemlich lang werden Danke für die Hinweise. Deshalb das gepuffert SPI bei den neueren AVRs. Der ATMEGA128 hat das sicher noch nicht. Muss ich mal nachschauen im Datenblatt. Der wird gerade geplant in einem Projekt, wo er SPI Slave sein soll. Ich darf evtl. die SW machen. Aber leider gibt es in diesem Fall keine Alternative zum 128-er.
900ss D. schrieb: > Der ATMEGA128 hat das sicher noch nicht. Muss ich mal nachschauen im > Datenblatt. Der wird gerade geplant in einem Projekt, wo er SPI Slave > sein soll. Ich darf evtl. die SW machen. Na dann viel Spaß damit. Ich würde in jedem Fall eine CRC vorsehen, um korrupte Pakete zu erkennen. Bei zuviel korrupten Paketen könnte dann der SPI-Master die Wartezeiten dynamisch verlängern. Für neue Projekte sollte man den ATmega128 aber nicht mehr einsetzen, sondern den pinkompatiblen ATmega2561.
900ss D. schrieb: > Was sind denn die konkreten Probleme mit AVR und SPI? Das Timing ist schwierig, weil der AVR kein DMA unterstützt. Solange man kein eigenes besonders entspanntes Übertragungsprotokoll verwendet, hat der AVR nur sehr kurze Momente Zeit, die Daten ins Sende-Register zu schreiben.
Stefanus F. schrieb: >> Was sind denn die konkreten Probleme mit AVR und SPI? > > Das Timing ist schwierig, weil der AVR kein DMA unterstützt. Selbst mit DMA: bei SPI Slave in Software (statt in Hardware) braucht man nach dem Eintrudeln des ersten Bytes vom Master eine Reaktionszeit, bevor man eine "customisierte" Antwort an den Slave schicken kann. Ansonsten wäre das erste Antwortbyte (das ist nicht das, was während des ersten Master-Bytes durchgeschoben wird, sondern schon das nächste) nur irgendwas fest vorgegebenes, das bereits vorher feststeht. SPI ist ein Schieberegister, das man halt gut in Hardware implementieren kann (da steht die Antwort mit dem nächsten Zyklus des Hardwaretakts bereit), aber weniger gut in Software. Es gibt halt einen Grund, warum Philips bei I²C dem Slave die Möglichkeit eingeräumt hat, um eine „Denkpause“ zu bitten.
Peter D. schrieb: > sondern den pinkompatiblen ATmega2561. Es wird der ATMegaS128 verwendet weil das Zeug später ca. 400km über dem Erdboden eingesetzt wird. Und da gibt es glaube ich nur den 128-er als S-Variante. Hab mich ehrlich gesagt noch nicht weiter informiert. Das sollten eigentlich die Kollegen machen ;) Aber das Problem beim SPI ist mir schon klar jetzt.
Stefanus F. schrieb: > 900ss D. schrieb: >> Was sind denn die konkreten Probleme mit AVR und SPI? > > Das Timing ist schwierig, weil der AVR kein DMA unterstützt. Solange man > kein eigenes besonders entspanntes Übertragungsprotokoll verwendet, hat > der AVR nur sehr kurze Momente Zeit, die Daten ins Sende-Register zu > schreiben. Der AVR hat so viel Zeit wie es dem Master beliebt. Und DMA mit Antwort von Slave ist sogar noch schwieriger als einfaches senden. DMA bringt nur bei dummen Peripheriegeräten und grossen Datenmengen einen Zeitgewinn, ansonsten gibt es keine grossen Zeitunterschiede. Selbst die ältesten AVRs können SPI mit 2MHz, da sind 4us für einen Byte (RDY/BUSY) kein Thema.
Peter D. schrieb: > Genau meine Rede, zuverlässiges RS-485 ist extrem aufwendig in der > Softwareschicht. Meiner Meinung nach, für Anfänger ungeeignet. > Insbesondere, wenn die Zeit knapp ist. Und es ist richtig, dass die CAN-Knoten harwaremäßig absolut zuverlässig arbeiten. Aber bei einem System mit 100 Teilnehmern wird man sicher mehr zu tun haben, als ein Byte in einen Puffer zu schreiben...also Software, auch wenn die unproblematische Hardware natürlich ein unschlagbares Plus ist! Und weiter möchte ich zu bedenken geben, dass die Hardware nur unproblematisch ist, wenn man gekaufte Module einsetzt! Das ist hier wohl nicht der Fall und hier gilt, sowohl für CAN oder RS-xx, dass die Hardware erst mal gut gemacht werden muß! Hier sehe ich, abgesehen von Anzahl der Teilnehmer des Bus, zwei Baustellen, die nicht ohne sind! Christian R. schrieb: > CAN-Bus ist ungeeignet, da dieser nur für kurze Distanzen gedacht ist > (< 2m). Zudem ist das dann keine Low-Cost-Lösung mehr. Nun, heute wird in unserer Firma auch nur noch CAN benutzt und es muß noch einmal gesagt werden, dass es keine Einschränkungen von lächerlichen 2 Metern gibt! Bei jedem anderen "lokalen" Bus sicher, es sei denn du packst noch mal kräftig Hardware an. Christian R. schrieb: > Mein Dozent meint jedoch dass es ausreichend ist wenn ich ein paar > Module anspreche, ohne Verteiler/Router. > Die RS485 Treiber habe ich bereits letzte Woche bei Aliexpress bestellt. Das habe ich doch schon vorgeschlagen! Wobei die Frage bliebe, wieviele "ein paar" Module denn sein sollen. Christian R. schrieb: > Mein Dozent sagt zum Thema "Aufwand" nur: Es soll einem > Techniker würdig sein. Na dann...wieviel Zeit hast du denn wirklich und das mit dem "low-cost" kannst du sicher vergessen! Ich warte mal ab und bin gespannt! Gruß Rainer
Christian R. schrieb: > Zählt ein Acc als Kommunikation? > Mein Plan ist, dass das Paket vom PC an die Module gesendet wird. Jeder > empfängt die Daten, aber NUR der Teilnehmer, der die Adresse hat > antwortet. Kommt keine Antwort ist es halt ein "Time out". Die Frage ist was tut ein Teilnehmer wenn der Empfänger kein ACK sendet? Wiederholen? Wann und wie oft? Hast du ne Checksumme an den Daten? Wie sehen die Nachrichten aus? Gibt es feste Pakete mit Kommando und Daten? Kann der Empfänger das in jedem Fall richtig aufdröseln? In der Realität hast du 1001 solche Details zu lösen. Du baust dir damit ein eigenes Protokoll. Das geht natürlich. Kann aber dauern und kann weh tun bis man alle Fälle und Ausnahmen abgedeckt hat und das ganze Robust läuft. Darum kann es Sinn machen auf etwas fertiges zu setzen.
:
Bearbeitet durch User
Cyblord -. schrieb: > Die Frage ist was tut ein Teilnehmer wenn der Empfänger kein ACK sendet? > Wiederholen? Wann und wie oft? Ja, das ist eins der 1000 Probleme und das ist der Grund, warum ich oben CAN als "Software-Intensiv" benannt habe. Das Handling aller Teilnehmer ist mehr als komplex und wird in der Regel durch 2-3-x Software-Ebenen bearbeitet. Ich spreche jetzt wieder von standartisierten, käuflichen Modulen. Und davon ist der TO meilenweit entfernt! Und nichts für ungut, man kann jetzt noch 100 ähnliche Probleme ansprechen, aber das Konzept ist ja noch nicht da!!! Rainer V. schrieb: > Es soll einem >> Techniker würdig sein. Na denn mal los! Gruß Rainer
Rainer V. schrieb: > Ja, das ist eins der 1000 Probleme und das ist der Grund, warum ich oben > CAN als "Software-Intensiv" benannt habe. Du verwechselst da was, das ACK ist bei RS-485 zwingend notwendig, nicht aber bei CAN. CAN ist auch bare metal sehr zuverlässig und sehr schlank. Eine ACK-Nachricht ist bei CAN auch kein Ding und es bremst den Master nicht aus. Bei RS-485 muß der Master aber darauf warten, d.h. den Slave zum Senden adressieren und ein Timeout aufsetzen.
Hallo, Peter D. schrieb: > Rainer V. schrieb: >> Ja, das ist eins der 1000 Probleme und das ist der Grund, warum ich oben >> CAN als "Software-Intensiv" benannt habe. > > Du verwechselst da was, das ACK ist bei RS-485 zwingend notwendig, nicht > aber bei CAN. CAN ist auch bare metal sehr zuverlässig und sehr schlank. > > Eine ACK-Nachricht ist bei CAN auch kein Ding und es bremst den Master > nicht aus. Bei RS-485 muß der Master aber darauf warten, d.h. den Slave > zum Senden adressieren und ein Timeout aufsetzen. Verwechselst Du hier ein ACK-Packet mit dem ACK-Slot beim CAN? Beim CAN muss jeder Teilnehmer, der eine korrektes Paket erkennt, nach dem CRC-Delimiter den Bus auf Dominant setzen (im ACK-Slot). Dadurch kann der Sender einen Bus-Off erkennen (wenn der ACK-Slot rezessiv bleibt). Zusätzlich muss jeder Empfänger, der einen Fehler im Paket findet einen Error-Frame senden, damit bekannt wird, dass nicht jeder Empfänger die Nachricht korrekt erhalten hat (ein dominantes ACK reicht hier nicht aus, da ja schon ein korrekter Empfang zu einem dominanten ACK führt, während alle anderen Empfänger Müll empfangen haben könnten). Diese Fehlerreaktion ist allerdings auf eine bestimmte Anzahl von Paketen beschränkt, damit ein defekter Empfänger nicht den Bus blockiert. Ist nun kein weiterer Teilnehmer am Bus folgt die Reaktion wie beim Bus-Off: Der Transmit Error counter wird hochgezählt, und es wird bis zu 256 (32) mal versucht, die Nachricht zu senden (128 mal im error active mode, also mit einem zusätzlich gesendeten Error Frame, 128 mal im error passive mode, also mit längerer Pause (passive error frame)). Da es Controller gibt, die bei einem Transmit-Error den Fehlerzähler gleich um 8 erhöhen, gehen diese schon nach 32 Versuchen in den Bus-Off. Danach geht der Sender auf Bus Off. Je nach CAN-Controller wechselt er nach einer gewissen Zeit der Bus-Ruhe (MCP2515 z.B. 128*11 Bits rezessiv auf dem Bus) wieder in den normalen Modus und die Prozedur beginnt von vorne. Bei anderen Controllern muss das Programm den Controller wieder aktivieren. Software-intensiv ist das allerdings nicht - im Regelfall läuft alles vollautomatisch ab und das Programm muss nur auf katastrophale Fehler (Bus-Off oder komplett verrauschter Bus) reagieren. Schöne Grüße, Martin
Hallo und danke für die ausführliche Beschreibung! Und wie gesagt, ich bin da nicht mehr dran. Also warten wir mal ab, was der TO jetzt macht... Gruß Rainer
Vielen Dank fpr die rege Teilnahme. Ich werde erstmal die Hardware aufbauen und erste Erfahrungen mit dem uC (sorry, per Smartphone gesendet) sammeln. Dazu werde ich versuchen die DIP-Schalter-Adresse auszulesen, und diese auf der 7-Segment Anzeige darzustellen. Wenn das klappt wage ich mich mal an den RS485 Bus dran, weil ich dafür alles daheim habe. Sollte ich überhaupt nicht weiter kommen besorge ich mir Can-Treiber und schau mal ob das besser klappt. Es sind halt meine ersten Gehversuche mit einem uC, also kann das etwas länger dauern. Wenn alles klappt brauche ich noch eine PC-Software. Wenn ich diese dann auch fertig habe stelle ich das gerne hier rein, sofern das erlaubt ist (notfalls NACH der Prüfung). Ich halte euch auf dem Laufenden. Ach ja, die Zeit für die Übertragung ist eher unkritisch. Wenn es 2 Sekunden dauert bis die Anzeige da ist kann ich auch damit leben. Viele Daten müssen ja nicht übertragen werden.
Christian R. schrieb: > Es sind halt meine ersten Gehversuche mit einem uC, also kann das etwas > länger dauern. Mit einem Bus-System? Nicht gut, da wirst du mehrere Baustellen gleichzeitig haben. Fange besser mit einzelnen Mikrocontrollern an, und mache Dich mit Debugging Methoden und einem Logic Analysator vertraut. Trial and Error wird am Bus nur noch Frust bereiten. > Wenn alles klappt brauche ich noch eine PC-Software. Brauchst du die nicht schon vorher, damit es überhaupt klappen kann?
Ich habe mich etwas ungünstig ausgedrückt. Zum Testen reicht es erst mal aus, wenn ich eien fixen String übertrage. Wenn das klappt brauche ich ein Programm um gezielte Daten zu üertragen.
Dann folge meiner Empfehlung. Diese Methode funktioniert sowohl mit Strings als auch mit Binärdaten. Auf das Verändern der Zeilenumbrüche (in der ISR bzw. im Puffer) solltest du dann allerdings besser verzichten.
OK, String war nun auch etwas übertrieben. Eigentlich möchte ich nur eine 2-Stellige Zahl übertragen (7 Bit = 0-127). Die Werte oberhalb von 99 kann ich dann für "Steuerbefehle" nutzen: Beispiel: Das Datenpaket enhält den Wert 1001001, dann soll eine 73 auf den 7-Segment-Anzeigen dargestellt werden. Wenn das Datenpaket 1111111 enthält, dann soll z.B. das Display gelöscht werden, 1111110 soll die eingestellte Adresse dezimal in der 7-Segment-Anzeige anzeigen, usw. Bei der Addressierung habe ich das gleiche vor. Die Adresse 111111 (höchster Wert soll als Broadcast dienen und alle Module ansprechen, z.B. um bei allen Modulen die 7-Segment-Anzeigen zu löschen. Aber nun mal was anderes... Wenn ich mit "DDRD = 0x64" PD2, PD5 und PD6 auf Ausgang setzte, dann werden die anderen Pins doch automatisch auf Eingang gesetzt, oder? Was passiert dann mit Rx/Tx (PD0 und PD1) ? Setzte ich die somit gleichzeitig als Eingang? Ich brauche die ja noch zum Datenaustausch als Rx/Tx. Oder funktioniert das so, dass ich Rx als Eingang und TX als Ausgang setze?
Christian R. schrieb: > Wenn ich mit "DDRD = 0x64" PD2, PD5 und PD6 auf Ausgang setzte, dann > werden die anderen Pins doch automatisch auf Eingang gesetzt, oder? Ja. Wenn du die anderen Pin unverändert lassen willst, schreibst du: DDRD |= 0x64; > Was passiert dann mit Rx/Tx (PD0 und PD1) ? Die Sonderfunktion hat vor normalem I/O immer Vorrang. Wenn serieller Transmitter und Receiver aktiviert sind, spielt die Einstellung des DDR Registers keine Rolle mehr. > Oder funktioniert das so, dass ich Rx als Eingang und TX als Ausgang > setze? Kannst du machen, ist jedoch nicht nötig.
Vielen Dank :-) Nun habe ich direkt die nächste Frage: Wie stelle ich die Clock ein? Ich überblicke die Einstellmöglichkeiten gerade nicht. Wenn ich ein Quartz verwenden (z.B. 8 MHz), dann definiere ich im Programm : "#define F_CPU 8000000", richtig? Was hat das mit den Teilern auf sich? Welches Quartz sollte ich verwenden, damit ich später bei der Datenübertragung einen gängigen (z.B. 9600 Baud, 19200 Baud, 115200 Baud) Takt hinbekomme?
Christian R. schrieb: > Nun habe ich direkt die nächste Frage: > Wie stelle ich die Clock ein? > Ich überblicke die Einstellmöglichkeiten gerade nicht. > Wenn ich ein Quartz verwenden (z.B. 8 MHz), dann definiere ich im > Programm : "#define F_CPU 8000000", richtig? Damit sagst du dem Programm, dass es davon ausgehen soll, dass der Prozessor mit 8 MHz getaktet ist - es sorgt nicht dafür, dass der Takt auch tatsächlich 8 MHz ist. Ich würde auch empfehlen, das nicht im Programm, sondern über das Makefile per Compiler-Kommandozeile zu definieren. Um einen AVR dazu zu bringen, den Quarz zu verwenden, musst du die Fuses entsprechend einstellen. > Was hat das mit den Teilern auf sich? > Welches Quartz sollte ich verwenden, damit ich später bei der > Datenübertragung einen gängigen (z.B. 9600 Baud, 19200 Baud, 115200 > Baud) Takt hinbekomme? Es gibt Baudratenquarze, die genau dafür ausgelegt sind.
:
Bearbeitet durch User
Rolf M. schrieb: > Um einen AVR dazu zu bringen, den Quarz zu verwenden, musst > du die Fuses entsprechend einstellen. Bei der Gelegenheit empfehle ich Dir, dich mit der CLKDIV8 Fuse zu beschäftigen. Viele AVR haben außerdem das in diesem Zusammenhang relevante CLKPRE Register. Dein ATtiny2313 hat keins, aber du kannst Dir das ja mal im Datenblatt des ATmega328P anschauen. Mit dem wirst du früher oder später sicher auch zu tun haben. Die Definition F_CPU wird von den delay() Funktionen verwendet, um die richtige Anzahl von befehlen auszuführen, um auf die gewünschte Verzögerungszeit zu kommen. Und sie wird von der Datei setbaud.h verwendet, um die Werte für die Baudraten-Register der USART Schnittstelle korrekt zu berechnen. Sie beeinflusst die tatsächliche Taktfrequenz jedoch nicht. Es ist deine Aufgabe, diese Definition mit dem richtigen Zahlenwert zu befüllen, damit die delay() Funktionen und die USART Schnittstelle mit dem richtigen Timing arbeiten. > Ich würde auch empfehlen, das nicht im Programm, sondern > über das Makefile per Compiler-Kommandozeile zu definieren. Das sehe ich auch so - falls Du ein Makefile hast. Was ich wiederum für empfehlenswert halte, damit das Projekt nicht von den Einstellungen der IDE abhängt. Denn IDEs werden erfahrungsgemäß öfters mal ausgetauscht.
Wie funktioniert das mit dem Makefile? Ich benutze Atmel Studio 7. Als ich das Projekt angelegt habe, konnte ich auswählen, dass ich einen Simulatior nutze möchte, was ich auch so ausgewählt habe. Wenn mich nicht alles täuscht konnte ich da auch die Fusebits einstellen. Kann man die nachträglich noch ändern, oder müsste ich dazu ein neues Projekt erstellen? Wenn ich die Fusebits im Atmel Studio einstelle, ist das dann ein Makefile? Sorry wegen der "dummen" Fragen, aber momentan ist das noch recht verwirrend für mich. Und vielen Dank für den Hinweis mit den Baudratenquartzen. Schneller ist ja nicht immer unbedingt besser (störanfälliger). Habe ich das richtig verstanden, dass ich z.B. ein Quartz mit 18,432 MHz nehme und die CPU dann mit der Taktfrequenz arbeitet und ich den Teilen durch 16 teilen kann und somit auf 1,152 MHz für die Übertragung komme? Das wäre ja schon mal gut, da ich schneller rechnen kann als die Daten empfangen werden. Aber wie geht es nun weiter? 115000 Baud ist ja ein gängiger Wert, aber wie komme ich von 1,152 MHz auf 115.000 Baud? Da ich lediglich binär sende sollten die 1,152 MHz ja auch 1,152 Bits/Sekunde darstellen, womit ein Symbol 10 Bit lang sein dürfte um zu einem Baud zu werden, oder? Ich hoffe ich habe das soweit richtig verstande, das mit den Baud, Bits/Sekunde, Taktrate, usw. bringt mich etwas durcheinander ;-) Fange ich mal rückwärts an. Wenn ich Daten mit 9600 Baud übertragen möchte und für jedes Symbol (was die Zahl beider 7-Segment-Anzeigen entspricht) x Bit brauche, dann hängt es nun von der Länge des Datensatzes ab, wie hoch die Frequenz sein muss, richtig? Da bin ich auch schon wieder bei der nächsten Frage: Wenn ich vom PC per Terminal-Programm eine "43" sende, dann sollte ich ja auf eine gängige Norm setzen. Gängig wäre z.B. 8N1 (8 Datenbits, kein Paritätsbit, 1 Stopbit). Ist da kein Startbit nötig? Warum ist es "gängig" auf das Paritätsbit zu verzichten? Auf meiner Arbeit muss ich bei einiges Tests eine Verbindung per TeraTerm aufauen und da ist die Einstellung IMMER 8N1 (lediglich die Baud-Rate muss angepasst werden). Kommt es so selten zu fehlerhaften Datenpaketen, oder warum wird meistens auf das Paritätsbit verzichtet? Macht es in meinem Fall Sinn das Paritätsbit zu nutzen (wegen der Distanz von mehreren Metern), oder wäre das für so kurze Datenpakete eher überflüssig? OK, ich gehe mal davon aus, dass ich ein Paritätsbit brauche, somit ist ein Paket bei 8E1 10 Bits lang. Ist das korrekt? Nun brauche ich 6 Bit für die Adresse und 7 Bit für die zu übermittelnde Zahl. Das könnte ich dann sauber in 2 separate Pakete verpacken, spricht das erste Paket enthält die Adresse. Das entsprechende Modul lauscht nun auf das 2. Paket und wertet die Daten aus. Da ich ja 8 Bit übertragen kann und nur 7 und 6 Bit brauche könnte ich ja auch ein Bit dazu nutzen um das Paket als Adresse oder Datenpaket zu kennzeichnen. Bitte korrigiert mich, wenn ich hier falsch liege, das ist alles nur eine Idee ohne jegliche Erfahrung. Weiter im Text... Wenn ich nun 2x 10 Bits senden muss um "ein Symbol" zu übertragen brauche ich also 20 Bits pro Symbol. Somit sind für 9600 Baud eine Frequenz von 192 kHz nötig, richtig? Wie ist das mit den Pausen zwischen den Datenpaketen? Braucht man da eine Pause? Zumindest der µC braucht eine Pause um die Daten aus dem ersten Paket auszuwerten und dann auf das 2. Paket zu lauschen. Reicht es da aus, wenn ich mehrere Stopbits sende, aber nur ein Stopbit empfange (und die rechtliche Zeit zum verarbeiten benutze), oder wie verschaffe ich dem µC eine Pause? Reicht es aus, wenn ich die Daten in 16-Bit-Stücke aufarbeite, und dann einfach per TeraTerm sende? Ich stelle mir das in etwa so vor: Adresse: 011010 Daten: 0011101 --> Daraus würde ich 1001101000011101 machen, was dann ja so beim Empfänger ankommen müsste: 1. Paket = 10011010 (das erste Bit sagt "Adresse" und die letzten 6 Bit enthalten die Adresse) 2. Paket = 00011101 (das erste Bit sagt "Daten" und die folgenden 7 Bit enthalten die Daten) Die Module lauschen alle und empfangen alle die Adresse 11010. Wenn die Adresse nicht übereinstimmt wird das folgende Paket ignoriert. Stimmt die Adresse überein wird das 2. Paket ausgewertet und die Daten (11101) als Zahl (29) auf den Anzeigen dargestellt. Wie funktioniert das mit dem Acc? Wartet TeraTerm mach jedem Paket auf ein Acc? Dann wäre das Problem mit der Pause erledigt. Wenn nicht, wie funktioniert das dann? Sorry für die 1000 Fragen, aber ich versuche das zu verstehen bevor ich das programmiere ;-)
Christian R. schrieb: > Wie funktioniert das mit dem Makefile? Guckst du hier: http://stefanfrings.de/avr_hello_world/index.html http://stefanfrings.de/avr_tools/index.html#atmelstudio > Simulator nutze ... > Kann man die nachträglich noch ändern? Ja. Aber ich benutze das Atmel Studio nicht, deswegen kann ich mich nicht daran erinnern, wo man es ändert. Du brauchst das auch gar nicht zu ändern, solange der µC Typ der selbe bleibt. Die Einstellung betrifft nur den Debugger: ob du im Simulator Debuggen willst, oder die echte Hardware (mit einem Atmel ICE). > Habe ich das richtig verstanden, dass ich z.B. ein Quartz > mit 18,432 MHz nehme und die CPU dann mit der Taktfrequenz > arbeitet und ich den Teilen durch 16 teilen kann und somit > auf 1,152 MHz für die Übertragung komme? Ja. Wobei nicht alle AVRs für mehr als 16MHz ausgelegt sind. > womit ein Symbol 10 Bit lang sein dürfte um zu einem Baud > zu werden, oder? > ...w ie geht es nun weiter? 115000 Baud ist ja ein gängiger Wert Aaah, wir sind inzwischen gar nicht mehr bei SPI. Die Beschreibung der UART Schnittstelle entnimmst du am Besten dem Datenblatt des Mikrocontrollers. Ich finde, dass Atmel diese Part sehr ordentlich dokumentiert hat. Für Baudraten-Einstellung findest du im Datenblatt sogar praktische Tabelle, die gängige Einstellungen für gängige Quarze darstellen. > OK, ich gehe mal davon aus, dass ich ein Paritätsbit brauche > ...Ist das korrekt? Keine Ahnung, was du brauchst. Die UART Schnittstelle kann jedenfalls nicht beliebig viele Bits übertragen. Ich meine es waren nur 6, 7 oder 8 Bits (optional plus parity). > Wie ist das mit den Pausen zwischen den Datenpaketen? > Braucht man da eine Pause? Die UART Schnittstelle kann pausenlos übertragen. Deine Software erfordert jedoch vielleicht Pausen. > Reicht es da aus, wenn ich mehrere Stopbits sende, aber nur > ein Stopbit empfange (und die rechtliche Zeit zum verarbeiten benutze) Ja, der UART Empfänger benötigt nur ein Stopbit, um korrekt zu funktionieren. Du kannst aber beliebig viele Stopbits senden. In der tat ist der Ruhepegel von UART einfach ein HIGH mit beliebiger Länge. Die Übertragung muss nicht einmal Taktsynchron fortgesetzt werden, jeder beliebige Zeitpunkt ist Ok. > Reicht es aus, wenn ich die Daten in 16-Bit-Stücke > aufarbeite, und dann einfach per TeraTerm sende? Ich kenne Teraterm nicht. Aber sobald Terminalprogramme ins Spiel kommen, möchte man meistens eine menschenlesbare Übertragung in Textform haben. Das finde ich auch vernünftig, denn solche Übertragungen kann man später im Fehlerfall viel leichter analysieren, als Binärdaten. Dazu sind die Funktionen atoi() und itoa() hilfreich. > Wie funktioniert das mit dem Acc? > Wartet TeraTerm mach jedem Paket auf ein Acc? Du meist sicher ACK (Acknowledge). Das UART Protokoll kennt kein solches Signal. Ob und wie du ein solches Signal übermittelst und auswertest bleibt Dir als Programmierer überlassen. Schau Dir mal die Steuerzeichen an, die der ASCII Zeichensatz definiert, die Zeichen mit dem Zahlenwert kleiner als 32 (dezimal). Vielleicht helfen Dir diese. Aber denke daran, das ASCII zum Übertragen von Text vorgesehen ist, nicht für Rohdaten in Binärform.
Wow, vielen Dank für die ausführliche Hilfe. Ich melde mich wieder wenn ich vor dem nächsten Problem stehe oder eines der "alten" lösen konnte ;-)
Kurzer Zwischenstatus. Die "Nebensachen wie 7-Segment-Ansteuerung, langen Tastendruck erkennen, Adresse auslesen) habe ich fertig und es funktioniert auch. Beim UART habe ich aber noch Probleme. Eine Übertragung findet statt, aber es kommt halt zu fehlern, Mit 2400 Baud geht es einigermaßen, aber je schneller ich die Verbindung mache desto mehr Fehler sind da (ok, ist auch logisch). Da ich alleine durch "annähnern" meiner Hand an das Steckboard mehr oder Weniger Fehler erzeugen kann habe ich nun ein ganz kurzes Stück CAT 5 Kabel benutzt. Das Probem ist weniger, aber immer noch da. Hat jemand eine Idee wie ich das in den Griff bekommen kann?
:
Bearbeitet durch User
Christian R. schrieb: > Kurzer Zwischenstatus. > Die "Nebensachen wie 7-Segment-Ansteuerung, langen Tastendruck erkennen, > Adresse auslesen) habe ich fertig und es funktioniert auch. Gut. > Eine Übertragung findet statt, aber es kommt halt zu fehlern, Mit 2400 > Baud geht es einigermaßen, aber je schneller ich die Verbindung mache > desto mehr Fehler sind da (ok, ist auch logisch). Nö, bei gescheiter Programmierung sind auch 9600 oder DEUTLICH höhere Baudraten fehlerfrei machbar. Mit an Sicherheit grenzender Wahrscheinlichkeit ist deine Software arg falsch konzipiert, weil mit tonnenweise Delays vollgestopft und blockierend. Wie man es richtig macht, steht im Artikel Multitasking. > Da ich alleine durch "annähnern" meiner Hand an das Steckboard mehr oder > Weniger Fehler erzeugen kann Dann stimmt was mit der Hardware nicht. Wackelkontakte oder offene Eingänge. > Hat jemand eine Idee wie ich das in den Griff bekommen kann? Wie wäre es mit einem Schaltplan und einem Stück Quelltext, ggf. sogar ein gescheites Bild vom realen Aufbau? Siehe Netiquette.
Sorry wegen der späten Antwort. Irgendwie muss die "Neue-Nachricht-Mail" untergegangen sein, so dass ich den letzten Kommentar erst jetzt gelesen habe. Zum Thema Schaltplan und Quellcode muss ich erst meinen Dozenten fragen, ob ich das bereits vor der Prüfung veröffentlichen darf. Es handelt sich um eine Projektarbeit mit einer Eidesstattlicher Erklärung. Vor allem dieser Satz der Eidesstattlichen Erklärung macht mich unsicher, ob ich etwas veröffentlichen darf: Die Arbeit wurde bisher weder im Inland noch im Ausland in gleicher o der ähnlicher Form einer anderen Prüfungsbehör de vorgelegt und auch noch nicht physisch oder elektronisch veröffentlicht. Da ich die Weiterbildung per "Ferstudium" mache sehe ich meine Dozenten nicht so häufig. Am Sa. den 26. habe ich meinen nächsten "Schultag", da werde ich fragen. Zum eigentlichen Thema. Ich habe das ganze nun erstmal im Simulator laufen, da kann ich äußere Störeinflusse schon mal ignorieren (vorerst). Nun habe ich zwischen den Datenpaketen kleine Pausen gelassen und nun klappt es. Im Simulator ist ein Oszilloskop, auf dem ich sehen konnte dass das folgende Startbit ziemlich kurz auf das letzte Stopbit folgte, wodurch es zu Frame-Error kam. Ich bin nun so weit, dass ich vom "virtuellen" Terminal ein Zeichen an den µC senden kann und dieser das gleiche Zeichen zurück senden (das werde ich später für das PC-Programm brauchen, damit ich eine fehlerfreie Übertragung sicherstellen kann. Das empfangene Zeichen wird per Interrupt in eine Variable gelegt und darauf wird in der Main-Schleife zugegriffen. Das klappt eigentlich super, mit 2 Ausnahmen: 1. Das erste Zeichen ist immer falsch. Nachdem das erste Zeichen falsch übertragen wurde ist der Rest fehlerfrei (im Simulator). Im virtuellen Oszilloskop ist erkennbar dass beim ersten Zeichen die Daten zwischen den Max485 auf der A-Leitung ca. 8 Volt höher liegen als beim 2. Zeichen. Ich tippe darauf, dass der Fehler zustande kommt, weil der Bus nicht terminiert ist. Obwohl das bei 3 Teilnehmer (1x MAX485 vom Modul, 1x MAX 485 zum senden vom virtuellen Terminal und 1x MAX485 zum empfangen vom virtuellen Terminal) ja auch nicht zwingen nötig wäre. Wenn ich den Bus jedoch terminiere (390 Ohm - 120 Ohm - 390 Ohm) bekomme ich keine Rechteckimpulse mehr, sondern nur noch Peaks. 2. Das zweite Problem ist, dass ich die Zeichen nicht so schnell hintereinander senden kann, da das sonst oftmals mit dem "Echo" nicht mehr klappt. Z.B. wische ich mit dem Finger schnell über die Tastatur von 1 bis 0 und sehe dann im Terminal: 00112233455667789900 --> Bei der 4 und der 8 kam es nicht zum Echo. Im Oszilloskop kann man erkennen dass die Pakete direkt hintereinander kommen und somit keine Verarbeitungszeit bleibt. Dieses Problem kann ich aber später PC-Seitig lösen, indem ich auf die Antwort warte bevor das nächste Paket raus geht.
Moin, Christian R. schrieb: > Das klappt eigentlich super, mit 2 Ausnahmen: Ehrlich: Das ist ueberhaupt nicht super. Das ist eigentlich der worst case. Es waere viel harmloser, wenn's ueberhaupt nicht klappen wuerde. Da waere die Fehlersuche viel simpler. So hast du viel mehr Action rauszufinden, was da jetzt wieder in deinem Simulator oder in deiner Software oder sonstwo schief geht. Christian R. schrieb: > Z.B. wische ich mit dem Finger schnell über die Tastatur von 1 bis 0 und > sehe dann im Terminal: Vielleicht so 'ne Sache ein bisschen "wissenschaftlicher" angehen. Also mit "normierteren" Testsequenzen. Ich formulier's mal noch so positiv, wie's grad' noch geht: Du bewegst ich noch innerhalb der von mir in meinem letzten Post gesteckten Erwartungen. Sorry for no better news. Gruss WK
Dergute W. schrieb: > Moin, > > Christian R. schrieb: >> Das klappt eigentlich super, mit 2 Ausnahmen: > > Ehrlich: Das ist ueberhaupt nicht super. Das ist eigentlich der worst > case. Es waere viel harmloser, wenn's ueberhaupt nicht klappen wuerde. > Da waere die Fehlersuche viel simpler. So hast du viel mehr Action > rauszufinden, was da jetzt wieder in deinem Simulator oder in deiner > Software oder sonstwo schief geht. Naja, ich bin eigentlich sehr froh, dass es soweit funktioniert. Ich teste das ganze mit 115200 Baud, denn wenn es hiermit problemlos läuft, dann mit kleineren Baudraten erst recht. Das Problem, dass das erste Zeichen falsch ist, weil Leitung A anscheinend mit einer Gleichspannung überlagert ist nicht schön, aber damit könnte ich "umgehen" indem ich vor dem Senden einen Broadcast verschicke und erst danach die einzelnen Module anspreche. Schöner wäre es natürlich wenn ich den Grund für die Spannungsanhebung finde. Dergute W. schrieb: > Christian R. schrieb: >> Z.B. wische ich mit dem Finger schnell über die Tastatur von 1 bis 0 und >> sehe dann im Terminal: > > Vielleicht so 'ne Sache ein bisschen "wissenschaftlicher" angehen. Also > mit "normierteren" Testsequenzen. Wenn ich Zeichen einzeln sende kommen die alle fehlerfrei an. Auch das Echo vom µC kommt fehlerfrei im virtuellen Terminal an. Lediglich das "erste" Zeichen ist fehlerhaft, danach kommen alle weiteren Zeichen fehlerfrei an. Wenn ich jedoch "zu schnell hintereinander" sende (das passiert beim "über die Tastatur wischen" kommt kein Echo mehr zurück. Die Daten werden jedoch fehlerfrei empfangen, aber bevor der µC diese bearbeiten kann kommen neue Daten per Interrupt und somit gehen vorherige Daten teilweise verloren. Warum das nur ab und zu passiert muss ich noch herausfinden. Wenn ich das Programm für den PC schreibe wird dieses Problem sich von selbst erledigen, denn der PC sendet und wartet dann auf die Antwort. Erst dann wird das nächste Paket gesendet. Somit hat der µC auf jeden Fall genügend Zeit um die Daten zu verarbeiten und der PC kann sicher sein, dass die Daten vom Modul richtig empfangen wurden. Wenn ich die Leitung terminiere wie es eigentlich gehört geht es nicht mehr (Peaks, statt Rechtecksignale). Nun muss ich erstmal herausfinden warum das so ist. Wenn ich die Datenleitung gescheit terminieren kann (inkl. Pull-Up und Pull-Down) bekomme ich das vielleicht auch hin, dass die Spannung von der A-Leitung am Anfang nicht zu hoch ist. Dann könnte auch das "erste" Zeichen fehlerfrei werden. Ich werde euch weiter auf dem Laufenden halten.
:
Bearbeitet durch User
Moin, Hm, was simulierst du denn da alles? Sind da auch echte Leitungen (mit Belaegen, etc. also transmission lines) in der Simulation? Und auch Transceiver chips? Und du hast ein Gleichspannungsversatz auf der Leitung bei einer Simulation, der das erste Byte verhunzt? Hm - na, ich drueck' mal sicherheitshalber die Daumen, hoffentlich hilfts was. Gruss WK
Christian R. schrieb: > Ich beabsichtige Bus-gesteuerte Module zu erstellen. Von diesen Modulen > sollten >100 ansteuerbar sein. > > Das "Kaskadieren" (in Reihe) sollte laut dieser Beschreibung > funktionieren: mach es doch wie WS2812B LEDs Din (Rx) und Dout(Tx) mit nicht zu hohem Takt Vorteil: Refresh vom Signal nach jeden Din durch Dout Nachteil: keinerlei Rückmeldung, Signal wird erst nach einer Pause von allen übernommen, wer nichts bekommt übernimmt auch nichts (Kette unterbrochen), für >100 und je nach Nachrichtenlänge kann es langsam, sehr langsam werden.
Hallo Joachim. So hatte ich das ja erst vor, deswegen heisst der Thread ja auch MISO/MOSI. Das ist für mein Projekt jedoch unpassend, da zu viele Module angesprochen werden müssen. Das dauert viel zu lange wenn die Daten immer weitergeleitet werden müssen und zudem ist das auch nicht für lange Leitungen ausgelegt. Ich bin soeben wieder einen Schritt weiter gekommen. Die Peaks beim Terminieren sind entstanden weil ich aus versehen A über 390 Ohm gegen Ground und B über 390 Ohm auf VCC gezogen habe. Nun habe ich es korrigiert (anders herum) und dann waren da keine Peaks mehr, aber dennoch kam da nur noch Mist an. Wenn ich nun aber nur 220 Ohm zwischen A und B schalte und zudem B über 390 Ohm auf Ground (A bleibt ohne Pull-Up), dann passt auch das erste Zeichen. Die Gleichspannungsüberlagerung ist nun weg. Warum es mit dem Pull-Up Probleme gibt verstehe ich nicht, dann egal wo ich etwas über eine RS485-Bus lese, dann ist der entweder nur mit 120 oder 220 Ohm zwischen A und B terminiert (an beiden Enden), oder zusätlich mit 390 Ohm zwischen A und VCC, sowie B und GND (Einseitig ...meist am Master). Nirgendwo habe ich mal sowas gesehen wie ich es hier gerade verwende (Pull-Down, aber kein Pull-Up). @Dergute Ich habe hier leihweise ein Notebook mit Proteus 8 Pro. Das simuliert alles mögliche. Da habe ich den ATtiny (samt hex-datei) und auch die Max487 (die Max 485 gibt es darin nicht, aber die sind ähnlich). Das Programm ist genial. Hier gibt es alles virtuell (Oszilloskop, Terminal, 7-Segment-Anzeige, usw.).
:
Bearbeitet durch User
Christian R. schrieb: > Hallo Joachim. > So hatte ich das ja erst vor, deswegen heisst der Thread ja auch > MISO/MOSI. > Das ist für mein Projekt jedoch unpassend, da zu viele Module > angesprochen werden müssen. Das dauert viel zu lange wenn die Daten > immer weitergeleitet werden müssen und zudem ist das auch nicht für > lange Leitungen ausgelegt. dann doch eher CAN-Bus gibt es ja für jeden Geschmack, von schnell bis langsam.
Wie geil :-D Ich habe das C-Programm nun wieder auf meinen ATtiny gespielt und "live" getestet. Das Echo kommt fehlerfrei an, und auch beim "Wisch" über die Tastatur kommt jedes Zeichen korrekt an. Der Simulator ist anscheinend einfach zu langsam und hat deshalb ab und zu ein Zeichen verschluckt. Da ich hier eine USB-RS485 Bridge von "in-circuit" verwende kann ich dank Dip-Schalter schnell die Terminierung ändern. Und siehe da, sowohl mit "lediglich Pull-Down", wie auch mit "Pull-Up und Pull-Down" bekomme ich trotz 115200 Baud keinen einzigen Fehler. Aktuell verwende ich nur ein Modul mit einem 20cm kurzen Kabel. Wenn alles fertig ist werde ich 10 weitere Module bauen und dann auch noch ein 20 Meter langes Kabel verwenden. Ich werde weiter berichten. Edit: @Joachim Ne, da ändere ich nun nichts mehr ;-) RS485 ist schon optimal. Ziemlich unanfällig gegen Störungen (dank Signal gegen invertiertes Signal), schnell und für lange Distanzen ausgelegt. Dieses verdammte Notebook verschluckt manchmal ein paar Tasten. Nun weiß ich auch warum ich das geliehen bekommen habe ;-)
:
Bearbeitet durch User
Christian R. schrieb: > @Joachim > Ne, da ändere ich nun nichts mehr ;-) > RS485 ist schon optimal. widerspreche ich auch nicht, Datenrate soll wohl längenabhängig sein? jedenfalls bei RS232, Can könnte wohl schneller (oder weiter? weiss ich aber nicht) Der Einfachheit halber würde ich auch bei RS485 bleiben wenns geenügt.
Nein, die Datenraten belasse ich fest auf 115200 Baud. Die maximale Reichweite von 1200 Meter wird niemals erreicht, da ich immer nur die Distanz bis zum Router berücksichtigen muss, denn jeder Router wertet das Signal aus und sendet es erneut. Bei 3 Router-Ebenen mit je max. 31 Routern und einer Modul-Ebene mit max. 31 Module kann ich somit 31^4 = 923521 Module ansteuern. Das setzt sich so zusammen: mit RS485 können max. 32 Teilnehmer angesprochen werden. Für die Adresse benötige ich also 5 Bit (0-31). Die höchtste Adresse (31) dient als Broadcast, somit bleiben noch 31 Teilnehmer (0-30), welche mit den 5 Bit angesprochen werden können. Bei den Routern gilt das gleiche. Da für jedes Modul 2 Pakete nötog sind (das erste für die Adresse, das zweite für die Daten) und jedes Modul das gleiche Paket zurück schickt (damit ich am PC den fehlerfreien Empfang prüfen kann) sind 4 Pakete je Modul nötig. (PC-Modul , Modul-PC , PC-Modul , Modul-PC) Wen nun ein Router verwendet wird sieht es so aus: PC-Router-Modul , Modul-Router-PC , PC-Router-Modul , Modul-Router-PC Das sind schon 8 Pakete. Mit jeder Router-Ebene verdoppeln sich die Paketanzahl. Mit 2 Router-Ebenen sind es 16 Pakete, mit 3 Router-Ebenen sind es schon 32 Pakete, um ein einziges Modul ansprechen zu können. Wenn man nun eine Monster-Liste von 1000 Einträgen übertragen will braucht man 32000 Pakete. Jedes Paket besteht aus 10 Bit (Startbit, 8x Datenbit, Stopbit), somit sind das 320000 Bits. Bei 115200 Bit wären also ca. 3 Sekunden nötig, um alle Module anzusprechen. 3 Sekunden wären bei so vielen Modulen noch vertretbar, aber wenn ich langsamer übertragen würde kommen leicht 2-Stellige Sekunden Übertragungszeit zustande, was dann nicht mehr akzeptabel ist. Ich könnte das ganze auch noch etwas beschleunigen, indem die Router die Antwort vom Modul nicht sofort weiterleiten, sondern erst auf "Abruf". Dann kann der PC erst Daten an alle 32 Router der höchsten Ebene senden, dann vorne wieder anfangen und die Antworten "Abrufen". So könnte die benötigte Zeit, bei guter Verteilung der Fächer, deutlich reduziert werden. Der PC müsste dann für 1000 Module 2000x Daten an den Router der höchsten Ebene senden, dann 2000x die Daten anfordern und 2000x Daten empfangen. Das wären 6000 Pakete, anstatt 32000 Pakete. Die Zeit könnte also auf ein Fünftel reduziert werden, sodern die Module schön verteilt sind. Diesen Aufwand werde ich mir aber ersparen, da eine Liste mit 1000 Stück doch recht selten wäre und dann die 3 Sekunden vertretbar wären.
Christian R. schrieb: > Ich habe noch nie mit einem Mikrokontroller gearbeitet, deswegen wollte > ich vorher mal fragen ob mein Vorhaben so realisierbar ist. Ja kein Problem, wenn du Sie alle hintereinander hängst brauchst du nicht mal eine Adresse Hat aber starke Seiteneffekte. Erstmal musst alles durch alle durchschieben, ein Ausfall, reboot, Strom weg und nichts geht mehr. Dann brauchst du ne relativ hohe Taktfrequenz. Deine 100 x deine Echtzeit ( minimale Reaktionszeit). I2C ist auch nicht geeignet, bzw. für sternförmige Topologien nicht gemacht. Auch die Buslast ist eingeschränkt, von den kapazitiven Problemen mal ganz abgesehen. LIN wäre gut geeignet, billig und hohe Reichweite. Sinnvoll wäre auch CAN. 2 Drähte parallel (also egal welches Gerät an oder aus ist) dazu 0 Volt. 100 Teilnehmer + , Adressierung, Datensicherung, lange Kabel, all inklusive. Test und Inbetriebnahme Hard und Softwares gibt es auch in allen Preis- und Geschmacksrichtungen.
HyperMario schrieb: > Ja kein Problem, wenn du Sie alle hintereinander hängst brauchst du > nicht mal eine Adresse Hast du dir wenigstens den Rest des bereits zwei Monate laufenden Threads durchgelesen? Das ist alles mehr oder weniger durchgekaut, und er befindet sich inzwischen in der Realisierungsphase …
Thread beobachten
Seitenaufteilung abschaltenBitte 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.