Der Header enthält Angaben zu Größe und Ausrichtung, verschiedene Fonts
werden durch Zeiger auf die Adresse ausgewählt, läuft auf ARM und AVR.
Wie überträgt man das auf c#?
Wie bekomme ich die verschiedene Fonts z.B. in eine Liste oder wie geht
ein Zeiger auf den jeweiligen font?
danke für Unterstützung
Karl K. schrieb:> Wie überträgt man das auf c#?
Gegenfrage: Warum willst du das tun? Ich kennen keinen Mikrocontroller,
den in C# programmierbar ist, und das Display wirst du wohl kaum an
einen PC anschließen wollen, oder?
Wenn du die Programmierung vorher auf dem PC üben willst, dann mache das
sinnvollerweise in der gleichen Programmiersprache, wie auf dem
Mikrocontroller. Die QT Creator IDE macht es einem besonders einfach.
Sherlock 🕵🏽♂️ schrieb:> Ich kennen keinen Mikrocontroller,> den in C# programmierbar ist,
du lebst halt hiterm Mond.
>Wie in C auch. Ein Array ist ein Referenztyp. Sein Bezeichner ist>gleichzeitig die Referenz auf das Element [0].
Nein. c# ist eine "memory managed" Sprache. Nix Zeiger, Zeiger böse
(unsafe)
Sherlock 🕵🏽♂️ schrieb:> Jonas B. schrieb:>> du lebst halt hiterm Mond.>> Kläre mich auf! Welche Mikrocontroller programmierst du in C#?
Er hat die dubiose Idee, seine AVR-Programme erst in C# zu schreiben und
auf dem PC zu testen und dann irgendwie mit einer Kombination aus Makros
und einem selbstgebastelten Konverter C draus zu machen, um sie für den
AVR zu bauen. Siehe Beitrag "gcc auf dem pc ausführen"
Karl K. schrieb:> uint8_t const f8x12[] PROGMEM = {> (...)> Wie überträgt man das auf c#?
Gar nicht. Du kannst natürlich Arrays anlegen, die Konstanten enthalten
– wo die dann liegen, bestimmst aber nicht du.
Rolf M. schrieb:> Er hat die dubiose Idee, seine AVR-Programme erst in C# zu schreiben und> auf dem PC zu testen
Weil er wohl eine IDE für C# hat, mit der er vertraut ist und in der man
komfortabel debuggen kann, z. B. Visual Studio. Aber kann man in dieser
IDE auch hardwarebezogene Programme debuggen oder auch nur compilieren?
Mit welcher Laufzeitumgebung?
Rolf schrieb:> Weil er wohl eine IDE für C# hat, mit der er vertraut ist und in der man> komfortabel debuggen kann, z. B. Visual Studio.
In der kann man mit exakt demselben Komfort auch mit C arbeiten.
> Aber kann man in dieser IDE auch hardwarebezogene Programme> debuggen oder auch nur compilieren?> Mit welcher Laufzeitumgebung?
Ja, für Visual Studio (nicht "Visual Studio Code", das ist was
komplett anderes) gibt es mit VisualGDB eine Erweiterung, mit der genau
das geht, für diverse Zielsysteme.
https://visualgdb.com/?features=embedded
Visual Studio ist übrigens auch die Grundlage für "Atmel Studio" bzw.
"Microchip Studio", das aber hat dann in der Handhabung schon etliche
Unterschiede.
"Visual Studio Code" hingegen ist eine sehr universell an alles mögliche
anpassbare IDE, quasi der Nachfolger des Java-Molochs "Eclipse", und
dafür gibt es Erweiterungen wie z.B. PlatformIO ...
Es gibt wirklich keinen Grund, der dafür spricht, sich mit C# die Finger
zu brechen, wenn man doch eigentlich C programmieren will.
Toll. Und was soll das bringen? Das hat mit C exakt nichts mehr zu tun.
Und wenn Du das ganze auf einem µC laufen lassen willst, bringt auch die
formelle Ähnlichkeit zu C++ nichts, denn auf einem µC will man kein
new verwenden.
Harald K. schrieb:> denn auf einem µC will man kein new verwenden.
Das ist jetzt eine sehr pauschale Aussage. Wir verwenden das ziemlich
oft, allerdings nur zum Startzeitpunkt bzw im Konstruktor.
Harald K. schrieb:> Toll. Und was soll das bringen?
Weiß ich noch nicht.
Ich kann Teile meines avr-Programms auf dem PC testen und habe dabei den
gleichen Zugriff auf Modbus wie mit dem avr.
Für die Ausgabe wird ein 240x320 lcd simuliert, so dass der output wie
auf dem avr ist. Die getesteten Programmteile laufen auf dem avr genau
so wie auf dem PC. Mehr wollte ich eigentlich nicht.
Rolf M. schrieb:> Er hat die dubiose Idee, seine AVR-Programme erst in C# zu schreiben und> auf dem PC zu testen
Die Idee ist garnicht so dumm, wie sie zunächst scheinen mag. Aber wohl
eher nur für ganz bestimmte Arten von Programmen wirklich vorteilhaft.
Keinesfalls für das übliche Geklingel mit Portbits oder die Ansprache
von Peripherie über die üblichen Schnittstellen.
Aber Routinen zur Signalverarbeitung kann man auf diese Weise schon sehr
gut (nämlich zeitsparend und trotzdem umfassend) testen.
Die ganze Signalverarbeitung für das hier z.B.:
Beitrag "Audio Spektrum Analyzer mit ATtiny85"
ist zunächst in VB.net entstanden. Natürlich gleich mit dem Ziel, daraus
am Ende AVR8-Code machen zu wollen. Deswegen sehen diese Routinen kaum
wie ein übliches VB-Programm aus, sind aber natürlich trotzdem gültiges
VB.
Das ginge in C# ganz genau so, ist ja eh' (abgesehen von der
unterschiedlichen Syntax) dieselbe Soße.
Das ganze wurde dann erst mal auf Funktion und Filterstabilität
getestet, dann in AVR8-Asm portiert und dann in mehreren Iteration immer
wieder geändert und die Änderungen erneut portiert. Bis halt auf dem
AVR8 alles gepasst hat, Funktion, Stabilität und auch die Perfomance.
> und dann irgendwie mit einer Kombination aus Makros> und einem selbstgebastelten Konverter C draus zu machen
Naja, so weit bin ich damals nicht gegangen. Das habe ich schön per
klassischer Handarbeit erledigt. War natürlich auch nicht schwer, weil
der Code ja von vornherein mit diesem Ziel geschrieben wurde.
Aber möglich wäre auch sowas natürlich theoretisch schon. Ich war nur
viel zu faul dazu, das so weit zu treiben.
Rolf M. schrieb:> Er hat die dubiose Idee, seine AVR-Programme erst in C# zu schreiben und> auf dem PC zu testen
Für Embedded-Programmierung in C verwende ich gelegentlich Code::Blocks
um einzelne Module zu testen, aber dann auch in C.
Gunnar F. schrieb:> Rolf M. schrieb:> Für Embedded-Programmierung in C verwende ich gelegentlich Code::Blocks> um einzelne Module zu testen, aber dann auch in C.
Hab ich probiert - aber mit der Grafik ist das bei cb nicht so einfach.
Zurück zu c#: der lcd-code ist ja relativ lang. ich würde den gerne in
eine separate Datei auslagern. Gibt es in c# sowas wie #include?
Ich habe versucht eine classe anzulegen - aber ich bekomme die Variablen
in Form1 nicht global.
Franko S. schrieb:> Wo hast du denn den Blödsinn her?
Was magst Du daran für "Blösdinn" halten? Beides sind leistungsfähige
IDEs, die an beliebie Programmiersprachen, Toolchains und was auch immer
angepasst werden können.
Oder störst Du Dich am "Moloch"?
Die IDE heisst Visual Studio, auf der auch das hier diskutierte
Atmel/Microchip Studio basiert. Die hat mit Visual Studio Code bis auf
ein paar Namensbestandteile nichts zu tun.
Wie Microsoft zum Visual Studio Code schreibt"Your code editor."
Oliver
Oliver S. schrieb:> Harald K. schrieb:>> Beides sind leistungsfähige>> IDEs>> Nicht mal das stimmt. VS Code ist immer noch ein Editor, keine IDE.
Ich würde es auch als Editor klassifizieren, wobei aber die Grenzen hier
teils verschwimmen.
Harald K. schrieb:> Was magst Du daran für "Blösdinn" halten? Beides sind leistungsfähige> IDEs, die an beliebie Programmiersprachen, Toolchains und was auch immer> angepasst werden können.
Code ist keine IDE, das ist ein besserer Editor. Ja das Pluginchaos ist
in etwa ebenbürtig.
Oliver S. schrieb:> VS Code ist immer noch ein Editor, keine IDE.
Sehe ich auch so. Erst diverse Plugins machen daraus eine IDE - wenn man
sie denn installiert.
Franko S. schrieb:> Code ist keine IDE, das ist ein besserer Editor. Ja das Pluginchaos ist> in etwa ebenbürtig.
So sieht das aus. Leider ist offensichtlich das Konzept von Plugins
alleine nicht dazu geeignet, ein konsistentes, gut benutzbares GUI
hervorzubringen.
Es braucht etwas mehr Zwang zu Konformität. Der Ansatz von MS mit der
"isolated shell" des richtigen VisualStudio hat das möglich gemacht.
Aber leider: inzwischen hat weder MS noch irgendwer anders ein Interesse
daran. Das hat wohl allein MS vergeigt. Die wurden zu gierig, so dass es
für potentielle User zu teuer wurde. Und für MS selber wurde der
Pflegeaufwand der historisch verkauften Lizenzen zu teuer.
Mit VS-Code gibt's aus MS-Sicht nun kein Problem mehr. Sie müssen für
garnix Support leisten, kassieren aber Daten ohne Ende, die sie direkt
oder indirekt zu Geld machen können.
Ob S. schrieb:> Sie müssen für> garnix Support leisten, kassieren aber Daten ohne Ende, die sie direkt> oder indirekt zu Geld machen können.
Wie machen die das?
Harald K. schrieb:> Ob S. schrieb:>> Sie müssen für>> garnix Support leisten, kassieren aber Daten ohne Ende, die sie direkt>> oder indirekt zu Geld machen können.>> Wie machen die das?
Indem sie an allen möglichen und unmöglichen Stellen nach Hause
telefonieren. Mach' einfach mal ein tcpdump. Wozu muss eine blöder
Editor ständig im Internet rumwurschteln? Hast du dich das mal gefragt?
Selbst wenn an vielen Stellen kaum Payload übertragen wird: die Tatsache
des Datentransfers alleine sind schon verkaufbare Daten. Vor allem, wenn
sie mit Daten aus anderen Quellen zusammengeführt werden können...
Rolf M. schrieb:> Genau deshalb gibt's ja mit VSCodium eine Variante, die um die> nach-hause-telefonier-Funktion bereinigt wurde. Siehe> https://vscodium.com/
Tja, das Problem dabei ist nur: die Plugins, die aus dem Editor erst
eine (halbwegs brauchbare) IDE machen, sind mindestens genauso
gesprächig wie der Editor selber...
Ob S. schrieb:> Indem sie an allen möglichen und unmöglichen Stellen nach Hause> telefonieren. Mach' einfach mal ein tcpdump. Wozu muss eine blöder> Editor ständig im Internet rumwurschteln? Hast du dich das mal gefragt?
Du weißt, daß man die "telemetrie" abschalten kann?
Du weißt, daß man den Kram auch a) selbst aus den Sourcen übersetzen
oder b) aus anderen Quellen (vscodium) beziehen kann, der dann keine
Telemetrie enthält?
Aber vermutlich verbringst Du zu viel Deiner Lebenszeit damit, C zu
hassen.
Harald K. schrieb:> Du weißt, daß man den Kram auch a) selbst aus den Sourcen übersetzen> oder b) aus anderen Quellen (vscodium) beziehen kann, der dann keine> Telemetrie enthält?
Du hast das eigentliche Problem nicht erkannt. Die Plugins, deren
Verbreitungswege, deren eigene Geschwätzigkeit.
Allerdings, wie rmagnus vollkommen zutreffend sagte: das ist ein
generelles Problem heutiger Software. Er meinte zwar auch, dass es
besonders kommerzielle Software beträfe, aber meiner Meinung nach ist es
so: OSS schnüffelt oft ganz genauso. Wozu auch immer...
Gerade bei VSCode-Plugins kann man sich jedenfalls jederzeit selber und
live davon überzeugen, dass geschnüffelt wird.
> Aber vermutlich verbringst Du zu viel Deiner Lebenszeit damit, C zu> hassen.
Nö, das kann ich locker nebenbei. Das kostet null Zeit. Ist nämlich kein
Prozess, sondern ein Status. Ist übrigens auch völlig unabhängig von der
IDE, in der ich den C-Dreck lesen oder schreiben muss. Hat also nicht
mit VSCode zu tun. Zumal das selber ja nicht mal in C geschrieben ist,
sondern in JS. Auch nicht wirklich besser, nur auf andere Art Scheiße.
Aber ein paar Gemeinsamkeiten gibt es schon: fehlendes striktes
Typsystem z.B.
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten