INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.

Antwort schreiben 
 
Themabewertung:
  • 0 Bewertungen - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Arduino Mega 2560 vs Arduino DUE
17.02.2019, 20:54
Beitrag #17
RE: Arduino Mega 2560 vs Arduino DUE
Da viele Vorgehensweisen sich für unterschiedliche Displayhardware sehr stark ähnelt, bietet es sich an, diese in den Libs zu bündeln.
Das würde ich nicht als Ballast (höchstens für Dein Verständnis) sehen, sondern als normalen Ablauf, den eine Lib im Laufe ihrer Weiterentwicklung durchläuft.

Gruß Tommy

"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
17.02.2019, 21:02
Beitrag #18
RE: Arduino Mega 2560 vs Arduino DUE
(17.02.2019 20:54)Tommy56 schrieb:  Da viele Vorgehensweisen sich für unterschiedliche Displayhardware sehr stark ähnelt, bietet es sich an, diese in den Libs zu bündeln.
Das würde ich nicht als Ballast (höchstens für Dein Verständnis) sehen, sondern als normalen Ablauf, den eine Lib im Laufe ihrer Weiterentwicklung durchläuft.

Angel Das ist wie mit der Nadel in einem (kleinen) Heuhaufen: Wenn man die Nadel erst mal gefunden hat, dann erscheint einem der Heuhaufen auch nicht mehr so groß.

Gruß

P.S. ich habe gerade wieder eine Nadel gefunden Big Grin Scheint ein gültiges Schema des CTE-Shields für den DUE zu sein.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
17.02.2019, 21:16 (Dieser Beitrag wurde zuletzt bearbeitet: 17.02.2019 21:17 von Tommy56.)
Beitrag #19
RE: Arduino Mega 2560 vs Arduino DUE
Wenn Du einige Jahre ein System weiterentwickelt hast, dessen Quellcode aus ca. 5000 Dateien + ca. 300 PL/SQL-Files besteht (und das schon da war, als Du kamst), dann kommt Dir so eine Lib direkt übersichtlich vor. Wink Was meinst Du, wieviele Nadeln in großen Heuhaufen ich da im Laufe der ersten Jahre gesucht habe.
Man kann aber beides nicht "auf die Schnelle" verstehen.

Gruß Tommy

"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
17.02.2019, 21:19
Beitrag #20
RE: Arduino Mega 2560 vs Arduino DUE
Smile
stimmt!
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
24.02.2019, 16:38
Beitrag #21
RE: Arduino Mega 2560 vs Arduino DUE
Hallo @all,

Ich habe mir mal die UTFT-Lib vor die Brust genommen, um das Zusammenspiel des Arduino Due (SAM3A von Atmel) und des LCD-Treiberchips (SSD1963 von Solomon Systech) zu studieren. Nun habe ich zunächst die Lib soweit zerlegt, wie es dabei auf die von mir bevorzugten Hardware-Komponenten ankam. Gestaunt habe ich nicht schlecht, denn es sind schon etliche Jahre her, dass ich beruflich mit C/C++ zu tun hatte. Aber das ist wohl wie mit dem Fahradfahren, einmal gelernt, ist man selbst nach einer längeren Pause schnell wieder drin. C kenne ich seit dem Ende der 80er aus dem ff. Lediglich bei C++ sind/waren meine Kenntnisse etwas rudimentär, und das hat sich in den letzten Tagen auch schon wesentlich verbessert.

Bei dem Studium der UTFT-Lib musste ich mich auch zwangsläufig mit der Hardware auseinander setzen und dabei bin ich auf eine Eigentümlichkeit des Arduino-Boards gestoßen. Zunächst war ich auf dem Holzweg und hatte die Eigentümlichkeit dem CTE-DUE-LCD-Shield zu geschrieben. Dann beim genaueren Hinsehen entpuppte sich das Arduino-Board als Ursache für die Eigentümlichkeit. Das Board belegt nicht die PIN-Leitung beginnend bei PC0 sondern für die ersten 8 Datenbits erst bei PC1..PC8, dann kommt eine Unterbrechung bis die nächsten 8 Bits wieder ab PC12..PC19 auf die Reise geschickt werden können. Das muss natürlich in der Software berücksichtigt werden, wenn man den LCD-Chip auf den Datenleitungen D0..D15 sauber ansprechen will. Eigentlich doof, aber den, der das Board entworfen hat, den sollte man eigentlich ...

