STM32F4 Discovery

STM32F4 Discovery

#Einleitung

In Absicht es bald mal zu nutzen, habe ich mich mit dem F4 Discoveryboard genauer auseinandergesetzt.

Ein paar Hardwareinfos:

µC STM32F407VGT6 (1MB Flash, 192 KB Ram, 168 MHz)
1 Quarz 8 MHz für HSE
4 User LEDs (Grün, Rot, Blau, Orange)
2 USB (nur einer als Micro-USB direkt nutzbar)
onboard ST-Link Debugger (über SWD Programmieren)
Bewegungssensor mit 3 Achsen (LIS302DL über SPI)
Audiosensor und Digitalmikrofon (MP45DT02)
DAC (CS43L22 als Audiotreiber)
1 Taster (+ 1 Reset)
4 Status LEDs (Usb-Power, Boardpower, Usb over-current, ST-Link Datatransfer)
jeder µC GPIO-Pin über Stiftleiste nach außen geführt

Clock configuration tool: STSW-STM32091
(enthält die STM32F4xx_Clock_Configuration_V1.1.0.xls, in welcher Quarz und Taktfrequenzen eingestellt werden können. Über Makros wird dann auch die passende system_stm32f4xx.c erzeugt)
Hier noch das Datenblatt:

stm32f4discovery board (PDF, 2.23 MB)

Mich interessiert dieses Board besonders, weil der µC zum einen knapp doppelt so schnell ist wie der vom MiniSTM32Board. Man braucht keinen Debugger, weil der schon integriert ist. Dadurch brauch ich das später eingebaute Board nur von der anderen Seite mit dem USB Verbinden und kann es direkt mit einer neuen Firmware versehen. Hinzu kommt dann noch der Bewegungssensor, welchen ich für sehr interessant halte.
Dann ist es noch für weniger Geld zu haben (15-16 € in diversen Onlineshops wie bei diesem Vertreiber, bei de.Mouser.com steht sogar 12,29 €, ist allerdings ohne MWS) und auch recht gut verfügbar.

Für Audiowiedergabe interessiere ich mich derzeit noch nicht. Man könnte vielleicht das Digitalmikrofon zum Low-Budget Oszilloskop umfunktionieren und den DAC mit Verstärker als Signalgenerator. Solche Spielereien werden aber möglicherweise erst ein Thema, wenn ich mein derzeitiges Endvorhaben mit diesem Board realisiert habe.

Erst mal will ich das Board für eine spezielle Steuerungsaufgabe verwenden. Deswegen ist in dem Bild oben auch alles entfernt, was ich vorerst nicht nutzen werde, aber wichtige Pins am µC belegt. Zur besseren Übersicht, sind die Pins Farblich so markiert, wie ich sie in die Excel-Tabelle eingetragen habe.

Der F4 hat eine sogenannte FPU (Floating Point Unit), also ein Hardwaremodul, dass sich mit der Berechnung von Fließkomma zahlen beschäftigt und so schneller als die CPU alleine arbeitet (hier ein Lesenswerter Thread: Floating Pointing Unit STM32F4).

#Beschreibung

Von den Möglichkeiten des Boards nutze ich insgesamt relativ wenig, aber erst mal kümmere ich mich nur um das, was ich brauche und nicht um das, was mich noch so interessieren würde oder möglich wäre.

Da die STM32_Init.c nicht für den F4 funktioniert, nutze ich mein selbst erstelltes STM32-GPIO-Tool (bestandteil der Dev-Tools_019).
Dafür brauche ich nur die hw_config.c per Drag & Drop auf die Dev-Tools zu ziehen, ein Häkchen bei "Send to: STM32 Tool" und schon kann ich bei Setup -> GPIO Setup meine Pins so einstellen, wie ich es brauche. Nach dem Speichern meldet die Keil-IDE, das die Datei extern verändert wurde (man muss nur das neu laden bestätigen).
Ansonsten ist die Konfiguration bei dem F4xx (4 Register) schon sehr anders, als bei dem F1xx(2 Register). Die Maximalgeschwindigkeit ist auch nicht mehr 50 MHz sondern nun 100 MHz.

TFT-LCD
Dieses Board hat von Hause aus kein Display, weshalb ich das gleiche, wie vom MiniSTM32board dort angeschlossen habe (im 8bit Latch-Mode). Es wird auch der gleiche Treiber (lcd.c) benutzt. Allerdings musste ich für den F4 einige Takte in die Länge ziehen:
LCD_WR_L(); LCD_WR_L(); LCD_WR_H(); LCD_WR_H();
Ohne diese Maßnahme, funktioniert das Display nicht richtig. Scheinbar kommt der Controller mit schnelleren Takten nicht zurecht.

