ATmega16 Port Ausgabe Problem

Moin,

1

/* Define pull-ups and set outputs high */

2

/* Define directions for port pins */

3

PORTB = (1<<PB7)|(1<<PB6)|(1<<PB1)|(1<<PB0);

4

DDRB = (1<<DDB3)|(1<<DDB2)|(1<<DDB1)|(1<<DDB0);

5

/* Insert nop for synchronization*/

6

__no_operation();

versuch mal mit NOP.

grüße

JTAG über Fuses deaktivieren.

Oder zur Laufzeit das JTAG Disable Bit setzen:
MCUCSR |= (1<<JTD);

Ich hoffe, du hast auch den zweiten GND Pin und AVCC angeschlossen.

Stefan Frings schrieb:
> Ich hoffe, du hast AVCC angeschlossen.

Was hat AVcc mit PORTC oder D zu tun?
"AVCC is the supply voltage pin for Port A and the A/D Converter."

Nicht die Hälfte weglassen, um Stunk zu provozieren, Herr Kollege!

SO steht's da:

AVCC is the supply voltage pin for Port A and the A/D Converter. It 
should be externally connected to VCC, even if the ADC is not used. If 
the ADC is used, it should be connected to VCC through a low-pass 
filter.

Und was hat das mit PORTC zu tun?

S. Landolt schrieb:
> Was hat AVcc mit PORTC oder D zu tun?

Ich habe mir dabei gedacht: sicher ist sicher.

Gut; ich hatte schon befürchtet, ich müsse meinen ATmega16 ausgraben 
(irgendwo muss einer sein) und das verifizieren.

Danke @all erstmal!

Also

Ich habe mich mit Fuses noch nicht ernsthft beschäftigt, aber dass sie 
mit Zuweisung einer 0 gesetzt werden weiss ich. In der Programmer 
Software muss ich auch nur Häkchen setzten oder entfernen.

Das an Port C ausgegebene Bitmuster nach PORTC = 0x00 ändert sich bei 
jeder neuen Session mit dem Programmer. Momentan wird bspw 1111 1111 
ausgegeben.

AVCC und den 2. GND anzuschliessen hat auch nichts gebracht

NOP() vor und/oder nach PORTC = 0x00 auch nicht

Zuweisung mit Bit-Operationen ist aber erfolgreich!
Hier der Code (verkürzt auf 4 Bit):

1

   int main (void)

2

   {

3

      DDRC |= ((1<<DDC3)|(1<<DDC2)|(1<<DDC1)|(1<<DDC0));

4

5

      PORTC &= ~((1<<PC3)|(1<<PC2)|(1<<PC1)|(1<<PC0));

6

      // PORTC |= (1<<PC2);

7

8

      while(1) 

9

      {

10

      }

11

12

      return 0;

13

   }

Damit ist die Frage, warum PORTC = 0x00 nicht funktioniert aber nicht 
geklärt.

Ich bekomme am Wochenende noch einen weiteren ATmega16 oder 32 und werde 
dann mal weitertesten

>avr-objcopy -O ihex -j .text -j .data test.elf test.hex

Lass die Angabe der Sections da mal weg.
Ich würde sagen .bss fehlt da auch.

avr-objcopy -O ihex test.elf test.hex

Volker A. schrieb:
> und den 2. GND anzuschliessen hat auch nichts gebracht

Vielleicht ist der Chip jetzt kaputt, weil du ihn vorher nicht 
angeschlossen hattest.

Generell würde ich mir immer mindestens einen zweiten Chip auf Vorrat 
legen, damit man solche Verdachtsmomente prüfen kann.

Für meine Steckbrett-Experimente habe ich zwei alte ATmega16 in der 
Bastelkiste, wie die vier Versorgungspins mit Drähten verbunden sind und 
auch ein Kondensator aufgelötet ist. So kann ich das niemals vergessen.

Meistens benutze ich aber kleinere ATtiny und Arduino nano Module. Die 
ATmega16 habe ich nur, weil so einer auf meinem NiboBEE Roboter saß.

