www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik anderer Atmega8 von Reichelt


Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Ich habe bei Reichelt 10 Atmega8 bestellt.
auf diesen läuft mein Programm "teilweise" und nicht immer.
Hat Aussetzer.
Mit anderen Atmega8, die ich früher hatte, war alles ok.
Habe jetzt alle 10 geflasht, fuse bits gesetzt wie immer.
Das Problem wiederholt sich immer.
Habe dann einen alten Atmega8 genommen, mit der SELBEN hex-Datei 
geflasht (war in PonyProg noch offen), und es läuft alles wie gewohnt.
Was kann das sein?

Auf den neuen µC steht
Atmel  1045
ATMEGA8-16PU

auf dem alten
Atmel  0716I
ATMEGA8-16PU

Stimmt da was mit der Charge nicht, oder was zum Teufel ist da los?

PS: Ich bin mir 100% sicher, dass die Fuses und HEX Dateien die selben 
sind.

Autor: unikum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, konkrete Antwort muß ich dier hier mal schuldig bleiben, aber über 
Reichelt liest, hört und erlebt man in letzter Zeit sehr viel Negatives:
Preistreiberei, minderwertige Qualität, ja, sogar Produktfälschungen.
Das alles mit steigender Intensität seit die Bude wohl verhökert wurde.
Ich hatte vor einigen Wochen auch noch ein paar Atmega8 von dort 
bezogen, sie aber noch nicht verwendet. Das kann ja eventuell auch bei 
mir noch heiter werden.
Dabei komme ich immer mehr zu dem Entschluß, Reichelt mal längere Zeit 
zu meiden. Mal sehen wie sich das noch entwickelt!?

Gruß, unikum.

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, ich konnte noch weitere 3 Atmega8 aus früheren Basteleien 
auftreiben.
Ich klicke in PonyProg auf Fusebits (die Einstellung bleibt immer 
gleich, sobald man das nicht selbst ändert), dann write.
Danach den Flash Speicher noch füllen.
Tatsache ist, bei ALLEN 3 alten Atmegas geht alles wunderbar, bei ALLEN 
10 neuen der selbe Fehler.
Ich kann mir das nicht erklären.
@unikum
Kannst du, bitte schauen, was bei deinen µC Rechts von "atmel" steht?

Danke

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das Problem wiederholt sich immer.

Welches Problem? Datenübertragung per UART klappt nicht?

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

Bewertung
0 lesenswert
nicht lesenswert
Das ist der Datecode, die neuen sind in KW45 2010 hergestellt, die alten 
in KW16 2007.

Möglicherweise gibt es neue Chiprevisionen, darüber sollte das jeweils 
aktuelle Datenblatt von Atmel sowie das entsprechende zur Revision 
gehörende Erratum aufklären.

