mikrocontroller.net

Forum: Projekte & Code GIGATRON Emulator im STM32


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Joerg W. (joergwolfram)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
bevor der Gigatron-Emulator Thread bei "Mikrocontroller und Digitale 
Elektronik" rasch wieder in der Versenkung verschwindet,
mache ich jetzt noch mal einen bei "Projekt und Code" auf, denn jetzt 
gibt es auch ein öffentliches Projekt dazu:

http://www.jcwolfram.de/projekte/gtmicro_de/main.php

Dabei geht es um eine Emulation des GIGATRON https://www.gigatron.io , 
ein Computer auf TTL-Basis von Marcel van Kervinck und Walter Belgers.

Kernstück des Emulators ist ein auf 225 MHz übertakteter STM32F405, dazu 
noch etwas "Hühnerfutter". Der ganze Emulator ist in ASM geschrieben, 
und selbst da wird es knapp, so dass die ROM-Images gepatcht werden 
müssen. Dafür läuft der Emulator mit exakt 100% Originalgeschwindigkeit 
(zumindest theoretisch, alle Befehle habe ich nicht nachgemessen).

Es werden 64K RAM unterstützt und es lassen sich verschiedene ROM-Images 
laden. Das ausgewählte ROM-Image wird beim Start in das RAM des 
Controllers kopiert und das CCM RAM dient als emuliertes RAM. Der 
Emulator selbst läuft im Flash, weiteres RAM wird nicht benötigt (auch 
kein Stack). Dafür ist auch keine Zeit, alle relevanten Informationen 
werden in Registern gehalten.

Jörg

Autor: Als ich aus dem Internet ab (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow, ich gratuliere zum Erfolg des "Single Chip Gigatron, a CPU without 
a CPU made with a CPU"! :-)

Der Neid läßt mich da nur Haare in der Suppe suchen: auf Deiner Webseite 
dazu sehe ich ein Wort welches ich in keinem Wörterbuch finde: "selbat".
Dann wird es wohl so sein dass der auf dem Bildschirmfoto sichtbare 
farbige "Schnee" dem noch nicht ganz ausgelüfteten Silvesteralkohol zu 
verdanken ist ;-)

Autor: Joerg W. (joergwolfram)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis, ich habe das jetzt korrigiert. Das ist halt der 
Nachteil, wenn der Texteditor zwar Syntax-Highlighting aber keine 
Rechtschreibkorrektur hat...


Ich habe auch ein Keypad auf Basis eines ATMega8 entwickelt, allerdings 
nur auf Lochraster. Inzwischen wird auch eine angeschlossene PS/2 
Tastatur unterstützt, was auch bei 3,3V Versorgung bei mir mit allen 
verfügbaren Tastaturen geklappt hat. Datentransfer habe ich aber nicht 
implementiert. Bei Bedarf kann ich das mit zum Projekt hinzufügen.

Jörg

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wahrscheinlich wird es demnächst eine erweiterte Schaltung geben:

- UART zum Hochladen eines neuen ROM-Images beim Start
- Soft-SPI mit 2 CS-Leitungen


Im Moment bin ich am Überlegen, wie man möglichst simpel ein 
SPI-Interface (via RAM-Zwischensockel in TTL Technik beim 
Original-Gigatron) realisieren könnte. Damit wäre es auch möglich, einen 
Massenspeicher z.B. SD-Karte) zu benutzen und könnte den zweiten CS für 
I/O Erweiterungen nutzen.

https://forum.gigatron.io/viewtopic.php?f=4&t=64

Jörg