Stefan Frings schrieb:
> Vielleicht ist der Chip jetzt kaputt, weil du ihn vorher
> nicht angeschlossen hattest.

Da die beiden GNDs beim ATmega16 intern verbunden sind, ist das nur sehr 
schwer vorstellbar.

S. Landolt schrieb:
> Stefan Frings schrieb:
>> Vielleicht ist der Chip jetzt kaputt, weil du ihn vorher
>> nicht angeschlossen hattest.
>
> Da die beiden GNDs beim ATmega16 intern verbunden sind, ist das nur sehr
> schwer vorstellbar.

Ich meine mich zu erinnern, dass im Datenblatt NICHT steht "schliessen 
Sie nach Belieben irgendeinen der GND-Pins an. Stattdessen steht da, 
dass ALLE angeschlossen werden müssen. Was hat sich der Hersteller wohl 
dabei gedacht?

SCNR

Peter D. schrieb:
> im Datenblatt ... Stattdessen steht da,
> dass ALLE angeschlossen werden müssen.

Im Datenblatt steht das eben nicht, da täuschen Sie sich.

S. Landolt schrieb:
> Peter D. schrieb:
>> im Datenblatt ... Stattdessen steht da,
>> dass ALLE angeschlossen werden müssen.
>
> Im Datenblatt steht das eben nicht, da täuschen Sie sich.

Aha. Doch ein Stunksucher. Die Vermutung von gestern hat sich also als 
richtig erwiesen.

Wenn du ein Spielzeugauto als Bausatz kaufst, und da steht an vier 
Stellen "Rad", ohne weitere Erklärungen. Wie viele Räder würdest du 
montieren?

S. Landolt schrieb:
> Da die beiden GNDs beim ATmega16 intern verbunden sind, ist das nur sehr
> schwer vorstellbar

Sie sind intern HOCHOHMIG (relativ gesehen zu Metall, also nur über den 
Chip) verbunden, denn im Datenblatt ist erkennbar

PDIP Package:
1] The sum of all IOL, for all ports, should not exceed 200 mA.
2] The sum of all IOL, for port A0 - A7, should not exceed 100 mA.
3] The sum of all IOL, for ports B0 - B7,C0 - C7, D0 - D7 and XTAL2, 
should not exceed 100 mA.
TQFP and QFN/MLF Package:
1] The sum of all IOL, for all ports, should not exceed 400 mA.
2] The sum of all IOL, for ports A0 - A7, should not exceed 100 mA.
3] The sum of all IOL, for ports B0 - B4, should not exceed 100 mA.
4] The sum of all IOL, for ports B3 - B7, XTAL2, D0 - D2, should not 
exceed 100 mA.
5] The sum of all IOL, for ports D3 - D7, should not exceed 100 mA.
6] The sum of all IOL, for ports C0 - C7, should not exceed 100 mA.

dass der Strom von bestimmten Ports mit bestimmten, bei TQFP mehr als 
bei DIP, GND und VCC Pins gut verbunden sind und schlechter mit anderen.

Ich möchte an den Auslöser erinnern, nämlich, dass der Chip Schaden 
genommen hat, weil nicht alle GNDs angeschlossen waren; und den eingangs 
genannten Fehler auf PORTC zur Folge hatte. Das glaube ich nicht, und 
das wollte ich zur Diskussion stellen, nicht mehr und nicht weniger.

Als Diskussionsgrundlage: ich habe jetzt doch mal einen ATmega16-16PU 
(von 1431) hervorgekramt und nachgemessen: zwischen den beiden GND sind 
es 1,6 Ohm.

Peter D. schrieb:

> Ich meine mich zu erinnern, dass im Datenblatt NICHT steht "schliessen
> Sie nach Belieben irgendeinen der GND-Pins an. Stattdessen steht da,
> dass ALLE angeschlossen werden müssen. Was hat sich der Hersteller wohl
> dabei gedacht?