Encoder
Die Encoder sind Drehgeber, mit denen man Taktweise etwas verstellen/Zählen kann (genauere Beschreibung: mikrocontroller.net oder wikipedia.org). Solche Teile findet man fast in jeder Maus mit Mausrad.
Der Timer8 kann im EncoderMode betrieben werden, was ich mit diesem Board auch gemacht hab. Der Encoder muss also mit GND und mit C6 und C7 verbunden werden. Die 16bit-Variable wird auf dem LCD angezeigt.
Der Encoder, den ich verwendet habe, zählte pro Tick (fühlbares rasten) um 4rauf oder runter. Wenn die 0 unterschritten wurde, sprang er auf 65535 um, wie bei einem unsigned short (u16) zu erwarten war. Encoder sind sehr vielseitig. Man kann einen Encoder mit Motor als Antrieb verwenden und somit präzise die Umdrehungen zählen, gewissermaßen als Ersatz eines Schrittmotors. Aber auch für Bedienpanels sind die Encoder eine feine Sache, da sie in ihrer Handhabung besser sind, als einfache Plus / Minus Tasten. Wichtig ist nur, wie der Encoder ausgewertet wird. Interrupts sind zwar schnell, lasten den µC aber je nach Häufigkeit nicht unwesentlich aus.
Alternativ kann man die Zustände regelmäßig abfragen und anhand der Änderungen bestimmen, in welche Richtung gedreht wurde. Dabei entscheidet die Häufigkeit der Abfragen darüber, wie schnell der Encoder gedreht werden kann, bevor einzelne Ticks nicht gezählt werden. Genau das macht bei diesem Board der Timer8 im EncoderMode. Wie häufig er abfragt, weiß ich nicht genau, aber es ist immer noch schnell genug, um eine schnelle Handdrehung vollständig zu zählen. Der Timer Zählt selbstständig und arbeitet ohne den Prozessor zu belasten.

#I2C

Bei diesem Board ließ sich ohne Probleme der Hardware I2C aktivieren. Dennoch habe ich mich mit der Softwarevariante genauer beschäftigt und mit höheren Datenraten experimentiert. Hier die Ergebnisse für eine 1Mhz Übertragung:

Oben Links.
test mit 680khz.
Oben Rechts.
Laut Spezifikation, müssen die Teilnehmer des I2C Bus Open Drain Ausgängen verwenden. Dadurch kann keiner ein High Signal hervorrufen, dafür sind die Pullup-Widerstände auf den Leitungen da. Sie können nur ein aktives-Low hervorrufen.
Wenn ich die Taktrate stark erhöht habe, funktionierte die Datenkommunikation nicht mehr, weil der High-Pegel nicht schnell genug herbeigeführt wurde. Deshalb sieht man auch diese Sägezahnimpulse. Der kleine Impuls nach den ersten 8 Takten ist ein etwas kurzgeratener ACK-Takt. Wie man sieht, steigt die Datenleitung auch gerade an... es handelt sich also um ein NACK, weil der I2C-Slave hier nicht reagiert.
Unten Links.
Diese Einstellung ist schon nicht mehr I2C konform, allerdings wird der SCCB der Kamera so benutzt (weshalb er wohl auch nichtmehr I2C heißt). Dafür können aber die noch vorhandenen Pullup-Widerstände entfallen (sofern man vom Bus nicht lesen will). Außerdem sind die Flanken sehr viel steiler.
Wie im oberen Teil des Bildes (Zoomübersicht) zu sehen ist, dauert die Datenübertragung nun länger. Jetzt funktioniert der Datenaustausch nämlich und wird nicht wegen NACKs schon vorher vom µC unterbrochen, wie es oben der Fall war.
Unten Rechts. Hier der hintere Teil der Datenübertragung (Auslesen des GPIOB Registers). Der 16Bit IO Expander arbeitet weiterhin nur im Open-Drain Modus, weshalb bei ihm immer noch das Flankenanstiegsproblem besteht.
Die Datenübertragung wird vollständig ausgefüllt, aber der Fehlerzähler steigt meistens noch mit. Es gab auch mehrfach Momente, wo es keine Übertragungsprobleme gab.

