Hallo, habe mal eine Frage zu der Geschwindigkeit des USB to UART protocol converters von www.cesko.host.sk. Habe die Schaltung aus dem Dokument "AppNote_USBtoRS232.doc" (mit AT90S2313 und Z-Dioden) aufgebaut. Funktioniert soweit alles super. Ich habe dort ein Display angesteuert, daß ich über ein VB-Programm ansteuer. Jetzt zu meinem Problem: Die Übertragung zu den Ports am AT90S2313 ist recht langsam. Ich kann das Display (2x24) zwar ansteuern, aber es dauert mir zu lange, bis der Text auf dem Display steht. Habe mal 255 Bytes nacheinander an den Port geschickt und mal mit der Stopuhr die Zeit genommen, wie lange die 255 Bytes brauchen (ich weiß, daß das nicht gerade genau ist). Da kamen so ca. 2 Sekunden raus. Also braucht ein Byte ca. 7,8 ms (Bitte berichtet mich, wenn ich da falsch liege). Für eine Display-Ansteuerung ist das wirklich viel zu langsam. Ist das richtig, daß das sooo langsam ist? Hat da jemand mal Erfahrungen mit gemacht? Kann man die Geschwindigkeit irgendwie noch erhöhen? Oder ist das schon das Maximum? Die Routine für das Display kann ich auch nicht mehr in die Firmware einbauen, da kein Platz mehr für Quellcode vorhanden ist. Gruß PatrickHH
Hallo, habe noch nichts nachgebaut (also auch keine Erfahrung) sondern bin im Moment dabei, den Qelltext der Firmware zu analysieren. Denn mein Problem ist das gleiche wie deins: die Rechenleistung des AVR wird im Grunde komplett für das Timing des USB-Protokolls geschluckt. Igor schreibt, dass er den 10MHz-Chip mit 12 MHz übertaktet und das Timing demgemäß über die Periodendauer der Assemblerbefehle erzeugt. Meine Idee ist, den Mega8 (max. 16 MHz) zu nehmen. Dabei muss das Timing natürlich neu berechnet werden und mir ist noch nicht ganz klar, wieviel Rechenleistung das bringt, denn der Mega8 muss beim Senden und Empfangen die Zeit natürlich genauso vertrödeln wie der 2323. Bin zum Zwischenergebnis gekommen, dass ich wohl erstmal die USB-Doku lesen muss (uff, 650 Seiten, bin erst bei S.65 :o( Je länger ich darüber nachdenke, desto klarer wird mir, dass es wohl doch schlauer ist, einen USB-Chip zu benutzen, wenn man seinen Controller noch anderweitig braucht... (Dazu gibt es hier schon die verschiedensten Threads) mfg Frank Simon
Ich hatte ähnliche Timing-Probleme, allerdings mit einem USB-Controller von Cypress mit der Firmware von AK-Modulbus (Ansteuerung über nen Delphi Programm). Ich konnte sehen wir jeder einzelne Buchstabe auf dem Display geschrieben wurde. Ich denke, um da akzeptable Ergebnisse zu erzielen braucht man nen schnelleren USB-Controller. Auch der Mega8 mit der FW von Cesko wird nicht schnell genug sein. Oder man müsste die so umschreiben, das wirklich nur das nötigste gemacht wird. Sind da nicht noch Routinen für nen IR-Empfänger drin? Vielleicht kann man die mal rausnehmen. Gruß, Dominik
Hallo Dom, ich kenne die Firmware des AK-Modulbus Portbausteins sehr gut - hab den Linux Treiber dafür geschrieben - Fragen zu der Firmware werden ABER NICHT BEANTWORTET! Dein Timing-Problem muß irgendwo anders liegen. Ich kann abfrage und setzraten von bis zu 2kHz mit dem Gerät erzielen. Der 8051er in dem Chip hat NULL Overhead für den USB! Er betreibt den USB-Controller wie externes Ram mit Interrupt. Ähnliches macht der Tiny26 mit der USI Schnittstelle. So in etwa kann man sich das händlich vorstellen. Zu dem Timing - ich kenn die Firmware zwar nicht - aber läßt den Timer doch die Zeit verbummeln und arbeitet im Mainpart mit flags. Gruß
Hi Marcus,
ich habe mich schon mit dem Buchautor B. Kainka in Verbindung gesetzt
und ihm mein Problem geschildert. Er meinte dazu:
"Das liegt daran, dass jeder einzelne Transfer vier USB-Rahmen mit
zusammen 4 ms braucht. Die einzige Chance wäre eine Entwicklung, bei
der mehr Intelligenz im USB-Controller abläuft. "
Ich habe keine Möglichkeit gefunden meinen Code zu optimieren, aber
vielleicht licht das auch einfach an meinem OS, dass es nicht schneller
geht ;-)
Hier mal der Delphi Code für's LCD im 4Bit-Modus:
procedure setport(b:byte);
begin
temp1:=b;
lIn.bValue1 := b;
if (DeviceHandle <> INVALID_HANDLE_VALUE) then begin
bResult :=
DeviceIoControl(DeviceHandle,$08,@lIn,4,@lOut,8,nBytes,nil);
end;
end;
function swapx(byt:byte):byte;
begin
result:= (($0f and byt)shl 4) or (($f0 and byt) shr 4);
end;
procedure lcd_enable;
begin
setport(temp1 or $20);
setport(temp1 and $df);
end;
procedure lcd_command(cmd:byte);
begin
setport($0f and swapx(cmd));
lcd_enable;
setport($0f and cmd);
lcd_enable;
end;
procedure lcd_data(data:byte);
begin
setport(($0f and swapx(data))or $10);
lcd_enable;
setport(($0f and data)or $10);
lcd_enable;
end;
procedure lcd_init;
begin;
setport($03);
lcd_enable;
lcd_enable;
lcd_enable;
setport($02);
lcd_enable;
lcd_command($28);
lcd_command($0c);
lcd_command($04);
end;
procedure lcd_clear;
begin
lcd_command($01);
end;
"Fragen zu der Firmware werden ABER NICHT BEANTWORTET!"
>>> Kann ich mich vorstellen, A-K-Modulbus lässt sich diese ja auch
recht gut bezahlen ;) 20 für nen einzelnen Controller der ohne FW 5
kostet halte ich für übertrieben. Gerade für Schüler / Studenten...
Gruß, Dominik
Hallo Dominik, auf den ersten Blick finde ich jetzt nichts falsches. Das roblem mit dem USB-Rahmen stimmt, aber das wären dann immer noch 250Bytes/sec. Somit wärst Du theoretisch in der Lage das Display in einer Sekunde max. 3 mal zu beschreiben (80Char. Dis.). Da kannst Du nicht mehr bei zuschauen! Zur Firmware, ich hab mit dem Chip schon mal gebastelt und wer etwas fix im µC Bereich ist, der weiß auch, wie man das Ding baut. Ein Problem, was ich durchaus noch sehe, ist das dein Controller nicht mitbekommt, das es sich bei dem Chip um ein lowspeed USB 1.1 Device handelt. Ich kenne das von der Treiberprogrammierung, denn da passiert dann folgendes: Der Controller steuert den Chip mit 12Mbit an und der Controller selber versteht natürlich nur Bahnhof. Trotz Fehlerrate > 98% kommt aber eine Kommunikation zu stande. Dies ist natürlich weit unter dem, was möglich ist. Zudem haßt Du den 15kOhm Widerstand in die Datenleitung gelötet? Gern gemachter Fehler, bei dem aus mir nicht erkenntlichen Gründen einige Kontroller trotzdem die Geräte erkennen, ob wohl sie das NICHT dürften. Die Dinger werden IMHO immer seltsamer ;-) Gruß
Naja, ich konnt wirklich sehen wie jedes Zeichen einzeln hinzugefügt wurde (ich schätze mal so 5 Zeichen pro sek.) und die Daten auf dem Display waren alle korrekt. Der Widerstand war 1,5kOhm. Das stimmt doch, oder? Ich werd das demnächst noch mal auf meinem Board aufbauen, arbeite momentan an anderen Projekten. Gruß, Dominik
Ups, sorry es waren 1,5k. Gestern die vergessene 1 und heute das Komma => werd ne neue Tastatur brauchen ;-)
Hallo, vielleicht liegt es an den 2,2k und 4,7k Widerständen, daß es bei mir so langsam läuft. Werde mal die Schaltung ohne Z-Dioden und nur mit dem 1,5k Widerstand ausprobieren. Dann werde ich euch nochmal davon berichten. Gruß PatrickHH
Die "einfache" Schaltung mit dem 1,5k Widerstand hat nichts gebracht. Ist immer noch genauso langsam wie vorher. Versuche mal den Code soweit wie möglich zu reduzieren, damit ich die LCD-Routine dort noch hinein bekomme. Sonst muß ich halt nen größeren ATMEL nehmen oder nen 2. Controller. Gruß PatrickHH
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.