Ich glaube auch, Herr Landolt verwechselt hier was. Meines Wissens nach 
existiert nur beim Atmega8 diese interne Verbindung zwischen GND und 
AGND. Allerdings muss ich zugeben, dass ich das niemals systematisch 
erforscht habe und der Herr Landolt i.A. sehr zuverlässige Aussagen 
macht. Es könnte also trotzdem gut sein, dass er Recht hat.

S. Landolt schrieb:

> Als Diskussionsgrundlage: ich habe jetzt doch mal einen ATmega16-16PU
> (von 1431) hervorgekramt und nachgemessen: zwischen den beiden GND sind
> es 1,6 Ohm.

Also keine interne Verbindung. Das ist parasitär. Wo lang das auch immer 
intern laufen mag...

Okay - aber könnte dadurch tatsächlich der Chip beschädigt werden und 
dieses crude Fehlerbild an PORTC entstehen?

S. Landolt schrieb:

> Okay - aber könnte dadurch tatsächlich der Chip beschädigt werden und
> dieses crude Fehlerbild an PORTC entstehen?

Da niemand außerhalb Atmel/Microchip die Innenschaltung kennt, muß man 
das zumindest in Erwägung ziehen.

Nun denn - vielleicht kommt mehr Licht in die Sache, wenn Volker A. die 
neuen ATmega16 erhalten hat.

Oliver S. schrieb:
> Entweder macht dein
> Programmer Unsinn, oder das Problem sitzt vor dem Bildschirm.

Davon gehe ich auch aus. Ich mach das so als Hobby und habe für meine 
ATmega Projekte bislang immer das praktische Arduino Uno Board 
verwendet. Ohne irgendeine IDE, sondern mit der AVR Toolchain + 
avrdude.exe. Funktionierte immer bestens.

Ich wollte jetzt nur mal ein Minimalsystem mit Programmierung per ISP 
aufbauen und testen. Naja klappt nicht so wirklich, aber ich habe doch 
einiges gelernt dabei.  Ich meine mal irgendwo gelesen zu haben, dass 
man den Arduino Uno als ISP Programmer einsetzen kann, werde ich mich 
mal die nächsten Tage mit beschäftigen.

Aktueller Stand der Dinge: Neuer ATmega16 (jetzt ein ATmega16 16PI, 
vorher wars ein 16PU), beide GND und VCC + AVCC sind angeschlossen. In 
dem Schaltplan (siehe Anhang) ist nur eine LED eingezeichnet, real 
(Steckbrett) ist der ganze Port C belegt. JTAGEN Fuse jedesmal 
auszusschalten kann ich mir jetzt schenken, stattdessen  MCUCSR |= 
(1<<JTD)  (muss man 2x aufrufen, warum weiss ich (noch) nicht). 
Ansonsten nichts neues: Alle möglichen Zuweisungen an Port C werden 
korrekt ausgegeben, einzige Ausnahme: PORTC = 0x00.

C-Code:

1

   // *** test.c ***

2

3

4

   //     MCU:   ATmega16  oder  ATmega32

5

6

   #define F_CPU 1000000

7

8

   #include <avr/io.h>

9

   #include <util/delay.h>

10

11

12

13

   int main (void)

14

   {

15

      MCUCSR |= (1<<JTD);       // JTAG disable

16

      MCUCSR |= (1<<JTD);

17

18

      DDRC = 0xFF;

19

20

21

      // PORTC = 0b10101010;

22

      PORTC = 0b00000000;

23

24

      while(1) 

25

      {

26

      }

27

28

      return 0;

29

   }

Build Skript:

1

@echo off

2

3

4

rem  ***   buildhex.bat   ***

5

6

7

rem  Kompilation von test.c

8

9

rem  Übertragung des hex-Files auf Schaltung per ISP (ICSP) 

10

rem  mit Programmer TL866 II plus

11

12

avr-gcc -mmcu=atmega16 -Wall -Os -c test.c -o test.o

13

14

avr-gcc test.o -o test.elf

15

16

rem  +++ avr-objcopy -O ihex -j .text -j .data test.elf test.hex

17

avr-objcopy -O ihex test.elf test.hex

