mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Serielles Bussystem


Autor: Andreas Auer (Firma: Embedded Microtec) (andi) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich suche gerade nach einem (möglichst einfachen) seriellen Bussystem. 
Ich hab mir ein paar angesehen, aber die Entscheidung ist doch schwerer 
als erwartet.
An den Bus sollen ca. 32 Clients angeschlossen werden. Die 
Datenübertragung wird hauptsächlich von einem "Master" zu den restlichen 
Clients passieren. Wobei meistens alle Clients die selben Daten bekommen 
sollen (also per Broadcast). Unicast sollte aber trotzdem auch möglich 
sein. Es muss aber auch sichergestellt werden können, dass alle Clients 
die Daten bekommen haben (sowas wie ein ACK oder ein NACK).

Folgende Bussysteme hät ich mal angeschaut:
* RS422:
  Schneller und einfacher Bus. Jedoch befürchte ich, dass die 
Implementierung eines Protokolls, welches erlaubt Acknowledges an den 
Sender zurückzuschicken relativ schwierig werden kann, aufgrund von 
Kollisionen usw.

* CAN:
  Denke besser geeignet als RS422 aufgrund des definierten Protokolls. 
Sieht mir aber wesentlich komplizierter aus. Mit CAN hab ich bisher noch 
keine Erfahrungen sammeln können. Außderdem ist die Nettodatenrate auch 
nicht unbedingt der Hammer.

* Ethernet:
  Ethernet mit einem Switch IC (KSZ8893) pro Client. Damit müsst ich mir 
zumindest keine Sorgen um Kollisionen am Bus machen. Jedoch steigen auch 
die Anforderungen an den Mikrocontroller, der Clients. Außerdem muss 
gesichert werden, dass der Switch IC eines Clients korrekt konfiguriert 
ist, damit die Clients dahinter die Daten erhalten können. Vorteil von 
Ethernet wäre noch der Übertrager damit man keine Probleme mit den 
Massen der Clients bekommt.

Welchen Bus würdet ihr für diese Anforderungen verwenden??

Besten Dank,
Andreas

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I2C ?

Autor: pacer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie lang soll denn der Bus sein und was für Daten sollen denn über den 
Bus geschickt werden.

Autor: Andreas Auer (Firma: Embedded Microtec) (andi) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also der Bus wird so zwischen 30 und maximal 100m lang sein. Es werden 
einerseits größere Datenmengen (1-2 MByte) gesendet, die dann bei den 
Clients abgespeichert werden und andererseits Kommandos und kurze 
Textzeilen mit schätzungsweise so um die 64 Bytes.

