mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ISP-Mode Fehler bei Programmierung ATMEGA16 mit STK500


Autor: Sven G. (u-s-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bin neu hier im Forum und daher möchte ich kurz einige Sätze zu meiner 
Person schreiben, da ich bzgl. MCs und Elektrotechnik blutiger Anfänger 
bin: Bringe zwar einige Erfahrungen aus Programmierung in C, Assembler 
und einigen anderen Programmiersprachen mit, allerdings bezogen sich bis 
vor kurzem diese Kenntnisse ausschließlich auf Entwicklung von einfacher 
Anwendungssoftware.
Hinsichtlich Elektrotechnik und vor allen Dingen der Hardware rund um 
MCs habe ich ein äußerst lückenhaftes Grundwissen und tue mich mit 
meinem neuen Hobby der MC-Programmierung noch etwas schwer.
Nachdem ich zwei Bücher (Schmitt, Trampert)gelesen habe, bin ich vor 
etwa zwei Wochen auf dieses Forum gestoßen, welches ich abendlich 
seither fleißig studiert habe.
An dieser Stelle ein Lob an Euch, ist wirklich eine tolle, sehr 
informative Internetpräsenz inkl. Forum.
Einige meiner Fragen konnte ich bereits durch lesen beantworten und auch 
das Tutorial hat mir bei meinen ersten Schritten sehr geholfen. Wirklich 
klasse.
Allerdings komme ich seit einigen Tagen trotz Forum nicht weiter. An 
dieser Stelle möchte ich bereits jetzt um Nachsicht bitten, falls es 
sich in Euer Augen um eine triviale Sache handeln mag oder die Dinge an 
anderer Stelle in anderer Form behandelt wurden (aus Foren im Bereich 
Maschinenbau ist mir die Problematik mit Anfängern durchaus geläufig).


Aber zum Problem:

Besitze ein STK500 und programmiere derzeit die Prozessoren vom Typ 
"ATMEGA16 16PC". Bei einfacheren Programmen bei welchen ich z.B. LEDs 
angesteuert habe, hat bisher alles prima funktioniert.

Nun habe ich mir ein kleines Programm für ein kleines Steuergerät 
geschrieben, mit welchem ich über den prozessorinternen AD-Wandler eine 
Spannung (0 bis 5V) messe. Diesen Istwert vergleiche ich mit einem 
Sollwert. Entsprechend des Istwertes soll ein Pin am PortC bestromt 
werden um einen Transistor anzusteuern (oder nicht). Das Programm hat 
beim Debuggen und der Simulation einwandfrei funktioniert.

So weit so gut. Was seltsamerweise jetzt nicht mehr klappt ist das 
flashen des ATMEGA16.

Wenn ich versuche zu flashen erscheint ein "ISP-Mode Error".
(Alle Meldung OK, bis auf:
PROGRAMMING FLASH.. Failed!)

Da ich den Prozessor mit meinen anderen Programmen beschreiben kann und 
ich schon andere Prozessoren verwendet habe, vermute ich ja, daß ich bei 
der Konfiguration etwas geändert werden muß, sobald ich den AD-Wandler 
verwende.

Hat jemand vielleicht einen Tipp für mich woran das liegen könnte und 
worauf bei der Konfiguration zu achten ist? Ich weiß im Moment nicht mal 
wo ich ansetzen muß, da viele Sachen für mich noch böhmische Dörfer 
sind.
Im Voraus vielen Dank.


Nachfolgend mein Programm:

 .INCLUDE "m16def.inc"
  .DEF adhb = r18
  .DEF sollwert = r19
  .DEF ausgang = r20
  .CSEG
  rjmp start
  .org $10
start:
;Portkonfiguration
     ldi r16, 0x00
     out DDRB, r16
       out DDRA, r16
     ldi r16,0xFF
     out DDRC, R16


; Konfiguaration AD-Wandlung an Port A (über Steuerbytes ADMUX und 
ADCSR)


     ldi r16, 0b00100000
     out ADMUX,r16
    ; Referenzspannung extern an Pin AREF, Ergebnis linksbündig 
Highbyte, Messung an PIN ADC0
     ldi r16, 0b11000101
     out ADCSR, r16
    ; Modus single Conversion mit Taktteiler 32



;Sollspannung einlesen:
      ldi sollwert,0b00000000
    in sollwert, PINB


haupt:
;AD-Wandlung
       sbic ADCSR, ADSC
       rjmp haupt

;Vergleich Istspannung mit Sollspannung
     in adhb,ADCH
     cp adhb, sollwert
     brsh keinstrom
     cp adhb, sollwert
       brlo strom
     rjmp weiter
  keinstrom :
     ldi ausgang, 0b00000000
     out PORTC, ausgang
     rjmp weiter
  strom:
     ldi ausgang, 0b10000000
     out PORTC, ausgang
     rjmp weiter

weiter:
     sbi ADCSR,ADSC
     rjmp haupt
     .EXIT

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das Programm ist dem Programmer sowas von egal solange das Fileformat 
stimmt und der Prozessor der eingestellte ist.

Prozessor im richtigen Sockel?
Nur ein Prozessor gesteckt?
ISP-Clock passt (max. 1/4 des CPU-Taktes)?
ISP-Kabel richtig gesteckt?

Gruß aus Berlin
Michael

Autor: Sven G. (u-s-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielen Dank für Deine Antwort, es wäre schön wenn es daran liegen würde.


Ich schrieb ja schon oben, daß ich den Prozessor programmieren kann. 
Bedeutet: ich spiele z.B. ein LED-Programm auf und ich kann 
programmieren. Klappt alles einwandfrei.
Das STK500 fasse ich nicht an, sondern wechsel nur im AVR-Studio mein 
Programm und es funktioniert nicht.
Wechsel ich wieder das Programm auf z.B. das LED-Programm kann ich 
programmieren, ohne auch nur etwas am Setup des STK500 geändert zu 
haben, noch den Prozessor berührt zu haben.


Um die Fragen zu beantworten:

-Sockel ist der 3100A3. Prozessor ist richtig eingesetzt (Markierung)
-es ist auch nur ein Prozessor gesteckt
-ISP-Clock ist auf 57,6 kHz eingestellt
-ISP-Kabel ist mit von ISP6PIN mit SPROG3 (unverdreht) verbunden.

Grüße
Sven

P.S. Was hat es eigentlich mit der ISP-Clock genau auf sich?

Autor: Sven G. (u-s-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe das Programm jetzt Stück für Stück neu geschrieben und nach jeder 
Zeile auf den ATmega16 programmiert.

Funktioniert alles bis ich die Zeile inkl Sprungziel schreibe.

   brsh keinstrom
:keinstrom

Woran kann das liegen?


Mir ist auch noch aufgefallen, daß die Signatur nicht passt 'Signature 
does not match selected device'.

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Habe das Programm jetzt Stück für Stück neu geschrieben und nach jeder
>Zeile auf den ATmega16 programmiert.
>
>Funktioniert alles bis ich die Zeile inkl Sprungziel schreibe.
>
> brsh keinstrom
>:keinstrom

Ich geh mal davon aus, dass Du hier niemanden veräppeln willst. Die 
interessante Frage ist jetzt, was passiert, wenn Du das 'brsh' testweise 
--> an einer anderen Stelle <-- einfügst?

Wenn das Programmieren dann funktioniert, ist dies wohl als Indiz für 
einen physikalischen Defekt der betreffenden Flash-Speicherzelle zu 
werten.  Vielleicht im Zusammenhang mit der Eigenschaft von Flashmemory, 
nur eine begrenzte Zahl von Schreibzyklen (Größenordnung 10000) 
mitzumachen?

Wenn das Programmieren dann auch NICHT funktioniert, wäre das ein sehr 
sehr SEHR seltsamer Fehler, der eigentlich gar nicht existieren kann :-) 
Einen Grund dafür gäbe es allerdings doch - wenn auch eher theoretisch. 
Wenn das zur 'brsh'-Instruktion gehörende Bitmuster sehr viele Einsen 
oder Nullen beinhaltet, braucht das Programmieren entsprechend viel 
Strom - vielleicht so viel, dass Deine Versorgungsspannung auf einen 
ungenügenden Wert einbricht.

Autor: Sven G. (u-s-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nein, nein. Mir ist das wirklich ernst, da ich hier wirklich am 
Verzweifeln bin und schon das STK500 als defekt in Verdacht habe.

Jedenfalls schon mal vielen Dank für Deine Antwort AVRFan, ich glaube 
das ging schon mal in eine richtige Richtung.

Nachdem ich diese Tipps beherzigt habe scheint in der Tat so, daß es mit 
dem Befehl 'brsh' nichts zu tun hat, sondern mit dem 17.Befehl in diesem 
oder in einem anderen Programm.

Ist das Programm kürzer (so wie meine anderen bisher getesteten 
Programme), dann gibt es keine Probleme. Sobald das Programm eine Länge 
von 17 Befehlen oder mehr aufweist, tritt der Fehler auf.

Im Rahmen des Experimentierens habe ich dann mal eine serielle High 
Voltage Programmierung durchgeführt.
Seltsamerweise tritt hier keine Fehlermeldung bei der Programmierung 
auf. Diese scheint daher auf den ersten Blick erfolgreich durchgeführt 
worden sein, was dem aber nicht so ist.
Über die Funktion 'Verify Flash' im Bereich Auto läßt sich nach der 
seriellen HV-Programmierung folgende Fehlermeldung generieren:

Warning: Flash Byte Adress 0x0000 is 0xff (should be 0x0F).. Failed!

Ich habe solch eine Fehlermeldung als Bildschirmausdruck als Dateianhang 
beigefügt.

Daraufhin habe ich den Flash-Speicher ausgelesen und überprüft was 
tatsächlich auf den Speicher geladen wurde. Siehe da, die Programmierung 
ist unvollständig. Die Befehle des Programmes mit den Adressen > 18 
wurden zwar geladen, aber alles was vor (einschließlich) des 17. Befehls 
steht, d.h. der Anfang des Programmes, fehlt.

Wie geschrieben, das passiert bei der seriellen High Voltage 
Programmierung. Über ISP, läßt es sich erst gar nicht programmieren.
Erst wenn das Programm Befehle <17 hat, dann funktionieren beide 
Programmierungen einwandfrei.


Daraufhin habe ich mir gedacht, wenn es denn an einem zerschossenen bit 
oder Byte liegt, verändere ich die Adressierung des Programmbereiches 
(hoffe diese Logik macht grundsätzlich Sinn) und habe am Programmanfang 
die Direktive
.org$10

gegen die Direktive

.org$90 getauscht.

Ergebnis ist das gleiche nur die Fehlermeldung hat sich dagingehend 
geändert, daß jetzt 'Flash Byte Adress 0x0120...' ausgegeben wird.



Was mich noch weiter wundert ist, ich habe 3 Prozessoren vom Typ 
ATmega16, die ich zeitgleich vor etwa einer Woche als Neuware gekauft 
habe. Die Dinger habe ich bestimmt nicht mehr als 20 mal beschrieben 
(mittlerweile zwar mehrfach, aber weit unter 1000). Das Problem taucht 
bei allen meinen drei Prozessoren auf.
Insofern müßte es ja ein riesiger Zufall sein, daß alle drei Prozessoren 
unter dem gleichen Fehler leiden.


Zur Stromversorgung. Ich habe eine Labornetzteil Voltcraft 1405Pro (u.a. 
0 bis 40V bei 5A). Daran sollte es eigentlich nicht liegen - oder irre 
ich mich?
Programmieren tue ich bei 12,2V.



Ansonsten was hat es zu bedeuten - oder in welchem Zusammenhang könnte 
es stehen - daß wie bereits in meinen vorangehenden Beitrag aufgeführt, 
die Signatur nicht passt?


Weiterhin vielen Dank für Eure Hilfe.

Autor: Sven G. (u-s-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab jetzt einen nagelneuen ATmega8 eingesetzt und wollte die Signatur 
überprüfen. Passt auch nicht.

'Signature does not match selected device'.

Das kann doch nicht sein!?! ISt das Board vielleicht doch kaputt? Ich 
möchte jetzt den Atmega8 nicht einfach mal ins blaue programmieren bevor 
ich nicht weiß was los ist...

Jemand noch eine Idee woran so etwas überhaupt liegen könnte?

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ISt das Board vielleicht doch kaputt?

Meine vorsichtige Meinung: Die Symptome deuten leider darauf hin. 
Defekte Controller kann man mittlerweile ausschließen.  Hmm, da ist 
guter Rat teuer.  Ich würde alle Kabel und Controller vom Board 
abziehen, es zuerst einer gründlichen Sichtprüfung (nah unter einer 
Lampe, damit man auch was erkennen kann) unterziehen und danach mit 
einem Pinsel, und zwar einem von der festeren Sorte, d. h. keinen 
Staubpinsel.  Über zwei nebeneinandergelegten, leeren DIN-A4-Seiten, 
damit man hört, wenn was fällt und es anschließend findet.  Alle Ecken 
und Winkel penibel "auskehren".  Sollte sich ein Lötzinnkrümelchen oder 
ein kurzes Drahtstück irgendwohin verirrt haben und dort was 
kurzschließen, ist dies vielleicht die Rettung für Dein Board.  Eine 
weiterer Test bestünde darin, zu versuchen, ein Firmware-Update 
durchzuführen (geht wahrscheinlich  nur, wenn das Board nicht schon auf 
dem neuesten Stand ist).

Maue Tipps, ich weiß, sorry... :-|

Autor: Peter Roth (gelb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du in deinem AVR Studio mal im Menü Debug / Select Platform & 
Device nachschaust, erscheint dort als Device der Mega 16? Das 
AD-Wandler-Programm muss natürlich geladen sein.

Wenn nicht, wäre das die Erklärung, warum die Signatur nicht passt. 
Außerdem könnte dein Code für einen (falsch ausgewählten) kleineren AVR 
zu lang sein und seltsame Fehlermeldungen provozieren.

Grüße, Peter

Autor: Sven G. (u-s-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ertsmal danke für Eure Antworten. Das Problem ist leider immer noch da 
:-(

Äußerlich sind kein Defekte am Board erkennbar. Auch wenn ich Lötkrümel 
ausgeschlossen habe, da ich das Board erst vier Wochen habe und sehr 
sorgsam damit umgegangen bin und die Lötarbeiten an ganz anderer Stelle 
stattfinden, habe ich den Rat befolgt. Es hat keine Änderungen bewirkt.

Das neuste Update ist auf dem Board aufgespielt, ebenso wie die neuste 
mir bekannte Version vom AVR-Studio (SP2 build 571) ist auf dem Rechner 
drauf.

Zu:
Menü Debug / Select Platform & Device

ATmega16 ist eingestellt.


So wie die Sache jetzt ausschaut werde ich gleich mal zum Bekannten mit 
meinem STK500 fahren und ihn mal drüber schauen lassen ggf. mir mal 
seins ausleihen bevor ich mir ein neues kaufe.

Werde weiter berichten.

Autor: Sven G. (u-s-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also es sieht so aus, als ob mein Board kaputt ist :-( Werde es 
umtauschen.

Beim Bekannten geht es auch nicht. Mit seinem Board klappt aber alles 
einwandfrei so wie es soll.


Trotzdem vielen, vielen Dank für Eure Tipps und Unterstützung.

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So was Doofes, das tut mir leid für Dich.

Hier noch ein Link zu einer (englischsprachigen) 
"STK500-Reparaturanleitung", deren Inhalt ich mir jedoch nicht angesehen 
hab:

http://www.build-a-bot.com/STK500//fixstk500.zip

Jetzt musst Du nur noch den einen alles entscheidenden hilfreichen 
Hinweis darin finden - falls existent... ;-)

Außerdem gibt es auch einen Schaltplan des STK500:

http://www.build-a-bot.com/STK500//STK500_Schematics.zip

Und zu guter Letzt noch eine deutsche Übersetzung des STK500-Handbuchs:

http://home.arcor.de/matrixman/STK500-HW-Beschreibung.pdf

Vielleicht ist etwas davon ja in irgendeiner Form für Dich (oder Deinen 
Bekannten) nützlich.

Autor: Sven G. (u-s-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Anleitungen. Vielleicht werde ich sie irgendwann mal 
benötigen bzw. für andere möglicherweise jetzt schon hilfreich.

Hab jetzt ein neues STK500 und es klappt alles perfekt.

Euch ein schönes Wochenende und nochmals danke für diese tolle und 
schnelle Unterstützung.

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerne, und Dir gleichfalls ein nice WE sowie allzeit funktionierendes 
neues STK500 :-)

Autor: Sven G. (u-s-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-)

Bevor ich ein neues Thema aufmache, vielleicht nochmal eine Frage zu 
meinem Programm, da es nicht so funktioniert wie ich möchte. (wenn ich 
ein neues Thema aufmachen soll, kein Thema)

Es geht um den Anschluss AVCC und AGND.

Laut Datenblatt vom ATmega16 soll AVCC an VCC und AGND an GND 
angeschlossen werden. Zur Rauschunterdrückung ist ein Beispielschaltung 
mit einer Spule und einem Kondensator für AVCC angegeben. Sie ist aber 
nicht zwingend notwendig, sondern Anschluß an VCC sollte auch direkt 
funktionieren und für eine 8bit-Auflösung ausreichend sein.
Da ich im Moment nur einen passenden 100nF Kondensator habe (Spule wird 
noch gekauft), habe ich AVCC direkt an VCC angeschlossen. Es geht ja im 
Moment auch mehr um die Funktion des Programmes.

Das Ergebnis ist äußerst merkwürdig. Mein Ausgabeport (PortC) wird 
permanent mit folgender Bitbelegung 11110111 belegt.

Nach längerem hin und her habe ich dann mal mein Programm, unten stehend 
genannt, abgewandelt. Ohne AD-Wandlung und den PortC als Ausgabeport von 
Eingabe-PortB programmiert.
Es ändert sich nichts. PortC ist immer noch noch mit 11110111 permanent 
belegt.

Entferne ich den Anschluß zu AVCC, d.h. AVCC ist überhaupt nicht 
angeschlossen und hängt frei, dann klappt das nachstehende Programm 
prima und PortC gibt das aus was ich über PortB binär eingebe.

Woran könnte das liegen?


.INCLUDE "m16def.inc"
  .DEF akku = r16
  .DEF toleranz = r17
  .DEF spannunghb = r18
  .DEF sollwert = r19
  .DEF ausgang = r20
  .CSEG
  rjmp start
  .org $10
start:
; Einstellung der Ports
     ldi r16, 0x00
     out DDRB, r16
     ldi r16,0xFF ;
     out DDRC, r16 ;
     out PORTB, r16
     ldi akku, 0b00000000
     out PORTB, akku
     out PORTC, akku

schleife:
    ldi sollwert,0b00000000
    in sollwert, PINB
    ldi toleranz, 0b00000001
           out PORTC, sollwert
    rjmp schleife
    .Exit

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

JTAG-Interface ausschalten.

MfG Spess

Autor: Sven G. (u-s-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon mal vielen Dank.

JTAG war aktiviert wobei das doch nur die Pins 24 bis 27 betrifft?! Oder 
irre ich mich?

Muß jetzt gleich weg, daher konnte ich mich noch nicht ausreichend 
beschäftigen allerdings das Ergebnis gefällt mir immer noch nicht.
Die Pins lassen sich an PortC über PortB schalten. Allerdings liegt die 
Spannung bei etwa 3V im neutralen Zustand an PortC. Lege ich den 
entspprechenden einen Pin bei B auf Masse fällt C auf 0V ab. Gebe ich 
Strom auf B, geht C auf 5V hoch. Sobald gar nichts drafu liegt ist es 
3V.

Muß nochmal schauen.

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>das Ergebnis gefällt mir immer noch nicht.

Es ist allerdings logisch.

>1     ldi r16, 0x00
>2     out DDRB, r16
>3     ldi r16,0xFF ;
>4     out DDRC, r16 ;
>5     out PORTB, r16
>6     ldi akku, 0b00000000
>7     out PORTB, akku
>8     out PORTC, akku

>Die Pins lassen sich an PortC über PortB schalten.

Klar, Du liest ja PINB in 'sollwert' ein und gibst 'sollwert' gleich 
danach auf PORTC (durch Zeile 3 und 4 als Ausgang konfiguriert) aus. 
Die Zeile "ldi sollwert,0b00000000" ist übrigens obsolet.

>Allerdings liegt die
>Spannung bei etwa 3V im neutralen Zustand an PortC.

Ja, weil Port B vor sich hin floatet.  Alle Pins sind ja als Eingänge 
ohne aktivierte Pullups konfiguriert.  Die Zeilen 1, 2, 6, 7 sorgen 
dafür (und 5 hat überhaupt keine Wirkung).  DDRB = 00000000 und PORTB = 
00000000. Messen könntest Du das Floaten an Port B niemals - sobald Du 
ein Messgerät zwischen einen Pin und GND oder VCC klemmst, ist es damit 
nämlich sofort vorbei, weil das Messgerät dann durch seinen 
Innenwiderstand den Pegel festlegt.  Aber an Port C ist ebendieses 
Floaten messbar, weil Port B ja dann weiterhin offen ist.  Das ist, was 
Du misst; die angezeigten "3 V" ist der zeitliche Mittelwert aus ständig 
unregelmäßig wechselnden L- und H-Pegeln.

Der "Fehlerbehebung" besteht natürlich darin, an Port B die Pullups 
einzuschalten, damit sie die Eingänge, an denen nichts angeschlossen 
ist, "schwach" (aber sicher) auf H-Pegel ziehen.

>Lege ich den
>entspprechenden einen Pin bei B auf Masse fällt C auf 0V ab. Gebe ich
>Strom auf B, geht C auf 5V hoch. Sobald gar nichts drafu liegt ist es 3V.

Jetzt weißt Du, wieso.

Autor: Sven G. (u-s-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Herzlichen Dank. Das hat mir sehr geholfen, insbesondere die Erklärung 
was passiert wenn keine Pull-Up-Widerstände eingeschaltet sind. Das war 
mir bis dato noch unklar. Bislang habe ich es einfach hingenommen, daß 
in solchen Fällen diese aktiviert gehören, sofern kein externer 
Widerstand angebracht wird (wenn ich das richtig verstanden habe).

Mit ein wenig Abstand ist mir auch klar, warum mein Programm nicht wie 
geünscht funktionieren konnte, da ich die Pullups gleich mit dem 
übernächsten Befehl wieder deaktiviert habe (ist doch richtig!?). War im 
festen Glauben, daß sie aktiviert gewesen sind.
Unter Strich war ich in der Situation einfach etwas überfordert da der 
ganze Stoff inhaltlich noch nicht fest genung sitzt, und es Freitag 
schnell gehen mußte (zu schnell) weil ich das Problem nicht mit ins 
Wochenende nehmen wollte. Einmal mehr der Beweis, daß Eile zur 
Unachtsamkeit verleitet und in der Ruhe die Kraft liegt. Hoffe, daß ich 
beim nächsten Mal von meiner Seite durchdachtere Fragen stelle.

Wie dem auch sei, ich habe viel dazugelernt und dafür ein dickes 
dankeschön ...und für Eure Geduld mit Anfängerproblemen :-)

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.