Hallo, ich messe über einen Capture Interrupt Frequenzen bis ca 50kHz, funktioniert soweit auch alles ziemlich genau. Ich nutze TIM1 und habe einen OVF Interrupt und einen Capture Interrupt. Die gemessenen Werte übergebe ich an HTerm mit Hilfe folgender Library (beruht auf der von ST soweit ich weiß): http://mikrocontroller.bplaced.net/wordpress/?page_id=1263 Die Werte übergebe ich allerdings nicht als string sondern als 4*8bit Datenpakete. Auch das funktioniert eigentlich ganz gut, aber nach einigen übertragenen Werten stoppt bei HTerm die Anzeige. Dabei stoppt es (scheinbar) wirklich und nicht nach einer bestimmten Anzahl von Datenpaketen, aber immer nach einem kompletten Datenpaket. Hat vielleicht jemand einen Tipp an was es liegen könnte? Hab in den beiden Interrupts schon Pin Toggeln lassen und auch nach der Ende der Ausgabe, hängt es nicht in einem der beiden Interrupts fest, die Pins toggeln munter weiter. Könnte es irgendein Problem geben, weil die USB-Kommunikation auch über Interrupts arbeitet? Der Capture Interrupt benötigt 170 Ticks für einen Durchlauf (bei 160MHz). Würde mich sehr über eure Hilfe freuen. :)
Ich vermute, dass irgendwas mit den USB Flags nicht passt..komisch ist nur, dass dann die anderen Interrupts problemlos weiterlaufen? Usb hat Priorität 1 - 3, capture Interrupt 0 - 0, OVF Interrupt 0 - 1. Würde mich wirklich sehr über Hilfe freuen, hab schon einiges probiert,aber gab leider noch keine merkbare Besserung.
Mark W. schrieb: > aber immer nach einem kompletten Datenpaket. Die meisten CDC Implementation vergessen das Zero Packet. Das braucht man wenn eine Übertragung ein ganzes Vielfaces der MaxPacketLen des Endpoints ist - i.d.R 64 Bytes. Das dient zur Signalisierung "Übertragung abgeschlossen" - und nur dann liefert der "COM Port" auch die Daten an die Applikation aus. Echte UARTs füllen den Puffer nicht schnell genug um die 64 Bytes zu ereichen, und kürzere USB Pakete haben denselben Effekt wie Zero Packets.
Mark W. schrieb: > Die gemessenen Werte > übergebe ich an HTerm mit Hilfe folgender Library... Ja, eben. Ich kriege ziemliche Bedenken gegen diese Lib, wenn ich da lesen muß: "Die LIB erwartet beim empfang als Endekennung das Zeichen “0x0D” = CarriageReturn (das muss der PC also am Stringende anhängen)" "In der Library gibt es eine Sende und eine Empfangsfunktion für Strings und eine Funktion zum testen ob die USB-Verbindung steht." und "Auf der PC Seite muss der “VirtualComPort-Driver von ST” installiert sein." Also, diese Lib scheint nur blockweise zu funktionieren und verhält sich damit eben ganz anders als ein echter VCP. Der soll Zeichen übertragen - und zwar in beiden Richtungen und völlig egal, was das für welche sind und ob sie hereinrauschen oder nur tröpfeln. Ich hatte vor Zeiten schon mal meinen Virtuellen COM-Port hier gepostet. ch hab den für Nuvoton, LPC (egal ob ARM7TDMI oder Cortex) und STM32. Melden tut er sich immer als Nuvoton-VCP, aber das ist eigentlich schnurz, weil ohnehin nur der bei Windows enthaltene Treiber benutzt wird. Bei Bedarf suche einfach mal im Forum. W.S.
Vielen Dank für eure Hilfe. Habe das Problem mittlerweile gefunden, es lang daran, dass ich den Takt des uC geändert habe, aber vergessen habe den Teiler für Usb auf die 48MHz anzupassen. Von der Lib nutze ich die String Funktionen gar nicht, nur dir UB_VCP_DataTx() direkt. Werde mir trotzdem mal die Dateien von dir anschauen, weil es um einiges angenehmer wäre, wenn man nicht den Treiber von ST braucht.
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.