Autor: Lehrmann Michael (ubimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Auer schrieb:
> Also der Bus wird so zwischen 30 und maximal 100m lang sein. Es werden
> einerseits größere Datenmengen (1-2 MByte) gesendet, die dann bei den
> Clients abgespeichert werden und andererseits Kommandos und kurze
> Textzeilen mit schätzungsweise so um die 64 Bytes.

CAN - so kompliziert ist das nun wirklich nicht ...

Autor: Andreas Auer (Firma: Embedded Microtec) (andi) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum CAN Bus... Broadcast sollte ja gehen soviel ich beim Überfliegen 
mitbekommen habe. Bekomm ich auch mit, wenn ein Client einen Fehler beim 
Empfang hatte??

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CAN ist in der Anwendung eigentlich relativ einfach, weil der Controller 
sehr viel mehr selber macht als bei RS485, wo Du selber auf Kollisionen 
achten, Prüfsummen implementieren, Buszustände monitoren etc musst. Das 
ganze ist bei CAN schon in Hardware im Controller implementiert.

Für große Datenmengen ist CAN nicht gedacht, eher für kurze Befehle mit 
deterministischem Antwortverhalten, und genau das hast Du bei Deinen 
anderen Alternativen nicht.

Ethernet ist in der Implementierung deutlich teurer, allein schon wegen 
des erforderlichen Übertragers und des PHYs. Das heutzutage übliche 
Twisted Pair Ethernet ist für eine Sterntopologie gedacht. 
Ausrufezeichen!

Ob es zuverlässig klappt, 32 Switches zu kaskadieren, weiß ich nicht - 
gedacht ist es eigentlich nicht dafür. Ich würde es nicht machen, weil 
es Probleme bei der Kollisionserkennung geben könnte. Zumindest würde 
ich die Switches im Store&Forward Modus betreiben, nicht im 
Cut-Through-Modus. Damit erhöhen sich natürlich auch die Latenzzeiten, 
und die Zuverlässigkeit geht in den Keller. Was passiert, wenn ein 
Knoten in der Mitte ausfällt? Insgesamt halte ich das für eine ziemlich 
dumme Idee. Wenn Du Ethernet nimmst, betreibe es in Sterntopologie, wie 
es der Rest der Welt macht.

fchk

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Auer schrieb:
> RS422:

Das ist eine Punkt-zu-Punkt Verbindung. 485 ist ein Bus. Aber den 
meintest du wohl auch.

Andreas Auer schrieb:
> Datenübertragung wird hauptsächlich von einem "Master" zu den restlichen
>
> Clients passieren.

Da bietet sich RS485 mit einem einfachen Protokoll doch geradezu an. 
Einer ist Master, die Slaves halten die Klappe, bis sie gefragt werden. 
Oder sollen die auch untereinander Daten austauschen?

Damit beim Broadcast nicht alle gleichzeitig antworten, kann man z.B. 
unterschiedliche Verzögerungszeiten für das ACK/NACK definieren.

mfg.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Auer schrieb:
> Zum CAN Bus... Broadcast sollte ja gehen soviel ich beim Überfliegen
> mitbekommen habe.

CAN hat nichts anderes als Broadcasts. Jeder Teilnehmer empfängt erst 
einmal jede Message und entscheidet dann anhand der Message ID, ob er 
die Message verwirft oder weiterreicht.

> Bekomm ich auch mit, wenn ein Client einen Fehler beim
> Empfang hatte??

Ja. JEDER Teilnehmer empfängt ALLE Messages und prüft sie auch. Wenn 
auch nur einer einen Fehler meldet, zieht er das entsprechende Bit im 
Frame auf den dominanten Pegel (0), sodass der Sender weiß, dass er die 
Message erneut senden muss.

fchk

Autor: Andreas Auer (Firma: Embedded Microtec) (andi) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die raschen Antworten. Das sind schonmal sehr viele Argumente 
für den CAN Bus! Vielleicht kannst du mir noch gleich einen Tipp für 
mögliche CAN Controller ICs geben!?

Hast du vielleicht schonmal einen Cortex M3 Controller mit CAN Interface 
verwendet?? Würde mal gerne einen Cortex M3 verwenden. Hab gesehen, dass 
es z.B. welche mit CAN Interface von TI gibt.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt viele Hersteller von Cortex M3 mit CAN MAC: NXP, STM, 
TI/Luminary, Atmel; dazu noch Microchip (PIC32 oder PIC24/dsPIC) und 
Renesas. Du musst halt schauen, was für sonstige Anforderungen Du noch 
hast, wieviel Rechenleistung Du brauchst, wieviel Speicher, was für 
Peripherie etc. Einen einfachen CAN-Knoten bekommst Du mit einem PIC18 
schon für deutlichst unter 5€ hin.

Zum MAC kommt immer noch ein PHY dazu. Das ist wie bei Ethernet: der MAC 
macht den Digitalteil, der PHY die analoge Ankopplung an das Medium. Die 
CAN PHYs sind immer extern und alles 8-Pinner (DIL oder SO08). Hier 
musst Du sehen, welche Übertragungsrate Du mit Deiner Kabellänge fahren 
kannst und dann entweder einen schnellen PHY mit steilen Flanken oder 
einen langsameren, störsichereren mit flachen Flanken nehmen. Bei 
einigen PHYs kann man das per Widerstand einstellen.

fchk

Autor: Andreas Auer (Firma: Embedded Microtec) (andi) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atmel hat auch einen Cortex M3 mit CAN MAC?? Hab ich irgendwie nicht 
gefunden.

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

Bewertung
0 lesenswert
nicht lesenswert
Ich wuerd RS422 verwenden. Er ist fullduplex & bidirektional, speziell 
in einem Master-Slave System. Das Protokoll ist machbar. Wenn der Slave 
auf jedes Packet des Masters eine Antwort sendet ist man etwa da wo man 
sein wollte. Broadcasts ergeben natuerlich keine Antwort.

Autor: Andreas Auer (Firma: Embedded Microtec) (andi) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Oschi schrieb:
> Ich wuerd RS422 verwenden. Er ist fullduplex & bidirektional, speziell
> in einem Master-Slave System. Das Protokoll ist machbar. Wenn der Slave
> auf jedes Packet des Masters eine Antwort sendet ist man etwa da wo man
> sein wollte. Broadcasts ergeben natuerlich keine Antwort.

Wenn ich einzelne Slaves ansprechen möchte, dann wäre RS422 auf 
jedenfall geeignet. Bei mir gehts hauptsächlich um Broadcasts zu den 
Clients, da alle Clients möglichst zeitgleich die Daten erhalten sollen. 
Und dann muss sichergestellt werden können, dass alle Slaves die Daten 
fehlerfrei erhalten haben. Und da befürchte ich die Schwierigkeit bei 
RS422.
Ich weiß nicht wie oft das wirklich vorkommt, aber wenn es mehrere 
Slaves betrifft, die fehlerhafte Daten erhalten haben, dann muss ich vom 
Master die Daten nochmal schicken. Und dann muss ich auch Kollisionen am 
Bus erkennen können usw.

Ich glaub CAN hat da wirklich so seine Vorteile.

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

Bewertung
0 lesenswert
nicht lesenswert
Bei einem Bussystem gehen die Packete allenfalls wegen Reflexionen 
kaputt, oder bei einem Kabelbruch. Daher scheint mir wenn's die letzte 
Station im Kabel verstanden hat, haben's die anderen auch verstanden.

Kollisionen gibt es bei einem Master Slave System nicht, denn es gibt ja 
keine unplanmaessigen Packete.

Denkbar waere ein Bad-Packet Zaehler, der periodisch abgefragt wird.

CAN ist ein Bus mit 6 byte Nutzdaten. Wenn das zuwenig ist, wird's 
muehsam. Denn man sollte einen Bus zustandslos haben.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Auer schrieb:
> Atmel hat auch einen Cortex M3 mit CAN MAC?? Hab ich irgendwie nicht
> gefunden.

Ich eben gerade auch nicht mehr. Aber Atmel hat ohnehin so seine 
Lieferprobleme. Ich würde eher mal bei NXP und STM vorbeischauen. NXP 
baut mit die schnellsten Cortexe - insbesondere was das Flash angeht, 
aber ab und an auch häßliche Erratas. STM hat eine relativ breite 
Palette von klein bis groß und ist mir bezüglich Bugs nicht groß in 
Erinnerung geblieben.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Oschi schrieb:

> Bei einem Bussystem gehen die Packete allenfalls wegen Reflexionen
> kaputt, oder bei einem Kabelbruch. Daher scheint mir wenn's die letzte
> Station im Kabel verstanden hat, haben's die anderen auch verstanden.

Oder wenn nebenan ein 35kW Motor anläuft :-)

