Hallo Besucher, der Thread wurde 13k mal aufgerufen und enthält 20 Antworten

letzter Beitrag von LemiSt24 am

AMT630A based mini TFT screens

  • Hallo, ich hab mir vor ein paar Wochen einen 320x240 pixel 3.5" 4:3 car rear view TFT monitor als Bildschirm für alte computer/konsolen gekauft. Der video controller in dem Bildschirm ist ein AMT630A chip, und die firmware ist auf einem externem SPI-bus FLASH chip. Ausprobiert hab ich das Ding bis jetzt mit SNES und PSX konsolen, und es funktioniert so einigermaßen schlechter als erhofft: Normales PAL geht einigermaßen, PAL60 hat krasse glitches, das backlight ist zu hell, und das resampling auf 320x240 pixel könnte etwas besser aussehen.


    Teilweise lassen sich die Problem eventuell über die firmware beheben. Ich hab die firmware disassembliert und in funktionsfähigen kommentierten source code umgewandelt (das disassembly ist hier: http://problemkaputt.de/amt630a.htm inklusive mehr infos). Die I/O ports für OSD, ADC, PWM, SPI, timers, uart, watchdog usw. sind einigermaßen klar, und die übrigen I/O ports sind wahrscheinlich überwiegend für die Composite-to-TFT video konversion - da müßte man rumprobieren welche bits das display wie beeinflussen.


    Hilfreich wären außerdem weitere AMT630A (oder AMT630) firmware dumps, zum Beispiel für displays mit 16:9 ratio oder anderer Auflösung als 320x240, daran müßte sich erkennen lassen welche I/O ports für Bildauflösung & resampling zuständig sind.


    Am C64 hab ich das display bisher noch nicht ausprobiert (meine hardware ist gerade eingelagert, weil meine Wohnung saniert wird - umgekehrt hab ich deswegen das platzsparende 3.5" display gekauft). Anyways, hier, TFT Monitor am C64 Schaltung steht, daß AMT630A eher nicht ohne weiteres mit C64 klarkommt, jedenfalls bei einem getestetem display.

    EDIT by FXXS: Textdublette gelöscht...

  • Ein sehr spannender Ansatz, finde ich! Und möglicher Weise eine Lösung für mein Problem aus der entgegengesetzten Richtung.


    Ich Deine Hinweise zum Dump der Firmware überflogen und bin mir nicht sicher, ob ich das damit hinbekomme. Vielleicht könntest Du dazu noch eine detailliertere Anleitung schreiben? Wenn ich es dann schaffe, einen Dump zu ziehen, schicke ich ihn Dir gerne! Das einzige was mir ad hoc einfiele, wäre, das Flash auszulöten und mit einem Programmer auszulesen...

  • Hab meinen C64 gerade wieder gefunden, natürlich erst, nachdem ich alle anderen Umzugskartons durchwühlt hab. Auf Anhieb bekomme ich auch kein Bild. Und, dummerweise sieht's so aus, als ob die Bilderkennung per hardware gemacht wird - der firmware interrupt handler hat zwar auch ein paar picture detection funktionen (für PAL/NTSC und AV1/AV2 oder so). Die Umschaltung zwischen SNOW and AV1 passiert aber völlig automatisch (selbst wenn die interrupts mit CLR EA alle ausgeschaltet sind).


    Vielleicht gibt es irgendwo eine "force picture" funktion mit dem sich das auto-detect zeug umgehen läßt. Und selbst wenn ja, die Lösung mit dem externen sync-fix ist auch nicht schlecht, und wahrscheinlich einfacher für Leute die keine firmware über SPI bus patchen können.


    Für SPI FLASH dumpen... Du hast irgendwelche SPI hardware/software die das kann? Und die Frage ist bloß, wie den chip anschliessen, mit oder auslöten? Die chip pinouts findest Du in 25D40 und 25Q40 datasheets (beide gleich, unterschied ist bloß, ob Dual- oder Quad-databus vom jeweiligen chip unterstützt wird, was egal ist solange die nur seriell 1bit liest).


    Am einfachsten ist den chip auf dem mainboard lassen. Die vier SPI leitungen (DATA.IN/OUT, CLK, /CS) und Ground an die Lese-hardware anschliessen, für power supply einfach den monitor normal mit dessen Stromversorgung betun (der standby mode mit schwarzen display reicht, es muß kein Bild/AV signal da sein). Wichtig ist, den AMT630A chip während dem dumpen lahmzulegen (der liest sonst permanent vom SPI bus): Am besten den AMT630A RESET pin auf HIGH ziehen. Oder alternativ, einen der Quartz pins an GND kurzschliessen (welchen pin kommt drauf an, bei mir ist der quartz "oben" auf der platine, und ich hab den "rechten" pin kurzgeschlossen, mit dem anderen pin auf GND stürzt die hardware komisch ab).


    Falls das Lesen nicht klappt ist chip auslöten vielleicht doch ganz gut. Mein Ratschlag wäre dann, den chip auf eine Platine zu löten (keine losen Drähte direkt an die pins löten - mir ist auf die Weise ein pin abgebrochen nachdem ich das ganze ein paar dutzend mal hin und hergedreht habe).


    Meine eigene Lesesoftware ist für Windows PCs mit parallel port - ich kann die software gerne hochladen, falls jemand Bedarf dafür hat (ich hab allerdings seit 15 Jahren von niemanden mehr gehört der einen PC mit parallel port besitzt). Die dazugehörige Schaltung ist eigentlich ganz einfach... weil SPI transfers eben halt eigentlich ganz einfach sind... Aber: der MK 25D40 chip hat mich fast geschafft. Wenn das Lesen mal geklappt hat, dann hat's immer sofort dann nicht mehr funktioniert, wenn ich den parallel port socket ins Gehäuse eingebaut hab. Insgesamt hat's Tage gedauert bis alles ging wie es sollte. Und selbst die blöde Chip ID hat sich dabei ständig geändert:

    Code
    1. ID=C0001C (maker=invalid, dump=corrupt without any legible opcodes or ascii strings)
    2. ID=C84013 (maker=Apple, dump=intact)
    3. ID=EF4013 (maker=Nexcom, dump=intact)
    4. ID=EF4011 (maker=Nexcom, dump=slightly corrupted)


    Die C0001C ID hab ich bei fast jedem Versuch gekriegt, die Daten waren dann 512Kbyte Müll (ironischerweise absolut stabil, immer byte-für-byte derselbe Müll). C84013 hab ich mitunter ich-weiß-nicht-wie bekommen, und es sah eigentlich okay aus. Nachdem ich ein 74HCxx gatter in den FLASH ausgang gebaut hab, wurde es dann plötzlich EF4013, derzeit glaube ich, daß das die "richtige" ID ist (das 74HCxx gatter scheint wichtig zu sein, damit vom PC her keine 5V den 3.3V chip stören) (merkwürdigerweise sind 5V signale auf den FLASH eingängen kein Problem, aber ein 5V (pull-up) am FLASH ausgang scheint den MK 25D40 chip total aus der Bahn zu werfen) (und ausserdem vermeiden: keine unbenutzten "dead-end" drähte an den FLASH chip anschliessen (sowas hatte ich als "test point" an einer Leitung, und das fängt aber fieses noise oder signal-echos ein)).
    Inzwischen geht alles prima und ich kann die firmware beliebig patchen & flashen & die firmware re-bootet danach automatisch. Und, naja, ein kleines Problem ist immer noch: Wenn ich den PC hochfahre während der Monitor angeschlossen ist, dann bekomme ich danach immer EF4011 als ID, keine Ahnung was da passiert, es läßt sich aber dadurch beheben die monitor power supply kurz auszustecken.

  • Kann irgendjemand Russisch? Anscheinend gibt es auf dieser Seite diverse AMT630A firmware dumps, http://remont-aud.net/dump/car_audio/car_lcd_monitors/356 Soweit ich verstehe, muß man sich vor dem download registrieren, und das auch noch ungewöhnlich kompliziert, inklusive Nationalität & Stammbaum der Großmutter, und samt einem captcha das aus Ziffern und kyrilischen Buchstaben zu bestehen scheint. Und danach soll man noch einen Elektroniktest bestehen. Wär toll falls das wer hinbekommt. Oder einen email kontakt zu den Leuten findet.


    Oh, und firmware-seitig hab ich inzwischen 40x25 character OSD text output zusammengebastelt, und kann memory & I/O ports dumpen, und über die buttons selbstgebaute testfunktionen aufrufen usw. Die memory map und die funktionen von ein paar mehr I/O ports sind inzwischen auch klarer.


    Die fünf OSD windows sind recht enttäuschend: Jedes Zeichen hat nur zwei Farben (text und background, letzterer ist in der regel transparent). Eigentlich wollte ich mehr Farben mit überlappenden windows machen, leider kommt die OSD hardware mit überlapppenden windows nicht zurecht: Transparente pixel im "vorderen" window bleiben einfacht "transparent" (in dem Sinne von: AV layer oder den BLUE/SNOW backdrop anzeigen - dahinterliegende pixel von dem "hinteren" window werden einfach weggelassen). Halb überlappende windows, die nicht gleichermaßen auf die character width "aligned" sind, sehen noch schlimmer aus: die pixel werden dann in einem (oder beiden) fenstern wahllos horizontal verschoben. Und allgemein blöd: Es scheint echt keine Funktion zu geben einen schwarzen Rand um die Zeichen zu malen (was eigentlich die grundlegenste Funkton jeden OSD display sein sollte, zB. für hellen Text vor hellem Videobild).


    Backlight dimming funktioniert dagegen prima. Normal ist der backlight PWM pin von der firmware einfach auf HIGH geschaltet (also ohne die PWM funktion überhaupt zu benutzen). Bei PWM mit 50% duty wird das Bild recht dunkel, aber für indoor-use nicht zu dunkel & eigentlich ganz angenehm, auf jeden Fall besser als die superhelle firmware einstellung. Und der Stromverbrauch geht bei 50% duty rapide runter:

    Code
    1. duty 100% (aka HIGH) = 290mA = 1.45W (from 5V supply) ;firmware default
    2. duty 50% = 65mA = 0.33W (from 5V supply) ;patched firmware
    3. duty 0% (aka LOW) = 56mA = 0.28W (from 5V supply) ;backlight off


    Wobei die 65mA größtenteils für die übrige hardware draufgehen (56mA), und das backlight selbst offenbar nur 9mA anstelle der vom Hersteller verbratenen 234mA braucht. Ich hoffe, ich hab die Zahlen richtig gemessen. Die Display-scheibe ist mit dem software patch jedenfalls merklich kühler und wird auch nach stundenangem Dauerbetrieb nicht mehr warm.

  • Zuerst muß ich noch mal sagen: Sehr beeindruckende Reverse-Engineering Leistung! :thumbup:


    Vermutlich geeignete Hardware für das Auslesen, die ich habe, wäre ein TL866, ein Bus Pirate älterer Bauart oder auch irgendein Arduino mit ein paar Zeilen Code. Ausgelötet hätte ich den Käfer in so einen Adapter hier gepackt:



    Jetzt habe ich aber stattdessen noch einen in dieser Art bestellt:




    Es wird ein wenig dauern, bis der ankommt, aber dann versuche ich mich an dem Dump und stelle ihn gerne zur Verfügung.

  • Hat jemand mal einen Ebay-Link für ein passendes Display? Habe etwas gesucht, aber finde nur 16:9-Displays...


    Das Datenblatt (Product Spezifikation, Version 1.1, 2015.01) ist schon runtergeladen...


    Interessantes Reverse Engineering von Dir, @nocash!



    Danke und Gruß
    Thomas

  • Ich habe vor ein paar Wochen den hier bestellt. 16:9 / 4:3 ist einstellbar.


    Vielen Dank für den Link, ich habe mir auch mal einen bestellt.


    Das Datenblatt (Product Spezifikation, Version 1.1, 2015.01) ist schon runtergeladen...


    Naja, viel steht da ja nicht drin. Hatte jetzt auf eine Registerbeschreibung gehofft...


    Aber das Teil hat auch einen I2C-Slave onboard. Bei den Pollin-Displays gab es seinerzeit eine Möglichkeit hierüber (mit einem Raspberry Pi) das Flash auszulesen und neu zu beschreiben... Gibt der AMT630A vielleicht auch dieses Feature?


    Gruß
    Thomas

  • Ich hab mal alle bits von FB00h-FFFFh an/aus-geschaltet (außer die bei FDxxh, in dem Bereich stürzt die test-software (oder der ADC button input) oft ab). Jedenfalls, ich hab über 8000 bits probiert & geguckt was passiert (hat Stunden gedauert). Es gibt eine gute handvoll bits bei denen das C64 bild wenigstens kurzzeitig erscheint (vielleicht würde ein kombination aus solchen bits auch dauerhafter für ein Bild sorgen).


    Und, ganz zum Schluß hab ich ein bit gefunden das ziemlich perfekt funktioniert: FE42h.bit5 - damit ist das C64 bild dauerhaft da. Und wenn man den C64 ausschaltet wird trotzdem immer noch automatisch auf den snow-effekt umgeschaltet. Der video controller merkt also trotzdem noch wenn gar kein signal da ist.


    ---


    Von I2C bus handling ist in der firmware nichts zu sehen, würde mich also wundern wenn sich damit irgendwelche commands/daten übertragen lassen. Andererseits, wozu auch, man kann die firmware stattdesen über den SPI bus problemlos auslesen (*).
    (*) jedenfalls wenn man sich dabei nicht so blöd anstellt, wie ich's offenbar gemacht hab.


    Geld für einen Adapter hätte ich nicht ausgegeben (vielleicht war das mein Fehler), jedenfalls klingt adapter-kaufen sehr motiviert, bin gespannt wie sich die firmware von meiner unterscheidet. Das display das ich habe ist übrigens das hier: https://www.amazon.de/TOOGOO-M…eaufloesung/dp/B00UMWYHHI - 3.5 zoll. 4:3 ratio, 320x240 pixel, für 14.48 EUR inklusive porto. Das Gehäuse hat irgendweshalb 16:9 größe, obwoh das display darin 4:3 ist. Ich hab's Gehäuse weggeworfen, und selbst ein kleineres in 4:3 größe aus Holz gebastelt, und mit buchsen in der Rückwand anstelle der sonst rausbaumelnden Kabel).


    Falls jemand ein anderes AMT630(a) display (mit anderer aufösung, oder 16:9 ratio, oder sonstigen unterschieden) spenden wollte, würde ich's gerne nehmen, und da auch in die firmware gucken! Wenn ich's hinbekomme eine eigene firmware zu schreiben (=ist eigentlich fest geplant), könnte ich die hardware dann mitunterstützen.


    Was gibt es überhaupt noch für weitere billige mittel/kleine display-größen? Ich weiß von dem ehemaligen pollin 5.6" display mit 4:3 ratio (was hier im forum ausgiebig gepostet war). Ansonsten scheint 4:3 ratio selten zu sein... oder zumindest schwer zu finden (die meisten search engines ignorieren den doppelpunkt in "4:3" und liefern überwiegend unsinnige such-ergebnisse für "4.3 zoll" displays - mit 16:9 ratio).

  • Hab eine neue firmware version fertig. Die original firmware wird nur noch benutzt um ein paar hardware register zu initialisieren, die neue user interface ist etwas experimentiell und besteht hauptsächlich aus einem debug menu mit dem sich diverse hardware features testen lassen. Nebenher hab ich die AMT630A hardware emuliert, die hardware register recht vollständig dokumentiert (zumindest die register die tatsächlich benutzt werden), und eine AMT630A version des "Magic Floor" Suchspiels in die firmware miteingebaut, es ist sogar recht gut spielbar geworden (trotz dem 3-button keypad).


    http://problemkaputt.de/amt630a.htm - new AMT630A firmware disassembly with added custom source code
    http://problemkaputt.de/x51.htm - AMT630A emulator/debugger
    http://problemkaputt.de/x51specs.htm - specifications for AMT630A memory map and hardware registers


    Das backlight dimming und C64 video signal sind per default freigeschaltet (um tatsächlich was zu sehen: Hide OSD Screen auswählen). PAL60 läßt sich optional auch freischalten, das Bild flimmert dann aber etwas (und alles was nicht PAL60 ist funktioniert nicht mehr richtig). Das PAL60 flimmern läßt sich wahrscheinlich wegkriegen sobald die übrigen firmwares gedumpt sind und das pixel/ratio scaling/timing damit etwas klarer wird. Arbeitet da noch jemand dran? Ich hab im internet noch mehr danach gesucht, und der derzeitige stand scheint zu sein, das die gesamte nicht-russischsprachige Welt das mit den dumps nicht selber gebacken kriegt und sich stattdessen drüber ärgert die russischen dumps nicht downloaden zu können.


    Anbei noch ein paar Bilder von dem display. Einmal das orignal display mit den rausbaumelnden Kabeln, und dem 4:3 display etwas unglücklich in einem 16:9 Gehäuse verbaut. Und mein eigenes Gehäuse in 4:3 größe und mit Einbaubuchsen an der Rückseite. Winkel und Bodenhöhe sind darauf ausgelegt, das display hinter einer PC Tastatur auf den Tisch stellen zu können. Wände sind dünne MDF platten, Boden und Rückwand etwas dickeres Sperrholz, das ganze verleimt und dabei mit veganen Grillspiessen verdübelt. Das display ist in einer ausgefrästen Rille eingelassen (und die Platte vorne unten ist abschraubbar, damit sich das Display (samt der originalen Plexiglas Frontscheibe) dann nach unten rausschieben läßt). Die Rückwand ist etwas nach innen versetzt (so das die Buchsen nicht überstehen). Die Lautsprecher kommen aus einem kaputten notebook, mir fehlt aber noch ein passender Verstärker (mit etwa 2x1watt, 5V supply, und möglichst über PWM regelbarer lautstärke, und gerne noch einer low-power standby funktion, es sei denn der stromverbrauch ginge ohne audio signal sowieso gegen null).


  • Arbeitet da noch jemand dran?


    Merkwürdiges Timing: Ich habe den Adapter am Freitag bekommen und heute Nachmittag versucht, damit das Flash auszulesen. Bin aber gescheitert. Ich habe dann doch den Chip ausgelötet und konnte anschließend den Inhalt lesen. Anschließend habe ich mich dann gleich hier angemeldet, um Dir den Dump zu schicken und finde Deinen Post... :-) Bekommst gleich eine PM von mir.

  • Prima Timing! Dann bin ich ja gerade rechtzeitig fertig geworden bevor ich mich mit dem dump beschäftige. Hmmm, es ist jedenfalls dieselbe "Engels" firmware, aber Deine version ist etwas neuer, und - leider - sind die variablem im RAM und XRAM an anderen adressen, das macht es etwas schwieriger die tatsächlichen unterschiede im program code zu finden. Auf jeden Fall, vielen Dank für's dumpen!
    PS. Hast Du die JEDEC chip ID für den "MK 25D40BTIG" flash chip auch ausgelesen? Ich frag mich immer noch, ob eine von den von mir gelesenen IDs tatsächlich die "richtige" war.

  • Hab eine neue firmware version fertig. Die original firmware wird nur noch benutzt um ein paar hardware register zu initialisieren, die neue user interface ist etwas experimentiell und besteht hauptsächlich aus einem debug menu mit dem sich diverse hardware features testen lassen. Nebenher hab ich die AMT630A hardware emuliert, die hardware register recht vollständig dokumentiert (zumindest die register die tatsächlich benutzt werden), und eine AMT630A version des "Magic Floor" Suchspiels in die firmware miteingebaut, es ist sogar recht gut spielbar geworden (trotz dem 3-button keypad).


    Klasse Arbeit, @nocash!


    :thumbsup:


    Gruß
    Thomas

  • Neues update ist fertig. Die disassemblierte firmware enthält jetzt zwei verschiedene firmware versionen (mit .if/.else direktiven für 320x240 und 480x272 displays). Neben der anderen Auflösung ist an der neuen version auch interessant, daß darin IR unterstützt wird (leider nur für NEC remote controls, Philips RC-5 funktioniert wahrscheinlich etwas anders - und, naja, ich hab eh keine Ahnung was für Bauteile man genau bräuchte um IR nachzurüsten). Ach ja, und die neue firmware hat außerdem mehr SPI FLASH funktionen: Chip ID auszulesen, und mehr code der am write-protect status rum macht (im Gegensatz zur älteren firmware funktioniert das write-protect sogar tatsächlich um die ersten 64K schreibzuschützen - wobei das ständige Beschreiben der write-protect flags den chip vermutlich auf Dauer eher kaputtmacht, als damit tatsächlich etwas zu schützen).


    Die hardware specs haben neue Infos für Pin-Outs, SPI-FLASH, PLL/dotclock, Infra-red, IRQs, inklusive einem framerate IRQ der eventuell ganz praktisch sein könnte.


    Das Magic Floor game ist auch noch etwas überarbeitet: Mit fade-in/out Effekten, Text an die display breite an gepasst, und mehr verschiedenen Spielfeldgrößen (die nach und nach freigeschaltet werden, abhängig vom im FLASH gespeichertem Spielstand).


    Der no$x51 emulator/debugger unterstützt jetzt Font DMA, mehr IRQs, and der eingebaute assembler hat ein bugfix für "or c,bit" and "and c,bit" opcodes.


    ---


    Und, meine eigene firmware ist jetzt auch endlich fertig:
    - backlight dimming (spart strom und ist weniger anstrengend für die Augen)
    - low power standby mode: 8.4mA bei 5V (im Gegensatz zu 33mA in der original firmware)
    - unterstützt C64 video signal
    - unterstützt NTSC Tint Einstellung (OHNE dabei das PAL decoding durcheinanderzubringen)
    - unterstützt PAL60 (funktioniert, flimmert aber leider etwas, wahrscheinlich weil irgendwelche timings nicht exakt stimmen)
    - bessere GUI (ohne die nervigen timeouts, und mit schwarz umrandeten Buchstaben, also auch auf hellem Hintergrund sichtbar)
    - xflip/yflip gimmick (nur für displays mit SPI bus, also nicht für Innolux displays).
    - unterstützt zwei keypad types (je 3 buttons, optional mit +/- vertauscht)
    - unterstützt vier display types (Tianma3.5", Noname3.5", Innolux4.3" und Innolux5.0") (läßt sich beim ersten Einschalten einstellen, oder auch später ändern: MENU während dem Einschalten gedrückt halten).


    ---


    Anbei noch ein paar Fragen: PAL60 funktioniert bei meinem 320x240 display mit der original firmware überhaupt nicht - ich bin mir aber nicht sicher, ob das ein grundsätzliches Problem ist. Wie sieht das bei 480x272 pixel displays aus (zum Beispiel mit PAL SNES or PAL PSX im 60Hz mode), stimmen die Farben da, und funktioniert es ohne dirt scanlines in der unteren Bildhälfte?


    Wieviele firmware versionen gibt es eigentlich? Die version strings lassen sich über MENU,+,-,-,+,+ und MENU,-,+,+,-,- recht problemlos anzeigen. Bisher bekannt sind nur zwei versionen:
    VERSION 'XDD_MT_630A_35D_LD035H3_DX_3KEY_151022_LOGO' - CUSTOMER 'Customer:MT_35D' - DATE 'Time:Mar 07 2016'
    VERSION 'GK_SK_630A_43D_DX_3KEY_170911' - CUSTOMER 'Customer:SK_43D' - DATE 'Time:Sep 11 2017'
    Vorsicht: Das Factory menu kann eine KEYpad option haben, wenn die geändert wird funktionieren die Buttons nicht mehr (was dann eine gute Gelegenheit wäre um die firmware zu dumpen und danach neu zuflashen).


    Und vielleicht eine blöde Frage: Was macht die 16:9 option?
    Werden die pixel damit einfach in der Breite gedehnt, und die pixelhöhe bleibt unverändert?
    Oder werden die pixel auch in der Höhe gestreckt (und zB bei Kinofilmen mit schwarzen Balken die Balken abgeschnitten)?
    Und passiert das immer wenn die option eingeschaltet ist, oder nur bei "Breitbild" video signalen (falls die hardware sowas automatisch erkennen kann)?

  • und, naja, ich hab eh keine Ahnung was für Bauteile man genau bräuchte um IR nachzurüsten)

    ist nur ein bauteil. mit drei pins. einer ist die versorgungsspannung, gnd und der ausgang. manche benötigen noch einen widerstand (ca. 3,3 k bis 10kohm) am ausgang.


    da gibt es sehr viele hersteller und bauformen. eigentlich ist es egal welches du zum experimentieren nimmst.
    die haben ein eingebautes frequenzfilter um die trägerfrequenz automatisch auszufiltern. z.b. die xx38 sind für 38KHz optimiert.
    die kann man auch zum testen mit z.b. einer 30 bis 50Khz fernbedienung benutzen. man muss nur mit der fb näher heran.


    in (fast) jedem gerät, welches über eine fb gesteuert wird z.b. dvd player, tv, receiver usw. steckt so ein dreibeiner.
    hol dir ein schrottgerät und löte es aus und viel spass beim testen :)



    vielen dank @nocash für deine amt630 infos.
    ich habe mir auch so einen mini tft zugelegt und hoffe das ich es auch mal zum laufen bekomme.


    gruß
    helmut

  • Prima, das klingt ja überschaubar, ich dachte IR receiver bräuchte noch mehr analoge Bauteile, aber wenn die dreibeinigen Dinger direkt ein digitales Signal ausgeben ist's echt einfach. Ich werd mal die Augen offenhalten nach E-schrott, oder gelegentlich ein TSOP48xx oder TSOP312xx kaufen, wenn ich mal wieder Bauteile bestelle.
    Die unterschiedlichen frequenzen für NEC vs RC5 sind etwas unglücklich (wenn beides funktionieren soll). Aber wenn's auf kurze Entfernung so oder so geht, dann ist's auch gut (bei den kleinen displays wären größere Entfernungen eh quatsch) (und kurze Entfernungen sind natürlich auch quatsch, außer um IR mal ausprobiert zu haben, oder für etwas mehr input/komfort als mit den kleinen +/- buttons im Gehäuse).

  • ich habe ihn, seit 1985, sehr gerne für viele sachen eingesetzt. damals den sfh506 von tfk oder siemens.
    die sind sehr empfindlich, bei kurzer entfernung, geht es durch den kunststoff. ich bohrte die gehäuse, von innen, nur leicht an,
    das noch ca. 1mm stehen blieb. so sah man kein loch im gehäuse.


    z.b. benutzte ich ihn an einem 16x2 / 16x4 lcd display, mit einem schieberegister ic, ser. in und parallel raus.
    so benötigte ich damals nur einen portpin und nur eine ir diode um ein lcd display, kabellos anzusteuern.


    wenn ich bedienungstasten irgendwo unsichtbar verstecken wollte. baute ich die ir-empfänger mit einem retriggerbarem monoflop, auch innen ins gehäuse.
    als sender benutzte ich einen ne555 mit der trägerfrequenz. der sendete immer. das spiegelt sich über die wände im ganzen raum.
    berührt man nun die stelle, wo der ir-empfänger sitzt, wird das monoflop nicht mehr retriggert und gibt dann ein signal aus, solange man den finger oder die hand usw. hinhält.


    gruß
    helmut