www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CAN-Bus umschalten, aber wie? (analog switch möglich?)


Autor: Sven H. (dsb_sven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

So einen ähnlichen Thread gabs schonmal hier: 
Beitrag "Multiplexer für CAN-Bus"

Aber da ganz unten steht:

>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.


Also hier die Frage:

Ich will einen CAN-Bus (eigentlich zwei, aber das tut nichts zur Sache) 
zwischen mehreren Leitungen umschalten, will aber auf keinen Fall Relais 
verwenden. Das Umschalten soll natürlich per Software geschehen.

Was für Möglichkeiten hab ich da? Analogschalter vielleicht? Wie siehts 
da mit Strom aus? Digital wirds nicht gehn, da die Spannungen beim 
CAN-Bus ja um 2,5V liegen. (Wie CAN funktioniert weiß ich schon, also 
dazu bitte keine Erklärungen)

Zusätzliche Infos:

CAN Tranceiver: TJA1040
Baudrate: 1Mbit/s
Maximale Anzahl Busteilnehmer: 110 (Aus dem Datasheet vom TJA1040, 
werden whs nur so um 30 bis 40 aber vorsehen will ichs trotzdem)

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An jeder Leitung einen TJA1040 und dahinter einen Multiplexer zum 
Controller.
Das mit dem Analogschalter wird so  wahrscheinlich nicht funktionieren 
weil die zu hochohmig sind. Was spricht gegen Relais ?

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du es so machen möchtest, würde ich Dir unbedingt ein Multiplexing 
hinter dem Transceiver anraten, d.h. auf der TTL-Ebene. Das ist dann ja 
relativ einfach mit Logikgattern bzw. Analogschaltern zu realisieren.

Analogschalter auf der physikalischen Busebene (d.h. vor dem 
Transceiver) müssten immer gewisse Störfestigkeiten aufweisen und die 
gleichen Common-Mode Eigenschaften wie der Transceiver-Baustein 
aufweisen. Außerhalb des Labortisches würde ich das auf keinen Fall mit 
Analogschaltern o.ä. machen. Höchstens mit Relais, aber das scheidet ja 
aus.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man denn die Notwendigkeit der Umschaltung nicht durch geeignete 
Adressierung vermeiden?

Wenn man Tranceiver verwendet, um die Pegel auf CMOS zu bekommen, sollte 
eine Umschaltung kein Probkem sein.

Warum sollen eigentlich keine Relais verwendet werden?

Grüße,

Peter

Autor: Sven H. (dsb_sven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Problem bei der Lösung mit den mehreren Tranceivern ist, dass ich dann 
statt zwei Tranceiver 14 Tranceiver benötigen würde.

Umschalten mit Relais fällt aus dem selben Grund flach --> 14 Relais.

Zur Notwendigkeit des Umschaltens:

Wir entwickeln zur Zeit ein System, das intern über 7 CAN-Bus-Systeme 
kommunizier. Sieben weil so zum einen mehr Datenrate zur Verfügung steht 
und zum anderen die Bussysteme nach Funktionsbereichen der einzelnen 
Busteilnehmer aufgeteilt werden können.
Die Adressierung ist festgelegt (Seriennummer des einzelnen 
Busteilnehmers als Identifier)

Was ich vermeiden will ist dass die Karten nachdem sie hergestellt 
worden sind noch manuell (per Lötbrücke oder Jumper) konfiguriert werden 
müssen. Das stellt einen zusätzlichen Prozessschritt dar und kostet, 
meiner Meinung nach, unnötig Geld.

Autor: TManiac (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Sven,

so richtig kapier ich noch nicht warum ihr Multiplexen wollte.
Du schreibst:

Sven H. schrieb:
> Sieben weil so zum einen mehr Datenrate zur Verfügung steht
> und zum anderen die Bussysteme nach Funktionsbereichen der einzelnen
> Busteilnehmer aufgeteilt werden können.

Die Datenrate wird doch durch das Mux nicht größer. Man bekommt nicht 
mehr Bits hintereinander auf die Leitung als wenn alle Teilnehmer 
gleichberechtigt am Bus teilnehmen. Die Datenrate wird sogar noch 
kleiner, weil du Zeit zum Umschalten benötigst.
Wie ich gerade schon schrieb, kann man die Funktionstrennung auch durch 
mehrere Busteilnehmer erhalten (dafür ist ja ein Bus da).

Das einzige Argument was ich verstehen kann ist, dass du die Anzahl der 
Transceiver reduzieren möchtest. Aber die werden wohl nur einen kleinen 
Teil der Gesamtkosten einnehmen.

Bitte erklär mal etwas genauer:
>Wir entwickeln zur Zeit ein System, das intern über 7 CAN-Bus-Systeme
>kommunizier.
So hab ich es bisher verstanden:
Es gibt in eurem Gerät eine unbekannte Anzahl an Baugruppen die in 
sieben Funktionsbereiche unterteilt werden. Jede Baugruppe eines 
Funktionsbereiches kommuniziert über einen eigenen CAN-Bus. Also hat 
doch jede Baugruppe ihren eigenen Controller und Transceiver.
Und umschalten/multiplexen willst du nun den Bus der aus eurer Hardware 
nach außen geht?

Wie wäre es mit einem Gateway? Weil eben nicht mehr Bits auf die Leitung 
passen. Ok ein Gateway-Controller mit acht Kanälen ist schwer zu finden, 
aber für sechs würde mir sofort einer einfallen. Aber zur Not würde es 
ein FPGA auch schaffen.

Gruß,
TManiac

Autor: Sven H. (dsb_sven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir haben mehrere Bussysteme, weil das System insgesamt mehr Rate 
benötigt. Die verschiedenen Teilnehmer werden also je nach Funktion auf 
den ein oder anderen Bus geschaltet. Da die Karten sich nur durch die 
Software unterscheiden müssen wir die Verbindung zum Gesamtsystem 
dynamisch umschalten können.

Autor: TManiac (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Noch einmal fragend. Deiner letzten Beschreibung entnehme ich das eurer 
System ähnlich meiner Skizze aussieht?

Das sind dann aber doch in meinem Beispiel drei (in eurem sieben) 
sperarate System. Es fließen ja keine Informationen von einem System in 
das Andere. Oder hast du daher von Anfang an immer zwei Umschaltern 
geredet weil jeder Teilnehmer auf zwei Busse aufgeschaltet werden soll.

Soll die Umkonfiguration auf die verschiedene Systeme auch im Betrieb 
ablaufen? Wenn nicht ließe sich doch das ganze wesentlich günstiger in 
der Verkabelung realisieren.

TManiac
(vor der Lösung eines Problems muss dieses erst einmal vollständig 
erkannt und verstanden werden)

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven H. schrieb:
> Wir haben mehrere Bussysteme, weil das System insgesamt mehr Rate
> benötigt. Die verschiedenen Teilnehmer werden also je nach Funktion auf

Und warum habt ihr euch dann für einen CAN-Bus entschieden? Kommt mir 
irgendwie so vor als soll jetzt mit einer Krücke ein Konzept gerettet 
werden das von Anfang an nicht zur Aufgabenstellung passte. CAN ist 
nicht gerade ideal für hohe Datenraten. Was spricht denn gegen Ethernet?

Matthias

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven H. schrieb:
> Problem bei der Lösung mit den mehreren Tranceivern ist, dass ich dann
> statt zwei Tranceiver 14 Tranceiver benötigen würde.

Welche Multiplex-Lösung soll denn effektiv weniger Platz benötigen (pro 
Kanal) als ein SO-8 Gehäuse. Und welche Lösung soll preislich günstiger 
werden als 14 einzelne CAN-Transceiver?

Nebst Schutzbeschaltung wird jede Umschalterei mit MOSFETs oder was auch 
immer im Endeffekt teurer.

Sven H. schrieb:
> Wir haben mehrere Bussysteme, weil das System insgesamt mehr Rate
> benötigt.

Auch das mit der höheren Rate verstehe ich (auch) nicht.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Über welche Buslängen unterhalten wir uns denn gerade?

Autor: Sven H. (dsb_sven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Μαtthias W. schrieb:
> Sven H. schrieb:
>> Wir haben mehrere Bussysteme, weil das System insgesamt mehr Rate
>> benötigt. Die verschiedenen Teilnehmer werden also je nach Funktion auf
>
> Und warum habt ihr euch dann für einen CAN-Bus entschieden? Kommt mir
> irgendwie so vor als soll jetzt mit einer Krücke ein Konzept gerettet
> werden das von Anfang an nicht zur Aufgabenstellung passte. CAN ist
> nicht gerade ideal für hohe Datenraten. Was spricht denn gegen Ethernet?
>
> Matthias

Das Problem bei Verkabelung ist, dass ein weiterer Prozessschritt 
eingeführt werden muss. Das führt zwangsläufig zu weiteren Fehlern. Also 
will ich das vermeiden.

Gegen Ethernet spricht nur einer meiner Kollegen, der nicht zu 
überzeugen ist. Das war auch mein erster Ansatz.

Frank K. schrieb:
> Über welche Buslängen unterhalten wir uns denn gerade?

Die Teilnehmer kommunizieren innerhalb eines 19'' Gehäuses miteinander. 
Vielleicht kommt noch ein zweites Gehäuse oben drauf. Die Maximale 
Buslänge sollte somit zwei bis drei Meter von Tranceiver zu Tranceiver 
nicht überschreiten.


Und, natürlich wird die Rate durch das verwenden mehrerer paralleler 
Bussysteme insgesamt größer.

Ein Beispiel: Karte 1 kommuniziert mit Karte 2. Dabei werden Haufenweise 
AD-Werte übertragen. 250KS/s mit 16 Bit. Da wirds mit einem 1Mbit-Bus 
schon arg eng.
Jetzt muss aber Karte 1 noch unbedingt mit Karte 3 kommunizieren um 
irgendeinen digitalen Ausgang zu setzen. Dieser Befehl "passt" aber 
schlicht und einfach nicht mehr auf den ersten Bus und muss somit 
"ausgelagert" werden.

Unter anderem aber auch auf Grund der Tatsache, dass einige Karten schon 
entwickelt sind sind wir an den CAN-Bus (und zwar sieben, von denen 
einer auf alle Client-Karten geführt wird und die anderen je nach 
Funktion oder Auslastung verteilt werden) gebunden.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
voll dämliches Konzept.
Hat sich niemand vorher darüber Gedanken gemacht?
Wie wäre es denn mit einer Art Switch-Karte, die dann die Datenleitungen 
zwischen den einzelnen Slave verbindet.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt nach fast vollendeter Punkt zu Punkt Verkabelung, bei der jede 
Node grad versucht, eine Node anzusprechen, die z.Zt. nicht zuhören 
kann, weil sie grad auf einem anderen Kanal versucht, eine andere Node 
anzusprechen, die z.Zt. nicht zuhören kann, weil sie grad auf einem 
anderen Kanal ...

Autor: Sven H. (dsb_sven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nunja. Mein Problem ist, ich muss damit leben und versuchen das beste 
drauß zu machen.

Es gibt halt Kollegen, die erstellen ein Konzept, schmeißen einem den 
Kram vor die Füße, ziehen sich zurück, wenns knifflig wird und verkaufen 
es dann am Ende, wenn alles funktioniert, als ihr eigenes tolles Konzept 
und realisiert haben die natürlich auch alles alleine.

Autor: Sven H. (dsb_sven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Klingt nach fast vollendeter Punkt zu Punkt Verkabelung, bei der jede
> Node grad versucht, eine Node anzusprechen, die z.Zt. nicht zuhören
> kann, weil sie grad auf einem anderen Kanal versucht, eine andere Node
> anzusprechen, die z.Zt. nicht zuhören kann, weil sie grad auf einem
> anderen Kanal ...

Das wäre wohl so, wenn nicht zwei Punkte dagegen sprechen:

1. Ein Bus geht zu allen Teilnehmern. Über diesen kann eine 
Synchronisation stattfinden.
2. Es gibt eine "Master-Karte" von der aus sämtliche Kommunikation in 
die Wege geleitet wird.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven H. schrieb:
> Es gibt halt Kollegen, die erstellen ein Konzept, schmeißen einem den
> Kram vor die Füße, ziehen sich zurück, wenns knifflig wird und verkaufen
> es dann am Ende, wenn alles funktioniert, als Ihr eigenes tolles Konzept
> und realisiert haben die alles alleine.

Klassische Team-Arbeit... ;)

Sven H. schrieb:
> Unter anderem aber auch auf Grund der Tatsache, dass einige Karten schon
> entwickelt sind sind wir an den CAN-Bus (und zwar sieben, von denen
> einer auf alle Client-Karten geführt wird und die anderen je nach
> Funktion oder Auslastung verteilt werden) gebunden.

Eine Karte hat 7 CAN-Schnittstellen?
Wieviele Karten stecken den in dem ganzen System?
Ich würde auch zentrale Multiplex-Karten aufbauen, die eine gewisse 
Menge Eingänge wahlfrei auf eine gewissen Menge Ausgänge schalten kann. 
Eine Schaltmatrix...

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für solche Sachen könnte man vermutlich auch solche fertigen Systeme wie 
PXI verwenden.

Autor: Der Bahnhof ist jetzt geöffnet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ein Beispiel: Karte 1 kommuniziert mit Karte 2. Dabei werden Haufenweise
> AD-Werte übertragen. 250KS/s mit 16 Bit. Da wirds mit einem 1Mbit-Bus
> schon arg eng.
> Jetzt muss aber Karte 1 noch unbedingt mit Karte 3 kommunizieren um
> irgendeinen digitalen Ausgang zu setzen. Dieser Befehl "passt" aber
> schlicht und einfach nicht mehr auf den ersten Bus und muss somit
> "ausgelagert" werden.

Aha, und nach dem Umschalten kommuniziert Karte 1 mit Karte 3 und nicht 
mehr mit Karte 2 oder wie ? Deine Beschreibung des Systems ist für die 
Tonne !

Autor: Volker Zabe (vza)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Konzept ist ungeeignet.

FlexRay währe eine Option. http://de.wikipedia.org/wiki/FlexRay

Aber zurück zum Thema:
Nimm z.B den sn65hvd254 als Transceiver. Der hat einen Enable-Eingang.

http://focus.ti.com/general/docs/lit/getliterature...

Du must nur noch die R-Pins verodern.

Also 7 Transceiver und ein 8-Fach-Oder-IC.

Billiger wirds nicht.

ciao Volker

Autor: Volker Zabe (vza)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder nimm ein Controller von Luminary
http://www.luminarymicro.com/products/product_sele...

Die haben bis zu 3 CAN-Controller onboard.

Nimm zwei Busse für das Daten schaufeln und einen für Verwaltungszwecke.

Autor: Sven H. (dsb_sven)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich versuch nochmal das System zu erklären.

Es laufen im 19'' Gehäuse 7 CAN-Bussysteme parallel.

Ein Teilnehmer (Master) ist fest mit allen Bussystemen verbunden.

Jeder Slave ist fest mit dem ersten CAN-Bus (schwarz) verbunden.

Jeder Slave soll mit der gleichen Software laufen. (!!!)

Je nach Funktion des Slaves (Spannungen messen, digitale Ausgänge 
schalten, Spannungen ausgeben...) soll er mit einem anderen 
CAN-Bussystem verbunden werden. Die Funktion des Slaves wird in einem 
EEPROM auf der Karte selber abgelegt. Die Software weiß also, was die 
Funktion der Karte ist.

--> Klare Trennung der Bussysteme nach Funktion.
--> Fehlersuche vereinfacht sich, da ich, wenn ich den Fehler bei der 
digitalen Ausgabe sehe, nicht auf sieben Systemen schnüffeln muss, 
sondern nur auf einem.

Ich hätte gerne nachträgliche Lötarbeit vermieden, da das, wie schon 
öfters gesagt, einen zusätzlichen Prozessschritt dar stellt. Bei ein, 
zwei Karten und bei Prototypen sicherlich kein Problem, allerdings 
sollen die Karten vom Lieferanten direkt ans Lager gehen und von dort 
aus in der Fertigung eingesetzt werden.

Autor: Volker Zabe (vza)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geht es jetzt nur um die Slaves oder auch um den Master?
Was ist die maximale Anzahl der gleichzeitig betriebenen Busse an den 
Slaves?
Was ist die maximale Anzahl der gleichzeitig betriebenen Busse beim 
Master?
Wie viele CAN-Controller haben deine jetzigen µC on-board?

250KS/s mit 16 Bit = 4MBits/s. + Overhead >= 5 MBits/s.

Du must also min. 5 Busse gleichzeitig betreiben.

Das Konzept geht nie auf!!!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven H. schrieb:

> Ich hätte gerne nachträgliche Lötarbeit vermieden, da das, wie schon
> öfters gesagt, einen zusätzlichen Prozessschritt dar stellt. Bei ein,
> zwei Karten und bei Prototypen sicherlich kein Problem, allerdings
> sollen die Karten vom Lieferanten direkt ans Lager gehen und von dort
> aus in der Fertigung eingesetzt werden.

Anders ausgedrückt: Das Kommunikationssystem wird kurz mit 2 Karten 
getestet und anschliessend ohne Realtest sofort im Vollausbau produktiv 
beim Kunden eingesetzt? Na denn, viel Vergnügen. Hoffentlich nimmt 
niemand Schaden.

Autor: Sven H. (dsb_sven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich frage mich, warum ihr euch den Kopf über das Konzept zerbrecht, wenn 
die Frage doch recht eindeutig formuliert war. Das Konzept ist in Zement 
gegossen und steht hier nicht zur Diskussion. Es tut mir Leid, dass ich 
euch mit den Einzelheiten konfrontiert habe, was offensichtlich dazu 
geführt hat, dass die eigentliche Frage aus dem Blick geraten ist.

Also nochmal die Frage:

Wie schalte ich CAN-Busse um. Ohne Relais.


Offensichtlich gibt es zwei Lösungen:

1. Lass es sein.

2. Schalte die digitalen Signale vor den Tranceivern um. -> Erhöhte 
Tranceiveranzahl.

Ich denke, die Diskussion kann damit als beendet angesehen werden. 
Vielen Dank für die Hilfe.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Offensichtlich gibt es zwei Lösungen:

>1. Lass es sein.

>2. Schalte die digitalen Signale vor den Tranceivern um. -> Erhöhte
>Tranceiveranzahl.

>Ich denke, die Diskussion kann damit als beendet angesehen werden.
>Vielen Dank für die Hilfe.

>Jeder Slave ist fest mit dem ersten CAN-Bus (schwarz) verbunden.
Wieviele Schnittstellen hat denn jeder Slave? 2? 3? 7?

Autor: Klaus2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...ruf doch einfach mal bei irgendwem der distris oder 
transceiver-hersteller an? ich habe da auch so meine bedenken, aber wenn 
ihr nicht die ganz harten CAN specs erfüllen müsst, geht es ggf mit 
analog-schaltern (die im übrigen teilweise auch nur wenige ohm haben) 
und einem GEEIGNETEN layout.

ich hoffe vielmehr, dass ihr noch die zeit habt, das sauber 
testen/stressen zu können...sonst wars das mit der ersparnis :)

Klaus.

Autor: Sven H. (dsb_sven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STK500-Besitzer schrieb:
> Wieviele Schnittstellen hat denn jeder Slave? 2? 3? 7?

Jeder Slave hat 3 Schnittstellen von denen eine fest verbunden ist und 
die anderen eben, je nach Funktion anders verbunden wird.


Ich bin parallel mit dem Hardwareentwickler unseres Lieferanten in 
kontakt getreten und er sieht auch keine andere Möglichkeit als die 
beiden schon genannten.

Ich werde dann wohl doch Lötjumper verwenden, die aber vom Lieferanten 
löten lassen. Somit erübrigt sich die Fehlerquelle und der 
Prozessschritt bei uns im Haus.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Jeder Slave hat 3 Schnittstellen von denen eine fest verbunden ist und
>die anderen eben, je nach Funktion anders verbunden wird.

Ihr habt vermutlich keine Möglichkeit, noch eine Art CAN-Routing MAtrix 
mit zu entwickeln bzw. einzubauen.
Da würde man dann die "freien" CAN-Anschlüsse draufführen und 
entsprechend der angeforderten Verbindung routen.
Das wäre vermutlich noch mal eine eigene 19"-Kiste ;)

Autor: Volker Zabe (vza)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STK500-Besitzer schrieb:
> CAN-Routing MAtrix

Ein Routing nützt Ihm nichts. Seine Busse sind voll ausgelastet. Du 
kannst nicht den Verkehr über einen Bus zum anderen routen.

Was noch helfen könnte, ist die Anlyse ob jeder CAN-Controller auf jeden 
BUS zugreiffen mus.

Dies könnte im besten Falle dazu führen das beide CAN-Controller jeweils 
nur auf drei Busse schaltbar sein müßten.

Diese Analyse würde auch die Anzahl der Lötjumper, und damit die 
Fehlerwahrscheinlichkeit reduzieren.

Autor: Sven H. (dsb_sven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Volker Zabe schrieb:
> Was noch helfen könnte, ist die Anlyse ob jeder CAN-Controller auf jeden
> BUS zugreiffen mus.

Das ist auf jeden Fall eine gute Idee. Ich werd das alles nochmal 
durchspielen.

Vielen Dank!

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.