|
Anzeige
|
Graphische Funktionen für EA DOG XL160
Gast
#5930088
Hallo Nach dem die bmp auf meinem Display laufen und mir eigene Bilder damit erzeugen kann kommt die nächste Frage. Ich verwende als Datein die von Jan Michel(Muschelsoft). In den Datein sind ein paar Befehle mit Data drin. Aber keine Befehle um z.B. Striche, Kreis, Punkte oder ähnliches damit zu erzeugen. Es gibt viele Beispiel dazu im Netz. Mit der Umsetzung auf das XL160 habe ich so meine Probleme. Kennt da jemand was dazu? LG Heinz
Gast
#5930848
Kennt jemand was mit Graphik zum DOG XL160?
Gast
#5931384
Was erwartest du eigentlich so als Antwort? Ja, ich kenne was mit Grafik. Klare Sache das. Nein, ich habe mich nie um die EA-DOGM gekümmert. Sind mir viel zu teuer für das, was sie bieten. Reicht's? Ansonsten gibt es hier im Forum genügend Beispiele für was mit Grafik, da wird auch für dich was dabei sein. Allerdings würde ich dir eher raten, ein wenig dazuzulernen und nicht nur irgendwelche Quellen von Jan Michel u.a. zusammenzukopieren, sondern dir selbst ein passendes GDI und einen Treiber für dein Display zu schreiben. W.S.
Gast
#5931641
Danke für deine Worte. Habe mir die Sachen von Jan angesehen. Leider sehe ich die Sache etwas anders. Seine Sachen sind so umfangreich das ich einfach nicht nachvollziehen kann was alles notwendig ist. Wenn ich das alles erst lernen soll dann habe ich die nächsten Jahre damit zu tun alles neu zu erfinden. Warum soll man nicht auf vorhandenes zu greifen wenn es sich bewährt hat. Nehme einfach an das auch du auf vorhandene Bibliotheken zugreifst oder schreibst du für jede Anwendung alles neu?
Gast
#5931647
Heinz schrieb: > Wenn ich das alles erst > lernen soll dann habe ich die nächsten Jahre damit zu tun alles neu zu > erfinden. Dann bezahl einen, der das für Dich erledigt.
Gast
#5931702
Viele Dateien und Programme stehen unter einer bestimmtem Lizenz hier im Netz. Dort wird dann z.B. gesagt das sie für eine private Nutzung offen sind und genutzt werden dürfen. Warum sollte ich es nicht machen solange ich den ori Autor nenne und das Programm nicht als meines ausgebe? Heinz schrieb: > Warum sollte ich es nicht machen solange > ich den ori Autor nenne und das Programm nicht als meines ausgebe? Darum gehts nicht. Es geht darum dass du hier Hilfe in Form von fertigen Lösungen suchst und gleichzeitig aber nichts lernen willst du keine Zeit dafür opfern willst. Du nimmst also gerne die Zeit von anderen in Anspruch, deine eigene ist dir aber zu wertvoll. Das stößt manchen halt etwas sauer auf. Jetzt kapiert?
Gast
#5931729
Frag doch Jan Michel rolleyes Heinz schrieb: > Ich verwende als Datein die von Jan Michel(Muschelsoft). welche? Link? Dein bisheriges Programm? Wo steckst Du fest? Werden ja wohl n paar LOW Level Routinen bei sein: wenn BITMAP geht, sind da meist auch LINE RECT CIRCLE Funktionen bei. Datein<->Dataus? Tagein, tagaus; das kenne ich. Jetzt mal im Ernst ------------------ Du liest doch sicher hier schon einige Jahre mit und weisst ganz genau, was passiert, wenn man einen Thread so startet, wie Du da eben... Halte dich doch schlicht an die hier geltenden, ungeschrieben Gesetze. Link, Project, Problem, Doku, Fotos usw. "Datein von Jan Michel" äm Nee, reicht nicht. also mir nicht.
Gast
#5934113
Heinz schrieb: > Habe mir die Sachen von Jan angesehen. Leider sehe ich die Sache etwas > anders. Seine Sachen sind so umfangreich das "daß". So. Und nun mal ganz ernsthaft: Um einigermaßen Ordnung in eine Firmware zu kriegen, mußr du selbige sinnvoll aufteilen. Dann wird das Ganze auch übersichtlicher. Also in deinem Falle: Unterste Schicht: der Lowlevel-Hardwaretreiber für dein Display. Der beinhaltet die alleruntersten Funktionen, also bei I2C-Displays ist das ein Treiber für den I2C mit StartCond, StopCond, Adressieren, Bytes schreiben und lesen. Bei Parallelanschluß wäre das dann Setzen von A0 (bze.C/D) und Port schreiben und lesen. Dieser Treiber ist selbstverständlich plattformspezifisch, hat aber ein Interface nach oben (die .h), was bereits plattformunabhängig ist. Zweitunterste Schicht: der eigentliche Displaytreiber. Der stützt sich auf den o.g. Treier der untersten schicht und er beinhaltet das Initialisieren, Kontrast einstellen, ggf. Spiegeln usw. und den Blocktransfer von einem µC-internen Displayram ins eigentliche Display. Wenn du einen zu kleinen µC hast, der zu wenig RAM hat, dann mußt du in diesen Treiber auch das Setzen von Einzel-Pixeln aufnehmen. Dieser Treiber ist also plattformunabhängig und er bietet nach oben hin auch ein displayunabhängiges Interface. Das Einzige, was bleibt, ist das Bekanntgebe der Pixelanzahl in X und Y und die Anzahl der Farben (hier wohl 4: schwarz, 2x grau, weiß) Dritte Schicht: das ist das GDI, also die Funktionen zum Zeichnen von Punkten, Linien, Flächen usw. und Text. Vierte Schicht: Das sind Fonts und Grafiken in einer Form, die vom GDI verstanden wird. Mal ein paar Lese-Hinweise: https://www.mikrocontroller.net/attachment/316790/STM32F103C8T6.ZIP https://www.mikrocontroller.net/attachment/305446/Bastelquellen.zip W.S.
Gast
#5934500
Danke für deine Infos. Werde es durcharbeiten. Ist es notwendig so weit unten anzufangen? Die übertragung mit dem I2C Bus funktioniert ohne Probleme. Betreibe damit verschiedene Module bereits, darunter auch andere Displays. Im Vergleich zu anderen Displays ist die Ansteuerung beim XL160 aber anders. Eines gestehe ich voll und ganz, einzelne Funktionen beim Zeichnen der Graphischen Elemente ist mir unklar. Versuche es zu verstehen und gehe den Code durch, doch ab einem bestimmten Punkt ist Ruhe. Ist mir dann zu komplex. Empfinde es aber nicht als Schande, wenn man es offen zu gibt. Habe noch viel zu lernen dabei. Einige Sachen kopiere ich, gebe ich auch zu. Wenn man es aber anpasst muss man oft mehr machen als man so denkt. LG Heinz Antwort schreiben |
Anzeige
|
