mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik schneller als 20MHz - was nehmen? PC oder ARM?


Autor: devBoard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich bastele viel mit ATMega's. Bei manchen Projekten sind die 20MHz zu 
wenig, also orientiert man sich nach oben:

XMegas oder ARMs: Da brauche ich neue Programmer, Dev.-Boards etc.

Also warum nicht güstige PC-Mainboards mit mini-minimalkonfiguration und 
ein mini-Linux? So Tastaturen und Monitor hat man sowieso..

Mir geht es echt um die Kosten so als Bastler. Mir ist schon klar, daß 
ein Mainboard mehr Platz braucht und für die eine Serienfertigung 
wahrscheinlich viel teurer ist als ein einzelner Chip, der die spezielle 
Aufgabe auch kann, aber als Bastler von Unikaten stört das nicht.

Als Beispiel (Audio): angenommen, ich möchte 6 Spuren Stereo-PCM mit je 
16 bit aufnehmen - die Datenrate dafür schafft auch kein XMega mehr und 
keine sd oder cf-Karte...

Also ARM/ mehrere parallel / mit mehreren Karten oder gleich einen 
"quasi-PC" nehmen? Was sind die Vor- und Nachteile, was meint Ihr? Was 
gibt es so für Mini-PCs, die Ihr gerne nutzt?

Autor: Rene Schube (Firma: BfEHS) (rschube)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo devBoard,

also von der Rechenpower ist die PC basierte Variante wohl die bessere. 
Wenn es dir aber wie bei einem µC auf die I/O's ankommt ist das 
natürlich etwas anderes. Bei der PC Schiene hat man einiges an Overhead 
dabei und muss sich mit Dingen aus dem OS rumschlagen. Da ist es oft 
auch egal ob Linux, Windows oder DOS. API's, Kernel und Prozesse 
managen...

Die Entscheidung sollte man von genauen Anwendungsfall abhängig machen. 
Ich selbst hab immer noch etliches von der alten PC-Hardware am laufen. 
Und selbst mit FreeDOS kann man einige sehr schöne Dinge, schnell und 
effizient bearbeiten. Dazu hat man noch 'unmengen' an Speicher der 
unterschiedlichen Arten zur Verfügung. Zusatzhardware wie Sound, Grafik, 
Netzwerk und Massenspeicher etc.

Spricht also einiges dafür und auch etwas dagegen, wie auch immer. Ich 
würde diese Aufgabe erstmal mit einer PC Lösung angehen. Als OS dann 
FreeDOS oder Linux wählen.

Viel Erfolg
Rene

Autor: devBoard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am PC stört mich halt, daß irgendwelche Prozesse "dazwischenfunken" 
(Mausinterrupt, System-Timer oder was weiß ich noch) könnten.. beim uC 
finde ich, ich das Zeitverhalten besser vorhersagbar/kontrollierbar.

Autor: Rene Schube (Firma: BfEHS) (rschube)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, in den 'guten alten' Zeiten von DOS hat man das mit dem 
dazwischen funken noch ordentlich in den Griff bekommen. Die Probleme 
kammen ja erst später ;-)

Schon klar, wenn du kein OS auf deinem System hast, hast du auch keinen 
Stress damit. Allerdings must du dann auch alles selber bauen und 
managen. Und das könnte ganz schön stressig werden.

Ist aber auf jeden Fall ein ?fauler? Kompromiss. Der Aufwand dürfte aber 
auf der PC-Schiene erstmal geringer sein. Freie, kostenlose Compiler, 
Debugger und Trace-Tools etc. Viel Doku und natürlich die Hardware.

Nimm erstmal ein altes Mainboard mit ein bisschen gedoens drum herum. 
Später kann das auf ein schönes Embedded-PC Modul (z.Bsp.: Pep Modular 
Computers GmbH) drauf. Ich arbeite mit mehreren 'alten' CP30x. Hab damit 
sehr gute Erfahrungen gemacht.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Am PC stört mich halt, daß irgendwelche Prozesse "dazwischenfunken"
> (Mausinterrupt, System-Timer oder was weiß ich noch) könnten..

Was hindert dich daran dein Programm von DOS zu starten und dann alles 
abzuschalten? Oder ein eigenes Betriebsystem zu schreiben?
Ich meine das muesstest du doch bei einer eigenen Hardware auch machen.