> CAN ist ein Bus mit 6 byte Nutzdaten.
8 Byte!

> Wenn das zuwenig ist, wird's
> muehsam. Denn man sollte einen Bus zustandslos haben.

Die Automobilindustrie kommt damit ganz gut zurecht.

fchk

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

Bewertung
0 lesenswert
nicht lesenswert
>> CAN ist ein Bus mit 6 byte Nutzdaten.
>8 Byte!

Wow. Der Hammer ...

>
>> Wenn das zuwenig ist, wird's
>> muehsam. Denn man sollte einen Bus zustandslos haben.
>
>Die Automobilindustrie kommt damit ganz gut zurecht.

Das besagt leider absolut gar nichts. Ist kein Praedikat fuer nichts, 
ausser fuer ultrakurze Pakete. Fuer Megabyte file transfers waer's 
weniger geeignet.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche Datenrate brauchst Du denn?
Es geht durchaus ein RS485-Bus mit broadcast und anschließender Abfrage, 
ob jeder Empfänger alles richtig empfangen hat.
Das dürfte effizienter sein, als kBs - MBs über CAN zerhäckselt zu 
übertragen.

Um nach einer Datenübertragung bei allen Slaves gleichzeitig Aktionen 
auszulösen, kann man sich einen Trigger-Befehl definieren, der nach der 
erfolgreichen Datenübertragung kommt.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Oschi schrieb:

> CAN ist ein Bus mit 6 byte Nutzdaten. Wenn das zuwenig ist, wird's
> muehsam. Denn man sollte einen Bus zustandslos haben.

