www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CAN Grundlagenfrage


Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe eine grundlegende Frage zu Thema CAN.

Wollte ich jetzt mehrere CAN Teilnehmer miteinander verbinden, ähnlich
einem CAN@Home Projet, wie muss ich sie dann verbinden.

Bei CAN gibts doch eine Tx und eine RX Leitung... bei zweien scheint es
leicht, aber wie ist es mit drei Teilnehmern..

ist eine übertragung in beide richtungen gleichzeitig möglich??

Danke!

Martin

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alle Teilnehmer parallel denk ich ...
Abschlußwiederstand nich vergessen
  chris

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alle Tx leitungen zusammen, und alle rx leitungen, wie kann das
gehen???

wenn man sternförmig legt, wohin mit dem 120 ohm wiederstand!?
Martin

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du brachst noch nen bustreiberbaustein, z.b. den PC82C250

http://www.semiconductors.philips.com/acrobat_down...

...für jeden teilnehmer einen...

in den kommen deine Tx und Rx leitung...

raus kommen dann neue signale: CAN_L und CAN_H
...alle parallel anschliesen... CAN_H zu allenCAN_H und CAN_L zu allen
CAN_L

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...natürlich einen 120R am einen ende, und noch einen 120R am anderen
;-)

länge: Faustregel: länge[m]= (40[m]/ übertragungsrate[MBit/s])

-->1MBit/s : 40m
-->0.5MBit/s : 80m etc.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bone.

ahhh, klar, den habe ich auch schon bei reichelt entdeckt! setzt der
das dann passend um???

könnte ich 2 can devs direkt gekrosst verbinden

kennst du eine gute can grundlagensite, also

ü raten
ü rahmenlänge
ü standarts
usw...

weißt du zufällig wo ich einen für LIN her bekomme, habe da auch schon
exemplare raus gesucht...

MCP201
TJA1020

leider nicht bei reichelt..

danke

martin

Autor: Paul Baumer (paule)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gibts ne gute Zusammenfassung des Can Bus
http://www.kvaser.com
bei education / can

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Paul,

vielen Dank, werde mich da mal umsehen.

jetzt bereiten mir die LIN Transceiver noch sorgen, weis nicht wo ich
die mal am besten her bekommen kann.

als standart gibt hier wohl der
mcp201 oder
tja1020, aber die gibts nirgendwo...

martin

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn du versprichst sie keinem weiterzugeben!!!, schicke ich dir einen
teil aus meiner diplomarbeit, in der alles was du wissen musst steht...

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ausser LIN...
nur can

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bone,

das ist ein schwieriges versprechen! ich kann dir nur versprechen das
ich sie weder öffentlich, noch auf einer i site, noch in sonst
irgendeiner form geschäftlich - oder kommerziell einsetzten werde, mein
interesse ist rein privat, und das wird auch bleiben....

wenn das reicht... brauch ja nur was zum einlesen...

damit ist aber immer noch meine LIn Transceiver frage offen, mensch die
muss es doch irgentwo geben....

martin

Autor: Viktor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin,

CAN ist ein Bussystem deswegen werden alle Teilnehmer, wie schon
besrieben, an eine Leitung gelegt. Beim CAN-Bus werden die Teilnehmer
mit Hilfe von Adressen angesprochen.
Eine Übertragung in beide richtungen gleichzeitig ist meines Wissens
nach nicht möglich, da die beiden Datenleitungen CAN_H und CAN_L ein
zueinander invertiertes Signal führen. Das dient der
Übertragungssicherheit.
Am besten du siehst dir diese Seite mal an
http://www.elektrocrew.de/modules.php?name=News&fi...
das ist die beste die ich auf die schnelle finden konnte.

Ich hoffe das hilft dir weiter.

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit lin hab ich mich noch nicht befasst,

nur ethernet/lan
can
spi
i2c
rs232
rs485
pci
(usb)grad am erlernen

ich werde dir heute abend (wenn endlich zu hause) den
CAN-grundlagenteil mal schicken... (halte dein obiges wort ;-) !!)

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Viktor,