18

19

pause

> Inklusive Meßstrippen?
Ohne, also 1,6 Ohm an den Pins.

> Alle möglichen Zuweisungen an Port C werden
> korrekt ausgegeben, einzige Ausnahme: PORTC = 0x00.

Da sieht, für mich, nach einem Problem mit der Stromversorgung aus: die 
Spannung zwischen Vcc und GND direkt am ATmega16 messen, einmal bei 
PORTC=0 und dann bei PORTC=irgendwas.

PS:
Ein Bild des Steckbrettaufbaus brächte uns wahrscheinlich weiter.

Volker A. schrieb:

> Kompiliert habe ich den Code mittels AVR Toolchain. Zum Laden des
> Hex-Files über ICSP verwende ich den Programmer TL866 II plus.


Wenn Du den auch zum Speisen der Schaltung mit dem Mega 16 benutzt, mußt 
Du Dich über dessen lustiges Verhalten nicht wundern. In dem Programmer 
sind es nämlich die Ausgänge von normalen Logikschaltkreisen, die die 
Betriebsspannung für den Mega16 liefern sollen. Das schaffen sie nicht, 
wenn noch 8 LED mit am Futternapf sitzen.

So, ich noch mal!

Vorweg: Ich konnte das Problem leider nicht lösen.


Ich habe mir jetzt nochmal beim C. um die Ecke einen weiteren ATmega16 
16PU gekauft.

Programmierung

-  MiniPro TL866 ii + wie gehabt
-  ArduinoISP
   nach der folgenden Anleitung bei Heise 
https://m.heise.de/make/artikel/Microcontroller-flashen-Arduino-Uno-als-In-System-Programmer-2769246.html?seite=all

Spannungsversorgung extern bei Verwendung des TL866 und per USB bei 
ArduinoISP, siehe Anhänge Schaltpläne + Fotos

Auch der neue ATmega16 gibt bei Zuweisung PORTC = 0x00 bzw 0b00000000 
einen falschen Wert aus:  10111101 (egal ob per TL866 oder ArduinoISP 
geladen)

Bei Verwendung von Bitoperationen (auskommentierter Teil des Codes) 
läuft alles korrekt.

Ich beende das Ganze erstmal und danke für die Teilnahme


C Code

1

   // *** test.c ***

2

3

4

   //     MCU:   ATmega16  oder  ATmega32

5

6

7

   #define F_CPU 1000000

8

9

   #include <avr/io.h>

10

   #include <util/delay.h>

11

12

13

14

   int main (void)

15

   {

16

      MCUCSR |= (1<<JTD);       // JTAG disable

17

      MCUCSR |= (1<<JTD);

18

19

      DDRC = 0b11111111;

20

21

      while(1) 

22

      {

23

         PORTC = 0b00000000;      // -> LED  1011 1111 bei ATmega16 alt

24

                                  //         1011 1101              neu

25

         // PORTC = 0b10000000;      // -> LED  1000 0000

26

         _delay_ms(500);

27

28

         PORTC = 0b11111111;      // -> LED  1111 1111

29

         _delay_ms(500);

30

      }

31

32

      return 0;

33

   }

34

35

36

/*

37

   int main (void)

38

   {

39

      MCUCSR |= (1<<JTD);       // JTAG disable

40

      MCUCSR |= (1<<JTD);

41

42

      DDRC |= (1 << PC0 | 1 << PC1 | 1 << PC2 | 1 << PC3);

43

44

      while(1) 

45

      {

46

         PORTC ^= (1 << PC0 | 1 << PC1 | 1 << PC2 | 1 << PC3);

47

         _delay_ms(100);

48

      }

49

50

      return 0;

51

   }

52

*/

Build Skript

1

@echo off

2

3

rem  ***   buildhex.bat   ***

4

5

rem  Kompilation von test.c

6

7

rem  Übertragung des hex-Files auf Schaltung per ISP (ICSP) 

8

rem  mit Programmer TL866 II plus

9

10

avr-gcc -mmcu=atmega16 -Wall -Os -c test.c -o test.o

