Hallo, mit Hilfe von Forum hier bin ich zur Programmierung des µCs gekommen. Ich benutze ADuC 7027 und FT232RL, um die Messdaten durch A/D Wandlung an PC zu schicken. Ich kriege zwei Probleme: 1). Nachdem meine Platine gestartet wird (c.a nach 5 bis unendliche Minuten, unregelmäßig!), wird mein Rechner, der mit dem µC durch USB und Parallel verbunden ist, automatisch ausgeschaltet, und gleichzeitig klingelt er. Es war nicht normale bi...bi...bi... sondern bi...pu...bi...pu...Ich glaube es hat mit etwas hochfrequentiges zu tun. Ich weiß nicht genau und keine Ahnung wie den Fehler zu finden. 2). Ich habe die Treiber von FTDI schon installiert. Der Rechner kennt diesen USB-Port schon, z.B. COM3. Nachdem ich ein Programm (Daten durch UART zu senden) geflasht, es bringt nix, sieht so aus: Serial Port Object : Serial-COM3 Communication Settings Port: COM3 BaudRate: 9600 Terminator: 'LF' Communication State Status: closed RecordStatus: off Read/Write State TransferStatus: idle BytesAvailable: 0 ValuesReceived: 0 ValuesSent: 0 Soll ich ein sehr komplizierten Protokoll schreiben? Es geht nicht einfach den Register von µC einzustellen? ich habe keine Beispiele für USB-Protokoll im Internet gefunden. Ich habe keine Ahnung. Hoffe die Experte können mir helfen. Gruss Yaolan
Kennt niemand so was? Ich brauche eure Hilfe!
Gast
#338703
bi...pu...bi...pu...?????????? aus dem eingebauten pc lautsprecher ????? hört sich für mich an als wird etwas zu warm aber ob das was mit deinem problem zu tun hat????
Gast
#338704
Das Getute ist in der Regel im Handbuch zum Mainboard beschrieben. Du solltest vielleicht mal den Parallelport mal abklemmen bzw. nur zum Programmieren anklemmen.
Gast
#338705
P.O.S.T. oder Post-mortem dump heißt das , auch als Beep-codes bezeichnet, und vom jeweiligen BIOS abhängig. Es kann einfach eine verklemmte Taste bedeuten, oder ein Kurzschluß der Betriebsspannung auf einem angeschlossenen Kabel, z.B. am Maus/Tatstur-Stecker oder Joystick-Anschluß. Wenn die Kabel dünn genug sind, gibt es keinen sattem Kurzschluß, sondern nur Unterspannung, die den Prozessor neu booten läßt.
Gast
#338706
man lernt eben nie aus G
Gast
#338707
Hi, P.O.S.T. steht für Power On Self Test, einen Post mortem Dump, gibt es erst nach dem Tode, eben post mortem. Ein system das nicht startet kann aber nicht abegestürzt sein weils dafür noch zu früh ist. Eckhard
Gast
#338708
Gast
#338709
Eckhard hat recht, das sind zwei verschiedene Fälle. post mortem dump ist wie bei Witwe Boltes Hühnern: "jedes legt noch schnell ein Ei und dann kommt der Tod herbei"
Vielen Dank für eure Antworten. Ich habe schon etwas gelernt, das nie im meinen Leben vorgekommen war. Trotzdem hat es mein Problem nicht gelöst. Bei BIOS-Beep-Codes Seite, die von Mathias gegeben ist, steht alle Beeps mit einzelner Frequenz. Ich meine immer bi...bi... länger oder kürzer. Aber bei mir sind die mit zwei verschiedenen Frequenz. Wie kann ich ausfinden, was ist das Problem...
Kontaktiere den Händler, der Dir den PC verkauft hat. Oder den Hersteller des PCs bzw. des PC-Motherboards.
Gast
#338712
Überlauf am PC USB-Port?
Gast
#338713
Wenn dein Rechner nur noch bi.. pu macht dann ist etwas ganz schön schie gelaufen. Überprüfe deine Platine und dein Programm. Am USB kannst du kaum etwas falsch machen, deswegen würde ich vorschlagen du betreibst die Platine ohne Parallelport. Höchstwahrscheinlich liegt da der Fehler. Wenn dein Rechner also nicht mehr abstürzt ohne den Parallelport zu benutzen ist das ein gewisses Indiz. Ich vermute deine Schaltung treibt irgendwann gegen die Ausgänge des Parallelports. Darauf reagieren Rechner z.T. SEHR unangenehm in der von dir beschriebenen Art oder auch zusätzlich mit einem kaputten Parallelport. Ich würde an deiner Stelle den Parallelport mal mit einem Drucker testen ob er es überlebt hat. Nur so als Tip: "Ich habe an den USB und Parallelport eine Schaltung angeschlossen und wenn ich dies mache, dann macht der Rechner nach 5 Minuten bi...pu" Ist ein Satz der einem mit Sicherheit den Garantieanspruch versaut.
Gast
#338714
Lüfter ist defekt deshalb die Notabschaltung
Gast
#338715
stimmt. Das hatte ich auch mal. Den Radau machte mein Asus-Board, wenn ein Lüfter stehen geblieben ist (Drehzahl-Signal blieb aus). Entweder Lüfter-Blockade aufheben oder im Bios die Überwachungsfunktion abschalten.
Gast
#338716
... und dann auf den Brandgeruch achten ;-)
Gast
#338717
Vielen Danke für eure Tipps. Ich habe es ausgefunden, es liegt an dem Parallelport. Nachdem ich den weg gemacht habe, passiert das nicht mehr. Wie der Titel geschrieben ist, kommt nun die Frage über Protokoll des USBs. µC->UART->FT232RL->PC Ich habe schon im Programm über UART eingestellt. Die Daten werden durch UART gesendet. Aber bei PC(Matlab) habe ich keine Information gekriegt. (wie ganz oben Frage 2 geschrieben!) Was passiert zwischen UART und FT232RL? Alle passiert automatisch, oder soll ich noch etwas dazu programmieren, z.B. Protokoll von USB usw.
ich war nicht eingelogt, Noch Frage war ich!
Entire USB protocol handled on the chip - No USB-specific firmware programming required. Ich habe es von FTDI gefunden. D.h. brauche ich keinen Protokoll für USB schreiben. Aber woher kommt mein Problem? Hardwarefehler?? Hat jd Erfahrung damit?
Gast
#338720
Der FT232RL macht eigentlich alles. Er muss halt nur von Hardware aus richtig angeschlossen sein und auf dem PC muss der treiber richtig installiert sein.
Danke! Zwei Treiber habe ich schon installiert. Der PC hat schon den IC von FTDI erkannt. Ich schätze, bei FT232RL habe ich irgendwo nicht richtig geschlossen. Geht es, wenn ich DTR#, RTS#, RI#, DSR#, DCD#, CTS#, CBUS4, CBUS2, CBUS3, CBUS1, CBUS0 leer lasse? Ist PWREN# nötig?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.