mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP SVGA aus FullHD schneiden


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Stefan M. (phreakshow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi zusammen.

Ich suche einen IC, der mir aus einem FullHD-Bild einen Teil (sagen wir 
SVGA oder WVGA oder auch QVGA) an definierter Position (zur Not default 
links oben) ausschneidet und per LVDS ausgibt. Der Eingang ist entweder 
auch LVDS oder idealerweise Displayport.

Ich bin bei meiner Suche über den Begriff Scaler gestolpert, allerdings 
ist das nach meinem Verständnis nicht das richtige. Bildbereiche 
außerhalb meines definierten Fensters möchte ich ignorieren, und wie ich 
es verstehe versucht der Scaler das Bild im Ganzen auf die neue 
Auflösung umzurechnen.

Beim Suchen bin ich auf den TW8834 gekommen, allerdings ist das 
Datenblatt nicht öffentlich zugänglich.

Wenn ich beim mouser oder farnell in die Video-ICs schaue finde ich zwar 
den TW8834, aber nicht durch seine Eigenschaften, nur durch den Namen.

Wie nennt man so einen IC? Und wie finde ich mehr als einen :)

Autor: Bildverarbeiter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig umsetzen erfordert mitunter ein Übersetzen des timings von 
schnellem HD auf langsameres SD (geringerer Takt) und damit einen 
Bildspeicher für annähernd das halbe Bild.

Schau Dir mal iChips an:

Die machen u.a. picture in picture, das muss nur umgedreht werden, dann 
noch das Ganze zurück auf einen der Inputs und Hochskalieren. Retiming 
können die auch im begrenzten Umfang. Anbindung DDR inklusive.

Wenn das nicht reicht, muss ein FPGA ran. Das wird dann etwas 
kniffeliger. Mit dem Nexys Video geht sowas z.B.

