Neuentwicklung eines VDR Erweiterungsboards, wer macht mit ?

Leider ist die Cypress-page momentan down (wird scheinbar neu hochgeladen, da das Layout ein komplett anderes ist), deswegen kann ich mir gerade kein Datenblatt runterladen.

Für HID-Keyboardunterstützung kann man so ziemlich jeden USB-controller mit integriertem µC nehmen (Microchip, Cypress, TI, ...).

Das "Tastaturprotokoll" bekommt man auch recht einfach mit 2 I/Os realisiert, hab ich auch vor Ewigkeiten mal mit einem pic gemacht, siehe: http://elektronikseiten.de/projects/default.asp?project=15

Hallo,
wenn ihr Hilfe beim USB braucht, helfe ich gerne. Ich entwickle USB-Geräte seit 1996. Habe auch einen USB-Analysator (Full-Speed only).

Ich muss nochmal meinen Senf dazugeben - berücksichtigt Ihr bei den USB-Überlegungen auch das LCD? Wenn, sollte man das meiner Meinung nach gleich miterschlagen ... für verschiedene LCD-Typen müsste man dann halt eine parametrisierbare FW oder entsprechend angepasste FW schreiben.

Ein entscheidender Punkt bei der Auswahl des Chips sehe ich in der Verfügbarkeit einer Entwicklungsumgebung bzw. eines vernünftigen C-Compilers - am besten gratis.

arghgra

STB. Sobald die Seite wieder klappt schaue ich mir den Controller an. Ich denke als erstes Kriterium sollte die Anzahl der IOs dienen um auch LCD und die anderen Erweiterungen ohne großen Anstalten (I2c Portexpander/Schieberegister/...) realisieren zu können.

Hardware Full speed analyzer ist bei mir auch vorhanden. High speed werden wir wohl auch nicht brauchen

Ich denke das man auch die Software sehr gut in verschiedene Aufgabenbereiche aufteilen kann, z.B. Interfaces zu verschiedener Hardware, wie LCD, Tastatur, ..., Low level USB-Protokoll, Treiber oder User-mode implementation für Linux, ...

arghgra:
Die Cypress-controller haben (fast) alle einen 8051 kompatiblen kern und lassen sich wunderbar mit dem freien SDCC kompilieren.

Hallo,

ich befürworte nach wie vor den Atmega128 aus folgenden Gründen:.

• er ist lange am Markt
• relativ günstig und überall erhältlich
• er hat eine große freie Codebasis (I2C, RS232, Bootloader, Universeller IR-Decoder usw.)
• viele freie Tools und Compiler unterstützen ihn
• gut debugbar (besonders, wenn man wie Zugriff auf einen JTAG ICE hat ;))
• unendlich viele Ports, Timer, Interrupts, und und und

Hiemal die wichtigsten Daten zum ATmega128 aus dem Datenblatt:
Flash (Kbytes) 128
EEPROM (Kbytes) 4
SRAM (bytes) 4096
Max I/O Pins 53
F.max (MHz) 16

Wofür soll eigentlich der Tastaturanschluß gut sein?

In der Firma haben wir gerade ein Projekt, wo ebenfalls ein Atmega ein LCD ansteuert. Hier haben dem Display auch einen analogen Touchscreen verpasst. Wie sind die Meinungen zum Thema Touchscreen in Verbindung mit dem VDR?

Die FTDI USB-Chip sind nur als Ersatz für RS232 zu sehen. Der Vorteil der hierfür vorhandenen Treiber ist, dass sie voll kompatibel zu den Treibern der Comports sind. Wer genug Comports hat kann eventuell ganz auf sie verzichten. Software, die für Comports geschrieben ist, wie zum Beispiel LIRC, LCDproc/seriell, Bootloader usw., muss nicht extra angepasst werden.

Tschüß Frank

So gern ich die AVRs mag, so sehr hasse ich es das Atmel sehr schnell abkündigt (z.B. AtMega103, AtTiny22, AtTiny15L in DIP und diverse andere).

Ich habe mit denen schon viel gemacht und würde die Benutzung natürlich auch befürworten, wobei jedoch das Problem mit fehlender USB-Unterstützung bleibt. Sofern überhaupt von der Mehrheit gewünscht...

PS/2 oder HID-Keyboard Unterstützung fände ich persönlich auch sehr praktisch, da die Einbindung sehr einfach ist. Irgendwie gefällt mir auch das LIRC-geraffel nicht und wenn der Prozessor mal mehr zu tun hat scheitert auch die Erkennung.
Der "externe" Prozessor würde einfach nur Scancodes oder RS232-Kommandos schicken und nicht einen undekodierten "Bitstream".

@FrankJespen: Was meinst Du mit freier Codebasis? Sourcecode der frei Verfügbar ist (appnotes und co.)?

Hallo,

@ Frank:
lirc (simple homebrew) dürfe mit dem FTDI nicht gehen, da lirc (bzw dessen Treiber) direct auf the UART zugreift.
Ansonsten ist er eine schöne Lösung, habe ihn auch schon einegesetzt (damals gabs noch nicht mal den Chip, hab in in Firmware emuliert).

STB
Gerne, send mir ne pmail, dann tauschen wir phone etc. Hast Du Skype?

Zitat

Original von Dieter
Hallo,

