Hallo an alle, Ich bin dabei einen MIDI Controller zu bauen mit einem atmega2560. Software und Controller laufen nun möchte ich aber die Möglichkeit eines Softwareupdates integrieren. Am liebsten über einen USB Stick oder über MIDI Sysex. Meine Überlegung ist nun den bootloader so um zu programmieren, dass der MIDI Controller beim einschalten testet ob eine bestimmte Taste gedrückt ist und von einem USB Stick die neue Software flashed. Wie spreche ich aber einen USB-Stick an und kann ich z.b. die LCD- library im bootloader benutzen? Welche anderen einfachen (PC und MAC kompatibel)Möglichkeiten gibt es für eine Update über einen Rechner, ohne programmer. Es soll für andere User meines MIDI Controllers so einfach wie möglich sein die Software des MIDI Controllers zu aktualisieren. Hoffe ihr wisst was ich meine. Sorry für den vielen Text. Danke für eure Hilfe und Tipps.
Der Bootloader sollte relativ klein sein und mit möglichst wenig komplexen Dingen auskommen können um ein Update durchführen zu können. Man könnte dies machen: In der Applikation ist das ganze mit Display und USB Bedienung enthalten. Wenn nun ein Update durchgeführt werden soll so wird die Applikation den USB Stick (oder andere Quelle) lesen und die Daten zu erst in einen externen Falsh (z.B. DataFlash über SPI) speichern. Das kann alles die Applikation erledigen. Im zweiten Schritt führt der Prozessor einen Reset aus, dabei startet der Bootloader. Seine Aufgabe ist es im externen Flash nach zu schauen ob eine neue Firmware vorhanden ist, dann ausrechnen ob die Firmware gültig ist anhand einer Prüfsumme. Wenn ja, dann wird der Inhalt vom externen Flash in das interne Flash kopiert. Während der Bootloader diese Aktion durchführt braucht es auch kein Display, da dies in der Regel ohnehin innerhalb weniger Sekunden erledigt ist. Wenn der Bootloader fertig ist startet dieser die Applikation. Sollte der Bootloader kein Update erkennen, so startet er direkt die Applikation, ohne Update. Dann kann man die Sache noch etwas verfeinern, dass z.B. der Bootloader erst einmal vor dem Update die zu letzt gültige Firmware noch mal in das externe Flash sichert, so dass wenn der eigentliche Update fehl schlägt die zuvorige nochmals restauriert werden könnte. Oder dass der Bootloader den Flash vom Prozessor bei jedem Start mit einer Prüfsumme kontrolliert, ob der überhaupt noch gültig ist und ggf. aus dem externen Flash den wieder restauriert. Mit einem externen DataFlash hat man sehr viele Möglichkeiten. Auch könnte die Applikation da drin noch Parameter ablegen. (z.B. Bilder für das Display usw.)
:
Bearbeitet durch User
Ich würde dazu ein USB Laufwerrk nehmen da gibt es welche die dan über RS232 Protokoll und einfachen befehlen Dateien Lesen und schreiben können. Das macht es einfacher. Habe als beispiel schon bei Bestehenden Steuerungen dies RS232 zu USB Converter realisiert
Patrick L. schrieb: > Ich würde dazu ein USB Laufwerrk nehmen da gibt es welche die dan über > RS232 Protokoll und einfachen befehlen Dateien Lesen und schreiben > können. Hast du mal einen Link dazu? Außerdem hört sich das teuer an. Sowas kann sicher niemand kostendeckend in ein Seriengerät einbauen. Die einfachste Lösung ist ein USB->UART Dongle und Update via Serielle Schnittstelle und einem PC Programm. Wer seinen Kunden das nicht zumuten will, kann auch einfach ein eigenes einfaches Dongle machen, z.B. mit einem seriellen Flash drauf. Das gibt man dem Kunden als Update. Dabei spart man sich den USB Kram dazwischen. Und so ein Dongle kann man trotzdem noch sehr günstig fertigen lassen. Nachteil: Muss körperlich versendet werden.
:
Bearbeitet durch User
Cyblord -. schrieb: > Hast du mal einen Link dazu? Ich muss morgen mal im Lager schauen wie die geheißen haben. Das waren so kleine weiße Einbaudinger, die auch nicht besonders Teuer waren. Ganz am Anfang als es noch keine MSP430 mit USB Host gab, hatten wir die Verbaut. Der Name fällt mir aber grad nicht ein. schaue aber morgen mal im Lager wie die Dinger hießen. Heute verwende ich MSP430 mit Onboard USB Host.
Hey danke für eure Tips und Ideen. Markus M. Die Idee ist super, da ich eh eine SD-Karte zum Speichern verschiedener Konfigurationen nutze. Muss ich Mal testen. Kann man in den bootloader auch library's mit einbinden oder wird das dann zu gross? Im Moment nutze ich die spi und SD library zum lesen, schreiben und löschen von Dateien auf die SD-Karte. Es soll für den User so einfach wie möglich sein. Danke für eure Tipps Grüsse Stefan
Stefan M. schrieb: > Kann man in den bootloader auch library's mit einbinden oder wird das > dann zu gross? "Libraries" sind ja auch erstmal nur compilierter Code wie alles andere. Du hast einen ATmega2560, der hat maximal 8 KiB für den Bootloaderbereich, da passt einiges rein. In einem kommerziellen Projekt (auf einem ARM, aber das spielt hier keine große Rolle) haben wir es so gemacht, dass bei eingesetzter SD-Karte grundsätzlich das erstbeste .bin-File auf der Karte gesucht und analysiert worden ist. Dabei wurden ein paar Plausibilitätstests gemacht (passt die Datei überhaupt in den Flash, zeigen alle Interruptvektoren nach innerhalb des Images) und danach wurde eine CRC über die Datei und den gleich langen Flash-Bereich gemacht. War die CRC gleich, dann besaß der Flash bereits das aktuelle Image, und die eigentliche Firmware wurde gestartet. Wenn nicht, wurde das neue Image geflasht. Über alles zusammen (gefundene Datei, Größe, CRC) wurde auf der Karte ein Logfile geschrieben.
Ich bau auch gerade sowas für für meinen Midi Code und habe mich entschlossen das mit SysEx Requests zu lösen. Dazu werte ich einen 64 Byte SysExBuffer aus. Dieser besteht immer aus einer konst. Preaambel gefolgt von einer normalen Intel Hex Zeile. Damit habe ich gleichzeitig das 8Bit Problem im Griff was ja sonst eine Umcodierung erforderlich machen würde. Den Code speichere ich dann mit Offset einfach im internen Flash. Bei mir ergibt das folgendes Layout (kein AVR sondern MCS51) - Firmware 0x0000-0x17FD - Update 0x1800-0x27FD - Flasher 0x3000-0x37FF Die letzten beiden Bytes enthalten jeweils eine 16Bit CRC Prüfsume. Das eigentliche Update wird dann beim Start aufgerufen wenn sich die CRC Werte unterscheiten (aber gültig sind). Die entsprechenden CRCs und Hexfiles werden beim Postprocessing generiert. Der Flasher ist ein eigenständiges C Programm was nach 0x3000 gelinkt wird. Der Nachteil dieser Lösung ist das man die Hälfte des Flashs für die die doppelte Firmware verliert. Das kann man umgehen wenn als Zwischenspeicher ein ext SPI Flash zum Einsatz kommt.
Stefan M. schrieb: > nun möchte ich aber die Möglichkeit eines > Softwareupdates integrieren. Der Arduino-Bootloader (eigentlich ein Monitor) kann über die serielle Schnittstelle / USB ein Update fahren. Kuck Dir auch mal Optiboot an: https://github.com/Optiboot/optiboot Ansonsten fällt mir noch RISM ein. Hatte ich vor zig Jahren mal in der Ausprägung RISM-51 eingesetzt. Kuck hier: http://www.sxlist.com/techref/8051/slide6.html Lag mal auf ftp.intel.com : /pub/mcs51/tools Findet sich vielleicht noch über http://archive.org Was ähnliches hatte ich mal für ARM. Müsste ich mal suchen. Der Monitor muss die Kommandos "L" (load) und "R" (run) und IntelHEX verstehen. Ist also keine Raketenwissenschaft.
Hey, danke für eure Tipps. Werde wohl eher auf die SD-Karten Möglichkeit zurück greifen, da ich sowieso eine Karte benutze. Da ich mich mit dem bootloader noch nicht auseinander gesetzt habe gehe ich davon aus das der umprogrammiert werden muss. Gibt es eine gute Erklärung oder den sourcecode für den bootloader? Schönen Sonntag
Für mich wäre die Nutzung des Arduiono Bootloaders mit dem bei Arduino üblichen USB-UART Chip die naheliegendste Lösung Dabei wir der AVR durch ein Handshake Signal vom USB-UART resetted. In der ersten Sekunde erwartet er den Empfang eines bestimmtes Startsignals. Kommt das nicht, dann beendet sich der Bootloader und startet das normale Programm. Diesen Bootloader kann man ganz einfach mit der Arduino IDE installieren. Ich fürchte dass du den seriellen Port bereits mit der MIDI Schnittstelle belegt hast. Das ist aber kein Problem, denn mit wenigen Bauteilen (z.B einer Diode) kann man sie ruhig doppelt belegen. Der Benutzer soll nur während des Updates dafür sorgen, dass die MIDI Schnittstelle inaktiv ist, oder besser das Kabel abstecken. Für die Eingabe:
1 | |
2 | +------[===]----o 5V |
3 | | |
4 | USB-UART >-----|<|---------------+---------------> AVR RxD Eingang |
5 | | |
6 | ____________|_ |
7 | MIDI IN >---[===]---| | |
8 | | Optokoppler | |
9 | MIDI IN >-----------|______________| |
10 | | |
11 | | |
12 | +--------------- GND |
Für die Ausgabe:
1 | +-----------------> USB-UART |
2 | | |
3 | AVR TxD Ausgang >-------+------[===]------> MIDI OUT |
4 | |
5 | 5V ----------------------------[===]------> MIDI OUT |
Stefan ⛄ F. schrieb: > Dabei wir der AVR durch ein Handshake Signal vom USB-UART resetted. In > der ersten Sekunde erwartet er den Empfang eines bestimmtes > Startsignals. ziemlich umständlich, da man nur fürs Update eine extra USB Verbindung + USB Uart braucht. Das widerspricht etwas der Forderung möglichst einfach für den User. Beim SysEx Transfer würde die vorhandene Midi Schnittstelle verwendet. Nicht ohne Grund verwenden Mid Gerätehersteller oft SysEx für FW Updates
Thomas Z. schrieb: > ziemlich umständlich, da man nur fürs Update eine > extra USB Verbindung + USB Uart braucht Du kannst ja ein WLAN Modul mit Cloud Anbindung einbauen, wenn du dich damit wohler fühlst. Wie oft willst du denn die Firmware aktualisieren? Ich persönlich würde mich mit einem extra Kabel wohler fühlen, oder noch besser wenn ein physischer Schalter umgestellt werden muss. Weil: Mein Fernseher hat eigenmächtig ein Update installiert obwohl die Funktion im Menü deaktiviert war. Seit dem muss ich nach jedem Einschalten umständlich die Audio-Ausgabe auf Bluetooth umstellen. Ich hatte früher mal einen Drucker, der nach einem eigenmächtigen Update die Nutzung von umweltfreundlich aufbereiteten Tinten-Tanks verweigerte. Also: Ich habe die Nase voll in ungewollten upgrades.
Stefan ⛄ F. schrieb: > Du kannst ja ein WLAN Modul mit Cloud Anbindung einbauen, wenn du dich > damit wohler fühlst. Er hatte aber explizit die SD-Karten-Lösung als Optimum für sich bereits deklariert. Was soll dann diese Anmerkung? Die SD-Karten-Lösung ist nicht wirklich schwierig. Natürlich nimmt man Chan's FatFS zum Lesen der Karte, das muss man halt in den Bootloader mit rein linken. Da Stefan (M.) die SD-Karte bereits nutzt, gehe ich davon aus, dass ihm das nicht fremd ist und dass er auch schon einen Lowlevel-Treiber zum Zugriff auf die Karte hat. Ansonsten habe ich den groben Ablauf weiter oben schon skizziert, wie wir es in einer kommerziellen Lösung bei einem früheren Brötchengeber von mir implementiert haben. Das funktionierte am Ende recht zuverlässig dort.
Danke für eure Tipps. Stefan F.: Ich nutze einen atmega 90USB162 für die USB UART Anbindung. Auf den wird Hiduino geflashed und danach kommt der atmega2560. Die Nutzung des 90USB162 nutze ich das mein Midi controller nicht als Universal Audio Midi device am Rechner erkannt wird sondern als mein eigenes Gerät mit eigenem Namen. Mein Problem bei der USB Update Möglichkeit ist das ich nicht ganz verstehe wie ich den Atmega 2560 welcher ja hinter dem at90USB162 hängt Flashen kann. Dazu brauche ich doch dann ein eigenes Programm für den Rechner. Ich hoffe ihr wisst was ich meine? Schönen Abend.
Stefan M. schrieb: > Mein Problem bei der USB Update Möglichkeit ist das ich nicht ganz > verstehe wie ich den Atmega 2560 welcher ja hinter dem at90USB162 hängt > Flashen kann Das macht eben eine Software (Bootloader) Diese liest von der SD Karte dein Update und macht die notwendigen Plausibilitätstests. Sind diese Tests ok wird das File mittels IAP Calls blockweise ins interne Flash geschrieben. Wenn alles geschrieben ist wird die FW gestartet. Diesen Loader must du in jedem Fall schreiben. Die FW kannst du entweder direkt auf die SD Karte kopieren, oder deine FW loggt die SysEx Requests auf passende Kennungen und schreibt das File dann auf deine SD Karte. Falls du mit SysEx arbeiten willst brauchst du auch ein Programm auf dem PC was solche Messages erzeugen kann. Das ist aber nicht schwer da MS die entsprechende Multimedia API seit ewigen Zeiten eingebaut hat. Beispiel für ein SysEx request wie ich das mache 0xF0 "usbman" ":1000B50075E20075EB0C7E007F008FED75EC007E2070" 0xF7 Das ACK / NAK Protokoll hab ich allerdings nicht implementiert. Mir reicht die Quersumme im Intel Hex. Wenn was schief geht verlasse ich mich darauf dass die CRC Sicherung das merkt.
:
Bearbeitet durch User
Beitrag #6858391 wurde vom Autor gelöscht.
Hallo, sorry das ich mich erst jetzt wieder melde. Ich glaube ich werde mich mal mit der Bootloader Thematik beschäftigen. Gibt es da eine Seite die das leicht erklärt? Kann ich z.b. mit der Arduino IDE jeden Bootloader brennen? Gibt es Beispielcode für/von einem Atmega Bootloader? Stefan F.: Wie übertragst du das Update per SysEx vom Rechner? Nutzt du da ein eigenes PC Programm? Ach noch etwas, hat zwar nicht wirklich was mit dem Thema zu tun aber hat jemand von euch erfahrung mit Kickstarter Projekten? Danke für eure Hilfe. Grüße Stefan
Stefan M. schrieb: > Kann ich z.b. mit der Arduino IDE jeden Bootloader brennen? Nur die Bootloader, die in die Arduino IDE integriert sind. Bzw in den Core Plugins die du hinzugefügt hast. > Gibt es Beispielcode für/von einem Atmega Bootloader? Sicher, Arduino ist komplett Open-Source. Schau in Github. Der aktuelle Bootloader heißt "Optiboot".
Stefan M. schrieb: > Stefan F.: Wie übertragst du das Update per SysEx vom Rechner? Nutzt du > da ein eigenes PC Programm? Für den Anfang zum Testen reicht reicht dafür auch MidiOx. Damit kannst du einzelne SysEx Requests verschicken und damit deine Programmlogik testen. Im Endausbau musst du dann halt eine Update.exe bauen die mit Hilfe der Multimedia API deine komplette Firmware an das Device sendet.
Stefan M. schrieb: > Kann ich z.b. mit der Arduino IDE jeden Bootloader brennen? Natürlich! Jeden AVR Bootloader. Vieles ist vorbereitet, den Rest kann man selber definieren. Stefan M. schrieb: > Gibt es Beispielcode für/von einem Atmega Bootloader? Liegt in deiner Arduino Installation. Verschiedene Varianten, incl Quellcode und Toolchain.
Beitrag #6866380 wurde von einem Moderator gelöscht.
Stefan M. schrieb: > Wie übertragst du das Update per SysEx vom Rechner? Ich verstehe die Frage nicht "SysEx" kenne ich nicht. Vermutlich meinst du damit ein Midi Kommando (ist zu lange her dass mit Midi zu tun hatte). Wenn ich Firmware auf Mikrocontroller update, dann per Bootloader oder Programmieradapter. Auf jeden Fall versuche ich nicht, es möglichst einfach zu machen, weil das riskant ist. Mir reicht, dass die Firmware von meinem Fernseher manchmal ferngesteuert verschlimmbessert wird, obwohl ich das Feature in den Settings deaktiviert habe. Nie wieder Samsung! Update per Midi Interface finde ich furchtbar. Das soll bitteschön über eine separate Schnittstelle gehen oder wenigstens manuelle Betätigung von Steckbrücken erfordern, für die man das Gerät aufschrauben muss. Ich akzeptiere, dass du dir das Update per Midi in den Kopf gesetzt hast. Das sollte theoretisch mit einem Bootloader machbar sein. Allerdings muss der dann das Midi Protokoll "sprechen", also wohl nicht die sonst üblichen Bootloader mit STK500 oder AVR910 Protokoll.
Thomas Z. schrieb: > Im Endausbau musst du dann halt eine Update.exe bauen die mit Hilfe der > Multimedia API deine komplette Firmware an das Device sendet. Soso - eine Update.exe. Da freu'n sich aber die MACies unter den Musikern. Wie viele sind das denn - in Prozent? Neunzig - oder doch schon mehr? Wenn ich sowas höre wie: "da baut man *halt*", oder noch besser: "da baut man *einfach*" - da weiß ich von vorne rein: Das geht in die Hose.
jo schrieb: > Soso - eine Update.exe. Da freu'n sich aber die MACies unter den > Musikern. Wie viele sind das denn - in Prozent? Neunzig - oder doch > schon mehr? Der Windows User erwartet eine Update.exe die einfach funktioniert. Mit MACies verfährt man auch völlig anders: Man zockt richtig Kohle für das Update ab. Egal wie das dann da drauf kommt. Im Zweifel ein neues Gerät. Die zahlen das gerne. Die brauchen das. Einem Linuxer schmeißt man einfach alle Quellcode Dateien in einem tarball hin und behauptet man müsse das Ding selber bauen. Bis der merkt dass es nicht geht, nach monatelangem probieren, man pages lesen, in Foren fragen, ist das Gerät abgekündigt. So geht modernes zielgruppenorientiertes Marketing.
:
Bearbeitet durch User
Stefan M. schrieb: > Ich glaube ich werde mich mal mit der Bootloader Thematik beschäftigen. > Gibt es da eine Seite die das leicht erklärt? > Kann ich z.b. mit der Arduino IDE jeden Bootloader brennen? > Gibt es Beispielcode für/von einem Atmega Bootloader? Gääähhn - wie wäre es mit Lesen? Beitrag "Re: Update Funktion für eigenes Projekt"
jo schrieb: > Soso - eine Update.exe. Da freu'n sich aber die MACies unter den > Musikern. Wie viele sind das denn - in Prozent? Neunzig - oder doch > schon mehr? wie man sowas auf dem Mac macht weis ich nicht. Ich bin mir aber sicher das auch auf dem Mac eine entsprechende API existiert die es erlaubt SysEx Requests zu verschicken. Das letzte mal als wir sowas für den MAC gebraucht habe, hat das ein anderer Programmierer in der Firma gemacht. jo schrieb: > Wenn ich sowas höre wie: "da baut man *halt*", oder noch besser: "da > baut man *einfach*" - da weiß ich von vorne rein: Das geht in die Hose. Nun eine entsprechende Update.exe läuft hier schon im Testbetrieb. (für meine Midi Firmware)
Man könnte das Update Programm als Webseite konzipieren. WebUSB, WebMIDI, oder einfach als abspielbares wav file, wie früher mit den kasetten. Was auch immer gerade am einfachsten ist.
Wenn hier jemand von einer "exe" schreibt, meint er ein ausführbares Programm. Das muss nicht unbedingt ein Windows Programm sein.
Stefan ⛄ F. schrieb: > Wenn hier jemand von einer "exe" schreibt, meint er ein > ausführbares > Programm. Das muss nicht unbedingt ein Windows Programm sein. Natürlich kann man auch unter Linux ein Programm Update.exe nennen. Nur: Wer würde auf eine solche irre Idee kommen....
EAF schrieb: > Stefan ⛄ F. schrieb: >> Wenn hier jemand von einer "exe" schreibt, meint er ein >> ausführbares >> Programm. Das muss nicht unbedingt ein Windows Programm sein. > > Natürlich kann man auch unter Linux ein Programm Update.exe nennen. > Nur: Wer würde auf eine solche irre Idee kommen.... Das ist typischer Nullbeitrag von Stefan. Leider in einer Reihe mit sooo vielen. Natürlich referenziert "Update.exe" eindeutig und unzweifelhaft auf ein Windows Programm. Es ging eben auch nicht um "irgendeine ausführbare Datei".
Cyblord -. schrieb: > Natürlich referenziert "Update.exe" eindeutig und unzweifelhaft auf ein > Windows Programm. mono
🐧 DPA 🐧 schrieb: > Cyblord -. schrieb: >> Natürlich referenziert "Update.exe" eindeutig und unzweifelhaft auf ein >> Windows Programm. > > mono Ist auch nichts anderes als ein Windows Programm. Nur dass man es in einer Linux Umgebung ausführen kann.
Cyblord -. schrieb: > 🐧 DPA 🐧 schrieb: >> Cyblord -. schrieb: >>> Natürlich referenziert "Update.exe" eindeutig und unzweifelhaft auf ein >>> Windows Programm. >> >> mono > > Ist auch nichts anderes als ein Windows Programm. Nur dass man es in > einer Linux Umgebung ausführen kann. Nein, die sind technisch gesehen kein Windows Programm. Ähnlich wie EFI Dateien sind es auch PE Dateien, was Windows Anwendungen zufällig auch sind. Es ist aber ein .NET Program, und kein Windows Programm. Naja, zumindest alles bevor .NET 5.0. Der Code in den Anwendungen ist kein Maschinencode, sondern vergleichbar mit Java binär Code https://en.wikipedia.org/wiki/Common_Intermediate_Language Die APIs die unterstützt werden müssen, sind standardisiert: https://github.com/dotnet/standard Idealerweise nutzt eine Anwendung nur die Standardisierten APIs. Beliebige unabhängige Implementationen von .NET implementieren diese ebenfalls. So eine Anwendung ist dann eigentlich nicht Platformabhängig in dem sinne, das irgend ein bestimmtes OS, oder eine bestimmte Implementation benötigt wird. Deshalb ist es eine .NET Anwendung, aber keine Windows Anwendung. Es ist genau wie bei Java. Und Java Programme sind ja auch keine Windows Programme, sondern eben Java Programme. Es geht darum, worauf laufen die Anwendungen, was ist deren Platform. Und die Antwort ist in dem Fall halt technisch gesehen nicht Windows. Man sollte aber beachten, dass das .NET Ökosystem hauptsächlich von Microsoft Kontrolliert wird. Ich würde also trotzdem davon abraten, es zu verwenden.
Cyblord -. schrieb: > 🐧 DPA 🐧 schrieb: >> >> mono > > Ist auch nichts anderes als ein Windows Programm. Nur dass man es in > einer Linux Umgebung ausführen kann. Ich wusste, dass du vom Programmieren keine Ahnung hast. Natürlich steckt in einer Exe für Mono kein Stück "Windows-Programm", jedenfalls nicht, wenn man mal annimmt, dass ein Windows-Programm sich dadurch auszeichnet, dass es die Windows-APIs verwendet. Das Einzige, was so ein Executable mit Windows verbindet, ist die Tatsache, dass es das unter Windows übliche Format für Executables hat. Dieses Format ist aber vom OS (und auch der Maschine) prinzipiell unabhängig, war sogar von Anfang an so geplant, wie schon der Name "portable executable" besagt.
c-hater schrieb: > Natürlich steckt in einer Exe für Mono kein Stück "Windows-Programm", > jedenfalls nicht, wenn man mal annimmt, dass ein Windows-Programm sich > dadurch auszeichnet, dass es die Windows-APIs verwendet. > > Das Einzige, was so ein Executable mit Windows verbindet, ist die > Tatsache, dass es das unter Windows übliche Format für Executables hat. Und das reicht für die Charakterisierung "Windows Programm" nicht aus? > Dieses Format ist aber vom OS (und auch der Maschine) prinzipiell > unabhängig, war sogar von Anfang an so geplant, wie schon der Name > "portable executable" besagt. Darum war der Einwand mit Mono auch eher quatsch. Und der kam nicht von mir.
:
Bearbeitet durch User
Cyblord -. schrieb: > Und das reicht für die Charakterisierung "Windows Programm" nicht aus? Nö. Ist ja weder die erste, noch die einzige Platform, die das PE Format und die .exe Endung verwendet.
EAF schrieb: > Natürlich kann man auch unter Linux ein Programm Update.exe nennen. > Nur: Wer würde auf eine solche irre Idee kommen.... Es geht nicht um die Dateiendung. Mit "exe" meint man ein "executable".
Cyblord -. schrieb: > Ist auch nichts anderes als ein Windows Programm. Nur dass man es in > einer Linux Umgebung ausführen kann. Das stimmt nicht. Zum Beispiel ist die Linux Version von Keepass2 eine *.exe Datei. Darin befindet sich kein Nativer Windows Code. Aber mir ging es wie gesagt nicht um die Dateiendung, sondern um "exe" als Abkürzung für "executable program".
Stefan ⛄ F. schrieb: > Mit "exe" meint man ein "executable". Alles klar! Du hast die Definitionshoheit, und darfst darum bestimmen was andere meinen. Alles klar! Keine Fragen mehr.
EAF schrieb: > Alles klar! Du hast die Definitionshoheit Der Thomas hat doch längst klar gestellt dass er mit exe nicht ausdrücken wollte, dass es nur unter Windows möglich sei. Thomas Z. schrieb: > Im Endausbau musst du dann halt eine Update.exe bauen die mit Hilfe der > Multimedia API deine komplette Firmware an das Device sendet. Thomas Z. schrieb: > wie man sowas auf dem Mac macht weis ich nicht. Ich bin mir aber sicher > das auch auf dem Mac eine entsprechende API existiert die es erlaubt > SysEx Requests zu verschicken.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.