so langsam wird mir die sache mit dem Bussystem klarer...

Also ein differenzielles Übertragungsverfahren auf dem Medium, ähnlich
Ethernet... gut zu wissen...

dann ist auf jeden fall klar das man nur in eine richtung auf mal
senden kann, und es eines zugriffsverfahrens bedarf wenn man mehrere
bussteilnehmer hat....

ich versuche zwei fujitsu mb90385 miteinander zu verknüpfen und einfach
daten zu übertragen,

die site schaut interessant aus, dank dir, sehe mich mal um,

martin

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo bone,

da hast du ja schon eine menge bussysteme durch...vor allem pci sticht
dort etwas raus, hut ab, pci kann ich mir garnicht vorstellen, also das
man da als normal sterblicher nocht mit um kann... :-)

ich halte mein wort.

binn gespannt was kommt..

größer als 4 mb kann probleme geben...

jetzt bleiben noch die lin sorgen, bezüglich des beschaffens...

ich versuche zwei fujitsu 90385 zum kommunizieren zu bringen, es gibt
auch einige app notes dazu, aber meine herren, einen can uart
anzusprechen ist im gegensatz zu einen rs232 uart eja eine  tortur kann
das sein!?

martin

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@viktor:
>Beim CAN-Bus werden die Teilnehmer
mit Hilfe von Adressen angesprochen.

-ausgerechnet beim CAN ist das nicht so...
beim can wird die information des telegramms adressiert...
-jedes telegramm ist (topolodiebedingt) ein broadcastobjekt...
die Teilnehmer(Knoten bzw. Nodes) entscheiden dann anhand dieser
adresse ((informations-)IDENTIFIER) ob die information für sie selbst
interessant ist...

>Das dient der
Übertragungssicherheit.

-schonwieder nicht... :-)
stichwort MAC (medium access controll) ...
...der buszugriff zu deutsch...
es kann immer nur ein packet über den CAN-Bus laufen!
keine zwei oder mehr gleichzeitig!! (topologie mal wieder)
beim CAN eng verknüpft mit der Kabellänge!
weil hier durch die sogenannte arbitrierung die telegrampriorisierung
stattfindet. LAUFZEITEN etc. müssen berücksichtigt werden!!!

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bone,

in einer app ist mir noch ein zusätliches bauteil aufgefallen, es ist
eine art übertrager, aber länks geschaltet, drosselspule!? also in
reihe zu canh und canL, vorab noch 2 folien c's zu masse.

ähnlich wie bei ethernet, wo auch eine art übertrager vor der rj buchse
sitzt.

bei den apps auf can at home, ist diese nicht vorhanden. das ganze
dient ja nun der störunterdrückung ähnlich EIB,Ethernet,S0(ISDN)
usw...

ich habe ein problem mit der beschaffung und der beschaffenheit dieser
spulen/drosseln/übertrager...

eine idee, oder infos??

Autor: Eddy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Überigens einen CAN Abschlusswiderstand von ca. 120 Ohm wird nur in der
Highspeed- CAN Technologie verwendet.

Beim Lowspeed CAN nicht zwingend erforderlich.


Der Transceiver von Philips TJA 1054 empfehlenswert, da das Bauteil
sehr hohe ESD Schutz besitz.

Gruß
Eddy

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Bone,

deine Can ausarbeitung ist leider nicht angekommen, sie würde mich
dennoch sehr interessieren.

Martin

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry, bin nicht dazu gekommen...

hab es aber schon parat gelegt ;-)
heute abend schick ichs dann rüber :-) (vermutlich gegen 22uhr)

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,

wie gesagt, bin mal gespannt.

martin

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
keine zu groosen erwartungen :-)
sind nur etwa 10 seiten ;-)

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...Hey Hey,

so wie ich dich verstanden habe, handelt es sich um einen ausschnitt
aus deinem diplom, wenn ich da keine erwartungen haben soll, wo denn
dann :-))

Martin

Autor: Ronald H. (do7rh)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nabend zusammen,

ich habe mal ein kleines Bild angehängt, was mein MCP2515 nach dem init 
und der 1. gesendeten Nachricht macht. Ich sende nur ein Telegramm, aber 
wenn ich das richtig deute, hört der gar nicht mehr auf, oder muss das 
so sein? Hat da jemand Erfahrungswerte? Wenn ich von der Zeit her runter 
gehen, kann ich verschieden lange HIGH Impulse erkennen. Die langen 
Impulse sind ca. 4,4µs, die kurzen etwa 3µs. Einen ganz Kurzen mit 1,3 
µs habe ich außerdem noch finden können.

Gemessen habe ich zwischen CAN_H und CAN_L vom Treiber IC.

Ronald

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das muss so sein, wenn keiner da ist der die Nachricht entgegeb nimmt, 
also dein Sender kein Ackn bekommt.

Autor: Ronald H. (do7rh)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch das 2. Bild mit einer anderen Eionstellung der Zeitachse.

Autor: Ronald H. (do7rh)
Datum:

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

Dann habe ich soeben mein erstes CAN Telegramm mit einem MCP2515 
versendet. :-)

Vielen Dank

ronald

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...ich vermute mal, das dein CAN-kumpl "alleine ist"

wenn er nimanden hat, der ihm das CAN-packet abnimmt(indem er im 
ACK-slot des packets einen dominanten pegel sendet) dann denkt DEIN 
CANchip IHM sei ein fehler unterlaufen, und wiederholt das versenden.... 
dabei incrementiert er seinen fehlerzähler...

....wenn sein fehlerzähler einen gewissen stand erreichte(siehe 
datenblatt) wird er sich ausschalten....

dh.
wenn dein chip "allein" am bus ist, dann gratulation zum test, du hast 
ein CAN-packet verschickt...

wenn noch ein (bereits auf die gleiche(!) baudrate konfigurierter) chip 
am bus hängt, solltest du nochmals prüfen, ob beide WIRKLICH die GLEICHE 
baudrate benutzen...

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich sollte nich so lange ich was tippe davonlaufn :( war zu spät :(

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es reicht aber nichjt nur die richtige Bautrate, sonder der 
Empfangsfilter des Empfängers muss auch die ID der Massage akzeptieren.

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja war ja etwas ausführlicher deine Antwort.

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@obelix:

nicht ganz richtig...
der ACK wird gesetzt, wenn das CAN-Packet von seiner struktur her 
korrekt auf dem Bus abgebildet wurde( anzahl bits, stuffregln 
eingehalten, ifs nicht unterschritten). dies wird von jedem 
Busteilnehmer mit einem ACK belohnt...

erst jetzt prüft der chip, ob er das packet in einen buffer schiebt oder 
verwirft (anhand filterverwendung und -wert)...

 ( ISO 11898 )

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bist du dir da sicher? Teste ich bei Gelegenheit mal aus.

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sehr sicher, hab (fast) täglich mim CAN zu tun ;)


noch ein buchtip, für alle dies interessiert:

Wolfhard Lawrenz
"CAN Controller Area Network
Grundlagen und Praxis"

Hüthig Verlag

ISBN 3-7785-2780-0


....lässt keine fragen offen :)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Obelix wrote:
> Bist du dir da sicher? Teste ich bei Gelegenheit mal aus.

Ja, es reicht, wenn ein Teilnehmer das Paket für gut befindet.
Ob auch der gewünschte Empfänger das Paket erhalten hat, weißt Du nicht.


Beim CAN wird auch nur der Identifier arbitriert, nicht das Datenpaket.
Wenn also zufällig 2 Teilnehmer den gleichen Identifier aber 
unterschiedliche Daten senden, ist der Bus erstmal ne Weile tot, bis 
dann beide das Senden aufgeben, weil ihr Errorcounter übergelaufen ist.