@ Frank:
lirc (simple homebrew) dürfe mit dem FTDI nicht gehen, da lirc (bzw dessen Treiber) direct auf the UART zugreift.
Ansonsten ist er eine schöne Lösung, habe ihn auch schon einegesetzt (damals gabs noch nicht mal den Chip, hab in in Firmware emuliert).

Sollte es nicht Ziel sein, kein simple-Homebrew zu verwenden, sondern die IR-Signale vom uc dekodieren zu lassen (--> PS/2-Emulation) ???

arghgra

Hallo,

Zitat

Original von arghgra
Sollte es nicht Ziel sein, kein simple-Homebrew zu verwenden, sondern die IR-Signale vom uc dekodieren zu lassen (--> PS/2-Emulation) ???

Ich habe ja die universelle IR-Erkennung VDR-Wakeup programmiert. Dort habe ich allerdings nur RC5 und RC6 decodiert. Alle anderen Codes werden im Rawformat gespeichert. Das kostet allerdings einiges an Speicher. Außerdem halte ich es für falsch das Rad ein zweites mal zu erfinden und ich denke nur die wenigsten haben Lust ihre Fernbedienung ein zweites mal anzulernen. Meine Idee hierzu ist, das was der lirc_serial Treiber macht, vom Atmel machen zu lassen und für LIRC einen neuen Treiber zu schreiben, der das Rohformat direkt vom Atmel über die bekommt.

• Atmel empfängt am Interrupt-Pin High/Low-Folge vom TSOP
• er berechnet die Zeiten 103,51,52,98,...
• die werden über seriell oder USB an unseren VDR-Erweiterungsboard-Kommunikations-Daemon geschickt
• von dort holt sich der neue LIRC-Treiber die Daten ab

Bei der Gelegenheit, was haltet ihr von der Idee einen universellen VDR-Erweiterungsboard-Kommunikations-Daemon (tolles Wort ;)) zu benutzen. Dann würde man mit einem Comport auskommen und nicht jedes Tool oder Plugin braucht eine eigene Schnittstelle.

Tschüß Frank

Hi,
ich kann mich Frank nur anschliessen: wenn man eine "universelle"
Schnittstelle hat, die bidirektional sowohl IR-Signale (als auch
Tastendrücke...) zum VDR, von diesem (serielle) Signale zum
LCD (graf oder hd44780), LEDs RTC-Wakeup, Hintergrundbeleuchtung, Videoumschaltern...
schafft trägt man viel zeitkritisches aus dem VDR in den ATMEL. Und der ist ja gerade für so was da!
Wenn es denn nur eine Schnittstelle im einem Plugin/Daemon und
einem Extensionboard ist kann man diese Schnittstelle (modular???)
auch auf USB umsetzen.
Aber los geht es mit der logischen Schnittstelle.
Bleibt weiter kreatiph!

CU Harvey

Btw: Ein Butterworth sechster Ordung braucht 3 Induktiviäten und
3 Kondensatoren (100pF, 1.5µH, 330pF, 1.8µH, 270pF, 0.56µH)
und hat ziemlich genau eine Impedanz von 75Ohm. Ist also sehr
reflektionsarm

http://bitstreamout.sf.net/Video-Filter-Design.pdf

Werner

Hi!

Ich hab zwar den Thread durchgelesen, es kann aber sein, dass ich es übersehen hab. Könntet ihr eine Pufferung für die FB-Codes vorsehen. Ne Knopfzelle genügt da ja vollkommen. Beim jetztigen AVBoard geht doch der Einschalt-Code bei Stromausfall oder Trennung vom Netz verloren, richtig?

Muss auch mal was zum Thema LCD sagen:
Das hier jetzt auch eine LCD-Anzeige im Offline-Zustand des PC´s angestrebt wird finde ich echt suuuper. Ist bei mir das totale K.O. Kriterium für eine externe ErweiterungPlatine!

ABER: Ich würde es viel besser finden wenn (wahlweise, vieleicht einstellbar per Jumper) für den Offlinestatus ein zweites LCD verwendet wird.
Manche, so auch ich, habe ein sehr großes, beleuchtetes (CCFL oder LED) , vieleicht auch externes, Display. Das wäre totaler Overkill dieses auch im OfflineModus zu verwenden. Viel besser ist es doch ein zweites kleines GLCD (64x128) /Textdisplay (2x40) dafür zu verwenden.
Anzuschließen dann über einem auf der Platine befindlichem LPT-Port.

BEispielsweise wären dann auf der Platine zwei LPT Ports. Einen für das Offline-, einen für das Online-LCD. Ist kein Offline-LCD angeschlossen wird das Online-LCD verwendet (falls eingestellt per Jumper)

<träum>
Ich habe z.b mein blaues 240x128 GLCD extern aufgestellt. In mein YYA106 Gehäuse würde ich dann ein 64x128 GLCD mit ganz schwacher HG-Beleuchtung einbauen.
</träum>

Was meint ihr dazu???

Tobias
Was meint ihr dazu?

Zitat

Original von MacVDR
Beim jetztigen AVBoard geht doch der Einschalt-Code bei Stromausfall oder Trennung vom Netz verloren, richtig?

Als bei meiner IR-Einschalt Platine von T.Breuer sind die Codes bei einem Stromverlust _nicht_ weg.

Tobias