Hallo zusammen,
ich versuche ein Software-Handshake zu machen, aber geht nicht.
Die Daten sind vom Mikrocontroller zur CPU über UART übertragen. Dafür
benutze ich die Pin PE0 und PE1 von PORTE.
PEO ist Receive für Mikrocontroller und Transmit für CPU.
PE1 ist Transmit für Mikrocontroller und Receiver für CPU.
Im Tutorial steht:Wenn der Pin auf low ist, darf der PC senden und auf
High darf er nicht senden.
Wenn ich das Pin auf High setze, passiert gar nicht, weil ich immer
Daten von der CPU empfange.
Hier ein Teil des Programms
int main(void)
{
DDRE=0xFF;
PORTE=0x00;
if(irgendwelche Bedingung)
{
PORTE=(1<<PE0);
}
}
danke euch
Jo, ich würde mal sagen der Atmega8 hat keinen Port E. Es gibt nur Port B, C und D.
gast wrote: > ich versuche ein Software-Handshake zu machen, aber geht nicht. In welchem Zusammenhang? Falls Du ne UART meinst, SW-Handshake erfolgt über die Zeichen XON/XOFF. > Die Daten sind vom Mikrocontroller zur CPU über UART übertragen. ??? Ein MC enthält eine CPU und eine UART. > Dafür > benutze ich die Pin PE0 und PE1 von PORTE. Wofür? > PEO ist Receive für Mikrocontroller und Transmit für CPU. > PE1 ist Transmit für Mikrocontroller und Receiver für CPU. Sind PE0/PE1 die RXD/TXD der UART in Deinem MC oder GPIOs, die Du für HW-Handshake verwenden willst? > Im Tutorial steht:Wenn der Pin auf low ist, darf der PC senden und auf > High darf er nicht senden. Welches Tutorial (link)? Peter
hallo Peter,
1) ja,ich meine Handshake über UART habe ich auch mit XON(DC3) und
XOFF(DC1) im ASCII probiert, aber geht nicht.
2)Die Platine besteht aus einem Mikrocontroller und einer CPU und sie
kommunizieren über UART.
3)Mit den Pin PEO und PE1 wollte ich das Senden abbrechen.
4)Ja die Pin PE0 und PE1 sind transmit bzw receive pin über die UART
d.h PEO ist RXD0 für Mikrocontroller und TXD1 für CPU
PE1 ist TXD0 für Mikrocontroller und RXD1 für CPU
5) Habe ich so verstanden:CTS ist clear to send das Pin soll 0 sein und
RTS request to send das Pin soll 1 sein. Ausserdem habe ich einige
Beiträge im Forum gelesen, ein Moderator hat gesagt: Pin auf low darf
der Pc nicht senden und auf high darf er senden.
Mit den Pin meine ich die beide Leitungen. die für die Kommunikation
benutzt sind.
Danke
@ Gast Nach dem wie und was Du schreibst, habe ich die Vermutung, das Du etwas falsch verstanden hast. Leider lässt sich das aber nur entweder durch (meist längliche) Nachfragen oder eben durch einen Verweis auf die von Dir benutzten Quellen klären. Bitte poste: 1. Deinen Schaltplan 2. Den Link auf das Tutorial 3. Den Link auf den Thread in dem der Moderator dir das mit dem senden und nicht senden dürfen erklärt hat. Im Moment vermute ich, 1. Es gibt nur zwei Verbindungen zwischen dem Mikrocontroller und dem Prozessor. 2. Diese sollen sowohl zum senden und empfangen als auch zum kontrollieren des Sende- bzw. Empfangsvorganges dienen. Falls das so ist, ist das ein Fehler. CTS/RTS geht über zusätzliche Leitungen. Also sind mindestens zwei weitere Leitungen nötig. Schau mal hier: http://www.sprut.de/electronic/interfaces/rs232/rs232.htm#hand
Also gut. Nach Deinem Schaltplan führen nur zwei Leitungen vom Mikrocontroller zu dem Prozessor. Das ist zu wenig. Du kannst nicht die RX- oder TX-Leitung verwenden um eine zusätzliche Information zu übertragen. Du brauchst mindestens eine Leitung mehr. Das wurde aber in dem von Dir genannten Thread schon beschrieben. Dort aber handelte es sich um eine Verbindung zum PC. Hier wäre es ein wenig einfacher, weil die Pegelwandlung evtl. entfallen kann. Es wäre wahrscheinlich besser doch das XON/XOFF Protokoll zu verwenden. Das hast Du aber leider nicht zum laufen gebracht. Ich glaube Du bist mit dieser Aufgabe im Moment überfordert. 1. Du kennst nicht den Unterscheid zwischen der RS232-Norm und einem MAX232 oder MAX202 2. Du verstehst den RS232-Standard nicht. 3. Du versuchst auf einer Leitung gleichzeitg RS232 zu übertragen und eine Statusinformation. Tut mir leid Dir möglicherweise ein wenig weh zu tun, aber ich denke es ist hilfreich für Dich, wenn Du weißt wo Du stehst. Insbesondere der 3. Punkt deutet darauf hin, das Dir hier das grundlegende Verständnis fehlt. Ich empfehle Dir, Dich erstmal mit einfachen Programme und einfacher Peripherie zu beschäftigen.
Du hast von "Schaltplan" die Endung abgeschnitten. Daher weiß der Browser nicht, womit er es öffnen soll (und ich auch nicht). Peter
Hallo, @ Klugscheisser 1) warum darf ich nicht das Softwarehandshake benutzen? 2) Zwar verstehe ich nicht das Prinzip, aber womit soll ich anfangen, das simpel als die Flusskontrolle ist. 3)Ich habe schon die Kommunikation zwischen Mikrocontroller und Prossezor erstellt. Jetzt möchte ich nur das Handshake dazu einfügen. Damit der Prozessor in einem bestimmten Zeitpunkt hört zu senden auf. Hier schicke ich ihr das andere Teil von Schaltplan. Danke euch
Software-Flowcontroll (oder Handshake) macht man in der Software. Hardware-Flowcontroll mit zusätzlicher Hardware. Du sabbelst was von Software-Flowcontroll und gleichzeitig was von Hardware-Pins. Das ergibt keinen Sinn.
Angehängte Dateien:
-
temp-fehler.png
1,5 KB
hallo, ich habe auch ein problem mit dem handshake. wie funktioniert das denn genau mit dem XON XOFF. Ich schicke über Labview(Visa Schnittstelle) ein Hexstring(in der die Pulsbreite für das PWM-Signal steckt) an den Mikrcontroller. Daraufhin schicke der µC eine Temperaturwer an Labview. Allerdings habe ich bei 20 bis 21°C immer einen Fehler. Dann wird das 1. und das 2. Byte vertauscht. Kann ich die Zeichen XON und XOFF mit der Pulsbreite schicken, oder wie soll ich das machen?
1 | getPWM: |
2 | lds r16,UCSR0A |
3 | sbrs r16,7 ; Alle Daten im UDR-Register... |
4 | ret ; ... wenn nicht, dann Rücksprung |
5 | lds serdatin,UDR0 ; ... wenn doch, dann Zeichen abholen |
6 | sts OCR1AL,serdatin ; PWM bedienen |
7 | |
8 | |
9 | putTemp: |
10 | |
11 | lds r16,UCSR0A |
12 | sbrs r16,5 ; Senderegister nicht leer? |
13 | ret ; ... dann Rücksprung |
14 | sts UDR0,r18 |
15 | |
16 | ;lds r16,UCSR0A |
17 | ;sbrs r16,5 ; Senderegister nicht leer? |
18 | ;ret ; ... dann Rücksprung |
19 | sts UDR0,r19 |
20 | |
21 | |
22 | ret ; nächstes Zeichen |
andre-atmega168 wrote: > Daraufhin schicke der µC eine Temperaturwer an Labview. Allerdings habe > ich bei 20 bis 21°C immer einen Fehler. Dann wird das 1. und das 2. Byte > vertauscht. Man darf nicht davon ausgehen, das CPUs hellsehen können. Das können sie nämlich nicht! Du mußt Dir ein Protokoll ausdenken, an dem der Empfänger eindeutig erkennen kann, welches Byte welche Bedeutung hat. Falls dann mal ein Datenpaket gestört sein sollte, sichert das Protokoll, daß das nächste wieder richtig erkannt werden kann. Ein häufig genutztes sehr einfaches Protokoll ist es, Zahlen als Text zu schicken, der mit 0x0D und/oder 0x0A abgeschlossen wird. Diesen Text kann man dann z.B. per atoi oder sscanf wieder in eine Zahl zurück wandeln. Peter
@peter ich habe auch schon mal versucht, zusätlich zu den 2 Bytes noch 2 Nullen an Labview(Visa-Schnittstelle) zu schicken, so dass labview die reihenfolge erkennen kann. Allerdings habe ich es nicht geschafft, noch 2Bytes(zusammen 4Bytes) an Labview zu schicken. Es kamen immer nur die zwei Temperatur-Bytes an. Woran kann das liegen.
andre-atmega168 wrote: > ich habe auch schon mal versucht, zusätlich zu den 2 Bytes noch 2 Nullen > an Labview(Visa-Schnittstelle) zu schicken, so dass labview die > reihenfolge erkennen kann. Ein Protokoll funktioniert natürlich nur, wenn Sender und Empfänger es verwenden. Ich kenne weder Labview noch Visa. Wie die UART dort funktioniert, sollte ja in der Hilfe oder im Manual stehen. Vielleicht gibts ja in Labview schon fertige Protokolle. Peter
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.