ADC & DMA
Der Pin A1 wird als Analogeingang ausgelesen und die Ergebnisse per DMA in eine Variable übertragen.
Im Grunde also nur die einfachste Form eines Funktionstests.

USB VCP und HID
Die Communication Device Class (CDC) wird für Datenkommunikation über USB verwendet. Hier meldet sich das Board als VCP (Virtual Com Port) und kann über dem PC wie die normale UART angesprochen werden oder als HID, was ja beim Ministm32Board schon bekannt war, an den PC an.
Im VCP Modus, kann man vom PC aus wie mit der regulären UART kommunizieren. Im Downloadbeispiel unten, sind Funktionen wie
usb_cdc_ReadExistig(text);zum Empfangen oder
usb_cdc_printf(text);zum Senden
von Strings (Char Arrays). Im VCP Modus versendet das Board über den USB Bulk Transfer (viel schneller als HID Interrupt). Bei meinem Beispiel, wird das Gesendete direkt wieder zurück geschickt, ähnlich einem Hardware Callback. Allerdings ist das Senden einer 0 nicht möglich... wahrscheinlich, weil die 0 das Ende des Strings darstellt und die Übertragung aktuell auf Strings ausgelegt ist. Somit wird eine 0 als "nur bis hier senden" gewertet. Zur Übertragung einer 16 Bit Variable kann ich so aber keine 2 Bytes verwenden, da die 0 hier wichtig ist. Mit der Thematik beschäftige ich mich später nochmal...
Im HID Modus, meldet sich das Board genau wie das Ministm32Board an und kann über die DevTools gesteuert werden. Über HID werden die Werte des Beschleunigungssensors als Analogwert übergeben. In Verbindung mit einem Display, kann der HID-Modus auch für die GUI Erstellung verwendet werden. Bis auf die UART Funktion, sind die HID-Möglichkeiten wie bei dem Ministm32Board.

#Neue Tools

Inzwischen sind noch ein paar Programmänderungen gemacht worden und es wurden ein paar erwähnenswerte Entwicklungstools benutzt.

MicroXplorer
Dieses von ST entwickelte Programm, kann benutzt werden um das Potential einzelner Mikrocontroller so weit wie möglich auszuschöpfen.
So kann man sein vorhandenes Board nehmen und den darauf befindlichen µC hier eingeben. Das Tool listet dann alle verfügbaren Funktionen auf. Sobald eine Funktion aktiviert wird, werden alle in Konflikt stehenden entsprechend markiert.
Wenn man beispielsweise den SPI1 aktiviert, werden die dafür verwendeten Pins nicht als Analogeingänge verwendet werden können. Deshalb sind diese Analogkanäle dann auch rot markiert.

Funktion rot markiert -> kann nicht verwendet werden
Funktion gelb markiert -> kann nur eingeschränkt verwendet werden

Das Tool hat auch ein Codegenerator, welcher die Initialisierung übernimmt. Ich hab es aber bisher nur als Vorlage genommen, da ohnehin schon das meiste vorhanden war.
Man kann sich aber auch die Pinbelegung als PDF abspeichern und als Übersicht verwenden. Eine MicroXplorer Beispieldatei ist bei Version 001 dabei (die Datei heißt "F4 Disc.ioc").

f4 disc sds (PDF, 101.02 KB)

CodeBlocks EPS Debugger
Die CodeBlocks IDE ist ja schon länger bei mir in Verwendung. Sie ist kostenlos und sehr funktionsreich.
Es gibt dafür aber ein käufliches Plug-In namens EPS Debugger, welches die Entwicklung für den STM32 (nach meinem Empfinden) erheblich angenehmer gestaltet, als mit der Keil µVision IDE.
Ich verwende eine spezielle portable CodeBlocks Version. Dafür hab ich die Code::Blocks EDU-Portable verwendet und diese Version mit dem EPS Debugger erweitert.
Jetzt hab ich einen Ordner mit rund 440 MB Größe und kann damit entwickeln und auch debuggen, wie im Bild links zu sehen.

Ich nutze eine aktivierte FREE Version. Dafür musste ich nur beim ersten einrichten meine Email angeben. Kurze Zeit später sendete mir der Anbieter automatisch einen Code zum eingeben zu. Beim Start einer Debug Session muss ich ein paar Sec warten (Countdown) und kann nur 5 Variablen gleichzeitig betrachten (5 Watches Limit), aber damit lässt sich schon recht gut was anfangen. Man kann z.B. auch die Einstellungen der Register ansehen (im Bild rechts, bei "Peripherals").
Im Release Modus hat das Programm eine Größe von knapp 130KB. Eigentlich müsste es laut den Herstellerangaben des Plug-Ins so nicht klappen (Free Version Download Limit: 25% of FLASH max. 16KB)... aber es funktioniert. Ich vermute, dass die Grenze von 16KB nachträglich entfernt wurde und nur die 25% gelten. Das würde bedeuten, dass ich bei diesem Board bis 250KB gehen kann.

