Könnte man auf einem Atmega xxx Linux drauf bekommen? Und wenn ja wie?
Bei den 8 Bit µCs wird Linux nicht gehen und macht auch keinen Sinn. Wenn überhaupt ist da ein spezielles µC-Betreibssystem wie RTOS angesagt. Meistens wird man aber ganz ohne Betreibsystem arbeiten, denn das Programm ist ja fest und Speicher eher knapp. Für die AVR32 Serie gint es Linux, dass sind aber auch 32 Bit µCs.
Krisi K. schrieb: > Könnte man auf einem Atmega xxx Linux drauf bekommen? > Und wenn ja wie? Nur wenn du verrückt genug bist auf einem Atmega einen CPU Emulator für eine von Linux unterstützte 32Bit CPU zu implementieren. Aber das wirst du nicht wollen. Da das erstens sehr Aufwändig ist und zweitens hinterher total langsam läuft.
War es nicht so das der nur Programme aus dem Flash ausführen kann? also dafür gibt es kein passendes OS .....
naja nen 8Bit Basicinterpreter ließe sich realisieren ;-)
Man koennte natuerlich fuer einen Mega256 einen 386 emulator schreiben und den auszufuehrenden Code von einem flash nach bedarf laden. Die fuer ein Linux noetigen Megabytes an RAM haette man natuerlich nicht, das wuerde dann auf die 8k Rein- und Rausgeswappt. Ueber ein SPI Interface...
Winfried J. schrieb: > naja > > nen 8Bit Basicinterpreter ließe sich realisieren ;-) Gibts schon: http://www.jcwolfram.de/projekte/avr/chipbasic32/main.php
Wäre es möglich nen 2MHz 386er auf nem 20Mhz AVR zu emulieren? Halt mit viel externem RAM + SD-Karte?
Gast schrieb: > Wäre es möglich nen 2MHz 386er auf nem 20Mhz AVR zu emulieren? Halt mit > viel externem RAM + SD-Karte? nö
Nimm doch einfach ein geeignetes vorhandenes Linux (embedded oder so) und passe es an eine möglichst leistungsfähige AT(X)Mega Plattform und den Compiler an. Gewisse Einschränkungen wird es dann wohl geben, aber durch Aufbohren der Plattform mit Ram, evtl. Netzwerkzugriff und Netzwerkspeicher, kann man die Limits vielleicht etwas hinausschieben. Ein Blick auf Busybox wäre sicher auch nicht verkehrt.
franz schrieb: >>nö > > quatsch, natürlich ist es möglich, nur eben extrem langsam. dann ist es aber kein 386er mit 2 MHz mehr...
Fundierte Kenntnisse des Linux-Kernels und der ganzen Linux-Umgebung usw. sind natürlich unerlässlich für sowas, wenn Du die nicht hast, vergiss es für's erste und fang erstmal damit an, Dich dort einzuarbeiten.
Na was fehlt dem AVR denn eigentlich für Linux? Mir fällt eigentlich nur die MMU ein. Linux für einen 8-Bitter zu compilieren sollte ein entsprechender Compiler ja hinkriegen. Die Grösse des RAM auf einem hypothetischen AVR lässt sich "gross genug" annehmen, wobei die Adressierung aber schnell zum Problem wird. > quatsch, natürlich ist es möglich, nur eben extrem langsam. Ja. Und dann erreicht er seine simulierten 2 MHz nicht, also geht es nicht.
>Ja. Und dann erreicht er seine simulierten 2 MHz nicht, also geht es >nicht. Du hast recht,ich habe die 2MHz übersehen .... :-( Hier sind die Atmels mit Linux: http://www.ixbat.de/index.php?page_id=237 http://mikrocontroller.jacob-pirna.de/avr_webserver_projekte_ngw100.html welchen nehmt ihr?
Gast schrieb: > Na was fehlt dem AVR denn eigentlich für Linux? Mir fällt eigentlich nur > die MMU ein. Das ist ausnahmsweise kein Problem - solange die Software nicht in den falschen Speicherberich schreibt. > Linux für einen 8-Bitter zu compilieren sollte ein > entsprechender Compiler ja hinkriegen. Einige Teile des Kernels dürften in Assembler geschrieben sein. > Die Grösse des RAM auf einem > hypothetischen AVR lässt sich "gross genug" annehmen, wobei die > Adressierung aber schnell zum Problem wird. Und das ist ein ziemlich großes Problem. > >> quatsch, natürlich ist es möglich, nur eben extrem langsam. > > Ja. Und dann erreicht er seine simulierten 2 MHz nicht, also geht es > nicht. Ja, ich denke man landet eher bei 2kHz.
> Wie schon genannt, hat der AVR nur ein Harvard Architektur.
Da sehe ich keine grossen Probleme, so lange der Compiler sinnvoll damit
umgehen kann.
>Harvard Architektur
Erlaubt einen 386 code interpreter ab Flash zu operieren.
Was hat denn das für ein Sinn. Dann läuft das Linux ja eh nicht auf dem AVR. Das dann verwendete Linux wär ja kein AVR Port dann. Aber darum geht es doch hier.
Mini Troll schrieb: > Man koennte natuerlich fuer einen Mega256 einen 386 emulator schreiben > und den auszufuehrenden Code von einem flash nach bedarf laden. Die > fuer ein Linux noetigen Megabytes an RAM haette man natuerlich nicht, > das wuerde dann auf die 8k Rein- und Rausgeswappt. Ueber ein SPI > Interface... Ich habe so etwas Ähnliches mit einem ATmega8 aufgebaut, nur noch viel besser: Damit das Ganze nicht zu langsam wird, wird der 386-Emulator durch einen externen Coprozessor unterstützt, mit dessen Hilfe sogar die Ausführung von 486- und Pentium-Code möglich ist. Der Coprozessor kann per DMA auf 512MB RAM zugreifen, was zum einen sehr schnell ist und zum anderen das Problem des eingschränkten Adressraums des AVRs umgeht. Die Linux- Dateien sind nicht in einem Flash, sondern auf einer 160GB-Festplatte abgelegt, auf die der Coprozessor ohne Umweg über den AVR zugreifen kann. Ein an den AVR angeschlossenes 4×27-Text-LCD und eine PS/2- Tastatur können als Linux-Konsole dienen, die aber so gut wie nie verwendet wird, da der Coprozessor über entsprechende Zusatzhardware auch ein 1600×1200-Farbgrafik-LCD ansteuern kann, womit sogar X11 lauffähig ist. Da sich die Grafikhardware aus Coprozessorsicht wie ein ATI-Chip verhält, muss man nicht einmal einen speziellen Treiber dafür schreiben. Natürlich ist das System netzwerkfähig. Um einen hohen Datendurchsatz zu erreichen, ist auch hier eine direkte Kommunikation zwischen Coprozessor und Ethernet-Hardware möglich. Selbstverständlich steht über ein entsprechendes API sämtliche integrierte AVR-Peripherie (I/O-Ports, ADC, Timer usw.) für die Nutzung in Linuxprogrammen zur Verfügung. Ein weiteres Highlight: Die AVR-Software kann zur Laufzeit (also ohne das Linux neu zu booten) modifiziert werden. Für die Dauer des Umprogrammierens hält der Coprozessor den Linux-Betrieb aufrecht. Alles in allem hat man damit ein AVR-Linux, dass performancemäßig selbst für 3-D-Spiele völlig ausreichend ist.
Man braucht auf so einem µC eigentlich gar kein Betreibssystem. Bestefalls könnte man einen Bootloader als eine Art Betreibsstystem ansehen. So langsam sind die AVRs auch gar nicht. Die Simulation eine MOS6502 soll mehr als 2 MHz Takt entsprechen. Man wird sich auch keinen 386er als CPU aussuchen, weil zu kompliziert. Eher schon sowas wie MIPS, ARM oder so. Die ersten Unix-Versionen liefen auf damaligen Großrechnern (VAX , PDP...), die auch nicht wesentlich leistungsfähiger als ein größerer 8 Bit AVR waren. Wenn man Linux auf einem µC haben will, dann aber doch lieber AVR32 oder ARM.
Ulrich schrieb: > Die ersten Unix-Versionen liefen auf damaligen Großrechnern > (VAX , PDP...), die auch nicht wesentlich leistungsfähiger als ein > größerer 8 Bit AVR waren. Wird hier auch mal das Geschriebene gelesen? Ist ja schön, dass du die Leistungsfähigkeit mit einem AVR vergleichst, aber Linux auf einem AVR ist nicht möglich, da es sich um eine Harvard Architektur handelt und Linux, soweit ich weiß, nur auf Von Neumann Architekturen läuft. Zumindest muss Programmcode aus dem RAM ausgeführt werden können.
Und selbst wenn man Linux irgendwie auf den Atmega zum laufen bringen könnte - allein der Boot dürfte zu einer Geduldprobe werden.
Und eine MMU ist ebenfalls zwingend erforderlich. Wie soll sonst ge-fork()-t werden?
.....Ich habe so etwas Ähnliches mit einem ATmega8 aufgebaut, nur noch viel besser: Damit das Ganze nicht zu langsam wird, wird der 386-Emulator durch einen externen Coprozessor unterstützt, mit dessen Hilfe sogar die Ausführung von 486- und Pentium-Code möglich ist...... Ach, jetzt hilft doch ein anderer Porzessor mit...oh... Sollte das der Atmega nicht alleine schaffen ,ihr schlaumeier...
>So langsam sind die AVRs auch gar nicht. Die Simulation eine MOS6502 >soll mehr als 2 MHz Takt entsprechen. Man wird sich auch keinen 386er >als CPU aussuchen, weil zu kompliziert. Eher schon sowas wie MIPS, ARM >oder so. Die ersten Unix-Versionen liefen auf damaligen Großrechnern >(VAX , PDP...), die auch nicht wesentlich leistungsfähiger als ein >größerer 8 Bit AVR waren. Wie wäre es mit einem 32Bit 8Core Prozessor?: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=76
neuer schrieb: > .....Ich habe so etwas Ähnliches mit einem ATmega8 aufgebaut, nur noch > viel > besser: > > Damit das Ganze nicht zu langsam wird, wird der 386-Emulator durch einen > externen Coprozessor unterstützt, mit dessen Hilfe sogar die Ausführung > von 486- und Pentium-Code möglich ist...... > > > Ach, jetzt hilft doch ein anderer Porzessor mit...oh... > Sollte das der Atmega nicht alleine schaffen ,ihr schlaumeier... Du hast anscheinend die Ironie in diesem Post nicht kapiert.
>Damit das Ganze nicht zu langsam wird, wird der 386-Emulator durch einen
externen Coprozessor unterstützt, mit dessen Hilfe sogar die Ausführung
von 486- und Pentium-Code möglich ist......
Durfte der Mega8 Tastatur und Maus eines PC simulieren ?
> Und eine MMU ist ebenfalls zwingend erforderlich. Wie soll sonst > ge-fork()-t werden? Noe. http://www.uclinux.org/
yalu schrieb: > Ich habe so etwas Ähnliches mit einem ATmega8 aufgebaut, nur noch viel > besser: > > Damit das Ganze nicht zu langsam wird, wird der 386-Emulator durch einen > externen Coprozessor unterstützt, ... You made my day.
Maxxie schrieb: >> Und eine MMU ist ebenfalls zwingend erforderlich. Wie soll sonst >> ge-fork()-t werden? > > Noe. > http://www.uclinux.org/ Ich schrieb von fork und der Unmöglichkeit, das ohne MMU zu machen, richtig? Es kommt "Noe" und uclinux. Ein Subset von Linux also und kein Linux wie es sonst läuft. Aus der dortigen FAQ:
1 | 1. uClinux does not implement fork(); instead it implements vfork(). |
2 | This does not mean no multitasking, it simply means that the |
3 | parent blocks until the child does exec() or exit(). |
Nix mit "Noe". Es hat keinen fork(), wie zu erwarten war. Statt dessen wird der Elternprozess geblockt. In den meisten fork()-Szenarien keine angenehme Aussicht. Inwieweit das noch den Anforderungen des TE und des Rest der Welt an ein Linux erfüllt, überlasse ich mal eurem Urteil.
Dummerweise hast du geschrieben, dass das Threadthema nicht ohne MMU möglich ist, eben weil fork fehlt. Das ist aber offensichtlich falsch. Was es nicht mehr erfüllt ist der Posix Standard. Der ist aber kein zwingend nötiger Teil eines OS/Linux sondern eine (von mehreren) Interface-Spezifikationen zu den OS-Funktionen.
> Damit das Ganze nicht zu langsam wird, wird der 386-Emulator durch > einen externen Coprozessor unterstützt, ... >> Ach, jetzt hilft doch ein anderer Porzessor mit...oh... >> Sollte das der Atmega nicht alleine schaffen ,ihr schlaumeier... Hmm ... > Du hast anscheinend die Ironie in diesem Post nicht kapiert. > Durfte der Mega8 Tastatur und Maus eines PC simulieren ? > You made my day. ... Aufatem! Und ich dachte erst, der nicht existierende Smiley sei mal wieder zu klein geraten :) Ja, der "Coprozessor" ist nichts weiter als ein Pentium auf einem Main- board in einem PC-Gehäuse unter meinem Schreibtisch mit einem zufälli- gerweise über ISP und einer RS-323-Schnittstelle angeschlossenem Loch- raster-ATmega8-Board, das ich nach der letzten Bastelstunde vergessen habe auszustecken ;-)
Hazeh Zimmerer schrieb: > >
1 | > |
2 | > 1. uClinux does not implement fork(); instead it implements |
3 | > vfork(). |
4 | > This does not mean no multitasking, it simply means that the |
5 | > parent blocks until the child does exec() or exit(). |
6 | > |
Ok, wieder was gelernt. > Nix mit "Noe". Es hat keinen fork(), wie zu erwarten war. Statt dessen > wird der Elternprozess geblockt. In den meisten fork()-Szenarien keine > angenehme Aussicht. Die meisten fork() Aufrufe gehen aber so weiter, dass danach eben exec() aufgerufen wird. Das ist unter Unix der übliche Weg neue Programme zu starten.
Maxxie schrieb: > Dummerweise hast du geschrieben, dass das Threadthema nicht ohne MMU > möglich ist, eben weil fork fehlt. Das ist aber offensichtlich falsch. Wo? Du musst ein anderes Forum lesen. > Was es nicht mehr erfüllt ist der Posix Standard. Der ist aber kein > zwingend nötiger Teil eines OS/Linux sondern eine (von mehreren) > Interface-Spezifikationen zu den OS-Funktionen. Es ist dann kein Linux mehr, sondern allenfalls ein uCLinux. Dein gewohntes Desktop-Linux läuft ohne fork() nicht mehr. Ich habe sehr lange mit einen Echtzeitbetriebssystem ohne fork() gearbeitet (OS/9-68000). Man kann damit im embedded-Bereich gut arbeiten, aber ein unixoides Betriebssystem ist es keins mehr - allenfalls ein paar Ähnlichkeiten.
Man kann fork auch ohne MMU implementieren. Nur konkurrieren dann eben zwei Prozesse um den gleichen Speicherplatz, d.h. sie müssen ggf. aus- und eingelagert oder hin- und hergeschubst werden.
Ja. Minix für 68k hat das mal so gemacht. Das Teil war nur noch am Speicherblöcke verschieben, aber - immerhin - es funktionierte. Die Performace war allerdings indiskutabel. For seinen Daseinszweck - ein Lehrbetriebssystem auf dem Atari ST lauffähig zu machen - tat's damals aber. Die zu schaufelnden Ram-Größen waren noch überschaubar.
> Maxxie schrieb: >> Dummerweise hast du geschrieben, dass das Threadthema nicht ohne MMU >> möglich ist, eben weil fork fehlt. Das ist aber offensichtlich falsch. > > Wo? Du musst ein anderes Forum lesen. Da: Und eine MMU ist ebenfalls zwingend erforderlich. >> Was es nicht mehr erfüllt ist der Posix Standard. Der ist aber kein >> zwingend nötiger Teil eines OS/Linux sondern eine (von mehreren) >> Interface-Spezifikationen zu den OS-Funktionen. > > Es ist dann kein Linux mehr, sondern allenfalls ein uCLinux. Dein > gewohntes Desktop-Linux läuft ohne fork() nicht mehr. Achso, weil du es sagst, ist eine nicht Desktop Linux Distribution kein Linux mehr. Ich bleib da eher bei der Definition über den Kernel und seine API (vergleiche lkml) und dessen Interface ist weder Posix-Abhängig noch fordert sie einen Fork. Du darfst mich gerne eines Besseren belehren und mir deine Definition heraussuchen. Bin gespannt ab wann ein Linux nach dir ein Linux ist ... Wenn man deiner Definition des vollständigen Einbindung (kein Subset an Funktionen) hernimmt, dann kenne ich keine Distribution, die das erfüllt. > Ich habe sehr lange mit einen Echtzeitbetriebssystem ohne fork() > gearbeitet (OS/9-68000). Man kann damit im embedded-Bereich gut > arbeiten, aber ein unixoides Betriebssystem ist es keins mehr - > allenfalls ein paar Ähnlichkeiten. Soso, dann müssen wir wohl die Geschichte von Unix umschreiben. Das waren füher gar keine. Zimmerer hat's gesagt. Mach dir selbst einen Gefallen und überprüfe mal deine Annahmen die du dann schon "sehr lange" mit dir rumschleppst und die dich in die Irre leiten.
Ich klinke mich aus. Das ist bloss noch Rechthaberei, garniert mit persönlichen Angriffen.
Ach komm, ich hab dich nicht persönlich angegriffen, das sieht anders aus. Du hast dich und deine Erfahrung selbst eingebracht (die hab ich auch nicht bezweifelt oder dir abgesprochen), und daraus deine Behauptung abgeleitet. Diesen Schluss jedoch habe ich zugegeben mit ein wenig Spott angezweifelt. Wenn du eine solche sachlich falsche Behauptung hier hinwirfst musst du eben mit "Rechthabern" rechnen.
Ja das geht! http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit#uniqstr_1401997921699_q
>Ja das geht!
Hurra, hurra. Alter Hut. Und dafür gräbst du hier
eine 5 Jahre alte Leiche aus?
Via Arm Emulator der auf einem 8-Bit Atmel läuft: http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit Der emulierte ARM-Takt liegt bei 6,5 KHz.
Logo geht das schrieb: > Via Arm Emulator der auf einem 8-Bit Atmel läuft: > http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit Junge... erstens wurde das 2 Post vor die schon geschrieben und zweitens: holger schrieb: > Und dafür gräbst du hier > eine 5 Jahre alte Leiche aus? Schaut hier auch mal wer was geschrieben wird?
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.