Ein Kollege hatte sich mal gewundert, weil der CAN-Bus nur ganz langsam 
vor sich hin tröpfelte. Er hatte versehentlich 2 gleiche Geräte 
angeschlossen.


Peter

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha, gut zu wissen. Man lernt halt nie aus :-)

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Dannegger

es reicht keineswegs dass nur ein Teilnehmer das Paket für gut befindet.
Es ist zusätzlich auch noch zwingend notwendig dass kein anderer 
Busteilnehmer das Paket ablehnt (durch senden eines Errorframes). Die 
Empfänger dürfen das Paket erst zur Applikation durchreichen wenn diese 
Bedingung erfüllt ist. Wenn der Sender ein Errorframe erkennt versucht 
er das Paket erneut zu senden.

Dirk

Autor: Ronald H. (do7rh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mahzeit,

also ich habe nun 2xMCP2515 mit µC an meinem BUS. Ich kann auch von 
einem µC LEDs am 2. ein bzw. ausschalten. Nur sendet mein 2. µC ein ACK 
zurück und somit muss ich nach dem 1. senden den "Sender" reseten und 
dann kann ich weiter machen. Also wird das ACK nicht von selbst 
gesendet, wenn es einen 2. Teilnehmner auf dem BUS gibt.
Nur wir komme ich jetzt mein ACK?

Ronald

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kannst du dein letztes Post noch mal etwas genauer beschreiben?

Also wenn du über den CAN ein/ausschalten kannst, dann funktioniert der 
CAN doch? Das ACK wird automatisch von MCP übernommen.

Warum musst du den Sender anschließend resetten? Das habe ich jetzt 
nicht ganz verstanden. Ich würde sagen, dass da in der Programmierung 
des Programmes was nicht stimmt...

Autor: Ronald H. (do7rh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

ich habe 4 Taster an meinem 1. µC angeschlossen. Bei Tastendruck soll er 
ein Telegramm senden. Dieses wird vom 2. µC auch empfangen und 
ausgewertet. Sprich meine LED am 2. µC geht entweder an oder eben aus. 
Das funktioniert auch alles wunderbar. Das Problem leigt nun am ACK, 
welches der 2. µC an den 1. als Bestätigung senden soll. Dieses 
passiert, aus welchen Günden auch immer, nicht. Der 1. sendet also 
munter weiter, da er ja denkt das Telegramm sei ncht angekommen. Wer 
erzeugt mein ACK? Ist es der CAN Controller (MCP2515) oder, wie ich es 
auch schon gelesen habe der BUS Treiber? Oder muss ich meinen µC dazu 
bringen es zu senden?
Da der 1. ja nun mal nicht mehr aufhört mit dem Senden muss ich ihn erst 
einen drüber geben um dann wieder ein neues Telegramm senden zu können. 
Beide µC habe ich im Normal Mode laufen, also kann es auch nicht an der 
fehlenden berechtigung zum senden (Listen only) liegen.
PS: Habe mich, was die Grundstruktur an geht an die Anleitung von 
http://www.kreatives-chaos.com/artikel/ansteuerung... 
gehalten.

Ronald

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ronald Hensen wrote:

> munter weiter, da er ja denkt das Telegramm sei ncht angekommen. Wer
> erzeugt mein ACK? Ist es der CAN Controller (MCP2515) oder, wie ich es
> auch schon gelesen habe der BUS Treiber?

Sag bloß, Du hast keine CAN-Treiber dazwischen, dann kanns auch nicht 
gehen.

Beide müssen sich selbst und den anderen mithören.


Peter

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der CAN-Treiber macht nur die Pegelanpassung sonst nichts. Alles andere 
was zum Protokoll gehört macht der CAN-Controller selbstständig.

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der CAN-Treiber macht nur die Pegelanpassung sonst nichts. Alles andere
was zum Protokoll gehört macht der CAN-Controller selbstständig.

^^

AUTSCH

naja, bis auf die tatsache, das erst der treiber die "dominanten" und 
überschreibbaren "rezessiven" pegel schafft....

TREIBER == UNVERZICHTBAR!!!!

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ausserdem kann der sendende Knoten seine eigenen Daten nicht 
zurücklesen, also ohne Bustreiber keine Funktion.

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@bone
Warum AUTSCH?

Ich habe es natürlich nur stark vereinfach gesagt.

> naja, bis auf die tatsache, das erst der treiber die "dominanten" und
überschreibbaren "rezessiven" pegel schafft....

Kurz gesagt Pegelanpassung.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für Testzwecke könnte man die beiden TXD über ein AND (74HC08) 
verknüpfen und den Ausgang dann auf beide RXD.


Peter

Autor: Ronald H. (do7rh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keine Sorge. Als Treiberbaustein habe ich den PCA82C250 eingebaut. Wie 
schon gesagt. das 1. senden von einem zum anderen Controller ist 
möglich, nur hört es mit dem Senden nicht mehr auf. Kann ich denn sehen, 
ob das ACK vom 2. µC gesendet wird (also auf dem Oszi)? Habe auch auf 
beiden Seiten einen Abschluss mit (da ich nichts anderes da hatte) 130 
Ohm gemacht. Die Entfernung sollte so etwa 1m betragen.

Ronald

Autor: Ronald H. (do7rh)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich bins dann doch noch einmal. Inzwischen bin ich der Meinung, das das 
ACK Bit doch gesendet wird. Jedenfalls versucht wird zu senden.
Ich habe das Oszi mit dem 1. Kanal auf die TX Leitung des MCP2515 vom 
Empfänger der Nachricht gehängt und den 2. Kanal auf CAN LOW. Jedesmal 
an der gleichen Stelle vom Frame wird ein Impuls über den TX vom 
"Empfänger" gesendet.
Hab mal ein Bild gemacht.

Ronald

Autor: Ronald H. (do7rh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh mann. Das nenne ich mal eigene Dummheit!!! Habt alle einen gut bei 
mir! Das ACK wird natürlich am MCP2515 gesendet, nur kann der BUS 
Treiber, wenn ihm die 5V Ub fehlen wenig damit anfangen! Hab auch 1000x 
die Schaltung kontrolliert, sogar mit Lupe und jetzt, nachdem ich die 
IC's aus den Sockeln genommen hatte um mal die Spauungen zu messen, 
fehlte der Pegel an Pin 3 (Vcc). Ich habe alles so oft kontrolliert und 
nichts gefunden - jetzt bei gutem Licht und einer Lupe war da eine 
kleine Unterbrechung auf der Platine.

Fazit: Ein Bustreiber ohne Spannung kann immernoch empfangen. UND! Wer 
misst misst nicht immer nur misst.

Vielen Dank für eure Unterstützung!


Ronald

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@obelix:
Kurz gesagt Pegelanpassung.


eben NICHT einfach nur eine Pegelanpassung...
einfach nur eine pegelanpassung wäre zB: bei rs232treibern der 
fall...(!)

rezessiv und dominant sind nicht einfach NUR pegel... das verhalten ist 
die crux!!

einfaches beispiel hierfür: I2C...


...schont bitte eure canchips :) spendiert ihnen treiber :)

ps: AUTSCH nur ugs. ;)

Autor: Stefan May (smay4finger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es geht auch ohne den CAN Transceiver.

http://de.sitestat.com/infineon/infineon/s?infineo...

Falls der Link nicht funktioniert, mit Google nach ap292101.pdf suchen.

mfg, Stefan.

Autor: bone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das is ja cool :D

...gefällt mir :)
schon von jmd von euch realisiert?

Autor: Stefan May (smay4finger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das für Testaufbauten so realisiert. Funktioniert ganz prima, 
ist schnell aufgebaut und ist billig. Wer keine Transceiver in der 
Bastelkiste hat, sollte das ausprobieren.

Der Nachteil ist, daß man diesen "Bus" nicht mit dem normalen CAN-Bus 
koppeln kann.

mfg, Stefan.

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.