'Framework' für Platform-Unabhängige Firmware

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 !?!

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

"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)