Den EPS Debugger werde ich mir noch etwas genauer ansehen, bevor ich entscheide, ob ich eine Lizenz erwerbe. Gemessen an der Leistungsfähigkeit und dem Preis, ist es sehr viel wahrscheinlicher als bei der Keil µVision IDE.

#Programmänderungen

Das VCP Programm lässt durch die zusätzliche Funktion auch das senden von Nullen zu. Dafür muss man einen Bytearray und die Menge der zu sendenden Zeichen angeben.
Bei Version 001 führt ein Druck auf die blaue User-Taste dazu, dass zuerst "Btn Down..." gesendet wird. Nachdem die Taste los gelassen wurde, sendet das Board die Bytes 1 128 0 255 0. Damit kann man sowohl Text als auch Datenwerte direkt senden.
Beim HID-Bilddownload des Kameraboards, wurde jeder Pixel in 2 Bytes übertragen (RGB 565 Format). Da die Datenrate des VCP deutlich höher ist, könnte später mal ein Live-Bild mit dem µC möglich werden... zumindest will ich es mal versuchen.

Beim HID Programm ist der Abfrageintervall sehr viel kürzer eingestellt (Paint-Modus läuft flüssiger) und der UART2 ist aktiv. Damit kann man über HID Serielle UART-Befehle senden (in DevTools als UART1 beschrieben, auf dem Discovery-F4 wird aber UART2 verwendet).

#Kamera und Display

Inzwischen hat sich wieder einiges getan. Ich programmiere jetzt fast nur noch mit Codeblocks EPS Portable. Nachdem ich 2 Displays und meine Kamera zu laufen bekommen habe, hier ein kleiner weiterer Nachtrag.

#Displays

Um die 2 anderen Displays verwenden zu können, wollte ich sie erst mal auf dem F4 Discovery zum Laufen bekommen, um von dort einfach die Dateien weiter zu benutzen.
Das 1.8 TFT Display hat knapp 6,30 Euro gekostet und das Nokia 5110 Display nur 2,40 Euro. Deshalb hab ich diese Teile auch gekauft, da sie eine sehr preisgünstige Darstellungsmöglichkeit von Informationen bieten.
Beide laufen über ein eigenes Serielles Interface, aber mit Bitbanging, nicht über den Hardware SPI, obwohl dies beim 1.8 Display möglich wäre. Beide werden Pixel für Pixel angesteuert weshalb es zwar aufwändiger ist, einen einfachen Text drauf zu bekommen (wegen Bitmaske, Shifter usw.), aber dafür sind auch Geometrische Darstellungen und Bilder möglich.
Beide werden mit den vom F4-Board gelieferten 3V betrieben. Beide haben eigene Dateien für die Funktionsaufrufe und sind momentan noch recht rudimentär. Beispielsweise könnten beide Displays Linien darstellen, aber derartige Funktionen sind noch nicht implementiert. Mir ging es erst mal um das Grobe "es funktioniert"

Für das Nokia 5110 Display (hat 84x48 Pixel) braucht nur eine Headerdatei eingebunden werden. Die 6x8 Font ist mit inbegriffen und über eine einfache Funktion wird der Text an das Display übertragen.
Hat etwas gedauert, bis das Display funktionierte, da der Chip ein bisschen zickig auf die falschen Reset-Timings und Reihenfolgen reagiert.

Durch die Einbindung des 1.8 TFT Displays (hat 128x160 Pixel), wurde die Struktur einiger Befehle so angepasst, dass sich beide Displays die gleichen Fonts teilen können. Bei der Gelegenheit hab ich mir aus der LCD Schriftarten Sammlung ein paar raus kopiert. An dieser Stelle auch mal ein Danke von mir an Benedikt K., der mir mit dieser Sammlung einiges an Arbeit erspart hat.
Dieses Display hat übrigens auch einen 2ten Ram. Sodass man beispielsweise Daten im Hintergrund des Displays ändern kann, ohne dass es angezeigt wird. Dieser Bereich könnte auch als Zwischenspeicher für den µC verwendet werden, wobei das natürlich nur eine langsame Notlösung wäre.