Autor: Christoph M. (mchris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den GIGATRON kannte ich noch nicht. Ein sehr schönes Gerät.

Es wäre super, wenn man deinen Emulator auf einem Nucleo- oder 
Discovery-Board laufen lassen könnte. Davon hätte ich noch welche. Wie 
wär's mit einem STM32F411?
Von der Speichergröße müsste eigentlich auch ein Arduino-Due passen.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Der STM43F411 geht leider nicht. Zum Einem hat er zu wenig RAM (128K). 
Da aber sowohl das emulierte RAM als auch das emulierte ROM im 
Controller-RAM liegen müssen, sind mindestens 192K notwendig.
Zum Zweiten liegt die maximale Frequenz beim F411 bei 100MHz. Hier halte 
ich es für fraglich, ob dich der Controller auf 225MHz übertakten lässt.
Da ich selbst keine Nucleo- bzw. Discovery-Boards besitze, kann ich zu 
anderen Boards nichts sagen bzw. müsste mir die ganzen Dokus raussuchen. 
Aber eigentlich sollte alles mit dem F405 / F407 funktionieren, ggf. 
muss halt die PLL an den verwendeten Quarz angepasst werden. Der "Rest" 
ist ja einfaches I/O.

Jörg

Autor: Christoph M. (mchris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antwort.

Du hast Deinen Emulator vollständig in Assembler geschrieben. Ich frage 
mich, ob's auch in C ginge.

Nehmen wir z.B. mal eine ESP32 mit 240MHz. Da hätte man für die 6.25MHz 
ca. 38 Takte. Vielleicht könnte das für die Emulation reichen. 
Vielleicht könnte man dann noch einen Timer benutzen um das Ganze 
zyklengenau hin zu bekommen.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
In C wäre man sowieso auf einen Timer angewiesen, da man anders das 
exakte Timing wohl gar nicht einhalten könnte.

In meinem Programm halte ich alle Informationen in Registern, der 
Emulator selbst benötigt kein RAM. Weil RAM-Zugriffe Zeit kosten. Aus 
diesem Grunde gibt es auch keine zentrale Schleife. Bei einer Umstellung 
auf C ohne manuelle Registeroptimierung würde ich einen 
Geschwindigkeitsverlust von mindestens 30% annehmen.

Jörg

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Nachtrag:

Ich kann ja mal spaßeshalber die gtemu2.c an mein Board anpassen und 
dann die HSYNC Frequenz messen, falls das von Interesse ist.

Spaßeshalber deswegen, weil das Ergebnis absehbar ist...

Um im Timer-Interrupt laufen zu können, darf die C-Version bei gleicher 
Taktfrequenz maximal 15 Clocks je emuliertem Befehl benötigen.
Der Cortex-M4 hat eine Interrupt-Latenz von 12 Takten, für das Verlassen 
der Interrupt-Routine werden nochmal mind. 8 Takte benötigt. Dazu kommt 
die leere main(), die mind. 1 Takt je Durchlauf braucht.

Mein jetziges Programm hat im längsten Zweig genau 1 NOP, braucht also 
maximal 35 Taktzyklen für die Ausführung von einer Gigatron Instruction. 
Wenn ich das auf Interrupt umstellen würde, käme ich auf 35+21 Takte, 
was 350MHz Taktfrequenz entspricht. Wenn ich jetzt noch optimistisch 
annehme, dass ein C-Programm nur 25% ineffizienter als mein ASM Programm 
ist, dann liegt die erforderliche Taktfrequenz schon bei über 400MHz. 
Wahrscheinlich ist es dann schneller, auf Interrupts zu verzichten und 
den Timer in der main zu pollen.

Das mag für die "Der C-Compiler kann das besser optimieren - Fraktion" 
zwar provokant klingen, ich lasse mich aber gern vom Gegenteil 
überzeugen.


Vielleicht geht das ja mit einem STM32H7xx und 400MHz, wer mag, kann es 
ja mal ausprobieren.

Jörg

Autor: Christoph M. (mchris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich kann ja mal spaßeshalber die gtemu2.c an mein Board anpassen und
>dann die HSYNC Frequenz messen, falls das von Interesse ist.

>Spaßeshalber deswegen, weil das Ergebnis absehbar ist...

Es wäre schon interessant, in welcher "Preisklasse" man da so liegt.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe gemessen und bin etwas überrascht. Daher will ich das 
Ergebnis noch mit anderen Einstellungen verifizieren. Inzwischen können 
Schätzungen abgegeben werden, um wie viel der "offizielle" C-Emulator 
(gtemu2.c) langsamer ist, als die ASM Variante.

Jörg

Autor: Christoph M. (mchris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schätze mal: Faktor 5 langsamer ...

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Naja, da kommt schon recht nahe ran.

Mit den "optimalen" Einstellungen (-O3) komme ich auf ca. 7KHz 
HSYNC-Frequenz, was durchschnittlich 161 Clocks je Gigatron-Instruction 
und einen Faktor von ca. 4,5 bedeutet. Allerdings jittert das Signal 
stark. Da die erreichbare Frequenz vom Befehl mit der längsten 
Ausführungszeit abhängt, würde ich 10% draufschlagen, das wären dann 177 
Clocks. Dazu kommen noch die 21 Clocks für das INT-Handling und wir sind 
schon bei 198 Clocks.

Und... 198 Clocks * 6,25 MHz ergeben stattliche 1,23 GHz notwendige 
Taktfrequenz!

Der Code ist zwar sehr übersichtlich, aber nicht sonderlich effizient. 
Mit etwas Optimierung habe ich die C-Variante auf ca. 96 Clocks pro 
Gigatron-Instruction gebracht, das wären dann min. 127 Clocks, was 
ungefähr 790 MHz Taktfrequenz bedeutet. Mit einem RasPi sollte das zu 
schaffen sein ;-).

Ich denke, damit können wir das Thema "C-Variante" getrost zu den Akten 
legen. Mit meinen 25% Overhead für C lag ich voll daneben, es sind 
günstigenfalls ca. 250%.

Ich habe mir mal die Belegung vom STM32F407 Discovery angeschaut. Wenn 
man die Peripherie stilllegen kann und den Quarz tauscht, sollte es 
gehen. Andernfalls ließe sich das Ganze auch auf 8 oder 16MHz 
Quarzfrequenz umstricken. Das Projekt ist ja Open Source.

Aber ich kann mir auch manchmal nicht den Gedanken verwehren, dass viele 
Leute sich irgendwelche STM32-Boards gekauft haben, weil es gerade 
"hipp" ist und jetzt darauf warten, dass jemand eine sinnvolle Anwendung 
dafür programmiert.

Jörg

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guck Dir mal das Disassembly genauer an. Es ist nicht der RAM-Zugriff, 
der langsam ist, weil das onchip-RAM keine Waitstates braucht. Aber 
Cortex-M hat einen load/store-Befehlssatz.

Wenn Du in Assembler alles in Registern halten kannst, braucht eine 
Wertemodifikation wie etwa ein & mit einer Konstanten nur einen Befehl.

Wenn der Compiler die Register nicht optimal verwaltet, dann braucht er 
einen Befehl zum Laden, einen zur Modifikation und einen zum 
Wegspeichern. Das wäre ein Faktor von 3. Manchmal geht es doch, deswegen 
"nur" 2.5. -O3 ist übrigens nicht unbedingt am schnellsten.

Besonders katastrophal kann es bei globalen Variablen werden, weil er 
die nicht über den Stackpointer nebst Offset lädt. Dann hat man nämlich 
u.U. noch einen Befehl mehr, weil er die 32-Bit-Adresse der Variablen 
mit zwei Befehlen lädt, mov und movt.

So ein Interpreter hat typisch irgendeine Art von switch-case, und hier 
ist die Frage, ob das so gemacht ist, daß der Compiler das als jump 
table umsetzt - schlimmstenfalls macht er das als if/elseif/else-Kette. 
Eine jump table kann man jedenfalls beim GCC aber auch mit computed goto 
erzwingen, einer GCC-Erweiterung.

Autor: Joerg W. (joergwolfram)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn Du in Assembler alles in Registern halten kannst, braucht eine
> Wertemodifikation wie etwa ein & mit einer Konstanten nur einen Befehl.

Deswegen ist auch alles in Registern. Ebenso wie ich die Pipeline durch 
die Struktur meines ASM Programms emuliere, ohne zusätzliche Takte zu 
verbrauchen. Dafür muss ich ohne Cache leben und ca. 5-8 Wait-States je 
Befehl. Die Optimierungsstufe -O3 war halt die schnellste Variante, 
wobei ich -O1 und -O0 nicht getestet habe.

Da ich ja eine funktionierende ASM-Version habe, werde ich mich mit der 
weiteren Optimierung des C-Codes eher nicht beschäftigen. Die Messungen 
sind für mich eigentlich nur eine Bestätigung dafür, dass die 
Entscheidung für ASM richtig war.

Falls jemand weitermachen will, meinen minimalistischen Testcode stelle 
ich hiermit zur Verfügung.

Jörg

Autor: Christoph M. (mchris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Falls jemand weitermachen will, meinen minimalistischen Testcode stelle
>ich hiermit zur Verfügung.

Danke für das Beispiel.

>Und... 198 Clocks * 6,25 MHz ergeben stattliche 1,23 GHz notwendige
>Taktfrequenz!

>Der Code ist zwar sehr übersichtlich, aber nicht sonderlich effizient.
>Mit etwas Optimierung habe ich die C-Variante auf ca. 96 Clocks pro
>Gigatron-Instruction gebracht, das wären dann min. 127 Clocks, was
>ungefähr 790 MHz Taktfrequenz bedeutet. Mit einem RasPi sollte das zu
>schaffen sein ;-).

Die Frage ist, ob der Raspi aus Echtzeitsicht geeignet wäre.

Es ist schon interessant zu sehen, welche großen Unterschiede es 
zwischen der Assmbler- und der C-Version gibt. Faktor 4.5 .... !

> Dazu kommen noch die 21 Clocks für das INT-Handling und wir sind
schon bei 198 Clocks.

Eine Interrupt bräuchte man meiner Meinung nach nicht, weil das System 
konstant laufen soll, könnte man das auch per Timer-Polling erledigen.

Hier gibt es ja das Projekt AVR CP/M, bei dem mit einigen Tricks 
erreicht wurde, dass der AVR einen Z80 emuliert. Da würde man ja denken, 
dass man die paar TTL-ICs des Gigatron locker auf einem 160MHz ARM 
emulieren kann.

https://www.mikrocontroller.net/articles/AVR_CP/M

Die Frage wäre, ob es noch Optimierungsmöglichkeiten für den CPU-Code 
gibt:
CpuState cpuCycle(const CpuState S)
{
  CpuState T = S; // New state is old state unless something changes

  T.IR = rom_data[pc][0]; // Instruction Fetch
  T.D  = rom_data[pc][1];

  int ins = S.IR >> 5;       // Instruction
  int mod = (S.IR >> 2) & 7; // Addressing mode (or condition)
  int bus = S.IR&3;          // Busmode
  int W = (ins == 6);        // Write instruction?
  int J = (ins == 7);        // Jump instruction?

  uint8_t lo=S.D, hi=0, *to=NULL; // Mode Decoder
  int incX=0;
  if (!J)
    switch (mod) {
      #define E(p) (W?0:p) // Disable AC and OUT loading during sim_ram write
      case 0: to=E(&acc);                          break;
      case 1: to=E(&acc); lo=rx;                  break;
      case 2: to=E(&acc);         hi=ry;          break;
      case 3: to=E(&acc); lo=rx; hi=ry;          break;
      case 4: to=  ℞                            break;
      case 5: to=  &ry;                            break;
      case 6: to=E(&io_out);                         break;
      case 7: to=E(&io_out); lo=rx; hi=ry; incX=1; break;
    }

  uint16_t addr = (hi << 8) | lo;

  int B = 0xff; // Data Bus
  switch (bus) {
    case 0: B=S.D;                        break;
    case 1: if (!W) B = sim_ram[addr&0x7fff]; break;
    case 2: B=acc;                       break;
    case 3: B=io_in;                         break;
  }

  if (W) sim_ram[addr&0x7fff] = B; // Random Access Memory

  uint8_t ALU; // Arithmetic and Logic Unit

  switch (ins) {
    case 0: ALU =        B; break; // LD
    case 1: ALU = acc & B; break; // ANDA
    case 2: ALU = acc | B; break; // ORA
    case 3: ALU = acc ^ B; break; // XORA
    case 4: ALU = acc + B; break; // ADDA
    case 5: ALU = acc - B; break; // SUBA
    case 6: ALU = acc;     break; // ST
    case 7: ALU = -acc;    break; // Bcc/JMP
  }

  if (to) *to = ALU; // Load value into register
  if (incX) rx = rx + 1; // Increment X

  pc = pc + 1; // Next instruction
  if (J) {
    if (mod != 0) { // Conditional branch within page
      int cond = (acc>>7) + 2*(acc==0);
      if (mod & (1 << cond)) // 74153
        pc = (pc & 0xff00) | B;
    } else
      pc = (ry << 8) | B; // Unconditional far jump
  }
  return T;
}


: Bearbeitet durch User
Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die Frage wäre, ob es noch Optimierungsmöglichkeiten für den CPU-Code
> gibt:

Natürlich gibt es die: Alle 256 Befehle in einer case-Tabelle 
ausdekodieren. Die ganze Bitschieberei ist auf dem ARM gegenüber z.B. 
AVR schon wesentlich effizienter geworden, aber richtig effizient für 
Sprungtabellen ist das meiner Meinung nach nur auf den PowerPC 
Controllern (z.B. rlwinm).

Natürlich könnte man auch den Timer pollen, aber das dauert auch ein 
paar Takte (Timerwert lesen, vergleichen, ggf. zurückspringen). Den 
dadurch entstehenden Jitter wird man auch nicht bemerken.

Wesentlich interessanter finde ich, das Konzept weiterzudenken. 
Theoretisch sollte es möglich sein, 640x480 in 4 aus 64/256 Farben 
darzustellen oder 320x240 in 16 aus 64/256 Farben auf 2 Pages oder 
320x240 in 64/256 Farben. Dazu noch einen virtuellen 16-Bit Prozessor 
mit ein paar Registern, der zudem FP beherrscht und z.B PLOT gleich mit 
im Befehlssatz hat...

Oder einen emulierten Z80 um CP/M darauf laufen zu lassen.Oder man 
könnte einen PDP11-Emulator nebst Video-Terminal in einem Chip haben. 
Auf jeden Fall scheint es mir lohnenswert, über größere ASM-Projekte auf 
diesen Controllern nachzudenken.

Jörg

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:

> Natürlich gibt es die: Alle 256 Befehle in einer case-Tabelle
> ausdekodieren.

Und zwar gleich mit Label-Adressen in dieser Tabelle und computed goto.

Ach ja, und außerdem sollte man auch dcache/icache aktivieren, da man in 
C sowieso das Timing nicht über die Befehle machen kann. Dann hat man 
nämlich meistens einen effektiven 0-Waitstate-Betrieb, was bei 168 MHz 
einem Faktor 5 entspricht.

Autor: Christoph M. (mchris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>dcache/icache aktivieren,

Kannst Du da mal ein Codeschnipsel zeigen?

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph M. schrieb:
>>dcache/icache aktivieren,
>
> Kannst Du da mal ein Codeschnipsel zeigen?

Ah das ist einfach: Du setzt ja im Flash_ACR eh schon die Waitstates in 
den Bits 0-3. Da mußt Du dann bloß noch gleichzeitig die Bits 8-10 auf 1 
setzen. Siehe Refman, Kapital 3.9.2.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Korrektur, Kapitel 3.9.1 für F405, 3.9.2 wäre für F42/43, und die 
Waitstates sind dann in den Bits 0-2. Der Rest stimmt aber.

Man kann außerdem dem GCC noch den Parameter -mslow-flash-data mitgeben, 
dann weiß er, daß Datenzugriffe aus dem Flash langsamer sein können. Mit 
-mcpu=cortex-m4 -mtune=cortex-m4 kann man vielleicht auch noch einen 
Tick rausholen.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und zwar gleich mit Label-Adressen in dieser Tabelle und computed goto.

So etwas mache ich ja auch bei meiner Variante, nur dass ich mir die 
Tabelle spare, indem alle Befehlsvarianten ein 256Byte Alignment haben. 
Dann muss ich nur noch nach (Befehlswort & 0xFF00) + Basisiadresse 
springen, wobei die Basisadresse+1 schon in einem Register (r14) liegt:
    and.w r2,r7,0xFF00
    add   r2,r14
    bx    r2

Das steht am Ende jeder Befehlsausführung, es gibt keine zentrale 
Schleife. Man könnte es eher mit einer Zustandsmaschine vergleichen, bei 
der die Bits 8-16 des PC (r15) den aktuellen Zustand verkörpern.


> was bei 168 MHz einem Faktor 5 entspricht.

Das ist Wunschdenken.
Das Flash ist mit 128 Bits an das Flash-Interface angebunden, ein 
weiterer Zugriff innerhalb dieser 16 Bytes erzeugt keine Waitstates. Aus 
diesem Grund liegt das emulierte ROM bei meinem Emulator auch im RAM. 
Weil dort die Zugriffszeit konstant ist und nicht von der Adresse des 
letzten Zugriffs abhängt. In einer früheren Version hatte ich den 
Emulatorcode im RAM und das ROM im Flash, damit war ein stabiles Timing 
nicht möglich. Mit einem zwischenzeitlichen Zugriff auf eine Adresse 
außerhalb des emulierten ROMs (nach jedem Befehl) war es dann zwar 
stabil, aber halt zu langsam.

Zum Zweiten werden Prefetch/Dcache/Icache beim Programmstart des 
C-Programmes eingeschaltet (via unilib_init). Einen weiteren Test mit 
ausgeschaltetem Cache erspare ich mir aber, da er das Ergebnis 
sicherlich nicht verbessern würde. In meinem ASM-Code schalte ich 
übrigens nur den Prefetch an.

Jörg

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja in C wird das schön langsam.
Der MIPS TTL existiert auch als selbstgestrickter Emulator in C.
Da hab ich nicht einfach ein mips qemu genommen, weil das Exception/IRQ 
System völlig anders ist.
Da wars einfacher/schneller das selber zu bauen als qemu SOurcen zu 
verstehen und dann umzubauen.
Zudem konnte ich mir so auch das Speichersystem so bauen, dass sich die 
Peripherie auch besser mitsimulieren lässt.

Aber wie langsam ist das denn jetzt?
Der MIPS TTL läuft als Multicycle Maschine mit 4MHz.
Auf einem i5-2500k läuft die Emulation nur ~50% schneller als ie echte 
Hardware!
http://www.fritzler-avr.de/spaceage2/gallery/main.php?cmd=imageview&var1=Emulator%2Fmipsemu.png

Da ich weis was das für eine Arbeit ist:
Hut ab vor Joerg ;)

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.

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