Code:
void UTFT::LCD_Writ_Bus(char VH, char VL) {
    REG_PIOC_CODR = 0xFF1FE;
    REG_PIOC_SODR = (VL <<  1) & 0x1FE;
    REG_PIOC_SODR = (VH << 12) & 0xFF000;
    pulse_low(P_WR, B_WR);
}

Ich habe natürlich etwas Zeit benötigt, um den Mechanismus der MCU-Register zu durchblicken. Um jetzt z.B. RGB-Informationen an den LCD-Chip weiter zu reichen, benötigt es schon einige Prozessorzyklen, also wesentlich mehr, als es die in der Hauptsache beteiligten 3 Programmzeilen vermuten lassen. Der Mechanismus mit REG_PIOC_CODR und REG_PIOC_SODR ist für sich selbst betrachtet keine schlechte Sache, funktioniert nach der Art von RS-Flipflops für jedes Datenbit. Man kann wirklich jedes Datenbit einzeln ansprechen, aber auch mehrere oder alle zusammen, ganz nach eigenem Belieben. Wenn man aber die Daten zuvor noch zusammenstoppeln muss, wird's leider etwas ungemütlich. Nun hat sich der Autor der UTFT-Lib bei den RGB-Pixeldaten für der 565-Format entschieden. Er wird seine Gründe dafür gehabt haben.

Wenn ich schon ein Farbdisplay betreibe, dann möchte ich vielleicht doch den vollen Farbumfang genießen. Zu dem Zwecke könnte man den Treiber-Chip anders konfigurieren. Der Treiber-Chip bietet dazu mehrere Möglichkeiten an. Es läuft aber darauf hinaus, dass noch mehr Schreibzyklen notwendig werden. Mit den Zwillingen REG_PIOC_CODR und REG_PIOC_SODR verdoppelt sich dabei der Aufwand, und je nach Konfiguration verdreifacht er sich sogar. Auch dafür bietet sich eine Lösung an und zwar durch einfachen Schreibzugriff auf PIO_ODSR (Output Data Status Register), wobei nur die von PIO_OWSR (Output Write Status Register) unmaskierten Bits geschrieben werden. Die Maskenbits in PIO_OWSR werden durch Schreiben in PIO_OWER (Output Write Enable Register) gesetzt und durch Schreiben in PIO_OWDR (Output Write Disable Register) gelöscht.

Damit entferne ich mich noch etwas mehr vom Grundkonzept der UTFT-Lib. Das wird ohnehin so kommen, da ich die Grafikfunktionen gerne durch ein anderes System ersetzen möchte. Mal sehen wo die Reise hingeht.

BTW die Eclipse-IDE zusammen mit dem Sloeber-Plugin ist eine komfortable Entwicklungsumgebung, semantische oder syntaktische Fehler werden schon während des Editierens analysiert und angemerkt.

Gruß
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
Antwort schreiben 


Möglicherweise verwandte Themen...
Thema: Verfasser Antworten: Ansichten: Letzter Beitrag
  Kann ein Arduino Nano mittels delayMicroseconds(13) ein 38kHz-Signal erzeugen SchwuppSchwupp 6 613 21.03.2019 11:06
Letzter Beitrag: biologist
  Arduino an Dartscheibe Hubii 10 566 19.03.2019 13:52
Letzter Beitrag: ardu_arne
  Arduino Netzteil 5V/230V carl 10 678 17.03.2019 22:31
Letzter Beitrag: hotsystems
  Arduino DUE über WiFi verbinden GuaAck 1 209 16.03.2019 23:23
Letzter Beitrag: Tommy56
  Lego-Motoren und Servos mit Arduino steuern dilbert 0 598 21.01.2019 10:48
Letzter Beitrag: dilbert
  Nextion + Arduino PS4 wifi Frage NickBBR 3 813 20.01.2019 22:01
Letzter Beitrag: GuaAck
  Health-Solution mit Arduino: AD8232 Analog Heart Rate Sensor dilbert 4 889 15.01.2019 14:59
Letzter Beitrag: dilbert
  Arduino uno mit cnc shield Maybe 13 1.786 04.01.2019 14:28
Letzter Beitrag: Chopp
Question Powerbank für Arduino Bikandajyo 21 6.975 30.12.2018 16:54
Letzter Beitrag: Sugar
  2,4GHz Fernbedienung für Arduino Seppl2202 14 1.902 30.12.2018 16:41
Letzter Beitrag: Tommy56

Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste