Re: Fragen zum TSB12LV32 Controller Interface

Hallo Andreas,

Also laut TI (Tech Support) ist das der aktuelle "General Purpose LLC". Ich habe schon mal darüber angedacht den TSB15LV01 zu verwenden. Dieser ist sogar auch IIDC compliant, aber hat nur ein 10bit Interface! Er ist gedacht, um direkt (über ein AFE) einen Image Sensor anzusteuern. Und für meine Anwendung somit nicht geeignet. Auch die anderen Chips haben alle andere Einsatzgebiete (OHCI, AV, DV,....). Andere wie NEC oder Philips haben nix besseres :(

Wie oben beschreiben, habe ich einen konstanten Kameradatenstrom von

640*480*30fps=9,216Mpx/s (12bit breit, wobei ich das ganze für 16bit auslegen möchte).Für einen Iso-Cycle ergibt sich dann (von Cycle Start Skew mal abgesehen) ein Input 9,216Mpx/s*152us=1152pixel(word). Laut der IIDC Spec besteht ein ISO Paket aus 1280pixel. Also muß das FiFo maximal 2*1280pixel speichern können (ergibt 40kbit FiFo, hätte aber zu Anfang mal lieber etwas Reserve).

Genau das macht mir die meisten Sorgen! Der ATmega hat ja den "External Memory Port". Aber er muliplext das Low Adress byte (DA7:0) und am LV32 habe ich ja getrennte Adress- und Datenleitungen. Kann ich das passend machen?

Da ich nur einen Port brauche, reicht mir der TSB41AB1.

Nee, eben nicht. Ich habe halt das Buch von Anderson(2nd Edt). Da ist aber alles so schön beschrieben, ich denke mal das müßte reichen. Zur IIDC 1394-based Digital Camera Specification habe ich Zugang.

Danke Jochen

Das kommt auf deinen FPGA-Typ an. Am besten mal beim Hersteller im Internet nachsehen.

In der Regel genauso wie den normalen uC, nur man baut den Binärcode anschließend in das VHDL des FPGA ein. Ich kenn jetzt im Moment nur den Picoblaze von Xilinx genauer. Bei dem setzt die Software den Assembler in VHDL um. Aber dere Core ist halt genau für die FPGAs entwickelt worden.

Das kommt auf die Größe deines FPGAs an. Ich habe damals im übrigen zuerst versucht ein FIFO in einem CPLD zu benutzen. Da dies aber nicht klappte hab ich dann ein FIFO genommen. Das hat aber auch einige Probleme gemacht. So hat es Probleme mit der ersten Speicherstelle gehabt, so daß ich von den isochronen Daten die ersten acht Bit als letzte Laden mußte.

Du mußt eigentlich nicht in in jedem Cycle senden. Aber den Zeitpunkt des Sendens legst du fest, wenn du dem LLC mitteilst, daß isochrone Daten im FIFO zum Abholen bereitstehen.

Christop

Hallo Jochen,

"Jochen R?dler" schrieb im Newsbeitrag news: snipped-for-privacy@posting.google.com...

TI

Funktionsumfang

Ist klar, wenn es auf das GP Interface ankommt ist das sicherlich eine gute Wahl.

Jedenfalls ist der Support bei TI hervorragend. ICh hatte es damals - und neulich auch wieder - mit einem Herrn Zipperer in Freising zu tun. Wenn er nicht mehr weiterkam wurde ich direkt nach Dallas vermittelt. Das hat hervorragend geklappt. ICh glaube, selbst das ist ein wichtiges Argument zugunsten TI.

Du

Was passiert, wenn die Übertragung - aus welchen Gründen auch immer - doch einmal ins Stocken geraten sollte (z.B. Laufzeiten von Windows etc)? Dann wäre es sicherlich sinnvoll, ein relativ großes FIFO für die Entwicklung einzusetzen und später dann - sollte man es wirklich nicht brauchen - auf ein möglichst pinkompatibles kleineres Modell auszuweichen. Die Pinkompatibilität ist von großem Vorteil, weil man sich in diesem Fall ein neues Layout spart. Hier bieten sich etwa die FIFOS von IDT (Serie IDT2V263,

273, 283,...). Da kannst Du maximal 512kB zwischenpuffern.

den

werden

Ich musste damals auf einen ungemuxten Bustransfer zurückgreifen um das ganze möglichst problemlos zusammenschalten zu können. Mein uC hatte beide Funktionsmodi angeboten. AFAIK hat der 12LV32 das gleiche uC-Interface wie der 12LV31, und der hat gemultiplexte Adressen und Daten nicht unterstützt. Will man das dennoch nutzen muss man noch zusätzliche Hardware spendieren und bekommt massig Laufzeit - und da liegt das Problem.

Ok. Willst Du eine galvanische Trennung vorsehen, z.B. mit Busholdern zwischen Link und PHY?

die

Hm, also ich hatte damals die Spec, noch in der Version 1394-1995, das war sehr sehr hilfreich. Ich weiß nicht, wie weit man ohne dieses Werk kommt. Schreibst Du die Arbeit in der Industrie? Vielleicht kann man die Firma dann dazu bewegen, die Spec zu kaufen - ich mene, sie wolen schließlich etwas standardkonformes entwickeln. Aber wen dein Buch ausreicht ist das ja auch gut.

Gruß Andreas

bei mir in der Abteilung gibt es einen Live-Ausgang an einem Bildverarbeitungsmodul - ebenfalls Firewire-DCAM an einem TSB Chip mit DataMover Port ...

ich hatte damals den FPGA Teil geschrieben und erinnere mich, dass ich die Header-Insertion in FPGA gemacht habe!

Der Header enthält ein Bit, das für das erste Paket im Bild gesetzt sein muss, für die anderen dann aber nicht mehr gesetzt sein darf ... da diese Informationen eigentlich nur im FPGA vorhanden sind, ist es einfacher diese auch von dortaus zu senden ...

Zum Fifo: es genügt 1 Paket vorzuhalten ... über die max. Paketgröße bin ich mir aber nicht mehr sicher ...

bye, Michael