Man kriegt problemlos auch grössere Datenmengen rüber (z.B. einen 4Mbit 
Protokollspeicher), ohne dass der Bus selbst irgendeinen Zustand braucht 
(die Nodes haben natürlich einen, aber warum auch nicht) oder es in 
übles Pingpong ausartet. Beispielsweise indem eine Teiladresse von 
burstartig gesendeten Daten als Teil einer 29bit Adresse übertragen 
wird. Der Empfänger akkumuliert die und reklamiert wenn ihm was fehlt.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:

> Das dürfte effizienter sein, als kBs - MBs über CAN zerhäckselt zu
> übertragen.

Effizient in Bits/Sekunde oder effizientes Programmieren? CAN reduziert 
die Nutzbitrate bei gleichen Rahmenbedingungen und erhöht die Nodekosten 
ein bischen, erhöht andererseits aber die Zuverlässigkeit dank fertiger 
Kontroll- und Fehlerbehandlungsmechanismen. Die Möglichkeit asynchroner 
Statusmitteilungen statt permanentem Polling kriegt man dann gratis.

In vielen Fällen ist die effektive Nutzbitrate von Steuerbussen kein 
vordringliches Problem.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:
> Es geht durchaus ein RS485-Bus mit broadcast und anschließender Abfrage,
> ob jeder Empfänger alles richtig empfangen hat.
> Das dürfte effizienter sein, als kBs - MBs über CAN zerhäckselt zu
> übertragen.

Das Zerhäckseln ist überhaupt kein Problem, macht Dir jeder 
CAN-Bootloader vor.

Dagegen mußt Du bei RS485 alles zu Fuß machen (CRC, Fehlererkennung, 
ACK, Retry, Adressierung, Kollision usw.). Du hast also bei RS485 
erheblich mehr Code zu schreiben und auszuführen. Effizienz ist was 
anderes.


Peter

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für RS485 wurde mal ein Protokoll entwickelt und nennt sich SISA/QD2.
Es kann 64 Stationen adressieren. Ob diese Datenmengen möglich sind, 
müsste man noch erforschen. Einfach mal danach suchen.

Fred

Autor: Andreas Auer (Firma: Embedded Microtec) (andi) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die vielen Antworten. Das hilft mir bei der Auswahl auf 
jedenfall weiter!

Peter Dannegger schrieb:
> Frank schrieb:
>> Es geht durchaus ein RS485-Bus mit broadcast und anschließender Abfrage,
>> ob jeder Empfänger alles richtig empfangen hat.
>
> Dagegen mußt Du bei RS485 alles zu Fuß machen (CRC, Fehlererkennung,
> ACK, Retry, Adressierung, Kollision usw.). Du hast also bei RS485
> erheblich mehr Code zu schreiben und auszuführen. Effizienz ist was
> anderes.

Genau vor diesen Dingen hab ich bei RS485 etwas "Angst". Jede Zeile Code 
mehr ist natürlich eine mögliche Fehlerquelle! Von dem her wäre mir auf 
jedenfall recht, wenn der Bus bzw. ein definiertes Protokoll das von 
sich aus schon regelt. Und dafür würde sich auf jedenfall CAN eignen.

Die Datenrate ist an sich nicht das Hauptkriterium (auch wenn ich hin 
und wieder 1-2 MByte schicken muss). Wichtig ist es, dass alle Nodes die 
Daten verlässlich und gleichzeitig bekommen. Und das würde CAN soweit 
ich das bis jetzt verstanden habe auf jedenfall gewährleisten.

Danke euch,
Andreas

Autor: zipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi

für das was du willst, gibt es das modbus-protokoll
das geht mit rs485 + rs422, da master - slave.

infos findest du unter modbus.org

ich mache das ( seit 30 jahren) mit den protokollen in basic,pascal,php,
über rs422-485 und ethernet.

cu zipp

Autor: Tom B. (botas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit einem Ringbus? Der Master Sender an Client1, Client1 an 
2, 2 an 3, ... n-1 an n, n an den Master. Hinter den Daten könnte ein 
Bitfeld sein welches jeder Client um 1 schiebt und sein Ack einträgt.

Autor: Christian Kreuzer (christian_rx7) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du es über RS485 machen willst, würde ich mir das S.N.A.P. 
Protokoll ansehen, einfach und leicht zu implementieren.
Allerdings würde ich dann nicht per Broadcast die Slaves abfragen, 
sondern der Master sollte jeden Slave geziehlt abfragen und die Anderen 
halten dabei die Klappe, somit umgehst du schon mal Kollisionen.

Christian

Autor: zipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
einer kaputt und der bus steht...
sehr praktisch und "state of the art"..

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zipp schrieb:
> einer kaputt und der bus steht...
> sehr praktisch und "state of the art"..

Doppelten (Token)ring benutzen ;-)


