Bitte um prüfende Blicke - vUSB ATMEGA

[thomasmaintz (Gast)]

Hallo liebes Bastlerinnen und Bastler!

Ich möchte gerne für meine Carrera-Bahn einen Rundenzähler bauen. Dieser 
soll Infrarotdioden (SFH309FA) auslesen (Carrera Digital Autos haben 
eine IR LED unter der Karrosserie, welche in einem typischen 
Frequenzverhältnis blinkt) und die ausgelesenen Daten kurz aufbereiten 
und dann via USB als HID Gerät bereitstellen.

Dazu habe ich ein Board mit einem ATMEGA entworfen und die Schaltungen 
aus vUSB von obdev.at genutzt. Laut Hinweis von 
"http://www.wasserstoffe.de/carrera-hacks/infrarot-erkennung/index.html"; 
habe ich Komparatoren für die bessere Flankenaufarbeitung der 
Photodioden verwendet.

Das Projekt ist von der Hardware auf dem Schaltplan und dem Board 
fertig. Allerdings neige ich dazu, schnell einige Dinge zu übersehen. 
Daher meine Frage, ob hier über das Layout gesehen werden kann. (Die 
LEDs sind absichtlich unterhalb des Displays)

Alle Dateien befinden sich im USB-Interface.zip im EAGLE Format.

Und vielleicht etwas grundsätzliches: Hat jemand Erfahrung mit der 
Auslastung von vUSB auf einem ATMEGA? Kann ich hier noch eine 
Frequenzerkennung sowie eine Zeitmessung parallel laufen lassen, oder 
ist das dem kleinen (veralteten) Controller zu viel (ich verwende 16MHz 
Quarze als Taktgeber)?

Liebe Grüße,
Thomas

[Jim M. (turboj)]

thomasmaintz schrieb:
> Auslastung von vUSB auf einem ATMEGA? Kann ich hier noch eine
> Frequenzerkennung sowie eine Zeitmessung parallel laufen lassen,

Eher nicht. VUSB beansprucht den Controller AFAIK zu 100% während der 
eigentlichen Übertragung zur Signalgenerierung, da fallen dann auch 
Interrupts hinten runter.

Atmega mit Hardware USB hat das Problem nicht. Das restliche Timing ist 
bei USB eher entspannt (im ms oder s Bereich).

[c-hater (Gast)]

Jim M. schrieb:

> thomasmaintz schrieb:
>> Auslastung von vUSB auf einem ATMEGA? Kann ich hier noch eine
>> Frequenzerkennung sowie eine Zeitmessung parallel laufen lassen,
>
> Eher nicht. VUSB beansprucht den Controller AFAIK zu 100% während der
> eigentlichen Übertragung zur Signalgenerierung, da fallen dann auch
> Interrupts hinten runter.

So ist es, die sind nämlich während der gesamten Zeit der USB-Tranfers 
gesperrt, weil diese ihrerseits als exlusiv laufender Code einer ISR 
geschrieben sind.

Aber: natürlich kann man trotzdem Zeiten messen oder Frequenzen 
erkennen. Dazu gibt es sogar mehrere Möglichkeiten.

1) Der V-USB-Code kann schon bei 12MHz laufen. Bei 16MHz tut er also 
logischerweise mindestens 25% seiner Zeit rein garnix, als zu warten. 
Statt nur zu warten, kann an dieser Stelle auch etwas nützliches gemacht 
werden. Das ist nicht ganz einfach (sondern fortgeschrittene 
Assemblerprogrammierung) aber möglich. Es gibt z.B. eine 
V-USB-Implementierung (für 18MHz), in der diese Zeit benutzt wird, um 
tatsächlich die eigentlich zum USB-Standard gehörende Prüfsumme in 
Echtzeit zu bilden und zu prüfen, die bei der 12MHz-Implementierung 
schlicht ignoriert wird. Eine einfache Zeitmessung ist viel weniger 
rechenzeitaufwendig als diese Prüfsummengeschichte. Hier bietet sich 
sogar förmlich an, die Struktur des V-USB-Codes selber zu nutzen, der ja 
die festen Bitzeiten mit den 1,5MHz des USB-LowSpeed-Timing generiert.

2) Gibt es Hardware, die natürlich auch dann läuft, wenn die Interrupts 
gesperrt sind und die in der Lage ist, äußere Ereignisse eine gewisse 
Zeit lang sozusagen zu "puffern". Das ist bei jedem Atmega erstmal die 
ICP-Funktion von Timer1, die genau für solche Anwendungen vorgesehen 
ist. Hier kommt es einzig darauf an, den Timer hinreichend langsam 
laufen zu lassen, so dass das Durchlaufen des vollen Zählumfangs länger 
dauert als ein kompletter USB-Transfer (kein Problem). Aber natürlich 
kann man mit dieser Lösung längst nicht so hohe Frequenzen erfassen wie 
mit der Software-Lösung, da man ja die gesamte Zeit eines Transfers 
nicht dazu kommt, den gemessen Wert von der Hardware abzuholen und 
auszuwerten. Man ist also logischerweise auf Frequenzen beschränkt, 
deren Periode mehr als doppelt so lang ist, wie die Dauer eines 
kompletten USB-Transfers.

3) Man kann 1) und 2) auch noch kombinieren. Damit ist dann eine sehr 
genaue Zeitmessung (Auflösung: 67,5ns) für Frequenzen bis knapp zur 
Hälfte der USB-Bitrate möglich. Damit kommt man also in den 
x*100kHz-Bereich.

[Jürgen (Gast)]

Nimm nen ATMEGA32U4 mit LUFA, der kann echtes USB und den Rest Deines 
Programms kannst Du weiter benutzen.
Es macht keinen Sinn eine Schaltung neu zu entwerfen und dann solche 
Krücken wie VUSB zu benutzen wenn es nicht nötig ist.

[Axel R. (Gast)]

www.wasserstoffe.de/carrera-hacks/infrarot-erkennung/index.html

wäre er bei seiner Lichtschranke mal besser GLEICH am Emitter vom 
fototransistor raus gegangen...


StromTuner

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Ich lasse V-USB auf einem Tiny85 mit 16Mhz (ext. Oszillator) laufen und 
behandle nebenbei eine ISR gesteuerte Soft-UART (als non-blocking) für 
den Empfang der seriellen Daten eines Tabletts.
Das ist alles in C geschrieben und funktioniert ganz normal als HID 
Device an Windows, Linux und Mac. V-USB muss lediglich die höchste IRQ 
Priorität haben (am besten also INT0 oder INT1), die Soft UART läuft mit 
einem Pinchange- und Timerinterrupt.