Ein PC-Board will man normalerweise nicht nehmen weil es gross ist, 
einen Luefter auf der CPU hat, von irgendwas booten muss, ein fettes 
Netzteil braucht und du erstmal keine IO-Leitungen hast um etwas 
anzuschliessen.

Evenutell kann es sinnvoll sein sich einen PDA zu besorgen und denn zu 
nutzen. Die bekommt man doch nachgeworfen. Es haengt aber auch da viel 
davon ab wie man an IO-Leitungen fuer eigene Hardware kommt.

Olaf

Autor: devBoard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht geht es ja auch so: Ich schalte im BIOS alle Störenfriede aus 
und lasse den "PC" von einer SD-Karte "booten" - dorthin tue ich dann 
auch mein Anwendungsprogramm - dann könnte ich das doch direkt laufen 
lassen, ganz ohne OS, oder? Müßte mir natürlich alle I/O-Zugriffe selber 
organisieren..

Gibt es solche Ansätze / Entwicklerprojekte?

Autor: Stefan Kunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn du nach solwas suchst guck dir das Beagle-Board an, der Prozessor 
dürfte schnell genug sein und mit QNX (für Hobbyanwender erstmal 
kostenlos) hast du ein gutes Betriebssystem.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
devBoard schrieb:
> Hallo Leute,
>
> ich bastele viel mit ATMega's. Bei manchen Projekten sind die 20MHz zu
> wenig, also orientiert man sich nach oben:
>
> XMegas oder ARMs: Da brauche ich neue Programmer, Dev.-Boards etc.
>
> Also warum nicht güstige PC-Mainboards mit mini-minimalkonfiguration und
> ein mini-Linux? So Tastaturen und Monitor hat man sowieso..
>
> Mir geht es echt um die Kosten so als Bastler. Mir ist schon klar, daß
> ein Mainboard mehr Platz braucht und für die eine Serienfertigung
> wahrscheinlich viel teurer ist als ein einzelner Chip, der die spezielle
> Aufgabe auch kann, aber als Bastler von Unikaten stört das nicht.
>
> Als Beispiel (Audio): angenommen, ich möchte 6 Spuren Stereo-PCM mit je
> 16 bit aufnehmen - die Datenrate dafür schafft auch kein XMega mehr und
> keine sd oder cf-Karte...

6  2  16-Bit * 48000 Hz = 1.152 MByte/s
Ginge also mit jeder SD und CF-Karte (teilweise werden bei CF >50 
MBytes/s dauerhafte Schreibleistung garantiert (und eingehalten)) und 
jedem XMega (das Teil läuft mit 32 MHz und hat einen DMA-Controller, ihm 
fehlt I2S o.ä. damit es wirklich einfach wäre)

> Also ARM/ mehrere parallel / mit mehreren Karten oder gleich einen
> "quasi-PC" nehmen? Was sind die Vor- und Nachteile, was meint Ihr? Was
> gibt es so für Mini-PCs, die Ihr gerne nutzt?

Für sowas, gar keinen. Ansonsten gibt's haufenweise Mini-ITX, PC/104-PCs 
mit allen möglichen CPUs, Speicher, Grafik, Netzwerk-Kombinationen 
(könnte allerdings schwer werden, ein Mainboard in der Größe mit mehr 
als zwei Audio-Eingängen zu finden). Ob das ganze dann noch günstiger 
ist als bspw ein Zoom R16 oder ein entsprechend aufgerüstetes Netbook, 
dürfte fraglich sein.

Autor: Rene Schube (Firma: BfEHS) (rschube)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, das dürfte dann etwas schwierig werden;

devBoard schrieb:
> Vielleicht geht es ja auch so: Ich schalte im BIOS alle Störenfriede aus
> und lasse den "PC" von einer SD-Karte "booten" - dorthin tue ich dann
> auch mein Anwendungsprogramm - dann könnte ich das doch direkt laufen
> lassen, ganz ohne OS, oder? Müßte mir natürlich alle I/O-Zugriffe selber
> organisieren..

Wenn du alle Störenfriede deaktivierst, z.Bsp. System-Timer wirst du 
nicht weit kommen.

Was willst du von SD-Card booten wenn du kein OS drauf haben willst?

Und alle I/O's selber organisieren??? Bei Audio mit mehreren Spuren und 
schnellem Datentransfer? Das wird echter Stress.