Autor: Stefan M. (phreakshow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, seh ich mir an. FPGA würde ich zunächst sehr gern vermeiden.

Autor: K. L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Darf es auch ein PC sein? Die VJs haben solche Systeme, um in Echtzeit 
Videos zu zerteilen und auf einen HDMI-Ausgang zu geben.

Ist recht erstaunlich, was die können!

Autor: Stefan M. (phreakshow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie nennt man denn die Funktion, die ich suche?
Image resizing?

Würde es etwas bringen, wenn ich meine Anforderung auf Halbieren bzw. 
Vierteln der Auflösung beschränke, also dass ich QVGA aus VGA oder SXVGA 
erzeuge?

Der Hintergrund ist, dass das Zieldisplay nativ nur QVGA hat. Wenn ich 
das per HDMI oder DP übertrage, unterschreite ich die minimalen 
Pixeltakte von afaik 25MHz, und auf dem Display erscheint nur Unsinn.


Nein ein PC würde nichts bringen. Auch da würde ich beim Ausspielen des 
Bildes wieder die Takte unterschreiten.

Autor: Signalverarbeiter (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Stefan M. schrieb:
> Der Hintergrund ist, dass das Zieldisplay nativ nur QVGA hat. Wenn ich
> das per HDMI oder DP übertrage, unterschreite ich die minimalen
> Pixeltakte von afaik 25MHz, und auf dem Display erscheint nur Unsinn.

Du musst ohnehin die Pixeltaktfrequenz selber herstellen und zwar exakt. 
Wie gross die genau ist, ist recht unerheblich.
Dein Problem ist ein anderes: Das Bild hat ein vollständig anderes 
timing, als das Ziel.

Z.B. kommt der kleine Bildausschnitt in 8ms an und soll aber später 16ms 
dauern, damit es wieder ein 50Hz Bild wird.

Du musst also die Zeilen aufblähen und die Spalten.

Uas heisst, Pixels speichern und langsam ausgeben, aber auch Zeilen 
aufnehmen, zwischenspeichern und langsam ausgeben.

In Echtzeit geht das nur, wenn das Display in der Lage ist, völlige 
ansynchron Zeilen zu beschreiben, ohne Rücksicht auf den Vertikaltakt. 
Dann braucht aber das Display einen Speicher, oder die Zeilen werden 
nicht passend zu jedem Bild aktualisiert, sondern mitten in den Zeilen.

Autor: J. S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan M. schrieb:
> Wie nennt man denn die Funktion, die ich suche?
> Image resizing?

"image cropping" wird das genannt. Das ist jedenfalls das, was du primär 
beschreibst. Bevor du dich aber auf die Suche nach chips machst, sollte 
erst einmal das interface klar sein. Braucht das Display ein echtes 
Videotiming, oder sind die Zeilen einzeln zugänglich?

Meistens muss schon irgend ein HS/VS/BL-timing erzeugt werden, d.h. du 
brauchst eine Schaltung, die dir die neuen HVB-Signale macht. Das geht 
am einfachsten mit einem FPGA. Bei ausreichender Größe ist die 
Zwischenpufferung der Zeilen auch kein Problem.

Autor: Stefan M. (phreakshow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider ist es so einfach nicht. Das Display wird nicht direkt per LVDS 
angesteuert, sondern über APIX mit Daten versorgt. Im Prinzip soll der 
Signalweg so aussehen:

Displayport/HDMI (mit irgendner typischen Auflösung, sagen wir XGA)

DP/HDMI Receiver -> LVDS -> Cropping-IC -> LVDS -> INAP375T -> APIX -> 
INAP375R -> LVDS/24-bit RGB -> Panel

Ich bezweifel dass da die Zeilen einzeln zugänglich sind, im LVDS werden 
ja Sync und Takt mit übertragen.

Wenn ich mir jetzt bswp den Renesas TW8845 anseh, bzw das spartanische 
Datenblatt dazu, dann seh ich da einen openLDI-Eingang, einen Block 
Bildverarbeitung und einen Block openLDI-Ausgang. In der Beschreibung 
steht "Supports programmable cropping of input video and graphics".

Das ist doch genau das, was ich suche?

Autor: K. L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan M. schrieb:
> Das ist doch genau das, was ich suche?

Kann sein, aber das kann solange niemand beurteilen, solange du uns 
nicht verräst, was du vor hast.

Autor: Stefan M. (phreakshow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich fass es gern nochmal zusammen:

Bildausgabe soll auf kleinem Display mit 480x240 Pxieln erfolgen, 
angesteuert per DP oder HDMI von einem PC aus. Native Auflösung ist zu 
gering und unterschreitet den üblichen Pixeltakt, deswegen erscheint auf 
dem Display Mist.

Idee: Vom PC mit höherer Auflösung rausgehen, von besagtem cropping-IC 
den gewünschten Ausschnitt per APIX weiterleiten, wie hier beschrieben:

DP/HDMI Receiver -> LVDS -> Cropping-IC -> LVDS -> INAP375T -> APIX ->
INAP375R -> LVDS/24-bit RGB -> Panel

Der INAP375 hat kein Problem mit geringen Auflösungen und Pixeltakten.

FPGA soll wenns geht nicht benutzt werden.

Autor: jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das durfte ich auch schon einmal suchen. Zum kostengünstigen Erfolg bin 
ich nicht gekommen. Was mich gewundert hat, denn jeder Monitor kann das, 
und daher düften solche Chips Massenware sein. Natürlich ist es möglich, 
dass in einem Monitor schlicht nur eine CPU mit HDMI drin ist.

Bei uns konnte man die Auflösung im Bios des "PC" nicht umstellen. Unser 
Problem war nicht ganz identisch mit deinem, aber ähnlich (Upscaling von 
800x600 auf HD).

Das Problem dabei ist, dass die üblichen HDMI-LVDS-Konverter-IC das 
nicht können, weil man dazu einen Framebuffer braucht. Man muss 
sozusagen ein ganzes Bild in den Speicher schreiben, und dann einen 
Auschnitt weitergeben, oder das Bild hochskalieren.
Ein normaler HDMI-Receiver wie der gute alte TFP401A schreibt die Pixel 
einfach 1:1 raus, wie sie kommen.

Analog Devices (die haben viele Video-Chips) hat mir auf Nachfrage einen 
Prozessor mit HDMI-IN und LVDS-Out empfohlen, sie hätte nichts 
einfacheres was das kann. Ist aber 2 Jahre her, Nachfrage kann nicht 
schaden.
Ein FAE eines Distributors hat mir ein XILIX-FPGA empfohlen, da hätten 
wir sogar Sourcen bekommen. Solche Dinge soll meinen Recherchen nach mit 
einem FPGA recht einfach machbar sein. Beispiel für HDMI:
https://www.xilinx.com/support/documentation/ip_documentation/v_hdmi_rx_ss/v3_1/pg236-v-hdmi-rx-ss.pdf
Das dürfte die kostengünstigste Lösung sein, man sparst sogar den SERDES 
und HDMI-Receiver ein, wenn man das FPGA richtig aussucht.

Es gibt China-Chips die das auch können, blos bekamen wir diese nicht, 
und Informationen dazu schon gar nicht.

Gelöst wurde das Problem bei uns duch den Hersteller des Boards, der 
stellte uns die Auflösung im Bios um.

Ich verfolge den Beitrag weiter mit Spannung, denn das Problem poppt bei 
uns sicher auch nochmal auf!

Wenn du ein Bastler bist: Es gibt Boards die das tun. Von diesen kenne 
ich besagte China-Chips, die man nicht bekommt.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Stefan M. schrieb:
> FPGA soll wenns geht nicht benutzt werden.

Wieso nicht? Da gibts wenigstens die 1000+ seitigen Datenblaetter dazu. 
Renesas ist ja nicht gerade dafuer bekannt, normalen Sterblichen da 
irgendwie viel Support / Chips in haushaltsueblichen Mengen zu liefern.
Dein cropping, so wie du's haben willst, ist auch eher problematisch, 
weil du dann deutlich mehr als z.b. eine Zeile puffern musst (=du 
brauchst externes, hurtiges RAM + dessen Ansteuerung).
Die Umwandlung waere simpler, wenn man z.B. jedes 2. Pixel und jede 2. 
Zeile "rausschmeissen" koennte. Also der PC dann eine Aufloesung von 
z.b. 960x480 Pixeln erzeugen muesste. Natuerlich muss das Bild auf dem 
PC auch "dafuer gemacht" sein, dass da die Aufloesung spaeter so 
reduziert wird. Sonst muesste man noch Tiefpaesse vor dem Rausschmeissen 
der Pixel/Zeilen reinbauen.

jemand schrieb:
> Das dürfte die kostengünstigste Lösung sein, man sparst sogar den SERDES
> und HDMI-Receiver ein, wenn man das FPGA richtig aussucht.

Das glaube ich nicht Tim. FPGAs mit eingebauten Serdes sind 
ueblicherweise deutlich teurer als ein Simpel-FPGA und externer HMDI/DP 
Receiver zusammen. Gibts den IP-Core fuer umme?

Gruss
WK

Autor: jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> jemand schrieb:
>> Das dürfte die kostengünstigste Lösung sein, man sparst sogar den SERDES
>> und HDMI-Receiver ein, wenn man das FPGA richtig aussucht.
>
> Das glaube ich nicht Tim. FPGAs mit eingebauten Serdes sind
> ueblicherweise deutlich teurer als ein Simpel-FPGA und externer HMDI/DP
> Receiver zusammen. Gibts den IP-Core fuer umme?

Die Spartan-6 Serie hat Devices mit SERDES drin:
https://www.xilinx.com/products/silicon-devices/fpga/spartan-6.html

Selbst die kleineren (z.B. XC6SLX4-2TQG144I) haben welche, und das ist 
am unteren Ende angesiedelt. Die Frage ist natürlich, ob die ausreichen, 
aber ausschließlich ein Feature teurer FPGAs ist das nicht.
Einige Spartan-6 bieten auch TMDS-Receiver an, womit sich HDMI umsetzen 
lässt.

Ich habe mir das natürlich auch nicht in großer Tiefe angesehen, das 
muss ich schon zugeben. Grund war, dass eine FPGA-Lösung von oben 
abgelehnt wurde. Mir hat aber ein (vertrauenswürdiger) FAE eine 
FPGA-Lösung empfohlen.

Mein Vorgehen wäre gewesen, sich ein passenden Evalboard zu holen und 
sich das mal anzusehen.

Was die Kosten das IP-Cores angeht, oder die Komplexität eines 
HDMI-Receivers, da fehlt mir der Einblick. Der LVDS-Teil dürfte keine 
Raketenwissenschaft sein.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Ja, ok. Ueber diese SerDes Funktion der normalen IO Leitungen, wirds 
datenratenmaessig bei der kleinen Aufloesung wohl auch irgendwie gehen. 
Und an der XAPP1064 fuehrt auch bei LVDS Eingaengen kein Weg vorbei. 
Aber die 1:7 Umsetzung fuer LVDS ist da schon fast fertig drinen; die 
1:10 Geschichte fuer HDMI wird man wohl per "Gearbox" mit 1:5 und 1:2 
hintereinander machen muessen, und danach noch die TMDS -> normal 
Wandlung. So richtig echtes HDMI koennen die Spartan-6 IOs eh nicht, da 
gibt's iirc auch nur so ne komische Geschichte mit Trenn-Cs und 
irgendwelchen Pull-irgendwohin-Rs. Oerks.

Dass der FAE das empfiehlt, ist mir klar. Das ist technisch auch eine 
schoene Loesung und wenn man viele der "richtigen" (GTP,GTX, whatever) 
Tranceiver uebrig hat und bei neueren, dickeren Bausteinen als gerade 
Spartan6. Aber halt von der Entwicklungszeit/Wirtschaftlichkeit her...

Gruss
WK

Autor: Stefan M. (phreakshow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Ding ist halt, von FPGAs habe ich bisher wenig Ahnung. Mein Ansatz 
wäre gewesen das erstmal mit einem diskreten IC aufzubauen und mir das 
FPGA-Fass zu sparen.
Ich hätte auch kein Problem damit mit der doppelten bzw vierfachen 
Auflösung aus dem PC zu gehen. Aber ich seh schon, dass ich um den FPGA 
vermutlich nicht rumkommen werde.

Autor: Signalverarbeiter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Das glaube ich nicht Tim. FPGAs mit eingebauten Serdes sind
> ueblicherweise deutlich teurer als ein Simpel-FPGA und externer HMDI/DP
> Receiver zusammen. Gibts den IP-Core fuer umme?

Nö, die FPGAs sind insgesamt schon billiger, nur braucht es auch noch 
ein bissl was fürn guten Pegel, also einen buffer. Es wird also nicht 
wirklich platzsparender.

>Gibts den IP-Core fuer umme?
Nein, jedenfalls nicht von Xilinx. Muss gekauft werden, weil die 
HDMI.org was abhaben will.

Ich plädiere daher auch eher für einen Receiver-Chip. ADV75xx oder 
sowas. Der macht Pegel, Clock-Refresh, Retiming, Übersetzung der Daten 
auf Parallel und löst das Lizenzproblem.

Wenn es nur ein Empfangskanal sein sollte, ist das dann sogar auch 
billiger, ganz abgesehen von den Entwicklungskosten. Es ist nämlich BEI 
WEITEM nicht damit getan, einfach den HDMI-Core ins design fallen zu 
lassen und nach hause zu gehen. Der möchte konfiguriert werden, damit er 
mit dem Video-PHY-subsystem (der mit den MGTs "receiver" spielt) 
zusammenwuselt.

Auch bei einem einfachen FPGA muss noch ein DDR-Controller eingebaut 
werden. Damit dürfte der TE genug zu tun haben.

Stefan M. schrieb:
> Das Ding ist halt, von FPGAs habe ich bisher wenig Ahnung.
Null Chance!

Wenn überhaupt, nimm einen fetten FPGA und einen HDMI-chip.
Dann kannst du die Funktion so wie in C schreiben:
Warten bis VSynch und Hsynch, Daten in die Block-RAMs und fertig.
Hinten ein paar Zähler, die sich die Daten aus den Rams holen und ein 
Bildlein machen.

Wenn du sehr geschickt bis, komsmt du ohne grosses RAM aus, wenn du die 
Quelle dazu bringen kannst, die Pixel zur richtigen Zeit auszuspucken.
Dann ist das nur ein Ausblenden, Einblenden mit IF THEN

Autor: Signalverarbeiter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan M. schrieb:
> Ich hätte auch kein Problem damit mit der doppelten bzw vierfachen
> Auflösung aus dem PC zu gehen.

Genau so. Das Bild muss vom Timing her schon so gross sein, wie es 
später gemacht werden muss. Die Länge in X und Y also übereinstimmen.

Das Display muss daher mit einem ganzzahligen Teiler der 
HDMI-Taktfrequenz gefahren werden.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jemand schrieb:
> Die Spartan-6 Serie hat Devices mit SERDES drin:
> https://www.xilinx.com/products/silicon-devices/fpga/spartan-6.html
>
> Selbst die kleineren (z.B. XC6SLX4-2TQG144I) haben welche, und das ist
> am unteren Ende angesiedelt. Die Frage ist natürlich, ob die ausreichen,
> aber ausschließlich ein Feature teurer FPGAs ist das nicht.
> Einige Spartan-6 bieten auch TMDS-Receiver an, womit sich HDMI umsetzen
> lässt.

Uhh...das geht zwar moeglicherweise mit viel Gefrickel, aber das wuerde 
ich nicht mehr machen. Bis man die Timings eingehalten kriegt, das 
Lane-Deskewing, usw. vergeht viel, viel Zeit und man muss tief in die 
Wissenschaften der manuellen Plazierung einsteigen.

Lattice hat Silicon Imaging unter der Haube, ergo gibt es da sehr 
schoene Referenzdesigns mit ECP5 und einem HDCP-freien Si irgendwas, 
siehe EVP-Kit.
Das ist auch vernuenftig dokumentiert (im gegensatz zu den 
HDCP-Kaefern), und die passenden HDMI-Cores gibt es in verschiedenen 
Varianten. Ich hatte damals relativ schnell (ein paar Wochen) was am 
Laufen, allerdings ohne externes DDR. Das ist bei Lattice wiederum etwas 
knifflig (gewesen).

Autor: K. L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Ich hatte damals relativ schnell (ein paar Wochen) was am
> Laufen, allerdings ohne externes DDR.

Nimm einen aktuellen größeren Baustein der 7er-Serie von Xilinx und baue 
es mit den MGT. Das geht binnen Tagen. Inklusive DDR-Controller. Alles 
fix und fertig aus der Box.

Also wenigstens hat uns das der Xilinx-FAE, den wir vor Tagen im Hause 
hatten, es so versprochen.

Autor: Tobias N. (technick2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> und einem HDCP-freien

Wie verhält sich der denn, wenn eine Senke HDCP anfordert?

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias N. schrieb:
> Martin S. schrieb:
>> und einem HDCP-freien
>
> Wie verhält sich der denn, wenn eine Senke HDCP anfordert?

Wieso sollte eine Senke sowas tun koennen?

Gruss
WK

Autor: Tobias N. (technick2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samstag abend, 2 Weißbier getrunken, man kennt das ja :-)

Also nochmal: "wenn die Quelle das anfordert"?

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Naja, das uebliche halt: 's dud ned.
Also mit viel Glueck schaltet dann die Quelle, wenn sie merkt, dass die 
Senke sich nicht authentisieren kann, auf eine hundsmiserablige 
Aufloesung runter oder sie liefert gar kein Ausgangssignal.

Gruss
WK

Autor: Sepp (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
K. L. schrieb:
> Das geht binnen Tagen. Inklusive DDR-Controller.
> Alles fix und fertig aus der Box.
> Also wenigstens hat uns das der Xilinx-FAE, den wir vor Tagen im Hause
> hatten, es so versprochen.

Xilinx verspricht da sehr viel und auf den ersten Blick schaut alles 
schnell und einfach aus. Aber versuchst du, ein wenig vom Weg 
abzuweichen und deine eigene Applikation zu entwickelln, verläufst du 
dich schnell in den Tiefen der Strukturen aus Scripten und Cores. Es 
reicht, wenn irgendwo ein Pfad nicht stimmt oder ein Parameter nicht 
passt. Dann viel Spass beim Suchen.

Autor: Martin S. (strubi)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
K. L. schrieb:
> Also wenigstens hat uns das der Xilinx-FAE, den wir vor Tagen im Hause
> hatten, es so versprochen.

Ha, ha :-)

Sepp schrieb:
> Xilinx verspricht da sehr viel und auf den ersten Blick schaut alles
> schnell und einfach aus. Aber versuchst du, ein wenig vom Weg
> abzuweichen und deine eigene Applikation zu entwickelln

Jeder kann alles, und Xilinx kann sowieso alles, aber es artet jedesmal 
aus. Da lob' ich mir die 'Kleinen', die sich auf ein Thema fokussieren, 
und das dann auch beherrschen.

Den Anlauf habe ich mal bei Altera genommen, auf die Ansage hin: 
"Koennen Sie als Blocks im SoC-Builder zusammenklicken - laeuft". Dass 
man da die getimebombten Cores aus irgendeinem Grund nicht mit eigenen 
kombinieren kann, sagt einem weder Tool noch FAE.

Bei HDMI ist das so eine Sache: Man kann u.U. mal schnell was zum Laufen 
kriegen, wenn's aber ans Einhalten der Timings geht und man mal so seine 
4-5 Sourcen angeschlossen hat, mit denen's dann nur sporadisch geht, 
muss man schnell mal ans harte Logik-Routing. Da spendiert man besser 
schon mal den Receiver-Chip fuer die Erstserie.

Autor: Signalverarbeiter (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Martin S. schrieb:
> Da spendiert man besser
> schon mal den Receiver-Chip fuer die Erstserie.
Der Vergleich ist aber nicht ganz fair, weil die HDMI-Transceiver-Chips 
auf den Datenstrom und die SPEC angepasst sind. Das gilt vor allem für 
die PLLs, Jitter und die Toleranz gegenüber dem Eingangssignal. Die 
integrierte CHIP PLL logged sich oft auch auf sehr schlechte und 
beflektionsbelastete Signale.

Die Transceiver im FPGA sind Universal-Architekturen, die so gut wie es 
geht, auf den Standard hingetrimmt werden. Ich bin nicht mal sicher, ob 
die den perfekt können. HDMI arbeitet mit Signalstandards, die nicht 
automatisch mit FPGA-Bänken kompatibel sind.

Die gleiche Rechnung lässt sich für SATA aufmachen: 2 Tage, um eine 
Schaltung zusammenzuklicken, 3 Tage Fehlersuche und 2 Wochen, um den PL 
davon zu überzeugen, die Schaltung zu redesignen und einen Chip 
draufzusetzen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.