Autor: Jens G. (jensig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das was rechtes von Atmel steht, wird die Chargenummer, oder 
Herstelldatum sein. Also mal die Eratas studieren, ob es da mal an für 
dein Programm entscheidender Stelle mal ein Problem gab.
Ansonsten könnten natürlich noch "lächerliche" Fehler deinerseits die 
Ursache sein: fehlende Resetbeschaltung, Abblock-C's, offene Eingänge, 
die vielleicht auf aktiver Interupts gehen, oder sonstwas. Kann durchaus 
sein, daß die neuen etwas empfindlicher auf sowas reagieren.

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielleicht ist ja auch einfach die schaltung so grottenschlecht, dass 
sie den armen avr eh schon über die spec-grenzen hinaus betreibt...

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke schön!
das hilft mit leider nicht wirklich weiter.
@holger
fast! es ist nicht UART, sondern ISP Kommunikation läuft jedes 3-4 mal 
nicht (total sporadisch).
Habe Datenblatt schon durchgelesen, aber nichts dazu gefunden.
Danke

Autor: Jens G. (jensig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht Interupts lost - s. Errata ...
Ansonsten wäre schonmal Layout, Schaltplan und (für die Programmierer 
unter uns) der Code (zumindest teilweise) nützlich.

Autor: unikum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mike,
ich muß mich etwas korrigieren. Mein Kauf stammt schon vom November 
letzten Jahres, wie doch die Zeit vergeht! Naja.
Der Aufdruck lautet demnach: 1013G
Aber, wie schon hier berichtet ist das ja das Herstellungsdatum. Ob Dir 
das was bringt?
Hast Du jetzt schon den Schweinepreis von 3,90 oder so bezahlt?

Gruß, unikum.

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, ich kann mit meinem English das nicht so ganz begreifen:
Interrupts may be lost when writing the timer registers in the 
asynchronous timer
Was heisst das? Übersetzen kann ich das, nur Verstehen klappt nicht 
ganz.

Ich benutze schon Interrupts, aber keinen Timer im Programm.
Das Programm reagiert auf Interrupt (ein Pin wird gelowert), aber die 
SPI Kommunikation findet nicht immer statt (ob komplett fehlt, oder 
fehlerhaft ist, weiss ich noch nicht).

Gruss Mike

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@unikum
ich habe 2,27 bezahlt. Artikel-Nr. ATMEGA 8-16 DIP
Habe ich einen "falschen" gekauft?
Kaufdatum: 02.02.11

Gruss Mike

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@holger
>fast! es ist nicht UART, sondern ISP Kommunikation läuft jedes 3-4 mal
>nicht (total sporadisch).

Wenn du SPI meinst, dann setz den SS Pin mal auf Ausgang.
Wenn du ISP meinst (Chip programmieren) dann setz die
ISP Frequenz auf 125kHz.

Autor: unikum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mike,

> Habe ich einen "falschen" gekauft?

Nee, Preis scheint in Ordnung. Den anderen Preis hatte ich aus einem 
anderen Thema dieses Forums. Da ging`s wohl mehr um einen Mega88. Wäre 
aber trotzdem ganz schön happig.

Gruß, unikum.

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@holger
Sorry, schreibe leider in Bascom
 Config Spi = Hard , Data Order = Msb , Master = Yes , Polarity = Low , 
Phase = 0 , Noss = 1 , Clockrate = 16

Erklärung:
Syntax for hardware SPI
CONFIG SPI = HARD, INTERRUPT=ON|OFF, DATA ORDER = LSB|MSB , MASTER = 
YES|NO , POLARITY = HIGH|LOW , PHASE = 0|1, CLOCKRATE = 4|16|64|128 , 
NOSS=1|0 , SPIIN=value

>Wenn du SPI meinst, dann setz den SS Pin mal auf Ausgang.

Warum funktioniert das dann mit den alten µC?

Danke
Gruss Mike

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Wenn du SPI meinst, dann setz den SS Pin mal auf Ausgang.

>Warum funktioniert das dann mit den alten µC?

Die reagieren evtl. nicht ganz so empfindlich wenn
der SS Pin offen und ein Eingang ist. Meine Erfahrung
mit offenem SS Pin: Einmal mit der Hand zu nah an die Schaltung
und SPI ist tot. Handy daneben reicht auch schon. Reines Glücksspiel;)

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
achso, das meinst du!
ALLE unbeschaltete Pins sind von Anfang an als Ausgänge definiert.
Daran liegt das dann nicht.

hm....

Gruss Mike

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wichtig ist der /SS-Pin, er muß vor dem SPI-Kram als Ausgang gesetzt 
werden!

Wenn das SPI scheinbar hängt, wurde es durch nen floatenden /SS-Pin in 
den Slavemode gesetzt.


Peter

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, die unbeschalteten Pins sind ganz am Anfang des Programms (als 
erstes nach der µC Konfiguration) als Ausgänge gesetzt.

Ich kann mir schon vorstellen, dass es am Programm liegen könnte, aber 
das hat doch schon früher so IMMER funktioniert, und ich habe viele von 
diesen Platinen gebaut. Mit der selben Belichtungsvorlage usw.

Danke
Gruss Mike

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Laut Speck und laut Bascom-Doku muss man den SS im Hardware-Master-Modus 
selber(!) setzen - ggf. aus Ausgang oder wenigstens per Pullup 
festhalten. Wenn der SS im Mastermodus Input ist und Low geht, dann geht 
der SPI in den Slavemodus [1]:
Serial Peripheral Interface – SPI
[..]
/SS Pin Functionality
[..]
Master Mode
[..]
If /SS is configured as an output, the pin is a general output pin which
does not affect the SPI system. Typically, the pin will be driving the /SS
pin of the SPI Slave.
If /SS is configured as an input, it must be held high to ensure Master SPI
operation. If the /SS pin is driven low by peripheral circuitry when the SPI
is configured as a Master with the /SS pin defined as an input, the SPI
system interprets this as another Master selecting the SPI as a Slave and
starting to send data to it. To avoid bus contention, the SPI system takes
the following actions:
1. The MSTR bit in SPCR is cleared and the SPI system becomes a Slave. As a
   result of the SPI becoming a Slave, the MOSI and SCK pins become inputs.
2. The SPIF Flag in SPSR is set, and if the SPI interrupt is enabled, and
   the I-bit in SREG is set, the interrupt routine will be executed.
[..]

Einfach mal testen, koscht ja nüscht.

HTH

[1] aus: Datenplatt vom m8 
http://www.atmel.com/dyn/resources/prod_documents/... Seite 129

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>fast! es ist nicht UART, sondern ISP Kommunikation läuft jedes 3-4 mal
>nicht (total sporadisch).

Was passiert denn da? Kompletter Hänger oder Daten falsch?

Autor: aaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meinst du wirklich ISP oder SPI?
Beim Atmega88 vom Reichelt (ähnliches Herstellungsdatum) habe ich in 
letzter Zeit ähnliche Fehler gehabt: Haben sich nicht richtig 
programmieren lassen bzw. nur immer einmal pro Strom-aus-Strom-an.
Programmer war ein Dragon, also nix bastelei oder so ;-)

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@g457
Danke für Deine Mühe, aber ich denke nicht, dass es das Problem ist.
Link: 
http://avrhelp.mcselec.com/config_spi.htm?zoom_hig...
Hier noch mal meine SPI Konfiguration:

Config Portb.2 = Output
........
Config Spi = Hard , Data Order = Msb , Master = Yes , Polarity = Low , 
Phase = 0 , Noss = 1 , Clockrate = 16

"NOSS = 1 or 0. Use 1 when you do not want the SS signal to be generated 
in master mode."


@holger
Nein, kein kompletter Hänger des µC/Programms

Der µC sendet gelegentlich die GLEICHEN Daten per SPI an einen anderen 
IC.
Der Empfänger reagiert manchmal auf die Daten nicht.
Das heisst wenn es 1 mal pro minute eine 8 Byte-lange Nachricht gesendet 
werden soll, kann das sein, dass es einmal (angenommen nach 5 minuten) 
nicht ankommt, dann gehts aber weiter, dann fehlen wieder die Daten.

Kann jetzt leider nicht sehen, ob der SPI komplett nicht sendet, oder 
"Müll" sendet.

DAnke
Gruss Mike

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Der µC sendet gelegentlich die GLEICHEN Daten per SPI an einen anderen
>IC.
>Der Empfänger reagiert manchmal auf die Daten nicht.

Programmfehler oder Schaltungsfehler.
Viel Spass beim suchen;)

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe gerade 3 µC, mit den es funktioniert (seit Monaten in Betrieb, kein 
Aussetzer). Und 10 neue m8, mit den es nicht funktioniert.

Wenn ich aus dem alten m8 das programm auslese, dann den neuen m8 
einsetze und das Ganze vergleiche, dann sagt Pony "Verify successful".

Das kann doch nicht sein, oder?

Danke
Gruss Mike

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mike schrieb:
> Das kann doch nicht sein, oder?
richtig... darum:

holger schrieb:
> Programmfehler oder Schaltungsfehler.

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, danke
...
Falls noch Jemand eine Idee hat, bitte schreiben.
Gruss Mike

Autor: Nachtaktiver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mal mit mehr Infos zu deiner Applikation?

Autor: Hans W. (stampede)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was willst du erwarten es ist ein ATMEL :)

Nein, Spass beiseite. Ich wuerde nochmal gezielt darauf schauen, was 
sich in der Zeit am Chip getan hat (Erratas, Silicon Revisions). Es kann 
ja durchaus sein, dass du irgendwo in nem Randbereich arbeitest, was bei 
dem alten Kontroller funktioniert hat. Der neue ist aus irgendwelchen 
Gruenden empfindlicher, Atmel hat aber beispielsweise die ganzen Werte 
nicht nochmal extra geprueft (oder geaendert und weist nicht explizita 
daruaf hin). Ich kann mir naemlich nicht vorstellen, dass das ein Fehler 
von Reichelt ist.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also ich kenne dieses Problem! Bei uns funktionierten ALLE Atmega8 mit 
einem "G" so wie von TE beschrieben eben NICHT. Ich kann das Problem 
nicht eingrenzen. Ich habe viele ältere Atmega8 getestet (gar kein 
Buchstabe hinter dem Datumscode, I oder N ...) Egal welche, alle 
funktionieren so wie es erwartet wird. Nur die mit "G" wollten irgendwie 
nicht richtig.

Unser Programmierer hat dann das Program grundlegend überarbeit und nun 
funktioniert es mit jedem Chip. Leider kann er auch nicht sagen welche 
Änderung das nun bewirkt hat.

Also ich konnte zwar nicht helfen aber zumindest die Beobachtung von 
Mike bestätigen...

grüße

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas schrieb:
> Unser Programmierer hat dann das Program grundlegend überarbeit und nun
> funktioniert es mit jedem Chip. Leider kann er auch nicht sagen welche
> Änderung das nun bewirkt hat.

Also eben Software Fehler....

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan S. schrieb:
> Andreas schrieb:
>> Unser Programmierer hat dann das Program grundlegend überarbeit und nun
>> funktioniert es mit jedem Chip. Leider kann er auch nicht sagen welche
>> Änderung das nun bewirkt hat.
>
> Also eben Software Fehler....

Nicht unbedingt!
Kann auch bedeuten: Hardwarebug in der neuen µC Revision Umschifft!

Wenn ich das so lese dann weiß ich schon warum ich häufiger PICs 
einsetze. Wenn ich da einen Baustein bestelle bekomme ich auch genau 
denselben Baustein wie seit Jahren... Die neuen Revisionen werden am 
Namen kennlich gemacht -
Das kann ganz schön nervig werden wenn sich die µCs einer Serie 
unterschiedlich verhalten und man nur irgendwie anhand des Datecodes 
nach erhalt schätzen kann was man genau in den Händen hat! Vorzugsweise 
in kritischen Projektphasen tritt soetwas dann auf.
Daher sollte es eigendlich ein No-go sein funktionsverschiedene 
Versionen zu haben die man bei der Bestellung nicht auseinanderhalten 
kann.

Gruß
Carsten

Autor: Jan S. (jan_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe von Atmel nicht den Eindruck, das Hardware Bugs verschwiegen 
werden.
Und funktional unterschiedliche Versionen der AVRs wurden bislang auch 
mit neuen Bezeichnungen gekennzeichnet.

Ich muss meine Behauptung allerdings auf Software- oder 
Hardwaredesignfehler ändern.

Es gibt ne Menge Fehler im Platinenlayout, welche man durch eine 
Softwareänderung noch umschiffen kann. Z.B.:
Langsameres Timing bei Leiterbahnen mit zu hoher Kapazität oder 
Induktivität.
Nicht mehrere Pins zeitgleich schalten, wenn man Ground-bounce hat.

Da gibts so einiges was man tun kann...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:

>> Also eben Software Fehler....
>
> Nicht unbedingt!

Aber sehr wahrscheinlich.

Gerade das SPI-Interface hat sich seit einem Jahrzehnt praktisch nicht
mehr geändert.

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> denselben Baustein wie seit Jahren... Die neuen Revisionen werden am
> Namen kennlich gemacht -
ähm... nein.

> Daher sollte es eigendlich ein No-go sein funktionsverschiedene
> Versionen zu haben die man bei der Bestellung nicht auseinanderhalten
vielleicht sollte man aber auch einfach nur den eigenen fehler in der 
eigenen software finden?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würd mal an den /SS-Pin (PB2) nen Pullup 1k ranpappen.
Wenns dann geht, stimmt doch was mit der Init-Reihenfolge nicht oder er 
wird zwischendurch mal floatend gesetzt.

Dann kannst Du noch nen Gegentest mit den alten M8 machen, d.h. einen 1k 
Pulldown an /SS und auch die alten gehen nicht mehr.

Daß sich verschiedene Chargen bei nem floatenden Pin unterschiedlich 
verhalten, liegt an den Leckströmen und ist kein Bug.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[erledigt, habe Peters Artikel editiert - Mod.]

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, Leute!
Also, ich habe jetzt ein 470 Ohm Pull-up nach SS (PB2) gelegt.
Der Fehler ist fast! weg.
Kommt nur noch selten vor.
Also vielen Dank an Alle, speziel an Peter!
Habe jetzt noch mal den alten m8 eingesetzt, und eine Weile lang 
beobachtet. Damit kommt der Fehler definitiv NICHT vor.
Was kann es denn noch sein?
Danke
Gruss Mike

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Also, ich habe jetzt ein 470 Ohm Pull-up nach SS (PB2) gelegt.
>Der Fehler ist fast! weg.

Buuuuuaaaaah. Sag mal hast du sie noch alle?
Schalte den Scheiss Pin auf Ausgang. Dann brauchst du
keinen Pullup.

Die Reihenfolge zum initialisieren:

SS Pin auf Ausgang.
Danach das SPI Modul initialisieren und gut iss.

Autor: Qwertz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Mike

Das würde mich jetzt auch mal interessieren:
Hast Du schon die Gegenprobe lt. Peters Empfehlung gemacht? Also alten 
Mega8 und Pulldown?

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>SS Pin auf Ausgang.
>Danach das SPI Modul initialisieren und gut iss.
So habe ich das auch gemacht.
Habe doch oben schon geschrieben.

>Also alten Mega8 und Pulldown?
Habe ich gerade probiert.
Alte und neue m8 senden trotz Pull-down.
Weil der pin eben vorher als Ausgang definiert ist.

Dann verstehe ich aber nicht, warum der Pull-up eine Besserung bringt?

Gruss Mike

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mike schrieb:
> Dann verstehe ich aber nicht, warum der Pull-up eine Besserung bringt?

Hmm, zeig' doch mal die Schaltung dazu ...

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hmm, zeig' doch mal die Schaltung dazu ...
Hätte ich schon längst gemacht, aber ich habe die nicht. Ich meine die 
Schaltung existiert (noch) nicht "auf Papier"
Gruss Mike

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mike schrieb:
> Hätte ich schon längst gemacht, aber ich habe die nicht. Ich meine die
> Schaltung existiert (noch) nicht "auf Papier"
> Gruss Mike

das ist normalerweise das erste was man macht.

Auch bei Lochraster kann man so doch das Layout wenigstens planen, dass 
möglichst wenig drähte verlötet werden müssen.

Außerdem reicht da auch nach Jahren ein Blick drauf und man sieht wie 
alles zusammenspielt, ohne irgendwelche Gehäuse zu öffnen und ewig 
verworrene Drähte durchzumessen.

Es Programmiert sich doch auch einfacher, wenn man auf einen Blick 
sieht, wo was dranhängt.

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gleich kommt das steckbrett...

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nein, nein. Ist kein Steckbrett.
Gruss Mike

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

Bewertung
0 lesenswert
nicht lesenswert
Mike schrieb:
>>Hmm, zeig' doch mal die Schaltung dazu ...
> Hätte ich schon längst gemacht, aber ich habe die nicht. Ich meine die
> Schaltung existiert (noch) nicht "auf Papier"

Dürfte kaum länger als 'ne Viertelstunde dauern, die mit 'nem Stift auf 
Karopapier zu malen, wo also ist das Problem?

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.