vorweg: Ich habe mir noch keinen Arduino zugelegt und bin, was Programmierung angeht, ein recht leeres Blatt. Dennoch habe ich die letzten Tage ordentlich das Internet durchwühlt, mir zig Tutorials und Videos angesehen und möchte nun starten. Folgendes Projekt ist mir im Kopf:
Für den Anfang hätte ich gern einen kleinen TFT, auf dem ich (entweder mit einem Encoder oder einer virtuellen Tastatur) Namen eingeben und diese in eine Liste speichern kann. Im Zuge dessen möchte ich jedem Namen einen Program Change Befehl zuweisen, der dann gesendet wird, sobald man den Namen auswählt. Mit anderen Worten: Eine Songliste, die auf Knopfdruck externe MIDI Geräte umschaltet.
Die Ideen gehen noch viel weiter, aber Step-by-Step.
Ich habe viele Videos und Anleitungen dazu gefunden, wie ich Buttons und Bilder auf dem Screen erstelle. Leider jedoch hab ich in der Richtung, in die ich gehen will, keine Dokumentationen gefunden. Deshalb der Post hier.
Wo fang ich für dieses Projekt an?
Klar, ich werd mir ein Starterkit zulegen und mich mit der Materie vertraut machen, aber letztlich habe ich kein Kit, keine Tutorials oder Dokumentationen gefunden, in denen beschrieben wird, wie man z.B. eine Liste (und lassen wir das Program Change auch gerne erstmal außen vor) erstellt.
Ich würde mich sehr freuen, wenn mich jemand in die richtige Richtung lenken kann. Bin für Tipps wirklich dankbar.
Anleitungen gibt es dazu nicht, weil man die gesamte Logik selbst programmieren muss wenn man nicht gerade irgendwo ein fertiges Menü findet.
Man kann das Display aber einfach in Zeilen unterteilen. Jede Zeile hat eine Koordinate, d.h. sie liegen z.B. 15-20 Pixel auseinander. Kommt natürlich auf die Schriftgröße an. Jede Zeile hat einen Index. Über den Index weiß man dann wo man ist und kann so z.B. in ein Array aus Strings für die Namen greifen. Den Index kann man so auch einfach auf die Display Koordinaten umsetzen.
Fang erst mal damit an, dass du einen Cursor - z.B. einen Pfeil oder erst mal das '>' Zeichen über den Bildschirm bewegst. Dazu musst die wie bei einem LCD auch die alte Position überschreiben und ein Zeichen auf die neue Position schreiben. Man kann es natürlich auch über die Text-Farbe machen. Aber auch da ist es das gleiche. Den alten Text muss man überschreiben und die neue Zeile in einer anderen Farbe schreiben.
Komplizierter wird dann das Scrollen. Da muss man aber auch nur über den Index feststellen ob man den Bildschirm verlässt und den Inhalt neu schreiben. Da macht sich dann negativ bemerkbar, dass die Displays relativ langsam sind. Besser ist da vielleicht Seiten-weise zu scrollen und nicht Zeile für Zeile.
Für den Anfang hätte ich gern einen kleinen TFT, auf dem ich (entweder mit einem Encoder oder einer virtuellen Tastatur) Namen eingeben und diese in eine Liste speichern kann. Im Zuge dessen möchte ich jedem Namen einen Program Change Befehl zuweisen, der dann gesendet wird, sobald man den Namen auswählt.
Obiger Text hört sich klar, einfach und verständlich an. Aber es steckt sehr viel Arbeit dahinter. Serenifly hat ja schon angefangen ein paar Details zu hinterfragen. Tatsächlich dürfte das auch der beste Ansatz sein: Zerlege das, was du machen möchtest in kleine und noch kleinere Schritte. Gehe dabei deinen Anforderungen Schritt für Schritt durch:
einen kleinen TFT,
Wie wird ein Zeichen dargestellt? Was für ein TFT? Welche Controller? Gibt es eine fertig Lib, oder muß man das selbst die Graphikausgabe programmieren?
einem Encoder
Einen Encoder auszulesen ist ebenfalls eine Wissenschaft für sich. Auch hier die Frage: Was für ein Encoder? Viellecht gibt es eine Lib dafür?
virtuellen Tastatur
Klingt gut. Aber wie soll das umgesetzt werden? Resistives Touchpad wäre eine Möglichkeit. Damit muss man sich aber auch erst mal ein paar Tage beschäftigen.
Namen eingeben und diese in eine Liste speichern kann
Oben wurde ja schon entsprechendes dazu geschrieben, aber auch eine Frage ist: Wie speichern? EEPROM wäre eine Möglichkeit. Auch hier müsste man sich erst mal damit beschäftige, wie man ein Byte dauerhaft abspeichern kann.
Ich finde das ein super interessantes Projekt, aber - wie bei allen Projekten - muss man das Problem erst mal in viele kleine lösbare Probleme zerlegen.
olikraus:
Wie wird ein Zeichen dargestellt? Was für ein TFT? Welche Controller? Gibt es eine fertig Lib, oder muß man das selbst die Graphikausgabe programmieren?
Na ja. Kann so kleinlich müssen wir auch nicht sein. Es stimmt zwar, dass das alles zusammen alles andere als trivial ist (gerade als Anfänger vielleicht zu kompliziert), aber man muss nicht bei Null anfangen. Es gibt schon einige fertige Libs für Displays. Wenn man ein Display nimmt dessen Controller von UTFT unterstützt wird hat man schon einen Satz gut brauchbarer Routinen, Fonts und mit UTFT Buttons auch eine fertige Lib für Knöpfe auf dem Bildschirm.
Als Informatiker war die Logik für ein TFT Menü für mich kein Problem, aber an ein paar Stellen habe ich trotzdem die Menge Code etwas unterschätzt die man braucht um Dinge zu implementieren die auf den ersten Blick recht einfach aussehen.
SD Karte ist auch eine gute Möglichkeit um Sachen zu speichern. Die TFT Adapter Shields haben meistens einen Slot. Eine Text Datei kann man auch einfach auf dem PC editieren. Das heißt man könnte seine Liste eventuell auf dem PC erstellen und auf dem Arduino einfach auslesen.
Du brauchst dafür übrigens besser einen Mega. Unter 3,2" wirst du nicht zufrieden sein wenn du viele Knöpfe auf dem Display hast. Die Displays benötigen viele Pins und das alles belegt auch ziemlich viel Flash. Ich bin inzwischen bei fast 60k Flash für ein paar Menüs (+ Uhr, SD und DallasTemperature) und 2,3k RAM. Ich verwende PROGMEM wo es geht um bei der Verwendung von Strings RAM zu sparen, aber ein Anfänger bräuchte da einiges mehr.
2,8" SPI Displays laufen wohl auch auf dem UNO, aber das RAM ist da einfach sehr knapp. Bildschirmtastatur könnte auf 2,8" vielleicht sogar gehen wenn man sich kleinere Handys anschaut.
ich würde mich erst mal um die Musikwiedergabe und Ansteuerung der MIDI-Geräte kümmern. Die Eingaben kann man im ersten Schritt auch über einen PC machen. Als erstes LCD kann man auch einfach ein 1602 oder 2004-Text-LCD nehmen. Erst wenn das Projekt die eigentliche Aufgabe erfüllt, würde ich mit TFT und Touchbedienung das Projekt aufhübschen.
Erst wenn das Programm seine Aufgabe erfüllt, hat man sämtliche Datenstrukturen und Parameter um effektiv eine gute Bedienoberfläche zu bauen. Natürlich kann man bei der Grundstruktur das eigentliche Ziel im Auge haben, damit man keine ungünstigen Entscheidungen trifft und Raum für die Erweiterungen lässt.
Ja, ein 20x4 LCD wollte ich auch schon vorschlagen. Damit kann man auch gut scrollen (und mit dem gleichen Prinzip), aber es ist wesentlich einfacher zu programmieren. Man ist halt in der Breite limitiert, aber man kann auch Text in einer Zeile scrollen (da gibt es hier auch irgendwo fertigen Code dafür).
Wäre für den Anfang wahrscheinlich das vernünftigste.
Ein herkömmliches LCD kommt für meine Anwendung nicht in Frage. Und auch Musikwiedergabe brauche ich gar nicht. Ich denke, das beste ist, erstmal den MIDI Gedanken völlig außen vor zu lassen. Wenn später ein Menü steht, kann man MIDI immer noch einbinden... so zumindest in meiner (einfachen) Vorstellung.
Serenifly:
Noch habe ich weder den Arduino, noch das Display gekauft. Wenn du für mich eine Empfehlung hast, bin ich dir dankbar. Sollte der Umgang mit TFT tatsächlich noch eine Stufe zu hoch sein, habe ich hier noch einige LCDs mit 2x20 und 2x40 Zeichen; folgendes Modell:
Also: Lassen wir mal Touch außen vor (womit also auch die virtuelle Tastatur rausfliegt). Auch lassen wir vorerst außen vor, die Namen direkt am Screen einzugeben.
-> Liste am PC erstellen, auf eine (micro-)SD Karte schieben und am Arduino auslesen und auf dem Bildschirm ausgeben. Das wäre somit also der erste und kleinste machbare Schritt.
Encoder hab ich übrigens von BOURNS PEC164015F-S0024 und von ALPS EC11.
Okay, hat jemand für mich einen Link zu einem Leitfaden, der einen mal so grob in die Richtung lenkt?
Es ist schon klar, dass ein 4x20 Display nicht viel Platz bietet. Ich meine das auch gar nicht als Endlösung.Aber es ist eine guter Zwischenschritt um sich in die Sache einzuarbeiten und was lauffähiges zu bekommen. Die TFTs sind wie gesagt auch mit Libs nicht ohne. Gerade für dein erstes Projekt und wenn du sagst "was Programmierung angeht, ein recht leeres Blatt".
Wenn das mal geht kannst du immer noch auf ein TFT umsteigen. Den Teil mit der SD Karte bearbeiten kannst du da z.B. 1:1 übernehmen. Auch das Scrollen mit einem Dreh-Encoder kann man auf einem TFT zusätzlich zum Touch gut machen (wobei da vielleicht die langsame Geschwindigkeit des Displays etwas reinpfuscht wenn man schnell dreht).
Da sind - anders als bei manch anderen Shields (z.B. das hier bei EXP TECH) - nicht alle Pins unnötig mit Stiftleisten belegt. Man kann dann da Stackable Header Kits und 8-Pin right-angle Header einbauen um an die Pins zu kommen. Bei komputer.de wird da übrigens anders als auf den Bildern die neuere 2.2 Version ohne Helligkeits-Poti und mit Bustreibern statt Spannungsteilern geliefert.
wenn ihr sagt, dass wir das nochmal in kleinere Schritte unterteilen können und ich erstmal ein LCD nehmen soll, dann mach ich das einfach so. Klein anfangen! LCDs hab ich, wie gesagt, ja noch hier liegen.
Jetzt geht es um den Arduino an sich: Welchen soll ich nehmen? Du schriebst, dass man eventuell gleich zu einem Größeren greifen sollte? Ich würde sehr gerne erstmal mit dem UNO anfangen, schon allein aus dem Grund, dass es dafür die meisten Starter Packs gibt. Auch hier: Habt ihr eine Empfehlung, welches Kit am brauchbarsten ist?
Und noch eine komplett andere Frage:
Sollte dann irgendwann das alles mal stehen, gibt es dann die Möglichkeit, das auf einen herkömmlichen AtMega zu brennen oder ist man immer auf die Arduino-Umgebung angewiesen? Stichwort: Kommerzialisierung.
Wenn du mit "herkömmlichen AtMega" einen atmel atmega chip meinst, z.B. einen atmega328p anstelle des kompletten UNO, das geht völlig problemlos ( jetzt sogar bei Fipsi ).
Gibt es einige Tutorials: http://arduino.cc/en/Tutorial/ArduinoToBreadboard
Auch nicht per default unterstützte Hardware ( atmega644, attiny ) geht.
Ich sehe den großen Vorteil des UNOs, dass man den 328 austauschen kann (Nicht die SMD-Version nehmen). So kann man im Notfall einen geschrotteten Prozessor ersetzen. Für dein Projekt wirst du wohl in den umfangreicheren Ausbaustufen einen Mega brauchen.
Die Projekte kann man auch auf den Prozessoren in eigener Umgebung laufen lassen. Der Atmega 1280 hat aber schon eine Menge SMD-Beinchen. Vielleicht wäre dann der 1284 eine Option, da er im Dip-Gehäuse lieferbar ist (Sanguino mit 1284). Das wäre allerdings nichts mehr für den blutigen Einsteiger.
Also dann erstmal den UNO im Starter Kit und dann bei Bedarf aufstocken.
Dann würde ich sagen, arbeite ich das Starter Kit (oder Fritzing Creator Kit) mal durch und danach die LCD Tutorials, die man auf arduino.cc findet. Ich melde mich dann wieder, sobald ich etwas mehr im Thema bin und hoffe, dass wir das dann konkreter angehen können.
Ich hab heute mal mit dem Stefan von Fritzing telefoniert.
Er würde mir in Sachen MIDI eher zu einem Teensy raten, weil dort schon vieles implementiert und auch die Online Dokumentation sehr aufschlussreich ist.
ich habe mir nun den Uno zugelegt und dazu das (btw. recht ernüchternde) Fritzing Creator Kit.
Habe gestern schon ein wenig mit MIDI rumgespielt, konnte CCs mit einem Poti senden, die Werte auch an LEDs übergeben. Auch ein Display habe ich zum laufen bekommen, in dem entweder der analoge Wert angezeigt wird oder eine prozentuale Anzeige.
Heute werde ich mich mal an das Auslesen eines Motorfaders machen.
Ich hab da noch eine generelle Frage:
Wieviele Displays unterstützt das Arduino eigentlich? Dazu habe ich nichts gefunden.
Und noch eine Frage:
Ist es möglich, den Arduino zu programmieren, dass man z.B. die zu sendenden ControlChange Befehle direkt am Interface einstellt ohne dazu den Rechner zu benutzen? Falls nicht, ist es möglich, über Processing eine Oberfläche zu bauen, die auf den Arduino zugreift? Am Ende soll der User nicht direkt in den Code einsteigen, sondern leicht Zugriff darauf haben.