Go Down

Topic: Frage eines Anfängers zu einem LCD Display 16x2 oder so (Read 791 times) previous topic - next topic

skyfox60

ui, ok, verstanden.

Das kann tatsächlich wohl kaum einer lesen.

Ganz zu Anfang haben sich aber scheinbar einige damit ausgekannt, und mussten das machen, weils noch nichts anderes gab.
Respekt. Das ist ne Lebensaufgabe.

michael_x

Kann sich keiner mehr vorstellen, dass der allererste C - Compiler nicht selbst in C geschrieben wurde.

MicroBahner

#77
Feb 18, 2020, 09:20 am Last Edit: Feb 18, 2020, 09:54 am by MicroBahner
Ja, der Weg von deinem Sketch bis zum Code im Arduino ist weiter als Du denkst ;) . Dein PC erledigt das zwar im Handumdrehen - aber was der dazu alles macht kannst Du dir kaum vorstellen.
Letztendlich dient das alles dazu, Dir das Leben leichter zu machen.
Auch wenn dir C++ kompliziert erscheinen mag ( und es in der Tiefe sicher auch ist ). Es ist geradezu nichts im Vergleich dazu, wenn DU den Maschinencode selbst erstellen müsstest.

N.B. Bei meinen ersten Schritten auf einem 6502 habe ich auch mal den dort vorhanden einfachst-Compiler selbst erweitert. Das war auch noch kein Cross-Compiler. Der lief auf dem 6502 selbst.
Das ist wie man sich selbst aus dem Sumpf zieht. Man schreibt den Compiler in seiner eigenen Sprache, und mit jeder Version kann er dann ein bisschen mehr - was man dann bei der nächsten Version wieder nutzen kann 8) .
War aber meilenweit ( eher Lichtjahre ;) ) entfernt von dem was jetzt geht.

Edit: Und immer schön Buch führen und sichern welchen Sketch Du auf welchen Arduino geladen hast. Denn wie schon geschrieben: Aus dem Arduino bekommst Du den nicht mehr zurück.
Gruß, Franz-Peter

agmue

Das kann tatsächlich wohl kaum einer lesen.
Doch kann man. In diesem Forum sind ein paar aktiv, die sich mit solchen Dingen beschäftigt haben.

Neben mir liegt das Zilog Data Book als wohl gehütetes Juwel, mit recht abgenutzten Seiten 6 und 7.

Nach Jahrzehnten ist mir "C9" noch als Return in Erinnerung. Ich habe es gerade mal im Anhang E von Programmierung des Z80 nachgeprüft.

In der IDE kannst Du in den Voreinstellungen die ausführliche Ausgabe während der Kompilierung einschalten, dann siehst Du, was Dein PC in Windeseile so tut. Aus dem kompfortablen C++ wird "Zahlensalat" für den µC, siehe  *.ino.hex

Einige schlaue Spezialisten beschäftigen sich gerade jetzt mit solchen Fragen, da sie einen neuen µC designen oder überarbeiten. Chapeau!

Mir war das zu hoch und zu mühselig. Für mich blieb es daher nur Hobby, schon ein paar blinkende LEDs machen mich glücklich!
Die Vorstellungskraft ist wichtiger als Wissen, denn Wissen ist begrenzt. (Albert Einstein)

postmaster-ino

Hi

Assembler hat durchaus Seinen Reiz - ist aber auf genau diesen µC / diese Familie zugeschnitten.
So kannst Du eine .hex von einem Uno nicht auf einem Mega benutzen - ist ein anderer µC, andere Register, andere Hardware (z.B. mehr Timer, mehr serielle Schnittstellen - hat der Uno Alles gar nicht).
Was geht Uno<->Nano (der 'normale' Nano) - Das aber auch nur, weil diese Beiden den gleichen µC benutzen, einzig das Aussehen (und beim Nano zusätzlich A6/A7) ist anders.

