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.
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
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
