|
Anzeige
|
#c Zeiger auf Adresse / array-listhallo, Ich möchte in c# verschiedene Fonts in eine Bitmap zeichnen:
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
Gast
#7825542
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. Wie in C auch. Ein Array ist ein Referenztyp. Sein Bezeichner ist gleichzeitig die Referenz auf das Element [0].
du lebst halt hiterm Mond.
Nein. c# ist eine "memory managed" Sprache. Nix Zeiger, Zeiger böse (unsafe)
Gast
#7825554
Kläre mich auf! Welche Mikrocontroller programmierst du in C#?
Habe ich nicht "Referenz" geschrieben? https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/arrays Das "learn" im Link steht für "Lern Grundlagen". Esp32. Generics werden nicht unterstützt. Brauchst du ein Link? Referenzen sind in C# nochmal was anderes, ref. Lern du mal lieber
Gast
#7825568
Danke das reicht mir.
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" Mit GCC? Was zum f***? Llvm als Middleware könnte das werden, wobei es dann kein C wird.
Gar nicht. Du kannst natürlich Arrays anlegen, die Konstanten enthalten – wo die dann liegen, bestimmst aber nicht du.
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?
In der kann man mit exakt demselben Komfort auch mit C arbeiten.
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. in c# geht alles - man muss es nur finden
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.
Das ist jetzt eine sehr pauschale Aussage. Wir verwenden das ziemlich oft, allerdings nur zum Startzeitpunkt bzw im Konstruktor.
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.
Angehängte Dateien:
Gast
#7825794
Dann mache das doch in C/C++ - erspart dir viele Probleme.
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.
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.
Es geht um einen Atmega328.
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. Es funktioniert. Und sogar erstaunlich gut.
Angehängte Dateien:
Gast
#7827181
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"?
Nicht mal das stimmt. VS Code ist immer noch ein Editor, keine IDE. Oliver
Kann es sein, daß Du keinen blassen Schimmer von dem hast, was Du da von Dir gibst? 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
Ich würde es auch als Editor klassifizieren, wobei aber die Grenzen hier teils verschwimmen.
Gast
#7827749
Code ist keine IDE, das ist ein besserer Editor. Ja das Pluginchaos ist in etwa ebenbürtig.
Gast
#7827850
Sehe ich auch so. Erst diverse Plugins machen daraus eine IDE - wenn man sie denn installiert.
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.
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... 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... Das kann durchaus sein. Allerdings ist das natürlich ein generelles Problem heutiger Software, vor allem der kommeziellen.
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.
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.
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. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