Am "Schneider CPC464" und an einem 80286er, wie dann kurz vor Arduino an ATtiny45 (25/45/85 haben den gleichen Befehlssatz, Register ect.pp. - nur der Speicher ist jeweils größer - 45 und 85 lassen sich auch mit der IDE programmieren - beim 25 ist einfach zu wenig Platz drin) habe ich mit Assembler 'gespielt'.
Am ATtiny45 habe ich händisch in Assembler DS18B20, also 1-wire Temperatur-Sensoren ausgelesen und auf eine 4x 8x8er Dot-Matrix (MAX7219, SPI) ausgegeben.
Das Ganze dauert aber Äonen länger, als in der IDE drei Zeilen Code hinzukritzeln, kompileren, hochschieben, glücklich sein.
Ok - man kennt jedes Bit in den Innereien mit Vornamen - bringt Einem aber recht wenig.

Beim Arduino, also hier den AVR-µC, ist der Befehlssatz übersichtlich klein - es gibt nur wenige Knöpfe, Die man drücken kann, um ALLES, was man mit dem Steinchen machen kann, zu machen. Das Datenblatt zum µC zeigt auch die (meine 131 - Alle machen immer nur eine Kleinigkeit) Assembler-Befehle, Die der µC kann - und damit kann man dann ALLES machen ... wenn man kann ... man muß halt nur den richtigen Knopf zur richtigen Zeit drücken ...

Hier schlägt dann die Stunde der Hochsprachen - jeder Deiner Sketche wird auf den von Dir angewählten µC hin übersetzt (Uno/Mega/ESP oder sonst was), dort kristallisiert sich auch heraus, wie viel Platz wohl benötigt wird.
Man kann zwar auch in Assembler richtig programmieren, also auch Sprungmarken und so Zeug, ist aber wenigstens auf die Familie (AVR oder PIC, 8088, die 286/386/486er Prozessoren - also Vor-Pentium Zeug) begrenzt.
Man lernt viel eher, wie sich die Datentypen zusammen setzen, man spart, wo man kann - man nimmt also keine 16bit-Variable, wenn man auch mit einer 8bit zurecht kommt - auch, weil der kleine AVR 8bit in einem Takt verarbeitet.
Man ist viel mehr am Bytes oder Timer-Ticks zählen, als in den Hochsprachen - ok, in Assembler wieß man, wie lange ein Befehl dauert - in der Arduino-IDE ist's nicht 100% sicher, was aus einem digitalWrite wirklich wird, weil Das im Kontext durchaus anderen Code ergeben kann - am Schluss bekommst Du Deinen Ausgang geschaltet, der Weg dahin bleibt aber dem Kompiler überlassen.
Ist aber interessant, was ein heutiger Kompiler an nahezu idealen Assembler/Maschinen-Code zusammen bekommt - wobei ich Das auch nur an Mini-Beispielen ansatzweise überschauen kann - aber immerhin da.

Doch, ich mag Assembler

MfG

Serenifly

Assembler hat auch zur Detail Optimierung an extrem zeit-kritischen noch seine Berechtigung. Vor allem FastLED macht da interessante Sachen mit optimierten Funktionen um bestimmte Rechnungen zu beschleunigen.

Und man lernt generell sehr viel über Logik und wie µC arbeiten wenn man sich wirklich um alle Details kümmern muss. Recht einfache Elektronik-Anwendungen sind mit Assembler nicht soooo kompliziert. Ich habe da in der Vergangenheit viel mit dem 8052 gemacht.

in Assembler wieß man, wie lange ein Befehl dauert
Da gibt es schöne Übungen sich Verzögerungs-Unterprogramme auf den Takt genau zu bauen. Die Ausführungszeit zweier ineinander verschachtelten Schleifen zu zählen hat es durchaus in sich.

Tommy56

Da gibt es schöne Übungen sich Verzögerungs-Unterprogramme auf den Takt genau zu bauen. Die Ausführungszeit zweier ineinander verschachtelten Schleifen zu zählen hat es durchaus in sich.
Damit haben wir früher (TM) unter DOS/Win 3 den PC ausgebremst, damit die alten Spiele auf schnelleren PC spielbar blieben.

Gruß Tommy
"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)

michael_x

Stimmt:

Die inline asssembler Anweisung
 __asm __volatile ("nop"); // 1 Takt mehr  (62.5 ns auf einem 16 MHz Arduino )
macht evtl. gelegentlich Sinn. Das compiliert auch für jedes avr-gcc Zielsystem (attiny .. atmega)  :)


Go Up