Hallo erstmal. Ich möchte bei zwei Tiny2313 über einen Port einen Datenaustausch ermöglichen (Parallel-Port sozusagen). Selbstverständlich noch ein paar Pins dazu zur Steuerung. Mein Problem: Muss ich beachten, ob im 'Ruhezustand' die Pins als Ausgang oder Eingang geschaltet sind, bzw. ob als Ausgang geschaltete Pins zur Sicherheit einen bestimmten Pegel haben sollten?
Nimm doch eine serielle Schnittstelle, welche schon in Hardware vorhanden ist: TWI / I2C UART SPI Geht viel einfacher als selbst was zu entwickeln, besonders als Anfänger
Moin, Paule! Warum definierst Du nicht eine Menge an Pins fest als Ausgang, andere fest als Eingang und schließt die über Kreuz an? In logischer Folge kannst Du Peripherie verwenden, die ohnehin vorhanden ist: SPI, I²C oder USART. Schau Dir das Datenblatt an, dann geht Dir ein Licht auf. Gruß - Wolfgang
ATTINY2313 Datenblatt ab Seite 138 Universal Serial Interface: Kann 3-Wire Mode (==SPI) und 2-wire mode (==I2C) oder eben UART
Naja, die seriellen Schnittstellen sind schon belegt. Von dem einen tiny gehts zum Computer und von dem anderen zur weiteren Steuerung. Aber die Variante die 8 Bit zu teilen, wäre eine Möglichkeit. Die Kommunikation zwischen den µCs bekomme ich bestimmt hin, bin mir eben nur nicht sicher, ob's bei zwei verbundenen Pins, die als Ausgang geschaltet sind, raucht.
Paule schrieb: > bin mir > eben nur nicht sicher, ob's bei zwei verbundenen Pins, die als Ausgang > geschaltet sind, raucht. Hast Du meinen Beitrag weiter oben gelesen? Offensichtlich nicht, denn sonst hätte sich Deine jetzige Frage erübrigt. Hole es nach. Gruß - Wolfgang
Paule schrieb: > [...] bin mir > eben nur nicht sicher, ob's bei zwei verbundenen Pins, die als Ausgang > geschaltet sind, raucht. Mit Garantie. Entweder du legst fest, dass ein Teil des Bus von Controller A nach B und der andere Teil von B nach A geht, oder du legst die Leitungen via Pullup auf High und der sendende µC zieht das Signal dann auf Low, so wird das ja auch bei I2C gehandhabt. Probleme kriegst du aber mit Sicherheit, wenn beide den Ausgang aktiv auf beide Logikpegel steuern. Wenn du es kompliziert machen willst, kannst du natürlich auch ein Mini-Protokoll einsetzen mit dem jeweils einer der beiden µCs das exklusive Senderecht erhält und der andere dann auf Eingang umschaltet, wenn du fehlerfrei arbeitest funktioniert auch das ... mfG Markus
Also der ATtiny2313 ist ja kein Pin-Junkie. Daher verbietet es sich von selbst, 10 Pins für ein parallel Interface zu vergeuden. Nimm einen der 3 seriellen Busse. Peter
@Markus J. "...Mini-Protokoll einsetzen mit dem jeweils einer der beiden µCs das exklusive Senderecht erhält..." So wollte ich es eigentlich machen. Falls aber beim Umschalten der Ports etwas schiefgeht (vielleicht auch nur in der Entwicklungsphase), sieht es nicht so gut aus. Deshalb werde ich die Idee von Wolfgang verwirklichen und einen Port teilen. Das vereinfacht das Protokoll erheblich.
Paule schrieb: > Die Kommunikation zwischen den µCs bekomme ich bestimmt hin, bin mir > eben nur nicht sicher, ob's bei zwei verbundenen Pins, die als Ausgang > geschaltet sind, raucht.Beitrag melden | Bearbeiten | Löschen | Klare Antwort: Kann es ... Entweder beide als Eingang (was wenig Sinn macht, Pull-up einschalten) oder Ausgang an Eingang. Du willst schließlich Daten übertragen.
Paule schrieb: > @Markus J. > "...Mini-Protokoll einsetzen mit dem jeweils einer der beiden µCs das > exklusive Senderecht erhält..." > So wollte ich es eigentlich machen. Falls aber beim Umschalten der Ports > etwas schiefgeht (vielleicht auch nur in der Entwicklungsphase), sieht > es nicht so gut aus. Als Schutz gegen versehentliche Ausgang-Ausgang Verbindung kannst du sonst einfach einen Widerstand mit ein paar kOhm dazwischenschalten. Dann kann da nichts rauchen.
Vielleicht noch zur Erklärung: Warum gerade 'Parallel-Port'? Der eine µC unterhält sich gemütlich mit dem Computer und gibt gelegentlich Daten an den zweiten µC weiter. Dieser hat allerdings voll mit der Kommunikation mit der Peripherie zu tuen (USART) und gibt nur alle paar Millisekunden ein Zeitfenster frei, um Daten zu empfangen bzw. abzuliefern. Da fand ich die Möglichkeit mit dem Parallel-Port am schnellsten. Bei der seriellen Übertragung habe/ hatte ich immer 'Interrupt' im Hinterkopf. Das würde allerdings viel durcheinander bringen. Möglich wären vielleicht auch ein paar zusätzliche Leitungen zur Steuerung. So nach dem Motto: Ich habe da was für dich, wenn du Zeit hast, sag Bescheid...
Irgendwie ist dein ganzes Konzept nicht so ganz rund. Mit 2 Controllern zu arbeiten, wobei der eine nur auf den anderen wartet, macht doch nicht wirklich Sinn. Nimm einen Controller mit 2 USARTs, z.B. Atmega 644. Mit dem einen USART handelst du die Kommunikation mit der Peripherie ab und der andere kommt an den PC. Wenn der PC Daten sendet, speichert der Controller die angekommenen Daten in einem Buffer und wenn Zeit ist, werden diese ausgewertet. Das ist im Gegensatz zu der Synchronisation bei der parallelen Kommunikation überhaupt nicht zeitkritisch. mfg.
@Thomas Eckmann Genau das habe ich gesucht: einen µC mit zwei USARTs! Ich habe den Atmega644 bis jetzt immer übersehen. So'n Mist.
Hi
>644P, um genau zu sein.
Wenn bis jetzt ein ATTiny2313 gereicht hat sollte es auch ein ATMega164p
oder ATMega324p tun.
MfG Spess
spess53 schrieb: > ATMega164p > > oder ATMega324p tun. Das ist richtig. Tut sich preislich aber nichts. Der 644p von Reichelt ist der günstigste von allen. mfg.
Hi
>Der 644p von Reichelt ist der günstigste von allen.
Wie kannst du das vergleichen? Bei Reichelt finde ich keinen ATMega164p
oder 324p. Bei CSD sind da 2€ Unterschied.
MfG Spess
Hi Nachtrag: Wenn kein ADC benötigt wird, kann man auch den ATMega162 nehmen. MfG Spess
Ich muss noch mal fortsetzen. Da ich Schwierigkeiten sehe, wenn beim atmega644 (o.ä.) beide USARTs gleichzeitig Daten empfangen sollen, würde ich die Variante 2x attiny2313 mit Datenaustausch über USI mal weiterverfolgen. Da ich gern auf der Platine die µCs programmieren möchte, stellt sich mir allerdings folgendes Problem: Durch die Verbindung von DO -> DI und DI -> DO, die ja gleichzeitig die Pins für MOSI und MISO sind, würde ja der Ausgang MISO des zweiten µC am Ausgang des 'AVR mk2 ISP' hängen. Programmiert wird da zwar nichts, solange der Reset-Pin nicht auf low liegt. Aber es ist eben Ausgang auf Ausgang. Deshalb meine Frage: Weiß jemand, ob der Programmer intern über Widerstände bzw. eine Strombegrenzung verfügt um diesen Zustand zu erlauben?
noch ein Zusatz: im 'AVRISP mkII User Guide' steht unter 'features': 'Target interface protection' Könnte das meine Frage beantworten?
Jetzt sind wir ja wieder am Anfang. Paule schrieb: > Da ich Schwierigkeiten sehe, wenn beim atmega644 (o.ä.) beide USARTs > > gleichzeitig Daten empfangen sollen Welche Schwierigkeiten siehst du da? Ich sehe da keine. mfg.
@Thomas Ich habe zwar noch nicht nachgerechnet, aber reicht denn die Zeit Zeit beim Empfang eines Datenpaketes die einzelnen Bytes (dann sicherlich immer abwechselnd) beim ungefähr gleichzeitigen Auftreten eines Interrupts aus dem Puffer zu holen und abzuspeichern ohne das nächste zu verpassen? (Der eine USART soll mit 57,6 BAUD laufen)
Paule schrieb: > aber reicht denn die Zeit Zeit Wenn du in der Interruptroutine keine großen Berechnungen durchführst reicht das dicke. Bei 57,6 bekommst du maximal 5760 Bytes/s. Bei einem 20MHz-Controller hast du dann 20 Mio / 5760 = 3472 Taktzyklen Zeit, bevor das nächste Byte da ist, um ungefähr das hier zu machen: ISR(USART0RX_vect) { nRx0Buf[nRx0++] = UDR0; } ISR(USART1RX_vect) { nRx1Buf[nRx1++] = UDR1; } Das reicht. mfg.
@Thomas doch sicherlich eher 3472/10? Denn ich darf ja das Start-BIT nicht verpassen. Aber, auch bei meinen geplanten 6,144MHz (gängige Baud-Raten lassen sich da prima mit 0% Fehler einstellen) bleiben immer noch über hundert Takte. Die Frage wäre jetzt nur noch, wie kurz das Startbit sein kann, damit es noch als solches erkannt wird.
Paule schrieb: > (Der eine USART soll mit 57,6 BAUD laufen) Da gähnt der AVR nur. Bei nem üblichen Baudratenquarz 7,3728MHz hast Du:
1 | 7,372MHz / 57,6kHz * 10 * 3 = 3840 Takte |
Zeit, in der Du Interrupts sperren darfst. Die UART kann nämlich 3 Byte a 10 Bit puffern. Peter
Paule schrieb: > doch sicherlich eher 3472/10? Denn ich darf ja das Start-BIT nicht > > verpassen. Nein. Ist doch schon mit eingerechnet. Peter Dannegger schrieb: > Die UART kann nämlich 3 Byte a 10 Bit puffern. Wieder was gelernt. mfg.
> Peter Dannegger schrieb: >> Die UART kann nämlich 3 Byte a 10 Bit puffern. Ja, ich auch! So weit war ich noch gar nicht vorgedrungen. Also sozusagen: Empfangspuffer + FIFO (Datasheet: 'The recive buffer consists of a two level FIFO') Nochmal wegen meiner 'Berechnung': Stimmt. Ich muss ja nicht auf das Startbit warten, das macht ja die USART (oder der, oder das?). Allerdings sollte man nicht zu sehr rumtrödeln. Es könnten ja noch mehr Daten ankommen...
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.