#Kamera

Verwendet wurde ein OV7670 Kamerachip mit zusätzlichen AL422B FIFO (First In First Out) Speicher auf dem Modul PCB.
Diese Variante kostet etwas mehr als der reine Kamerachip, ist dafür aber etwas entspannter in der Handhabung. Der Kamerachip braucht 3.3V deshalb wird er vom Board mit 5V Versorgt und dann über einen 3.3V Spannungsregler auf sein VCC Pegel gebracht. Hab es mit 3V versucht, aber es kommt kein sauberes Bild raus.

Auf dem Kameraboard ist ein 24MHz Quarz, der den Arbeitstakt der Kamera vorgibt. Ohne Quarz könnte ein MCO Pin vom STM32 den Takt vorgeben. Entsprechend seiner Konfiguration beginnt die Kamera nun, die Bildinformationen als digitalen Datensatz zu liefern. Dafür steht ein synchroner (getakteter) 8Bit Parallelbus zur Verfügung. Da die Kamera die Datenübertragung vorgibt, müsste ohne FIFO der µC hier jeden Takt abwarten und im richtigen Moment auslesen. Würde der µC einen Takt verpassen (Pegel nicht schnell genug ausgelesen, weil z.B. der letzte Pixel gerade an das Display gesendet wird) dann würde ein Pixel fehlen und alle nachfolgenden sind um einen Pixel verschoben. Wenn der µC schnell genug ist, hat man aber ein sauberes Bild. Sachen wie USB Kommunikation sind dann aber nebenher schwierig.

Eine Lösung ist hier der FIFO Speicher. Dieser taktet die Daten genau in der Reihenfolge raus, in der sie rein getaktet wurden. Und dafür können beide Arbeitstakte auch mal unregelmäßig sein (solange unter 50 MHz).

Arbeitsweise der Kamera.
Der VSync der Kamera ist mit einem als Interrupt konfigurierten Eingang des µC verbunden. Wann immer ein Bild fertig übertragen ist, bekommt der µC so ein Signal und kann als Folge darauf reagieren.

Der erste VSync Takt kommt und der µC führt einen Reset am FIFO aus. Dadurch werden alle dann folgenden Daten auf den FIFO auch alle neuen Bildpixel der Kamera sein. Der WE (Write Enable) Pin des FIFO wird durch den µC auf High gesetzt, wodurch die Kamera nun den FIFO beschreiben kann. Der Pixeltakt von der Kamera ist mit dem WCK (Write Clock) auf dem Kameramodul verbunden. Dadurch schreibt die Kamera jeden Pixel direkt in den FIFO, solange WE auf High ist.
Der µC wartet auf den nächsten VSync. Währenddessen läuft USB Kommunikation, Displaydarstellung oder was auch immer, jedenfalls nix, was gerade mit der Kamera zu tun hat.
Der nächste VSync ist eingetroffen und WE wird auf Low gesetzt. Dadurch ist nun ein komplettes Bild im FIFO und alles weitere von der Kamera kommende geht ins Leere.
Der µC Taktet aus dem FIFO jeden Pixel wie es ihm gerade passt. Kommt was anderes dazwischen (USB Kommunikation, Timer oder sonst was) dann wird der nächste Pixel eben etwas später abgeholt. Wenn alle Pixel aus dem FIFO getaktet wurden, ist der Zyklus beendet und geht wieder bei Nr. 1 los.
Bei meinem Beispiel wird jeder Pixel erst zum Display weitergeleitet und vorher, wenn aktiviert, noch bearbeitet. Dadurch benötigt man auch nicht so viel Speicher, wie für ein Bild. Sondern nur ein paar Zählervariablen.

Im Bild sind einerseits ein einfacher Farbfilter für rot und einen Kanalfilter für grün zu sehen. Der Kanalfilter ist so ziemlich das einfachste überhaupt. Die Variablen einzelner Farbkanäle werden einfach konsequent mit 0 überschrieben. Wenn rot und blau immer 0 sind wird letztendlich nur alles im grünen Farbkanal dargestellt.
Der rote Farbfilter ist da schon etwas komplexer. Hier muss rot mindestens einen gewissen Wert haben, während grün und blau maximal einen gewissen Wert haben dürfen. Ein Weißer Pixel bedeutet z.B. das alle Farbkanäle hohe Werte haben. Aber ein roter Farbfilter soll nur rote anzeigen, und nicht noch gelbe, weiße und magenta Pixel.

