Hallo liebe Gemeinde, ich habe hier eine PanelCard der Firma Taskit. http://www.taskit.de/produkte/panel-card/index.htm sowohl mit 3,5 als auch 5,7 Zoll LCD. Was ich nun suche sind leistungsstarke Demos, welche das Potential der Plattform aufzeigen. Ich dachte an solche Spielchen wie eine Portierung von Doom & Co, kann aber auch was vollkommen anderes sein. Auf welcher Softwarebasis das Ganze läuft ist vorerst egal, gut wären aber auch Links zu Beispielen basierend auf QT. MFG Falk
Hmmm, Schweigen im Walde? Kein embedded Profi der mitliest? Keine Linuxer? Schade.
Hast Du das Starterkit oder hast Du Dich schon fuer eine Toolchain entschieden? Wenn Du das Starterkit hast, wuerde mich mal interessieren was da fuer eine Toolchain verwendet wird. Weiter wuerde mich interessieren auf welcher Platform Du entwickelst oder entwickeln willst. Wenn dieser Teil geklaert ist kann ich Dir warscheinlich weiterhelfen. Linux auf einen Arm zu bringen ist heute kein grosser Akt mehr. Wenn man dann mal die Linux Umgebung in seiner IDE soweit am laufen hat, das der Kernel compiliert, ist der groeste Stress vorbei. Andere Anwendungen sind dann eine Frage des copierens von Lib's in die entsprechenden Verzeichnisse und abhaengigkeiten aufzuloesen. Ju
@Juergen G. (jup) >Hast Du das Starterkit oder hast Du Dich schon fuer eine Toolchain >entschieden? Wir haben hier in der 4ma beides. Als Software QT4.irgendwas, die Details der Toolchain kenne ich nicht, läuft alles unter Linux, Crosscompiler, Debugger etc. Ach ja, Embedded Linux läuft auch auf der Kiste. >Wenn dieser Teil geklaert ist kann ich Dir warscheinlich weiterhelfen. Naja, ich bin kein Softwerker, will die Sache auch nicht direkt nutzen/bearbeiten. Aber ich brauche ein paar zugkräftige Argumente, damt eben diese mal ein bisschen den Hintern hochkriegen, um unsere Applikationen eine wening zu beschleuningen. Ich höre immer der ARM wäre überfordert. Das glaub ich einfach mal nicht. Der ist in erster Linie mit sich selbst und dem Linux beschäftigt. Ein paar Tunigtips wäre auch ganz nett, z.B. ob es was bringt, den Stack vom Linux in den internen SRAM zu legen etc. >Linux auf einen Arm zu bringen ist heute kein grosser Akt mehr. Haben wir schon. >Wenn man dann mal die Linux Umgebung in seiner IDE soweit am laufen hat, >das der Kernel compiliert, ist der groeste Stress vorbei. Ja, wenn ;-) >Andere Anwendungen sind dann eine Frage des copierens von Lib's in die >entsprechenden Verzeichnisse und abhaengigkeiten aufzuloesen. Naja. Ich suche in erste Linie mal fertige Binaries, die ich einfach mal in den Flash brennen kann und den Leuten unter die Nase halten kann. Quellen dazu sind gut, aber nicht zwingend. MfG Falk
http://elk.informatik.fh-augsburg.de/pub/elinux-abgaben/ss10/Sedlbauer/Studienarbeit%20SS10%20Sedlbauer.pdf Hier hat einer Doom auf nem NGW100 laufen lassen - vllt hilft dir das ja... mfg
Falk Brunner schrieb: > Ich höre immer der ARM wäre > überfordert. Das glaub ich einfach mal nicht. Das ist die ganz normale Softwerker-Krankheit. Speicher ist grundsätzlich zu klein und die CPU grundsätzlich zu langsam. Du kannst ihnen eine Cray hinstellen und die würden immer noch jammern. Falk Brunner schrieb: > Ein paar Tunigtips wäre auch > ganz nett Das beste Tuning erreicht man durch eine sinnvolle Programmstruktur. Das Problem ist, daß die Zeit in der realen Programmierung eine Hauprolle spielt. Also wie oft muß was gemacht werden, wie lange braucht es, kann ich bei langer Dauer vorherige Ergebnisse mit verwenden, wie schnell kann die Peripherie überhaupt Daten liefern bzw. verarbeiten usw. Oftmals ist sogar die Einhaltung von Zeiten wichtiger als ein supergenaues Rechenergebnis. Durch die objektorientierte Programmierung scheint aber der Faktor Zeit noch weiter ins Hintertreffen zu geraten. Der Nachteil von OOP ist also nicht so sehr ein Mehrverbrauch an Ressourcen, sondern die Mißachtung der Hauptanforderung Zeit. Sowas lernt aber vermutlich kein Programmierer und daher wird massig Zeit vergeudet und dann gejammert. Peter
Falk Brunner schrieb: > Ich höre immer der ARM wäre > überfordert. Das glaub ich einfach mal nicht. Der ist in erster Linie > mit sich selbst und dem Linux beschäftigt. Ein paar Tunigtips wäre auch > ganz nett, z.B. ob es was bringt, den Stack vom Linux in den internen > SRAM zu legen etc. > Das Argument "der ARM wäre überfordert" kenne ich, das kommt meist von jungen Programmierern die mit Windows aufgewachsen sind, nicht gewoehnt sind mit dem Speicher zu haushalten und alles vorgekaut bekommen wollen. Das Problem ist, dass auch vorgefertigte ARM Linux Filesysteme nicht unbedingt Wert darauf legen klein und schnell zu sein. Vielmehr sind die Demo Linux' darauf ausgelegt viel Multimedia Muell abzuspielen. MM braucht Speicher, den die meisten embedded Syteme nicht haben und der dann auf langsame externe Speichermedien mit FAT ausgelagert wird. Was kann ich erwarten wenn ich ein 32Bit OS habe, der Zugriff auf die SD-Card aber seriell mit SPI gemacht wird. Viel RAM, schnelle SD's oder USB HD's bringen hier Vorteile. Den Swap auf eine eigene Swap Partition anstatt auf eine FAT Partition bringt hier auch sehr viel. Die Sache mit dem Stack ist, dass der bei "Out of the Box" Linux dynamisch ist und je nach System auch mal 12MB fuer einen einzelnen Thread haben kann. Da muss man bei embedded Systemen selbst Hand anlegen. Das Linux OS ist aber sehr modular aufgebaut, so das es kein Problem darstellt einzelne Module auszutauschen. Man muss sich da echt damit auseinandersetzen wie genau ein OS oder RTOS funktioniert, vor allem muss man es nicht nur gelesen sondern verstanden haben. Vorgefertigte Demo Kernels bringen hier nichts. >>Wenn man dann mal die Linux Umgebung in seiner IDE soweit am laufen hat, >>das der Kernel compiliert, ist der groeste Stress vorbei. > > Ja, wenn ;-) > http://buildroot.uclibc.org/download.html ist hier ein guter Einstieg. Das Tool macht den Anfang mit Linux echt leicht und man kann dann hergehen und einige Teile des Kernels durch eigene ersetzen. > > Naja. Ich suche in erste Linie mal fertige Binaries, die ich einfach mal > in den Flash brennen kann und den Leuten unter die Nase halten kann. > Quellen dazu sind gut, aber nicht zwingend. Fertige Binaries zu bekommen ist nicht einfach, da die meisten Programme fuer die entsprechende Architektur compiliert werden muessen. Mit buildroot bekommt man aber sehr schnell und einfach eine Minimalumbebung, in der man dann die Anwendungen compilieren kann die man moechte. Wenn Du die Programmierer beeindrucken willst sind Demo Apps nicht die erste Wahl, da sie meist irgendwelchen MM Kram machen der durch die externen Speicher ausgebremst wird. Ein Grafisches Spiel wie Mahjongg oder SuperTux macht hier mehr her.
@ Peter Dannegger (peda) >Das ist die ganz normale Softwerker-Krankheit. Speicher ist >grundsätzlich zu klein und die CPU grundsätzlich zu langsam. Leider. >Durch die objektorientierte Programmierung scheint aber der Faktor Zeit >noch weiter ins Hintertreffen zu geraten. Der Nachteil von OOP ist also >nicht so sehr ein Mehrverbrauch an Ressourcen, sondern die Mißachtung >der Hauptanforderung Zeit. Das ist auch meine Beobachtung. >Sowas lernt aber vermutlich kein Programmierer und daher wird massig >Zeit vergeudet und dann gejammert. Ich sag nur Java . . . @ Juergen G. (jup) >Das Argument "der ARM wäre überfordert" kenne ich, das kommt meist von >jungen Programmierern die mit Windows aufgewachsen sind, nicht gewoehnt >sind mit dem Speicher zu haushalten und alles vorgekaut bekommen wollen. Es sind jüngere Programmierer ;-) >Das Problem ist, dass auch vorgefertigte ARM Linux Filesysteme nicht >unbedingt Wert darauf legen klein und schnell zu sein. Vielmehr sind die >Demo Linux' darauf ausgelegt viel Multimedia Muell abzuspielen. Details kenne ich nicht, Multimedia wird eigentlich nicht weiter genutzt. Aber halt QT mit seinen Fenstern und allen anderen Funktionen. An Datenverarbeitung passiert nicht wirklich viel, im Höchstfall werden 10 Messwerte von Strom und Spannung per RS232 empfangen und sollen halbwegs flüssig als Oszi mit Scrolling dargestellt werden. Das soll angeblich mangels Performance nicht gehen. Glaub ich keine Sekunde. <alter Mann> Es gab Zeiten, da war ein Desktop mit 200 MHz CPU und 64 MB RAM eine High End Workstation, mit der man sonstwas machen konnte, nicht nur DOOM zocken. </alter Mann> > MM >braucht Speicher, den die meisten embedded Syteme nicht haben und der 64MB sind schon ganz brauchbar, oder? Mit 32 Bit@100MHz als SD-Ram angebunden. Macht theoretisch 400MB/s. Und der ARM9 hat ja auch noch Cache. >dann auf langsame externe Speichermedien mit FAT ausgelagert wird. Das Meiste läuft im Moment aus ner RAM-Disk. >Was kann ich erwarten wenn ich ein 32Bit OS habe, der Zugriff auf die >SD-Card aber seriell mit SPI gemacht wird. Ist hier nicht das Problem. >Die Sache mit dem Stack ist, dass der bei "Out of the Box" Linux >dynamisch ist und je nach System auch mal 12MB fuer einen einzelnen >Thread haben kann. Was kann man dann mit dem internen, schnellen SRAM sinvoll machen, sind ja nur 170k? Ganz am Anfang war da mal der Framebuffer drin, ist aber für ein 5,7 Zoll LCD zu klein. >Wenn Du die Programmierer beeindrucken willst sind Demo Apps nicht die >erste Wahl, da sie meist irgendwelchen MM Kram machen der durch die >externen Speicher ausgebremst wird. Naja, ich bin da optimistisch. Vielleich kriegen wir ja das prDoom zum Laufen. Aber dann wird wieder gejammer, "jaaaaa, ohne QT ist natürlich alles schnell". 8-( >Ein Grafisches Spiel wie Mahjongg oder SuperTux macht hier mehr her. Ist zu statisch. Ich such etwas in der Art Echtzeitanimation, Kurvendarstellung.
Falk Brunner schrieb: > Ist zu statisch. Ich such etwas in der Art Echtzeitanimation, > > Kurvendarstellung Ist doch bei QT als Demo dabei, z.B. Spectrum Analyzer... Siehe hier: http://doc.qt.nokia.com/4.7-snapshot/demos-spectrum.html
@ Gregor B. (gbo)
>Ist doch bei QT als Demo dabei, z.B. Spectrum Analyzer...
Ahhhh, das sieht schon mal sehr gut aus. Danke!
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.