Guck mal bei http://kontron.de die Embedded-Module. Da hast du fast 
alles selber in der Hand, ein schlankes OS (wieder ein DOS) drauf und 
los gehts.

mfg Rene

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Selbst wenn man PC-Hardware ohne Betriebssystem laufen lässt, ist sie 
aufgrund ihrer Architektur für viele Aufgaben ungeeignet. Trotz des sehr 
hohen Systemtakts sind an den einfach zugänglichen I/O-Schnittstellen 
keine besonders hohen Datendurchsätze zu erzielen; per Bit-Banging kann 
ein PC trotz etlicher GHz Systemtakt auf dem Parallelport bestenfalls 
mit 1 bis 2 MHz herummachen. Das liegt an der Systemgeschichte, die den 
mit Resten des ISA-Busses ansteuert.

Der Anschluss ernster gemeinter Peripherie über Schnittstellen wie I2C 
oder SPI scheitert bereits an diesem Problem.

Also müsste man anfangen, PCI-Karten für derlei Anforderungen zu bauen, 
aber das ist nichttrivial.

So aber kann PC-Hardware schön schnell rechnen, aber sie kann Daten nur 
sehr eingeschränkt übertragen oder empfangen, geschweige denn schnell 
auf externe Ereignisse reagieren, weil die Schnittstellen fehlen und nur 
sehr aufwendig nachzurüsten sind.

Hinzu kommt, daß PC-Hardware im Stromverbrauch gleich mehrere 
Größenordnungen oberhalb von sonstiger Embedded-Controller-Hardware 
liegt.

Autor: devBoard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Arc Net

man braucht aber schon ein bischen RAM, der auch noch schnell sein 
sollte, weil man diese Geschwindigkeiten ja nicht kontinuierlich auf die 
Karte schreiben kann. Dateisystem soll wahrscheinlich auch noch dabei 
sein.. also ganz so banal ist das nicht. war ja auch nur ein Besispiel.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eh ich es vergesse...ich hab mir fuer aehnliche Ideen einen Chumby One 
gekauft. (liegt noch beim Zoll ARGH!)

Man bekommt fuer sehr wenig Geld einen schnellen ARM-Rechner mit 
Gehaeuse und LCD. Es gibt bereits ein angepasstes Linux und die Hardware 
ist auch gut dokumentiert. Man muss nur den hirntoten Flashkram loeschen 
und kann loslegen.

Olaf

Autor: devBoard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rene Schube schrieb:
> Was willst du von SD-Card booten wenn du kein OS drauf haben willst?

Na den Boot-Lader im MBR schreibe ich schon noch drauf.. und dann 
"boote" ich diesen sozusagen als mein Programm.

dachte ich.. :-)

Autor: devBoard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Eh ich es vergesse...ich hab mir fuer aehnliche Ideen einen Chumby One
> gekauft. (liegt noch beim Zoll ARGH!)

Das ist ja mal eine Idee! Sozusagen eine ARM-Entwicklungsumgebung 
komplett für 119 Dollar..

Wo ist der dokumentiert? (Ich hab jetzt die Seite nicht so intensiv 
umgegraben..)

Autor: devBoard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry, schon gefunden im Wiki.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das ist ja mal eine Idee! Sozusagen eine ARM-Entwicklungsumgebung
> komplett für 119 Dollar..

Vor allem fuer deine Anwendung. Du steckst da einfach eine 
USB-Soundkarte rein und hast deine Ein/Ausgaenge. Treiber bringt Linux 
mit. Ausserdem gibt es fuer Linux einige recht schlichte Anwendungen 
fuer die Textoberflaeche welche mit der Soundkarte arbeiten. Da sollte 
man relativ schnell was eigenes auf die Beine stellen koennen.

Ich habe auch gelesen das jemand dafuer bereits Qt laufen hat und 
Geruechte ueber Android gibt es auch.

Einziger Nachteil, ich musste 4Wochen warten weil er ausverkauft war, 
und jetzt ist der schon wieder ausverkauft.

Vermutlich sitzt der Entwickler bereits in einer Badewanne, kichert irre 
und badet in Dollar weil die Idee die Entwicklungsunterlagen 
bereitzustellen offenbar sehr gut angekommen ist.

Olaf

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Vermutlich sitzt der Entwickler bereits in einer Badewanne, kichert irre
> und badet in Dollar weil die Idee die Entwicklungsunterlagen
> bereitzustellen offenbar sehr gut angekommen ist.