Nee, war'n Scherz.

Autor: zipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian H. schrieb:
> Doppelten (Token)ring benutzen ;-)
>
>
> Nee, war'n Scherz.

nö wieso?
die schmerzlichen erfahrungen habe ich mit einer 16x16 8048-matrix schon 
1982 gemacht. hoffe nur, das keiner den schwachsin schon wieder erfinden 
will!

;-))

Autor: Tom B. (botas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, wenn bei CAN oder RSxyz einer kaputt ist und den Bus auf Masse 
zieht geht auch der ganze Bus nicht mehr. So ein Ring hat durchaus auch 
Vorteile. Zum Beispiel wird das Signal immer wieder aufgefrischt. Nur 
weil das alt ist, ist es doch nicht gleich schlecht. Räder gibt es auch 
schon eine Weile.

Autor: Anja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Auer schrieb:
> Also der Bus wird so zwischen 30 und maximal 100m lang sein.

Bei 1 MBit ist der CAN für bis zu 40m spezifiziert. Bei 100m und 32 
Teilnehmern ist das schon sehr an der Grenze. Da wären dann 250kBit/s 
besser.

Gruß Anja

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei CAN können auch 9 oder 10 Byte mit einer Übertragung genutzt werden, 
habe ich auch schon programmiert.

Die CAN-ID hat 29 Bit also fast 4 Byte, davon habe ich einfach die 
unteren 16 Bit als Daten "Missbraucht".
+ die 8 Byte Daten
= 10 byte


Wenn man einen größeren Datenblock übertragen möchte, so kann man z.B. 
die ersten 8 Bit der CAN-ID als Daten-Block-Adresse verwenden.
Der Sender schickt immer Block 0..255, der Empfänger kann diese Daten 
anhand der Nummer in das RAM kopieren. Sollte eines Fehlen, so kann der 
Empfänger "Meckern". Auch wenn die Blöcke nicht in der Reihenfolge 
ankommen, so wird anhand dieser Adressierung immer der Block an die 
richtige Stelle eingefügt.


CAN ist in jedem Fall leichter zu implementieren als RS422, da die 
Hardware viel abnimmt.
Die Anzahl der Datenbytes kann durch einfache kluge Programmierung 
beliebig erweitert werden.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Müller schrieb:
> CAN ist in jedem Fall leichter zu implementieren als RS422, da die
> Hardware viel abnimmt.

Auch haben die CAN-MCs in der Regel mehrere Messagepuffer. Die CPU kann 
also ruhig mehrere Pakete abwarten und muß nicht gleich bei jedem Byte 
in den Interrupt springen.

Wenn ich mir dagegen den Ärger mit RS485 ansehe. Wehe, man schaltet 
nicht schnell genug die Richtung des Transceiver um, dann gibts 
Datensalat.
Die Interruptanforderungen von RS485 sind also um ein Vielfaches 
kritischer.


Peter

Autor: Andreas Auer (Firma: Embedded Microtec) (andi) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich glaub meine Entscheidung ist gefallen. Ich werds wohl auf 
jedenfall mit CAN probieren. Ich danke euch für die Hilfe und die 
Diskussion rund ums Thema!

mfg
Andreas

Autor: Michael Haberler (mah)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich halte auch Modbus für die einfachste Lösung, und mit einem guten 
Open Source Angebot bis zur Anwendungsebene (also jenseits der Frage 
"wie schiebe ich die Bits durchs Kabel")

zB http://libmodbus.org für Linux, Mac OS X, FreeBSD, QNX und Win32

http://freemodbus.berlios.de/index.php?idx=32 - eine ganze Reihe von 
Mikrokontrollern

Ich habe einen Modbus-Treiber für einen Frequenzumrichter und LinuxCNC 
geschrieben (http://git.mah.priv.at/gitweb/vfs11-vfd.git) und musste 
keineswegs "CRC, Fehlererkennung, ACK, Retry, Adressierung, Kollision 
usw." schreiben.

-Michael

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.