Hi, wie hoch ist das Interesse an einem 'Framework' (oder so etwas in der Art) mit dessen Hilfe man 'Grafische-Plattform-Unabhängige-Firmware' schreiben kann ohne diese an jede Platform anpassen zu müssen. Mit den 'Realtime-Betriebs-Systemen' komm ich nicht wirklich klar ! Also ein Code für AVR/ARM/x86realmode/Linux/Windows/Mac/BSD/MSP ,.......... Oder anders herum gefragt, gibt es so etwas ??? Danke Olli
Meintest mit OGL, OpenGL ??? nee, en bissl overdosed :-) Meinte eher was in Richtung Waschmaschine mit gLCD :-) Ich schreibe meine Software auf dem PC, inkl. grafische Menüs, Piepser, ADC, ... und sag beim Kompilieren einfach, das er es nicht für den PC(Lin/Win/Mac) übersetzten soll, sondern für einen AVR mit S65-Display oder ein ARM mit Nokia-Display !?!
Ich glaub das läuft, beim Aufwand, aufs Gleiche hinaus. Man braucht für jedes Zielsystem eine lib die man zulinkt. Gruß Z8
Oliver Dippel schrieb: > Ich schreibe meine Software auf dem PC, > inkl. grafische Menüs, Piepser, ADC, ... > und sag beim Kompilieren einfach, > das er es nicht für den PC(Lin/Win/Mac) übersetzten soll, > sondern für einen AVR mit S65-Display oder ein ARM mit Nokia-Display !?! Tust du das aktuelle schon, oder traeumst du nur davon? Das Problem vieler Frameworks ist naemlich leider, dass sich die Leute dran gewagt haben, bevor sie die noetige Erfahrung fuer sowas haben...
Wollte erstmal drüber diskutieren ;-) Was ihr davon haltet, und ob jemand gleich sagt: des geht nett :-) DBD Olli PS: mir ist der Aufwand klar, aber zusammen müssten wir es nur einmal bewältigen !
Interessiert das Thema überhaupt nett, hat keiner Lust was zu machen, oder wartet ihr alle auf was Fressfertiges ??? DBD Olli
So etwas in der Art existiert doch schon, warum das Rad neu erfinden? Drei bis vier Programmierer haben sich vergangenes Wochenende mal für 2 Stunden hingesetzt und so ein Framework entwickelt... Veröffentlicht haben sie das Ergebnis auch schon... unter http://java.sun.com kann man aktuell die ersten Testversionen herunterladen. ;-)
GTK+ und QT wären natürlich auch ein Ansatzpunkt... Ist bestimmt "mal eben" auf den AVR zu portieren... g
"AVR/ARM/x86realmode/Linux/Windows/Mac/BSD/MSP" ??? alles auf einmal grins Du must dich auf den kleinsten möglichen Nenner verständigen -- machbar aber mit sehr grossem Aufwand. Im Endeffekt wirst du dein eigenes 'Real-Time-Betriebssystem' oder zumindest ein normales Betriebssystem entwickeln. zumindest ein Abstaktionslevel. Was hast am Anfang gesagt, nur zur Info: "Mit den 'Realtime-Betriebs-Systemen' komm ich nicht wirklich klar !" gruss
Ich meinte das schon etwas ernster, und auch kein Java sondern C. Im Prinzip benötigt man doch nur eine vernünftige HAL. die Muss auch nur Sachen wie SPI, I2C , GPIO und Seriell können. Nach und nach dann vielleicht noch was in Richtung USB ? Alles andere ist eigentlich nur eine Funktion's und Treiber Sammlung, und eine Art Build-System. DBD Olli
Ich glaube du unterschätzt das Ganze ein wenig, kann das sein?
> Was hast am Anfang gesagt, nur zur Info: > "Mit den 'Realtime-Betriebs-Systemen' komm ich nicht wirklich klar !" Zu viel Overhead :-) @ Simon > Ich glaube du unterschätzt das Ganze ein wenig, kann das sein? An welcher Stelle denkt du denn, sollten größere Probleme auftauchen ?
> Im Prinzip benötigt man doch nur eine vernünftige HAL. > die Muss auch nur Sachen wie SPI, I2C , GPIO und Seriell können. > Nach und nach dann vielleicht noch was in Richtung USB ? Hab ich schon fertig, arbeite gerade am Filesystem. Läuft mit RTOS ab 23K Flash. Kann per fopen/close/read/write print/scanf stdin/out alles von überall nach überall hin- und her, kreuz und in die Runde leiten, der User braucht davon nix wissen, der sagt nur, woher und wohin. Geht mit UART0,1,2,3,... LCD, GLCD, ITM (Cortex-Debug-Channel), Ethernet, USB hab ich noch keine Target driver implementiert, sonst no prob. VG, /th.
Random ... schrieb: > Kann per fopen/close/read/write print/scanf stdin/out alles von überall > nach überall hin- und her, kreuz und in die Runde leiten, der User > braucht davon nix wissen, der sagt nur, woher und wohin. > Geht mit UART0,1,2,3,... LCD, GLCD, ITM (Cortex-Debug-Channel), > Ethernet, USB hab ich noch keine Target driver implementiert, sonst no > prob. Das ist doch mal ein interessanter Ansatz :-) Unter Linux läuft das ja eigentlich ähnlich, alles per File-System (/dev). Geht mir aber fast schon zu weit in Richtung OS, wenn meine Firmware nur irgendwas auf SPI ausgeben soll, sind 23kb auf einen kleinen AVR schon gewaltig. DBD Olli PS: langsam wird es interessant :-)
Ok, es existiert bereits ein Ansatz, ist aber noch im Rohbau und stark an ein Projekt angelehnt. Will ich aber als Basis meiner kommenden Programme nutzen. Zu sehen sind die Anfänge auf meiner Live-CD: http://rcos.codingmonkey.de/Downloads/rcos/livecd/livecd.iso # cd /usr/src/rcos/src # make setup oder zum testen direkt mit z.B. Windows-Cross-Compile (SDL) # make pc Linux-Compile (SDL) # make win DBD Olli PS: wer beim starten der Live-CD im Bootmanager ganz schnell (timeout) rcos eingibt, kann die x86-Version der kompilierten Firmware anschauen (noch 1bitFB und ohne viel Funktion)
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.