Hallo auch, ich habe gestern mit mit meinem Kumpel ein hypothetisches Projekt einer Messstation besprochen dabei stellten sich einige Fragen: Auf einer Grundplatine sollen, sagen wir mal 10 Tochterplatinen mit AVRs betrieben werden. Die Grundplatine besitzt eine Master-AVR der die Anderen verwalten soll. Die Kommunikation zum Ansprechen soll, sagen wir mal über eine Software-UART mit geringer Baudrate (4800 oder 9600 Bps) betrieben werden. Also alle AVRs auf den Tochterplatinen bekommen die gleichen Informationen über die UART. Wird z.B. eine 8 Übermittelt, soll ebend die 8.te Tochterplatine angesprochen werden. Das ganze soll natürlich als Binärwert übertragen werden, denn so kann man ja auch mehrere AVRs gleichzeitig aktiv schalten. Würde das Vorhaben eigentlich so funktionieren und wenn ja, wie kann man dennn die Kommunkikation der einzelnen Tochterplatinen mit dem Master-AVR realisieren, ohne das die Komunikationen sich gegenseitig stören? Habt ihr eine Idee dazu?
Markus Barkholz schrieb: > Die Kommunikation zum Ansprechen soll, sagen wir > mal über eine Software-UART mit geringer Baudrate (4800 oder 9600 Bps) > betrieben werden. Schlechte Idee, besser ist es, die vorhandene USART verwenden. Im Datenblatt ist ein "Multi-processor Communication Mode" beschrieben, die sich optimal dafür anbietet. Andere werden Dir IIC empfehlen.
Markus Barkholz schrieb: > Würde das Vorhaben eigentlich so funktionieren Ja, würde es. Ein AVR Ausgang (TxD) sollte eigentlich 10 Eingänge (RxD) noch treiben können. > und wenn ja, wie kann man > dennn die Kommunkikation der einzelnen Tochterplatinen mit dem > Master-AVR realisieren, ohne das die Komunikationen sich gegenseitig > stören? Mittels einem Dioden-OR. Du führst einfach alle TxD Ausgänge der Slaves zusammen, wobei du sie mit einer Diode entkoppelst.
1 | TxD---------->|-------+ |
2 | | |
3 | | |
4 | TxD---------->|-------+ |
5 | | |
6 | | |
7 | TxD---------->|-------+------------> RxD |
es geht ja nur darum, dass jeder TxD den RxD Eingang vom Master auf High ziehen kann, ohne dabei gegen die Lows der anderen TxDs ankämpfen zu müssen. Dass die Slaves nur dann reden dürfen, wenn sie vom Master angesprochen werden, versteht sich von selbst.
Ja, das würde so funktionieren, wenn man Open Collector bzw Open Drain Treiber einsetzt. Schau Dir LIN an, das ist im Prinzip genau das, wobei hier aber 12V Pegel verwendet werden. https://prof.beuth-hochschule.de/uploads/media/LIN-Bus_MuellerSommerStegemann.pdf Und noch etwas: Meist ist es einfacher, einen größeren Controller zu verwenden als mehrere kleine. Das vermeidet den Aufwand der Prozessorkommunikation und Synchronisation und ist damit effizienter. fchk
Karl Heinz schrieb: > es geht ja nur darum, dass jeder TxD den RxD Eingang vom Master auf High > ziehen kann, ohne dabei gegen die Lows der anderen TxDs ankämpfen zu > müssen. RxD wird immer '1' sein, das dies der Ruhepegel der TxD-Leitungen ist ;-) Die Entkopplung kann entfallen, wenn bei der MPCM-Adressierung nur der TxD-Pin aktiviert ist, der auch senden darf. Will man dennoch Treiber verwenden, dann eignen sich am besten solche, wie sie für den CAN-Bus verwendet werden.
M. N. schrieb: > Karl Heinz schrieb: >> es geht ja nur darum, dass jeder TxD den RxD Eingang vom Master auf High >> ziehen kann, ohne dabei gegen die Lows der anderen TxDs ankämpfen zu >> müssen. > > RxD wird immer '1' sein, das dies der Ruhepegel der TxD-Leitungen ist > ;-) Ach Mist. Das bring ich immer durcheinander, welches der Ruhepegel auf der +-12V und der +5V Schiene einer USART ist. Sorry, für die Fehlinformation.
Also I²C habe ich auch überlegt. Doch wie ich dann die Adressierung durchführen soll, bleibt mir ein Rätsel. Also wie vergibt man da eindeutige IDs und so.
Und ja, wenn mn eine größeren/leistungsfähigeren AVR nutzt wirds natürlich kleiner. Nur habe ich bestimmt 3 dutzen AVRs Mega328 hier rumfliegen und die werde ich wohl nie alle verbauen. Deshalb dachte ich mit mal so eine Art messstation im Acrylgehäuse, ähnlich einem 19" Gehäuse zu Anschauungszwecken und NUR für mich als Lernobjekt zu realisieren. Mehr steckt da nicht hinter.
Und dann wäre da noch die Frage der Takterzeugung. Überlegt habe ich mir einen 3.6864 Baudratenquarz. Aber nur einen für alle. Würde das auch funktionieren?
Markus Barkholz schrieb: > Also I²C habe ich auch überlegt. Doch wie ich dann die Adressierung > durchführen soll, bleibt mir ein Rätsel. Also wie vergibt man da > eindeutige IDs und so. Was gefällt dir an 1, 2, 3, 4, 5, ... nicht? Da wohl nicht damit zu rechnen ist, dass jemals andere I2C Geräte an deinen 'Bus' kommen, brauchst du dir da keinen Zwang anzutun. Ich würds allerdings trotzdem mit der Hardware UART machen. Dann eben ein Dioden-AND anstelle eines Dioden-OR. Ist ja nicht weiter wild: die Dioden umdrehen und ein Pullup.
:
Bearbeitet durch User
Gefallen tut mir das schon. Ich hab nur keinen Plan wie ich das umsetzen soll. BASCOM-Anfänger. I²C hab ich noch nicht wirklich verstanden. Einen EEProm oder LM75 Temperatursenser war eine Sache. Da gab es aber Beispiel-Codes von MyAVR
Markus Barkholz schrieb: > Gefallen tut mir das schon. Ich hab nur keinen Plan wie ich das umsetzen > soll. BASCOM-Anfänger. ? BASCOM hat doch eh schon alles für dich erledigt! > I²C hab ich noch nicht wirklich verstanden. Einen > EEProm oder LM75 Temperatursenser war eine Sache. Da gab es aber > Beispiel-Codes von MyAVR Tja. Dann sollte man sich über Beispiele auch mal etwas schlau machen und nicht nur abschreiben. Du rufst I2cstart auf, um eine Übertragung zu starten. Das nächste Byte, bzw das erste was nach dem I2cstart übertragen wird, ist die Adresse, wer überhaupt angesprochen werden soll. Die eigentliche Adresse steht in den Bits 7 bis 1, im Bit 0 ist codiert ob sich dieses Gerät als 'du kriegst einen Wert von mir' oder 'Ich will einen Wert von dir' betrachten soll. Ganz einfach. http://rn-wissen.de/wiki/index.php/Bascom_I2C_Master Auszug
1 | const Pcf_write = &H40 ' Slaveadresse |
2 | .... |
3 | |
4 | Do |
5 | I2cstart |
6 | I2cwbyte Pcf_write |
7 | I2cwbyte &HAA |
8 | I2cstop |
Pcf_write ist die Adresse. Die &H40 aufgedröselt in Bits
1 | 7 6 5 4 3 2 1 0 |
2 | +---+---+---+---+---+---+---+---+ |
3 | | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | |
4 | +---+---+---+---+---+---+---+---+ |
5 | ^ |
6 | | | | |
7 | +--- die eigentliche -------+ | |
8 | Adresse | |
9 | +--- Bit ist 0: daher Schreibzugriff |
weiterer Auszug aus dem Code
1 | Const Pcf_read = &H41 |
2 | |
3 | .... |
aufegdröselt in Bits
1 | 7 6 5 4 3 2 1 0 |
2 | +---+---+---+---+---+---+---+---+ |
3 | | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | |
4 | +---+---+---+---+---+---+---+---+ |
5 | ^ |
6 | | | | |
7 | +--- die eigentliche -------+ | |
8 | Adresse | |
9 | +--- Bit ist 1: daher Lesezugriff |
:
Bearbeitet durch User
Da hast'e recht. Also I²C erspart natürlich auch bauteile. Und lesen/verstehen sollte man den Code auch können. Nur gefiel mir die UART-Geschichte ganz gut weil ich damit umgehen kann.
Markus Barkholz schrieb: > Da hast'e recht. Also I²C erspart natürlich auch bauteile. Und > lesen/verstehen sollte man den Code auch können. > > Nur gefiel mir die UART-Geschichte ganz gut weil ich damit umgehen kann. Kannst du ja machen. Ein Dioden-AND mit einem Pullup ist ja so wild auch wieder nicht.
Die Vorhandene USART wollte ich für die Kommunikation mit einem Bluetooth-Modul zur Kommunikation mit dem PC oder Handy nutzen. Deshalb blieb bei den mir zur Verfügung stehenden Mega328 nur die SoftUART mit geringer Bps als Alternative. Oder Umgedreht. Die Soft UART mit 9600 Bps fürs BT-Modul. Mehr kann das Ding nämlich eh nicht - sehe ich grad im Datenblatt. Dann wäre die Hard-UART ja frei
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.