Hallo. Ich versuche seit einigen Tagen, meinem Windows 10 PC Software Handshake beizubringen. Es geht darum, das der Arduino (Programmiert unter Atmel Studio 7) eine große Textdatei (ca. 4MB) bekommt ('gesendet' mit Terra Term) und bearbeiten soll. Unter 'Quasi-Echtzeit', d.h. so schnell abarbeiten wie möglich, geht alles gut. Wenn aber eine zeitliche Verzögerung ins AVR Programm rein kommt, um die Abläufe in eine brauchbare Geschwindigkeit zu bringen, dann hört der PC nicht auf zu senden, wenn XOFF vom AVR gesendet wird. Da der AVR XON und XOFF korrekt sendet vermute ich mal, das Problem liegt beim Windows10 PC. Wenn einer Rat weiss... Viele Grüße Jürgen
Juergen schrieb: > vermute ich mal, das Problem > liegt beim Windows10 PC. Wie ist die Treiber in der Window -Systemsteuerung konfiguriert? - Ist XON eingeschaltet?
Sowohl im Gerätemanager als auch in Terrterm ist Flow-Control auf XON/XOFF.
> Da der AVR XON und XOFF korrekt sendet
Weisst du das? Oder glaubst du das?
Du solltest das vielleicht mal mit einem 2. Rechner testen
und das XON/XOFF haendisch senden.
Juergen schrieb: > Da der AVR XON und XOFF korrekt sendet vermute ich mal, das Problem > liegt beim Windows10 PC. Schau mal im Gerätemanager unter Einstellungen erweitert. Da steht die FIFO-Größe. Wenn da 4096 steht, heißt das, bei Empfang des XOFF können schon 4kB in der FIFO stehen, die dann erstmal gesendet werden, ehe das XOFF greift. Falls das Terminalprogramm eigene FIFO-Einstellungen hat, dann gelten diese.
Ich habe 2 AVRs genommen. Einer davon mit einem Testprogramm. Das hat funktioniert. Der FIFO ist aus, die Einstellung hat aber keinen Einfluss auf das Ergebnis. Windows bzw. das Terminalprogramm senden frühlich drauf los...
Achso, der FIFO am AVR ist so programmiert, das der XON und XOFF an der FIFO 'vorbeimogelt' und direkt verschickt.
Was muß denn der AVR mit den 4MB alles machen, daß er nicht mitkommt? Benutzt Du eine echte UART oder einen USB-RS232 Umsetzer? Hast Du mal ein anderes Terminalprogramm probiert? Schreib dochmal ein Testprogramm, ob der PC das XOFF völlig ignoriert oder nur verspätet bearbeitet.
Hallo. Der AVR ist eigentlich schnell genug, nur die Ausgabe muss mit einer bestimmten Geschwindigkeit erfolgen. Die Eingabedatei ist GCode und als Ausgabe wird über zwei Galvanometer ein blauer Laser gesteuert. Das ganze hoffentlich so genau, das es für die Platinenbelichtung reicht. Da der Fotolack ja eine bestimmte Belichtungszeit braucht, kann ich den Laser nicht mit der vollen Geschwindigkeit darüber fahren lassen. Das bremst die ganze Verarbeitung aus. Gruß Jürgen
Als UART benutze ich den, der auf dem Arduino Mega2560 drauf ist. Also der ATmega16U2. Als Terminalprogramm habe ich Putty und Terra Term probiert. Und auch einige andere, wo aber irgendwie das feature fehlt, Dateien zu senden... Der Test mit den beiden AVRs war mit Termite (kennt das wer? Das ist ein Terminalprogramm, wo man zwei Com-Ports koppeln und quasi mitlesen kann. Das hat die Steuerzeichen als solche erkannt und korrekt angezeigt. Bei Interesse kann ich ja mal zwei HEX-Files und eine abgespeckte GCode-Datei hochladen. Nen Arduino hat doch fast jederin der Grabbelkiste und mehr Hardware brauchts nicht zum testen. Ausser dem PC natürlich...
So. Habe eben unten stehendes Testpropgramm auf den AVR geflasht. Und siehe da: Nichts! Der PC hört einfach nicht auf zu senden.
1 | #include <avr/io.h> |
2 | |
3 | #define F_CPU 16000000UL |
4 | #include <util/delay.h> |
5 | |
6 | #include "uart.h" |
7 | |
8 | int main(void) |
9 | { |
10 | uart0_init(); |
11 | uart0_puts("UART Initialized!"); |
12 | /* Replace with your application code */ |
13 | while (1) |
14 | { |
15 | uart0_putc(0x13); |
16 | _delay_ms(2500); |
17 | uart0_putc(0x11); |
18 | _delay_ms(2500); |
19 | } |
20 | } |
Juergen schrieb: > Der PC hört einfach nicht auf zu senden. Das Problem dürfte an der verwendeten Schnittstelle liegen. Du nutzt USB-CDC, das kennt kein XON/XOFF. Was auch immer Du im jeweiligen Terminalprogramm einstellst, wird dem Treiber mitgeteilt (und nicht vom Terminalprogramm selbst ausgewertet). Nimm eine andere USB-Seriell-Bridge, also keine, die CDC nutzt. Die üblichen Verdächtigen von Prolific, FTDI, CHS etc. kommen in Frage.
Verflixt. Na dann werde ich einige USB-RS232 Wandler mit offenen Kabelenden bestellen. Dann kann ich evtl. auch Hardware-Handshake einsetzen. Hatte nur gehofft, den Hardwareaufwand so gering wie möglich zu halten. Jetzt kommt wieder eine Plaine dazu... ;) :( Ein herzliches Dankeschön an alle die hier mitgeholfen haben. Viele Grüße Jürgen
Würde das denn über Bluetooth (SPP) und ON/XOFF gehen? Gruß Jürgen
Bitte 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.