11

12

avr-gcc test.o -o test.elf

13

14

avr-objcopy -O ihex test.elf test.hex

15

16

rem  Laden mit ArduinoISP über COM3

17

rem  +++ avrdude -c avrisp -p atmega16 -P COM3 -b 19200 -U flash:w:test.hex

18

19

pause

Hast du den neuen ATmega16 etwas wieder nur halb an die Stromversorgung 
angeschlossen?

Was willst du damit beweisen?

Bei deinem 5V Regler scheinen Kondensatoren zu fehlen. Bedenke, dass 
dies zu Schwingungen mit Überspannung führen kann!

Stefan ⛄ F. schrieb:
> Bei deinem 5V Regler scheinen Kondensatoren zu fehlen.

Das ist sehr richtig und sehr wichtig!

Stefan ⛄ F. schrieb:
> Bedenke, dass
> dies zu Schwingungen mit Überspannung führen kann!

Nicht nur das. Der Regler funktioniert oft gar überhaupt nicht
so wie er soll. Er gibt dann gar nicht die Nennspannung aus.

Beratungsresistenz ist eine Zier, doch weiter kommt man ohne ihr.

OMG!

SCNR
(ich wollte ja eigentlich nichts schreiben, aber bei soviel
Bl..heit ...)

900ss D. schrieb:
> Und auch die Abblockkondensatoren am Atmega

Ich sehe da einen

Stefan ⛄ F. schrieb:
> 900ss D. schrieb:
>> Und auch die Abblockkondensatoren am Atmega
>
> Ich sehe da einen

Ob der Kontakt hat...

Meine Erfahrungen mit Breadboards sagen: Sicher sein kann man da 
allenfalls, wenn man die entprechenden Löcher das allererste Mal 
benutzt.

Deswegen bin ich schon vor Jahrzehnten auf 
Streifenleiter-PCB-Konstruktionen umgeschwenkt. Fast dieselbe Freiheit 
wie bei Breadboards, aber der ungewinnbare Kampf gegen die 
Wackelkontakte entfällt...

Ist aber doch äußerst merkwürdig, oder verstehe ich da etwas falsch: ein 
simples, offenbar korrektes Programm, auf zwei grundlegend verschiedene 
Aufbauten gespielt, führt zu demselben schrägen Fehler.

Frage, aus einer gewissen Ratlosigkeit entstanden: Zwar sind die 
Steckbretter so markiert, als seien die Versorgungsstränge durchgehend, 
aber ist das tatsächlich der Fall? Bei zweien meiner Steckbretter sind 
die nämlich in der Mitte unterbrochen.

S. Landolt schrieb:
> Ist aber doch äußerst merkwürdig, oder verstehe ich da etwas falsch: ein
> simples, offenbar korrektes Programm, auf zwei grundlegend verschiedene
> Aufbauten gespielt, führt zu demselben schrägen Fehler.

Ja und das lässt dann nur den Schluss zu, dass mit den avr-gcc 
Kommandoaufrufen irgendwas nicht stimmt.

Ich habe dann einfach mal aus dem Mikrocontroller.net Artikel "C ohne 
Makefile" etwas übernommen und angepasst und jetzt funktioniert es (auf 
beiden Aufbauten) und alle 8 LEDs blinken vor sich hin.

Warum, weiss ich noch nicht, aber das kriege ich auch noch raus.


Danke an Alle und sorry für die Verwirrungen.



Build Skript:

1

@echo off

2

3

avr-gcc -mmcu=atmega16 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -std=gnu99 -g test.c -o test.elf

4

avr-objcopy -O ihex -R .eeprom test.elf test.hex

5

rem  +++ avrdude -c avrisp -p atmega16 -P COM3 -b 19200 -B 12 -U flash:w:test.hex:i

6

7

pause

PS zu dem Spannungsregler: Ist sicherlich verbesserungsbedürftig, aber 
zwei schlecht sichtbare Kondensatoren sind schon drauf.

