mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Datenaustausch zwischen zwei Tiny2313


Autor: Paule (Gast)
Datum:

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

Autor: m. keller (Gast)
Datum:

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

Autor: Wolfgang (Gast)
Datum:

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

Autor: m. keller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATTINY2313 Datenblatt ab Seite 138
Universal Serial Interface:
Kann 3-Wire Mode (==SPI)
und 2-wire mode (==I2C)

oder eben UART

Autor: Paule (Gast)
Datum:

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

Autor: Wolfgang (Gast)
Datum:

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

Autor: Markus J. (markusj)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Paule (Gast)
Datum:

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

Autor: G a s t (Gast)
Datum:

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

Autor: G a s t (Gast)
Datum:

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

Autor: Paule (Gast)
Datum:

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

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

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

Autor: Paule (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas Eckmann
Genau das habe ich gesucht: einen µC mit zwei USARTs! Ich habe den 
Atmega644 bis jetzt immer übersehen. So'n Mist.

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
644P, um genau zu sein.

mfg.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>644P, um genau zu sein.

Wenn bis jetzt ein ATTiny2313 gereicht hat sollte es auch ein ATMega164p 
oder ATMega324p tun.

MfG Spess

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

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

Autor: spess53 (Gast)
Datum:

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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Nachtrag: Wenn kein ADC benötigt wird, kann man auch den ATMega162 
nehmen.

MfG Spess

Autor: Paule (Gast)
Datum:

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

Autor: Paule (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noch ein Zusatz:
im 'AVRISP mkII User Guide' steht unter 'features':
'Target interface protection'
Könnte das meine Frage beantworten?

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

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

Autor: Paule (Gast)
Datum:

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

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

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

Autor: Paule (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

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

Autor: Paule (Gast)
Datum:

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

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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