Zu Recht, wie ich finde.  :-)

Habe den Chumby bis eben nicht gekannt und bin hellauf begeistert. Werde 
mir das Teil bestellen, wenn es jemals wieder auf Lager sein sollte.

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alternativ kannst du dir mal das mini2440 und das micro2440 ansehen. 
Kosten auch nicht viel (besonders wenn man es importiert), hat mehr 
Schnittstellen on board aber dafür kein WLAN.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
devBoard schrieb:
> angenommen, ich möchte 6 Spuren Stereo-PCM mit je
> 16 bit aufnehmen - die Datenrate dafür schafft auch kein XMega mehr und
> keine sd oder cf-Karte...

Ich habe momentan ein ähnliches Projekt in Planung:
8 Monokanäle mit 192kHz und 24Bit, welche seriell ankommen (TDM), auf 
eine CF-Karte schreiben (Wurde hier ja schon erwähnt, daß das locker 
klappt), zur selben Zeit aber auch von der selben CF-Karte nochmal die 
selbe Menge an Daten lesen und wieder via TDM auszugeben. Desweiteren 
wäre die Möglichkeit, die gelesenen Daten mit den empfangenen Daten zu 
vermischen (keine Addition, nur einzelne Kanäle anstelle empfangener 
Kanäle verwenden)

Eine zufriedenstellende Lösung habe ich noch nicht. Ein PC ist dafür 
allerdings zu groß - auch was den Stromverbrauch angeht.
Derzeit hat dieses Projekt aber auch keine Priorität, weshalb ich im 
Moment auch nicht weiter suche. Von Deinen Erfahrungen zu hören, würde 
mich aber freuen!


Gruß

Jobst

