mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Linux auf einen Atmega?


Autor: Krisi K. (haxi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte man auf einem Atmega xxx Linux drauf bekommen?
Und wenn ja wie?

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und was soll das ? Wegen der KDE ?

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ch D. (chrisu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
War es nicht so das der nur Programme aus dem Flash ausführen kann? also 
dafür gibt es kein passendes OS .....

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja

nen 8Bit Basicinterpreter ließe sich realisieren ;-)

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Sigint 112 (sigint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Winfried J. schrieb:
> naja
>
> nen 8Bit Basicinterpreter ließe sich realisieren ;-)

Gibts schon: http://www.jcwolfram.de/projekte/avr/chipbasic32/main.php

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre es möglich nen 2MHz 386er auf nem 20Mhz AVR zu emulieren? Halt mit 
viel externem RAM + SD-Karte?

Autor: Andi ... (xaos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast schrieb:
> Wäre es möglich nen 2MHz 386er auf nem 20Mhz AVR zu emulieren? Halt mit
> viel externem RAM + SD-Karte?

Autor: franz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>nö

quatsch, natürlich ist es möglich, nur eben extrem langsam.

Autor: giec (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Justus Skorps (jussa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
franz schrieb:
>>nö
>
> quatsch, natürlich ist es möglich, nur eben extrem langsam.

dann ist es aber kein 386er mit 2 MHz mehr...

Autor: giec (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: pq (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: franz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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_webserve...

welchen nehmt ihr?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sind AVR32

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie schon genannt, hat der AVR nur ein Harvard Architektur.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wie schon genannt, hat der AVR nur ein Harvard Architektur.

Da sehe ich keine grossen Probleme, so lange der Compiler sinnvoll damit 
umgehen kann.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Harvard Architektur

Erlaubt einen 386 code interpreter ab Flash zu operieren.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir stellt sich grade die Frage nach dem Sinn des ganzen...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und selbst wenn man Linux irgendwie auf den Atmega zum laufen bringen 
könnte - allein der Boot dürfte zu einer Geduldprobe werden.

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und eine MMU ist ebenfalls zwingend erforderlich.  Wie soll sonst 
ge-fork()-t werden?

Autor: neuer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.....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...

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ?

Autor: Maxxie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und eine MMU ist ebenfalls zwingend erforderlich.  Wie soll sonst
> ge-fork()-t werden?

Noe.
http://www.uclinux.org/

Autor: Alexander Schmidt (esko) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. uClinux does not implement fork();  instead it implements vfork(). 
      This does not mean no multitasking, it simply means that the 
      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.

Autor: Maxxie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ;-)

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hazeh Zimmerer schrieb:
>
>
> 
>         1. uClinux does not implement fork();  instead it implements
> vfork().
>       This does not mean no multitasking, it simply means that the
>       parent blocks until the child does exec() or exit().
> 
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.

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Maxxie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich klinke mich aus.  Das ist bloss noch Rechthaberei, garniert mit 
persönlichen Angriffen.

Autor: Maxxie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ja das geht!

Hurra, hurra. Alter Hut. Und dafür gräbst du hier
eine 5 Jahre alte Leiche aus?

Autor: Logo geht das (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Via Arm Emulator der auf einem 8-Bit Atmel läuft: 
http://dmitry.gr/index.php?r=05.Projects&proj=07.%...

Der emulierte ARM-Takt liegt bei 6,5 KHz.

Autor: Kaj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.%...

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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.