Volker A. schrieb:
> zu dem Spannungsregler: Ist sicherlich verbesserungsbedürftig, aber
> zwei schlecht sichtbare Kondensatoren sind schon drauf.

Gut. Schlechte Stromversorgung ist nämlich wie Fettleibigkeit. Macht 
nicht immer Probleme, kann aber Auslöser für so ziemlich alle anderen 
Probleme sein - und das nicht gerade selten.

Ich habe die AVR Toolchain hier 2 x auf meinem Rechner. Die eine Version 
ist Teil einer Arduino Installation, die andere habe ich mal von 
atmel.com runtergeladen (Seite gibt es natürlich nicht mehr)

Die GCC Version ist 4.9.2

Ich habe beide Toolchains getestet, das Ergebnis ist dasselbe.

Im Anhang 2 Zip-Files (Build Skript, Quellcode, Hex-File, 
Assembler-Listing) einmal mit der fehlerhaften und einmal mit der 
korrekten Version.

Im fehlerhaften Fall erzeugst du zuerst eine *.o Datei und links sie in 
einem zweiten Schritt zu einer *.elf Datei (dem ausführbaren Programm).

Was mir da direkt auffällt ist, dass du beim Linken gar nicht angegeben 
hast, für welche Zielplattform das Programm sein soll. Vermutlich ist 
das notwendig.

Im guten Fall machst du beides in einem Schritt. Dadurch weiß der 
linker, für welche Zielplattform das Programm sein soll.


Ich gebe dem avr-gcc in beiden Schritten immer folgende Parameter mit:
> -Wall -O1 -fshort-enums -mmcu=atmega16 -DF_CPU=1000000
> -ffunction-sections -fdata-sections

Der compiliert-schritt bekommt zusätzlich:
> -std=c99

Der linker-schritt bekommt zusätzlich:
> -lm -Wl,--gc-sections

Erklärung:

1

-Wall             aktiviert alle Warnungen.

2

-O1               stellt die Optimierungsstufe ein, da kannst du auch 

3

                  gerne -Os nehmen.

4

-fshort-enums     Nutzt 8bit für Enums (standard wäre 16bit).

5

-mmcu=atmega16    Der Mikrocontroller Typ.

6

-DF_CPU=1000000   Taktfrequenz der CPU, wird für delay gebraucht. 

7

                  Kann man alternativ auch im Quelltext angeben, 

8

                  so wie du es gemacht hast.

9

-ffunction-sections 

10

-fdata-sections   Funktionen und Daten bekommen eigene Sektionen, 

11

                  so kann der Linker später ungenutzte Funktionen 

12

                  weg lassen.

13

-std=c99          Die C Version.

14

-lm               Bindet die math Library ein. Ist in deinem Fall

15

                  ungenutzt.

16

-Wl,--gc-sections Sagt dem Linker, dass er ungenutzte Funktionen weg 

17

                  lassen soll.

Was mich aber extremst irritiert ist, dass dein funktionierendes 
Programm um ein vielfaches größer ist. Ich sehe dafür keinen plausiblen 
Grund. Vielleicht kann da jemand anders weiter forschen, und es 
erklären. Das würde mich freuen.

Tja, merkwürdig, bei mir sieht es anders aus: ohne mir das Ganze näher 
anzuschauen, habe ich die beiden Hex-Dateien auf meinen ATmega16-16PU 
gespielt, und beide Male blinkt es, wie es soll, nämlich mit 00 und FF; 
bei der zweiten Version mit Tastgrad 0.5, bei der ersten ist es eher ein 
Aufblitzen, so wie es ja im Programm steht.

Stefan ⛄ F. schrieb:
> Was mir da direkt auffällt ist, dass du beim Linken gar nicht angegeben
> hast, für welche Zielplattform das Programm sein soll. Vermutlich ist
> das notwendig

Ja, das wars wohl!

Das folgende Skript funktioniert jetzt
Alternativ können die beiden avr-gcc Aufrufe auch zu einer Zeile 
zusammengefasst werden, wobei die Option -c duch -g ersetzt werden muss 
(auskommentierte Zeile)