Autor: Ephraim Hahn (ephi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
evtl ein kleines FPGA. Das hat dann auch noch Leistungskapazitäten die 
Signale bei bedarf zu bearbeiten.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FPGAs habe ich auch schon gesucht, habe aber kein passendes gefunden.

Voraussetzungen wären:
- Kein BGA-Gehäuse o.ä., max. QFP144 (0.5mm Raster)
- >2kB RAM
- Offene Dokumentation des Programmdatenstroms

Sehr viel habe ich mich mit den Dingern noch nicht auseinandergesetzt, 
aber das sind die Punkte, wo ich immer angeeckt bin. Evtl. hat ja jemand 
einen Tip.


Gruß

Jobst

Autor: devBoard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur weil hier immer wieder behauptet wird, das geht "mal locker so 
nebenbei", mußt Du das trotzdem erst mal schaffen, diese Datenrate auch 
zu schreiben und gleichzeitig zu lesen auf SD oder CF.. also erstmal 
vorzeigen, dann auf cool machen..

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Och, da kann ich cool bleiben. Da habe ich schon einige Jährchen an 
Erfahrung. Vorzeigen brauche ich das auch nicht, ich weiß was ich kann. 
Wenn mir das wer nicht glaubt, dann ist das sein Problem, nicht meins.


Gruß

Jobst

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Jobst M. (jobstens-de)

>8 Monokanäle mit 192kHz und 24Bit, welche seriell ankommen (TDM), auf
>eine CF-Karte schreiben (Wurde hier ja schon erwähnt, daß das locker

Macht 8x192kx3 = 4,6 MByte/s. Not bad.

>klappt), zur selben Zeit aber auch von der selben CF-Karte nochmal die
>selbe Menge an Daten lesen und wieder via TDM auszugeben.

Macht in Summe ~9 Mbyte/s. Sportlich, aber machbar denke ich. Das auf 
nehmen und ausgeben ist für ein FPGA ein Klacks.

> Desweiteren
>wäre die Möglichkeit, die gelesenen Daten mit den empfangenen Daten zu
>vermischen (keine Addition, nur einzelne Kanäle anstelle empfangener
>Kanäle verwenden)

Trivial.

>Eine zufriedenstellende Lösung habe ich noch nicht. Ein PC ist dafür
>allerdings zu groß - auch was den Stromverbrauch angeht.

FPGA, selbst die kleinsten Spartan3 reichen.

>FPGAs habe ich auch schon gesucht, habe aber kein passendes gefunden.

>Voraussetzungen wären:
>- Kein BGA-Gehäuse o.ä., max. QFP144 (0.5mm Raster)
>- >2kB RAM

Hat jeder Spartan3 (Xilinx) oder Cyclone I oder II (Altera)

>-> Offene Dokumentation des Programmdatenstroms

Wirst du von keinem Hersteller bekommen. Ist auch vollkommen 
uninterresant.

MFG
Falk

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
>>-> Offene Dokumentation des Programmdatenstroms
>
> Wirst du von keinem Hersteller bekommen. Ist auch vollkommen
> uninterresant

Finde ich etwas arm, daß das so ist. Aber es ist absolutes 
Ausschlusskriterium. Wieso das uninteressant sein soll, ist mir ein 
Rätsel. Nur weil es ohne Kenntnis auch funktioniert, ist für mich noch 
lange kein Argument.


Gruß

Jobst

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was willst du denn mit der Information anfangen? Die braeuchte man doch 
nur wenn man selber einen Verilog-Compiler fuer sein FPGA schreiben 
wollte.

Olaf

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Was willst du denn mit der Information anfangen? Die braeuchte man doch
> nur wenn man selber einen Verilog-Compiler fuer sein FPGA schreiben
> wollte.
>
> Olaf

Vielleicht.

Vielleicht soll es ja auch gar kein Verilog sein.

Vielleicht will ich die Möglichkeit haben, den Datenstrom von einem uC 
selber erstellen zu lassen.

Aber auf jeden Fall will ich wissen, wie das Teil funktioniert - und 
zwar komplett.
Und geschlossene Funktionsprinzipien möchte ich in meinen Schaltungen 
einfach nicht haben.


Gruß

Jobst

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jobst M. (jobstens-de)

>Vielleicht will ich die Möglichkeit haben, den Datenstrom von einem uC
>selber erstellen zu lassen.

[ ] Du hast auch nur ansatzweise eine Vorstellung, wie komplex und 
umfangreich so ein Datenstrom und dessen Erzeugung ist.

>Aber auf jeden Fall will ich wissen, wie das Teil funktioniert - und
>zwar komplett.

Sicher, du kaufst auch nur ein Auto, das bis in die letzte Schaube 
dokumentiert ist.
Und du kaufst nur ein Essen im Restaurant, wenn der Chefkoch dir jede 
Zutat haarklein erklärt.

>Und geschlossene Funktionsprinzipien möchte ich in meinen Schaltungen
>einfach nicht haben.

Dream on. Perfektionist.

http://de.wikipedia.org/wiki/Perfektionismus_%28Ps...

MfG
Falk

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich konstruiere keine Autos und bin auch kein Koch. Du vermischst gerade 
Entwicklung und Anwendung.
Das der Datenstrom umfangreich und komplex ist, ist mir bewusst. Das 
stört mich aber im Gegensatz zu Dir nicht.

> http://de.wikipedia.org/wiki/Perfektionismus_%28Ps...

Das sehe ich erst einmal als Kompliment. :-)


Gruß

Jobst

Autor: T. C. (tripplex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob das ein Kompliment war ist eher zu bezweifeln.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pascal L. schrieb:
> Ob das ein Kompliment war ist eher zu bezweifeln.

Das ist mir schon klar ... ;-)
Macht aber nix ...


Gruß

Jobst

Autor: Michael H. (overthere)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte mal eine ganz andere Lösung vorschlagen. Schau dir zum 
Beispiel mal den Mega168 an, versorge den gut mit 5 Volt und lege 24 Mhz 
an. Das geht laut Datenblatt gut.
Dann versuchst du dich hochzutasten, ich schätze mal bis 30 Mhz wirst du 
mit einem externen treibenden Quarzoszillator kommen. Vorsaussetzung ist 
ultrastabile Spannungsvorsorung, massig Abbblockkondensatoren.
Wenn das nicht mehr reicht, erstmal Quellcode optimieren, notfalls mit 
inline ASM.
Wenn das jetzt nicht mehr reicht, schauste dir mal die AVR32 series an. 
Da biste dann gleich bei 200 MHz gut unterwegs. Aber das würde ich nur 
als Notlösung in Betracht ziehen.

Autor: devBoard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bis 30 MHz? meinst Du? Hat das jemand mal getestet, wie schnell man mit 
externem Takt kommt?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kommt drauf an, welche Komponenten man benutzen will. Das EEPROM 
gibt soweit ich weiß als erstes auf.

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.