In diesem Beispiel wird die blaue LED bei jedem Auslesevorgang leuchten. Man hat also ein blaues Blinken im Takt des Bildauslesens.

Auf diese Weise kommt natürlich keine hohe Framerate zusammen. Wenn man aber für einen kurzen Moment viele Bilder hintereinander haben will... aus welchen Grund auch immer... dann kann man einfach ein paar VSyncs abwarten und dann die Bilder nach und nach auslesen. Wenn die Kamera auf 320x240 eingestellt ist (QVGA) dann sind es bei 320x240 -> 76800 Pixel. Jeder Pixel belegt 2 Byte (RGB565 Format) macht pro Bild 153.6 KB Bilddaten. Der FIFO hat laut Datenblatt 384 KB... so würden also gerade mal 2 Bilder reinpassen.
Laut Datenblatt der Kamera kann die kleinste Auflösung aber 40x30 betragen da würde man bestimmt noch einiges mehr rausholen.
Mal sehen ob ich den Gedanken mal weiterverfolge...

Zu erwähnen wäre noch... der F4 hat eigentlich einen extra Peripherieanschluss für Kameras: den DCMI.
Im F4 Reference Manual stet hierzu:

Digital camera interface (DCMI)...The digital camera is a synchronous parallel interface able to receive a high-speed data flow from an external 8-, 10-, 12- or 14-bit CMOS camera module. It supports different data formats: YCbCr4:2:2/RGB565 progressive video and compressed data (JPEG).

This interface is for use with black & white cameras, X24 and X5 cameras, and it is assumed that all pre-processing like resizing is performed in the camera module.

Um den DCMI aber auf dem Discovery F4 nutzen zu können, muss man viele der mitgelieferten Bauteile runter löten. Vielleicht später mal...

#Encoder

Der Encoder war ja schon vorher eingebaut, aber jetzt hab ich einen Focusring von einem Sony Camcorder verwendet. Hier sind 2 Lichtschranken, die durch ein gezacktes Rad entsprechend beim drehen unterbrochen werden. Die Ausgänge sind zwar nicht mehr so niederohmig (sind schon ein paar KOhm), aber es klappt trotzdem sehr gut. Jetzt führt ein kleines drehen am Rad dazu, dass sich der Wert um +1 oder -1 verändert. Die IR LEDs werden mit einem Vorwiederstand an 3V betrieben. Ich hab einfach einen 500 Ohm Poti benutzt um die richtige Größe zu finden. Einfach so lange verstellen, bis das Focusrad vernünftig funktioniert und dann den nächst kleineren Widerstand einbauen.
Außerdem wurde der Zähler auf die Hälfte gesetzt (32767) und eben dieser Wert wird von ihm beim auslesen wieder abgezogen. Als Folge davon kann ein verstellen positive und in Gegenrichtung auch negative Werte erreichen, wie im Bild.

#GUI und Fonts

Im Zuge der 2 Displays, die sich dieselben Fonts teilen sollten, bin ich auf die LCD Schriftarten Sammlung gestoßen. Hier hab ich mich ordentlich bedient und somit sind nun 8 Schriftgrößen verfügbar.

Außerdem sind neben Texten in unterschiedlichen Schriftgrößen nun auch Schaltflächen in unterschiedlichen Schriftgrößen und Farben möglich.
Bei Schaltflächen kann nun eine Vordergrundfarbe (Schriftfarbe) und Hintergrundfarbe (Schaltflächenhintergrund) definiert werden. Durch das drücken der Schaltfläche wird beides invertiert dargestellt.
Die Schaltfläche mit Anzeige wurde in Switch umbenannt und wechselt nach jedem klick zwischen Vorder und Hintergrundfarbe. Der Zustand kann auch im Code über eine Statusnummer abgefragt werden.
Mit if (LCD_GetButtonstate(5)==BtnIsOn) ... kann z.B. abgefragt werden, ob die Schaltfläche Nr. 5 eingeschaltet wurde.
Durch diese Änderungen funktioniert der GUI Editor nur ab DevTool_V020 richtig.

#Download

f4disc hidpaint v002 cam lcd18 n5110 (ZIP, 1.96 MB)

Enthält die Projektdatei (CodeBlocks und Keil), den Quellcode, einige Datenblätter und eine Pinbelegungs Excel.

Zuletzt geändert am: Jan 31 2014 um 10:46 AM

Last updated 29.10.2023