Das Hex File ist jetzt auch deutlich grösser geworden (484 Byte)

Das Skript:

1

rem  ***   buildhex.bat   ***

2

3

rem  Kompilation von test.c

4

5

rem  Übertragung des hex-Files auf Schaltung per ISP (ICSP) 

6

rem  mit Programmer TL866 II plus

7

8

avr-gcc -save-temps -mmcu=atmega16 -Wall -Os -c test.c -o test.o

9

avr-gcc -mmcu=atmega16 test.o -o test.elf

10

rem  +++ avr-gcc -save-temps -mmcu=atmega16 -Wall -Os -g test.c -o test.elf

11

12

avr-objcopy -O ihex test.elf test.hex

13

14

rem  Laden mit ArduinoISP über COM3

15

rem  +++ avrdude -c avrisp -p atmega16 -P COM3 -b 19200 -U flash:w:test.hex

16

17

pause

Volker A. schrieb:
> Ja, das wars wohl!

Ja, und achte darauf dass du nicht zuviel Geld verschwendest mit
einer Unzahl an Abblock-Kondensatoren. Die machen dich nämlich
arm und sind immer nur unnützer Ballast. Dewswegen werden sie
auch in allen seriösen Schaltungen weggelassen. Bloss nichts
machen was der Hersteller vorschreibt, immer schön als
Individualist auf der Aussenseiter-Spur bleiben!

Volker A. schrieb:
> wobei die Option -c duch -g ersetzt werden muss

Ich glaube, es genügt "-c" weg zu lassen.

-g fügt Informationen für den Debugger ins Kompilat ein, aber die landen 
letztendlich nicht im Mikrocontroller und der Debugger funktioniert auch 
ohne sie, soweit ich weiß.

OMG (Gast) schrieb:
> blabla

Kauf dir mal ne Brille, dass siehst du auch die Abblockkondensatoren. 
Und vegiss nicht regelmässig deine Tabletten zu nehmen.

Volker A. schrieb:
> Kauf dir mal ne Brille, dass siehst du auch die Abblockkondensatoren.

Puuuut, put, put .... ja wo sind sie denn ....

Im Schaumschlägern bist du ganz gross.

OMG schrieb:
> Puuuut, put, put .... ja wo sind sie denn ....

Wenn der TO schreibt, dass sie vorhanden sind (nur schlecht sichtbar), 
dann ist das so.

Mit deiner ewigen Stänkerei machst du dir keine Freunde. Hast du 
überhaupt jemals einen hilfreichen Beitrag geschrieben oder zumindest 
Hilfsbereitschaft gezeigt?

Im Simulator unter AS7 funktioniert das Programm. Alle Bits des Port C 
werden richtig umgeschaltet.

Gerade die Schaltung mit einem ATmega16 auf einem Steckbrett mit eigener 
Batterieversorgung aufgebaut. Ohne Abblockkondensatoren und ohne die 
Stromversorgungs-Pins untereinander zu verbinden. Nur AVCC musste ich 
wegen des LED-Moduls (gemeinsame Kathode) mit VCC (5V) verbinden. Es 
läuft alles wie im Programm vorgesehen. Der Fehler muss woanders liegen.

BlaBla schrieb:
> Der Fehler muss woanders liegen.

Ach was!

Stefan ⛄ F. schrieb:
> Was mir da direkt auffällt ist, dass du beim Linken gar nicht angegeben
> hast, für welche Zielplattform das Programm sein soll.

Volker A. schrieb:
> Ja, das wars wohl!

Stefan ⛄ F. schrieb:
> BlaBla schrieb:
>> Der Fehler muss woanders liegen.
>
> Ach was!

Ja, ich habe die Lösung übersehen. Das habe ich nun davon...

BlaBla schrieb:
> Ja, ich habe die Lösung übersehen. Das habe ich nun davon...

Ist nich schlimm. Ich habe mich in den vergangenen warmen Tagen auch 
mehrfach heftig blamiert, so unaufmerksam wie ich da war.