mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bus per MISO MOSI


Autor: Christian R. (holle)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Falk B. (falk)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
@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.

Autor: Falk B. (falk)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
@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ö.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: M. K. (sylaina)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: S------- R. (simonr)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Name: (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: OhLord (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. S. (achs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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)
       A     B
Pin1   5V    5V
Pin2   Rx    Tx
Pin3   K     K
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.

Autor: Christian R. (holle)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: A. S. (achs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Christian R. (holle)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: A. S. (achs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: Christian R. (holle)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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?

Autor: Falk B. (falk)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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!

Autor: A. S. (achs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Du hast verdammt schlecht recherchiert und nix kapiert. Glückwunsch!

Das war zwar nicht nett, aber Recht hat er.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Korrektur:

> Wesentlich sinnvoller scheint mir eine Sternförmige Infrastruktur,
> eventuell mit mehreren Ebenen.

Sternförmige Infrastruktur oder Bus, eventuell mit mehrere Ebenen

Autor: Rainer V. (a_zip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Christian R. (holle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Falk B. (falk)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Ohje (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael X. (Firma: vyuxc) (der-michl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die ursprüngliche Idee des TE hört sich schwer nach Modbus an. Ein 
Mega-Schieberegister ;-)

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (holle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rainer V. (a_zip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Rainer V. (a_zip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin L. (maveric00)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer V. (a_zip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (holle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
Autor: Christian R. (holle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (holle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (holle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Christian R. (holle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Christian R. (holle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.