www.LaserFreak.net

Hallo,

für ein microcontrollerprojekt will ich einen FT232RL verwenden. Beschaltung ist standard und aus dem datenblatt übernommen. Laut datenblatt kann ich unbenutzte pins einfach unbelegt lassen - nur leider ist eagle da anderer meinung und quittiert mir das mit einem fehler.
Abgesehen davon ist _DTR lt. datenblatt ein ausgang, und kein eingang ! Weiterhin sagt das datenblatt auch nicht, ob ich OSCI auf HIGH oder LOW ziehen kann wenn der interne oszillator nicht benötigt wird. Was ist mit den RS232 statusleitungen vom FT232 ? Der USART des µC hat keine sondern nur TxD/RxD.

Hi,


all deine Signale lasse ich offen.

Der RL hat ja im Gegensatz zum Vorgänger EEProm, Quarz und die
Schutzwiderstände mit drin.

Extern nur noch die 10yH in der 5V Leitung bei Bus-Powered,
der 3.3nF und ein 100nF Angstkondensator

So löppt es in einer Standart USB -> RS232 Wandlung.

Benutze aber Target und nicht Eagle , bei beiden gilt aber:

Traue keiner Bibliothek die du nicht selber erstellt hast...

Das ist erprobt und geht.

Gento

Das Problem liegt in der Bauteildefinition. Normale CMOS Eingänge dürfen nicht offen bleiben, sondern müssen definiertes Potential haben. Deswegen schreit das Programm in diesem Fall - sollte aber nur ein "Warning" (Meldung, Programm arbeitet weiter) sein und kein "Error" (Fehler der zum Programmabbruch führt). Das Programm weis nicht, daß diese Eingänge bei diesem speziellen IC unbeschaltet sein dürfen. Wenn du sie in der Bauteil/Symboldefinition als "analog" oder "tri-state" statt "input" definierst, bzw _DTR als "output", dann sollte das Programm keine Fehlermeldungen mehr ausgeben.

@Rainer,

was macht R18 ?? Ist das ein "Platzhalter" für die Drossel ?
Mit meinem C 3,3nF hab ich mich vertan, ist ein 10nF. Stimmt
so bei Rainer.

Hi,

wo ihr gerade so schön bei dem teil seid. Ich hätte da mal eine frage bezüglich der dll und der programmierung damit.

ich habe beim empfangen unter delphi, also dem aufruf der funktion ft_read(..), eine dauer von 500ms laut gettickcount. das finde ich etwas viel. gibt es einen trick diese kürzer zu halter?

intern läuft in der dll ja ein extra thread der den FTDI dauert auf empfangene daten abfragt, wieso dauert dann die übergabe via ft_read(..) nur so lange?

mfg

Thomas

ich empfehle den ftdi nicht über die dll sondern über den com-port abzufragen! So sind auch 1Mbit möglich!

Alex20q90 wrote:ich empfehle den ftdi nicht über die dll sondern über den com-port abzufragen! So sind auch 1Mbit möglich!

1 000 000 / 8 = max 100 000 Byte

100 000Byte / X+Y+R+G+B+I = knapp max 10K Ausgabespeed.

Was für ein schlechter TIP.

Gento

@Rainer,

Thomas würde für ne ILDA Ausgabe keinen 232 nehmen denke ich.


@Thomas,
was solls denn werden ? Normale Serielle Übertragung oder
viele Daten ?

Guido wrote:
Benutze aber Target und nicht Eagle , bei beiden gilt aber:

Traue keiner Bibliothek die du nicht selber erstellt hast...

Hi,

Ware Worte!!
Mich hat es auch schon mehrmals erwischt!!

Gruß Serial

Hi,

nein. sicher keine Laserausgabe dafür ist der doch zu schwach. soll eine rs485 schnittstelle für eine überwachung werden.

also eigentlich nicht so zeitkritisch. aber 500ms sind doch zu viel. und ich würde gern die dll verwenden, da ich mit dieser gleich die FTDIs suchen kann und nicht den comport vorher einstellen muss. aussderm kann es doch nicht sein das die dll so viel langsamer ist als der comporttreiber von windows.

mit der dll sollte ja dann auch das maximum von 3Mbit erricht werden, was ich zwar nicht brauche, aber bei deinem funktionsaufruf von 500ms doch etwas komisch ist.

hab ihr damit noch nicht gearbeitet?
Gento du hast doch auch das teil auf deiner neuen safety drauf. wie kommunizierst du denn mit der? Sicher nicht über den virtuellen Comport oder? Finde ich jedenfalls nicht so elegant, da der user ja doch wieder einen port auswählen muss. mit der dll kannst du gleich nach den teilen suchen und mit denen sprechen

gruß thomas

Hallo,

vielen dank für die antworten ! Platine ist jetzt in auftrag - hoffentlich ohne fehler