Grafikdisplay 320x240 ansteuern

  • Liebe Profis,


    habe mir dieses XMega-Board mit Touchdisplay gegönnt: mikromedia for XMEGA


    Laut Datenblatt tft_320_240_touch_spec.pdf ist der Displaycontroller ein HX8347D.


    Die Beschaltung, wie das XMega-Board das Display ansteuert, sieht so aus:


    [Blockierte Grafik: http://www.EDV-Dompteur.de/image/maxi/touchdisplay_320x240.jpg
    OK,
    durch die feste Beschaltung der Pins IM0, IM1, IM2 und IM3 ist der Schnittstellentyp also unveränderlich auf 8 parallele Bits eingestellt, im Modus:
    "8080 MCU, type 2"
    wozu die Pins DB10 bis DB17 dienen.



    Nun verkauft Mikroelektronika ein eigenes Basic, einen grafischen Fontdesigner, ein Programm um grafische Oberflächen für das Ding am PC zu erstellen ...
    Alles schön, aber ein paar Hunnis wird man los, muss sich wieder in ein anderes Basic einarbeiten und und und.
    - Ich will es daher mit Bascom ansteuern!
    Schon allein um meine etlichen Bascom-Routinen praktisch unverändert einsetzen zu können. Die Syntax von deren MikroBasic sieht nämlich reichlich anders aus.


    Gut, die Backlight-LED habe ich mit einem Minimalprogramm schon mal testweise erfolgreich zum Blinken gebracht - welch ein Erfolgserlebnis ... ;)


    Aber bei dem Datenblatt vom Display bekomme ich Pickel.
    Noch viel mehr Pickel bekomme ich, wenn ich mir die Codebeispiele in MikroBasic anschaue (die für Bascom erheblich umgefrickelt werden müssten).
    So 65kB recht schwer kapierbarer Quelltext und vermutlich noch weitere, dazuincludetete Routinen ...
    Stundenlanges Googlen nach mundfertigen Bascom-Routinen hat nichts guttenbergbares hervorgebracht. Wenn ich mich also durch das Datenblatt quälen und alles selbst machen sollte, sitze ich da bestimmt 3 oder 4 Wochen dran.



    Frage also:
    Hat einer der hier mitlesenden Profis Tipps, wie man so ein Display im Modus 8 Bit, 8080 MCU type 2 relativ schmerzlos ansteuern kann?


    Ich brauche nicht viel von dem ganzen Spielkram, den das Display unterstützt (keine Spiegelung, kein Scrolling, kein ...)
    Es wäre schon Gold wert, einfach eine Grafikdatei dort reinschieben zu können (habe Speicher satt).
    Traum: Dann noch Textausgabe, die über der Grafik liegt. Mehr brauche ich echt nicht.


    Bin für jeden Tipp dankbar! :love:

  • Hmm, mangels Antworten vereinfache ich die Fragestellung mal.
    Streichen wir das Wort "Bascom".


    Also: Wer weiß, wie man bei einem solchem Display, das im Modus "8080 MPU type 2" über einen 8-Bit Datenbus angesteuert wird, ein Bild in das Ding geladen bekommt?
    Programmiersprache wurscht, hauptsache das Prinzip kommt rüber.

  • Ja, muss es.
    Weil es bei dem Produkt schon mit dabei ist - fest mit der Platine verbunden.


    Hatte früher ein anderes Grafikdisplay verwendet, da weiß ich wie man das Ding zum Tanzen bekommt. Allerdings war da auch schon jede Menge Vorarbeit des Lieferanten drin, der eine Bascom-Lib gleich mitlieferte. Da konnte man dann sofort mit Hochsprachenbefehlen arbeiten.


    Hier, bei diesem Display, muss ich das wohl notgedrungen alles selbst machen.
    Dass das ein Riesenaufwand werden würde, war mir klar, aber das Produkt war einfach zu verlockend und ich hatte doch gedacht, dass ich in relativ kurzer Zeit in der Lage wäre, da zumindest 'ne Grafik reinzuschieben.
    Oder dass zumindest einfache ACII-Sachen gehen, über einen schon integrierten Zeichensatz.
    Das Erwachen kam erst, als ich das Ding in Betrieb nahm und mir das Datenblatt zu Brust nahm ...
    - Nix mit integriertem Zeichensatz. Dafür ein Haufen Schickimicki-Features, die mir aber auch nichts nützen.

  • Schau' doch mal bei Mikrocontroller.net, da gibt's ein paar Threads über das Teil... ;)


    der 6. Link ist direkt ein C-Quellcode, bei Watterot gibt's auch einen...


    So wie ich das verstanden habe, ist das praktisch wie ein RAM, was DU da rein schreibst, zeigt das Display an - aber Text etc. musst Du alles selbst machen...


    bei meinem 35-Euro-STM32-inkl. Display-Board wäre sogar ne Lib für ne GUI dabei, aber da scheitert's bei mir am C... :D (ähnliches Problem wie bei Dir...)

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Tja Pesi, die Quellcodes beziehen sich aber auf den SPI-Modus, nicht auf den 8-Bit-Modus.
    Ganz so einfach umstricken kann man das nicht (oder ich bin nur zu dumm), weil zu dem 8-Bit Modus sich noch vier weitere Steuerleitungen gesellen (von Reset abgesehen, damit wären es 5) und ich keine Ahnung habe, wie die zu bedienen sind.
    Ja, im Datenblatt steht es sicherlich, aber ich werde aus dem halt nicht so schmerzfrei schlau, wie aus einem AVR-Datenblatt.


    Die Links auf Microcontroller.net nützen auch nichts.
    Ich habe ja schon stundenlang gegoogelt, bevor ich die hier Frage stellte und bin über die Threads dort selbst schon gestolpert.
    In den Threads auf Microcontroller.net findet man die gleichen Fragen, die ich auch stelle, aber mit (brauchbaren) Antworten sieht es dünn aus.


    Nett gemeint, hilft nur nicht.

  • Tja Pesi, die Quellcodes beziehen sich aber auf den SPI-Modus, nicht auf den 8-Bit-Modus.
    Ganz so einfach umstricken kann man das nicht

    Wo ist das große Problem...?


    Wie ich bereits schrob:

    ist das praktisch wie ein RAM

    Und es ist auch von der Ansteuerung so, wie damals SRAM am MOS6502 o.ä. - Du hast nen Datenbus, /CS, damit der Chip sich angesprochen fühlt, und RD und WR, damit er weiß, ob er nun Daten an den Bus anlegen soll oder die Daten vom Bus übernehmen...


    guck' doch mal in den Thread - da ist übrigens (im 8. Post) ein ausführlicheres DB verlinkt, dort auf Seite 28 das Timing...


    also einfach das Byte an den Datenbus anlegen, dann die anderen Leitungen dementsprechend schalten (CS auf Low, dann WR auf Low, etc.), so dass der das Byte übernimmt... das kann man auch in Bascom (einzelne Portpins high und low schalten)


    *das* ist ja nicht das Problem, wie die Kommandos/Daten da rein kommen, sondern *welche* - du musst ja da auch "Kommandos" (also Bytes) mit bestimmtem Timing rein schicken, um das Ding zu initialisieren etc. - und da helfen die Code-Beispiele eben, weil das da alles drin steht:



    usw. - diese Zahlen, die da rein müssen, und die Pausen dazwischen etc., *das* ist das interessante, und da kannst Du froh sein, dass es das für Dein Display gibt - *wie* die da rein kommen ist das kleinere Problem, oldschool SRAM/Interface-Baustein am Mikroprozessor-Bus...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Danke Pesi!


    Habe das Datenblatt vom Display jetzt begriffen.
    Von den 179 Seiten sind nur knapp 70 überhaupt irgendwie relevant. Der Rest bezieht sich auf die anderen Ansteuermodi, da muss man also echt aufpassen, dass man sich nur den richtigen Teil zur Brust nimmt.


    Verwirrt hatte mich, dass die im Datenblatt die Signalnamen nicht durchgängig benutzen. Da wird aus "NWR_SCL" an anderer Stelle plötzlich schlicht "NWR".
    Oder aus "DNC_SCL" an anderer Stelle einfach "DNC".


    Und im Schaltplan der Displayplatine heißen die Signale wieder völlig anders.
    Da heißt "DNC_SCL" vom Displaydatenblatt dann "RS" und wird vom Controller mit dem Signal "LCD_RS" angesteuert.
    Oder aus "NRD" im Displaydatenblatt wird im Schaltplan der Platine einfach "RD" und wird vom Controller mit dem Signal "PMRD" bedient ...



    OK, die Ansteuerung ist mir nun zumindest theoretisch klar, nun kann ich mich gezielt an die Arbeit machen.

  • Habe das blöde Ding noch immer nicht zum Tanzen gebracht und verstehe nicht, wo es jetzt noch klemmen kann.
    Flashe ich eine der dem Board beiliegende Demo-Hex-Dateien, dann löppt es problemlos.


    Nun würde ich gerne mal den Logic-Analyzer dranhängen, um mir die Signale zum Display mal am funktionierenden Beispiel anzuschauen.
    Aber da gibt es ein kleines Problem: Es gibt absolut keine zugänglichen Testpunkte, ich muss also wirklich direkt an den Controller.
    Doch der steckt in einem 100-poligen, nur 1mm hohen TQFT mit 0,5mm Pitch ...


    Da komme ich nichtmal mit Stecknadeln ran, die haben selbst schon 0,6mm Durchmesser.
    Dünne Drähte direkt an die Pins löten? - Am Rande der Unmöglichkeit.
    0,8mm Pitch wäre ja noch machbar, aber bei 0,5mm ist wirklich der Ofen aus.


    Wer weiß einen kaufbaren Prüfadapter, mit dem man so einen Chip in eingelötetem Zustand kontaktieren kann?
    Oder ist inzwischen zufällig jemand über eine funktionierende Routine gestolpert, die das Display im 8-Bit-Modus ansteuert?


    Die geguttenbergten Initialisierungsroutinen, habe ich nach bestem Wissen umgestrickt, aber selbst nach drei Tagen intensiver Beschäftigung nicht zum Funzen gebracht.
    Die nötigen Pausenzeiten halte ich jedenfalls satt ein, daran liegt es auch nicht.


    Bin für jeden Tipp dankbar!

  • Hallo Irrlicht,


    ich habe genau das selbe Problem. Ich möchte das Display ebenfalls im Modus "8080 MCU 8-bit parallel type II" ansteuern.
    Allerdings habe ich den LM3S9B95 Mikrocontroller. Aber die Beschaltung ist genau die selbe.
    Hast du schon irgendwelche neuen Erkenntnisse sammeln können?


    Ich bin über jede Information dankbar!


    Chumby

  • Hallo Chumby,


    nein, ich habe noch keine neuen Erkenntnisse.
    Den Codeschnipsel den Pesi gepostet hat und den man auch woanders im Internet findet, habe ich ja entsprechend auf Bascom umgefrickelt, aber leider ohne Erfolg.


    Dem Schnipsel feht auch etwas entscheidendes: Die Routine "lcd_cmd()".
    Die wird in dem Codeschnipsel ja in einer Tour aufgerufen, aber wie die aussieht, erfährt man nicht.


    Mich wundert, dass dort offenbar ein Byte und ein Integer übergeben wird.
    Das erste Byte ist das Register, soweit klar.
    Aber der Integer müsste nach meinem Verständnis bloß ein Byte sein. Die Hexcodes beginnen ja auch jedesmal mit 00.


    Habe die Routine so umgefrickelt, dass als zweiter Parameter lediglich ein Byte übergeben wird. Aber das funzt nicht.
    Mit Integer, also zwei Bytes hintereinander, wovon das erste hex. 00 ist, klappt es auch nicht.


    Habe fast den Verdacht, dass ich mich in den Signalen täusche. Die 8 Datenbits sind ohne Zweifel korrekt, aber die vier Steuersignale könnten irgendwie falsch sein.


    Im nächsten Post mal mein Code, der nicht funzt - vielleicht sieht ja jemand mehr als ich (Nachricht zu lang, passt nicht in dieses Posting).



    Wie man sieht ist der Code quick & dirty, aber so, dass kaum was schiefgehen kann. Am Ende der Initialisierungsroutine steht testweise ein Codeblock, der das Display einfach nur einfärben sollte. Tut aber nicht.


    Nach Aufruf der Sub "LCD_ON" blinkt die Hintergrundbeleuchtung ordnungsgemäß dreimal, es gibt also keinen "Hänger" vorher oder sowas.
    Die eigentliche Programmschleife ist dann schnuppe, der entscheidende Teil wird ja vorher aufgerufen, also die Initialisierung und das Einfärben, was eben nicht hinhaut.



    Könnte ich den Logic-Analyzer dort dranhängen, wäre sofort alles klar, aber die Pins sind dermaßen hardcore-klein und eng nebeneinander, dass ich es noch nicht gewagt habe, dort dünne Drähte ranzulöten.

  • Und hier noch meine Notizen, welche Seiten des Datenblattes für unserem Modus relevant sind und welche Signale was bewirken.
    Habe es in Code-Tags gepackt, in der Hoffnung damit die Tabulatoren beizubehalten. Mal sehen ob es klappt ...




  • Dem Schnipsel feht auch etwas entscheidendes: Die Routine "lcd_cmd()".
    Die wird in dem Codeschnipsel ja in einer Tour aufgerufen, aber wie die aussieht, erfährt man nicht.

    Die ist doch mit dabei:


    Du musst da anscheinend vor Register und Parameter jeweils noch ein Byte übergeben, das wird weiter oben im Text definiert:

    Code
    #define LCD_ID               (0)
    #define LCD_DATA             ((0x72)|(LCD_ID<<2))
    #define LCD_REGISTER         ((0x70)|(LCD_ID<<2))


    Mich wundert, dass dort offenbar ein Byte und ein Integer übergeben wird.
    Das erste Byte ist das Register, soweit klar.
    Aber der Integer müsste nach meinem Verständnis bloß ein Byte sein. Die Hexcodes beginnen ja auch jedesmal mit 00.

    Da reichen meine C-Kenntnisse leider auch nicht, also ob bei z.B. 0x000C für param dann 00 0C ausgegeben wird, oder die zwei führenden Nullen ignoriert (warum auch immer sie dann überhaupt dabei stehen...), k.A., das müsste ein C-Spezialist sagen....

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Du musst da anscheinend vor Register und Parameter jeweils noch ein Byte übergeben, das wird weiter oben im Text definiert:

    Hatte ich auch schon erfolglos probiert.
    Nach meinem bescheidenen Verständnis ist das aber sowieso nur im SPI-Modus erforderlich.
    Im Parallelmodus entscheidet der high/low-Zustand des Signals "LCD-RS / RS DNC (DNC_SCL)" darüber, ob gerade das Indexregister oder das Commandregister beschrieben werden soll.


    Das hier funzt jedenfalls nicht:



    Trotzdem vielen Dank!

  • Nach meinem bescheidenen Verständnis ist das aber sowieso nur im SPI-Modus erforderlich.

    Sorry, dann nehme ich das zurück und behaupte das Gegenteil :D


    ich bin nur irgendwie davon ausgegangen, dass Du das noch gar nicht gesehen hättest, weil Du ja gemeint hast, Du findest die lcd_cmd(); nicht... und dass das wohl immer nötig wäre, soo genau habe ich mir die xxx Seiten DB auch nicht angesehen - mein Fehler...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Pesi, weißt Du, als Assembler-Guru, eventuell Rat?


    Ich bin auf 'ne neue Idee gekommen: Es gelingt mir zwar nicht, den Logic-Analyzer an die Schaltung anzuschließen, aber dem Board lagen ja diverse Demos als Hex-Dateien vor, die ganz wunderbar das Display zum Tanzen bringen, wenn man die flasht.
    Meine Idee also: Eine solche Datei disassemblieren und nachschauen, wie die Portpins tatsächlich angesteuert werden!


    Mit diesem Tool:
    http://www.jassenbaum.de/ja-tools/reavr.html
    konnte ich eine Hex-Datei disassemblieren.


    Nur: Erstens werde ich aus dem Output nicht schlau, zweitens gibt es noch diverse Einstellmöglichkeiten, die wohl irgendwie Einfluss auf den Output nehmen.


    Nun habe ich auch mal eine wesentlich einfachere Datei disassembliert, nämlich die letzte aus diesem Thread:
    Mehrere Muster speichern und abrufen
    Und reibe mir nur die Augen, weil ich die (inzwischen) 22 Bilder aus je 12 Data-Zeilen da schon nicht wiederfinde.
    Es gibt zwar einen Block, wo jede Menge Words aufeinanderfolgend gespeichert sind, aber zu wenig.
    Optmiert Bascom da etwa irgendwas?


    Kannst Du aus so einer disassemblierten Datei schlau werden?



    Edit: Wenn ich diesen absolut minimalistischen Quelltext mit Bascom compilliere:


    Und das Hex-File mit ReAVR disaaembliere, kommt das raus, was im Anhang zu finden ist.


    Also mein Quelltxt macht ja nichts, als die Ports J1 bis J5 nach einem Schema anzusteuern, von dem ich denken würde, dass ich das irgendwie wiederfinden müsste, in dem Decompilat.
    Bin aber wohl zu doof, ich finde da nix wieder.
    Hülfäää!!!

  • Hier oben:


    das ist die Interrupt-Vektor-Tabelle, die legt Bascom wohl immer an, auch wenn gar keine Interrupts benutzt werden....


    das Ports setzen geschieht dann so wie's aussieht hier:



    und dann wird nix mehr gemacht, Endlosschleife:

    Code
    L0195:
    	rjmp	L0195


    das mag' jetzt verwirren, weil da "sts" steht (Store to SRAM), bei größeren AVRs sind aber manche Register schon im Bereich, der wie RAM angesprochen wird, also da auch "sts" statt "out"


    das steht im Datenblatt, welches Register welche Adresse hat ("Register Summary"), anhand dessen lässt sich das rausfinden...


    ein guter Disassembler macht das automatisch, ersetzt dann eben die Register-Adresse durch den Namen, für bessere Lesbarkeit - dazu muss er aber wissen, um welchen µc es sich handelt... kann man das da nicht irgendwo einstellen, oben steht ja drin:

    Code
    ; AVR_TYPE=<unknown>


    ?


    unten sind dann noch ein paar Subroutinen drin:


    völlig sinnlos, weil die nirgendwo aufgerufen werden ?( - k.A., evtl. sind das irgendwelche Bascom-Grundroutinen, die der Compiler *immer* rein schreibt, egal ob gebraucht oder nicht...? - oder ich habe den Aufruf (da müsste irgendo call oder rcall stehen) übersehen...?


    wenn Du sowas genauer rausfinden willst (also was Bascom da so macht), dann am Besten weniger compilieren, dann findet man's eher - also z.B. mal nur einen Port auf Ausgang schalten, sonst nix, dann sollte auch in der .hex (neben dem drumherum) nur das drin stehen... dann mal nur ein Portbit setzen, mit der vorherigen Datei vergleichen, dann sieht man leichter, welcher Bascom-Befehl welchen Code erzeugt...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Boahhh, Pesi, jetzt bist Du aber als Masochist entlarvt!


    12 Zeilen Assemblercode sind notwenig, um einen Portpin auf 1 oder auf Null zu setzen???
    Und das Gruseligste:
    Setzt man erst 'nen Pin auf 1, dann auf Null und dann nochmal auf 1, dann ist der letzte 12-Zeilen-Block nicht identisch mit dem ersten!?!
    Wer programmiert denn in so einer Sprache?


    Dennoch vielen Dank für die Erhellung! [Blockierte Grafik: http://www.pagan-spirit.de/wcf/images/smilies/thank-you2.gif]



    Inzwischen bin ich auf ganz anderem Wege weiter gekommen.
    Das Display tut jetzt ein Bisschen was.
    Zwar noch nicht ganz das, was ich erwarte, aber offenbar bin ich schon mal auf dem richtigen Weg.

  • 12 Zeilen Assemblercode sind notwenig, um einen Portpin auf 1 oder auf Null zu setzen???

    nee, wie kommst Du da drauf, Du setzt doch nicht nur einen Portpin in Deiner SW.... ?(


    in Assembler setzt man einen Portpin ganz einfach mit:


    Code
    sbi PortD, 3    ; PortD.3 auf 1 setzen


    und wenn der Port in so nem "wie-RAM-ansprechen-Bereich" liegt, dann heisst's halt (Register temp0 wird irgendwo weiter oben global definiert, braucht man immer wieder):


    Code
    lds temp0, PortD
    sbr temp0, (1<<3)
    sts PortD, temp0


    das kommt aber sehr selten vor (auf XMega vielleicht, aber noch keinem, den ich bis jetzt benutzt habe...), ausserdem kann man da ja auch c&p machen - oder *ein mal* ein Makro schreiben:


    Code
    .macro	SetzePortBit
    	lds temp0, @0
    	sbr temp0, (1<<@1)
    	sts @0, temp1
    .endm


    das man dann auch wie einen Befehl benutzen kann, also dann einfach:


    Code
    SetzePortBit PortD, 3


    hin schreiben, der Assembler ersetzt dann eben den "Befehl" durch diese 3 Zeilen, und hier @0 durch "PortD" sowie @1 durch "3" - alle oft benutzten Makros in eine zentrale Datei, und die immer per .include einbinden, so kann man sich selbst ein paar "Hochsprachen-Befehle" zusammenbasteln... muss man wie gesagt nur *einmalig* machen, nicht jedes Mal!


    EDIT: letztlich macht Bascom bei vielen Befehlen auch nix anderes, wenn Du irgendsonen Bascom-Befehl hin schreibst, schaut der Compiler in seiner internen Lib nach, welcher Assembler-Fetzen dazu gehört, und klatscht den dann in das Output-File, ersetzt dabei eben bestimmte Parameter durch die beim Befehl angegebenen...


    Setzt man erst 'nen Pin auf 1, dann auf Null und dann nochmal auf 1, dann ist der letzte 12-Zeilen-Block nicht identisch mit dem ersten!?!

    ich hab's auch noch nicht ganz durchstiegen, was der da genau macht, sieht aber für mich so aus, dass der Compiler gar nicht echt einzelne Bits setzt, sondern der weiß ja, welchen Wert er zuletzt da rein geschrieben hat, und dann schreibt er beim "Bit setzen" einfach den Wert von vorher, nur mit dem zusätzlich gesetzten Bit rein... ein echter "Bit setzen"-Befehl wie sbi oder sbr kommt da ja gar nicht vor...


    Wer programmiert denn in so einer Sprache?

    In der von Dir beschriebenen Sprache kein Mensch - aber der Bascom-Compiler macht halt sowas... ;) :D

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Einmal editiert, zuletzt von Pesi ()