ATmega16 Port Ausgabe Problem

[Volker A. (Gast)]

Moin!

Ich will ein beliebiges Bitmuster über Port C ausgeben. JTAGEN Fuse ist 
gelöscht. Mein Problem: die Ausgabe von 0x00 funktioniert nicht. Ich 
bekommen an den Pins die Pegel 1011 1111 (statt 0000 0000). Am Port D 
dasselbe Verhalten. Alle anderen Bitmuster, die ich so getestet habe 
funktionieren.

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

Der Code

   // *** test.c ***
    
   //     MCU:   ATmega16  oder  ATmega32

   #define F_CPU 1000000
   
   #include <avr/io.h>
   #include <util/delay.h>

   int main (void)
   {
      DDRC = 0xFF;

      PORTC = 0x00;         // ->  10111111 statt 00000000  !!!
      //  PORTC = 0xAA;      // ->   1010 1010  ok

      while(1) 
      {
      }

      return 0;
   }

Compilieren, Linken usw

@echo off

rem  ***   buildhex.bat   ***


rem  Kompilation von test.c

rem  Übertragung des hex-Files auf Schaltung per ISP (ICSP) 
rem  mit Programmer TL866 II plus

avr-gcc -mmcu=atmega16 -Wall -Os -c test.c -o test.o
avr-gcc test.o -o test.elf
avr-objcopy -O ihex -j .text -j .data test.elf test.hex

pause

[B. Lötmann (Gast)]

Moin,

/* Define pull-ups and set outputs high */
/* Define directions for port pins */
PORTB = (1<<PB7)|(1<<PB6)|(1<<PB1)|(1<<PB0);
DDRB = (1<<DDB3)|(1<<DDB2)|(1<<DDB1)|(1<<DDB0);
/* Insert nop for synchronization*/
__no_operation();

versuch mal mit NOP.

grüße

[Genderkorrekter Sprachwissenschaftler (Gast)]

JTAG über Fuses deaktivieren.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Volker A. schrieb:
> JTAGEN Fuse ist
> gelöscht.

Eine 0 bei JTAGEN bedeutet, das JTAG angeschaltet ist (Voreinstellung), 
eine 1 schaltet JTAG ab.

[C. K. (Gast)]

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

[Oliver S. (oliverso)]

B. Lötmann schrieb:
> /* Insert nop for synchronization*/
> __no_operation();

Man könnte auch eine Kerze anzünden.

Oliver

[Stefan F. (Gast)]

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

[S. Landolt (Gast)]

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."

[Selektiver Zitierer (Gast)]

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.

[BlaBla (Gast)]

Und was hat das mit PORTC zu tun?

[Stefan F. (Gast)]

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

Ich habe mir dabei gedacht: sicher ist sicher.

[S. Landolt (Gast)]

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

[Volker A. (Gast)]

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):

   int main (void)
   {
      DDRC |= ((1<<DDC3)|(1<<DDC2)|(1<<DDC1)|(1<<DDC0));

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

      while(1) 
      {
      }

      return 0;
   }

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

[holger (Gast)]

>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

[Peter D. (peda)]

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

Auch beim Programmieren?
Signatur lesen, Verify o.k.?
Richtigen AVR-Typ ausgewählt (Compiler, Linker, Programmer)?
Richtiges Hex-File genommen?
Nicht zu hohen ISP-Takt ausgewählt?

[Stefan F. (Gast)]

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ß.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Volker A. schrieb:
> Ich habe mich mit Fuses noch nicht ernsthft beschäftigt, aber dass sie
> mit Zuweisung einer 0 gesetzt werden weiss ich.

Dann wende doch die Methode von C.K. an, kostet ja so gut wie nichts:

C. K. schrieb:
> Oder zur Laufzeit das JTAG Disable Bit setzen:
> MCUCSR |= (1<<JTD);

Damit bist du auf der sicheren Seite. Das gleiche gilt für AVCC und alle 
GND Anschlüsse. Richtig anschliessen erspart eine Menge Kopfschmerzen. 
Und bitte auch mindestens einen Abblockkondensator dicht am MC von VCC 
zu GND.

[S. Landolt (Gast)]

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.

[Oliver S. (oliverso)]

Volker A. schrieb:
> Zuweisung mit Bit-Operationen ist aber erfolgreich!
> Hier der Code (verkürzt auf 4 Bit):
>    int main (void)
>    {
>       DDRC |= ((1<<DDC3)|(1<<DDC2)|(1<<DDC1)|(1<<DDC0));
>
>       PORTC &= ~((1<<PC3)|(1<<PC2)|(1<<PC1)|(1<<PC0));
>       // PORTC |= (1<<PC2);
>
>       while(1)
>       {
>       }
>
>       return 0;
>    }
>
> Damit ist die Frage, warum PORTC = 0x00 nicht funktioniert aber nicht
> geklärt.

Das ist auch alles völlig sinnfrei. Selbst, wenn der Prozesser kaputt 
wäre, so speziell kaputt kann der gar nicht sein. Entweder macht dein 
Programmer Unsinn, oder das Problem sitzt vor dem Bildschirm.

Wie oben schon geschrieben wurde: Abblockkondensatoren installiert?
Ist das verify nach dem Programmieren erfolgreich?
Was gibt PortC denn aus, wenn du gar nichts drauf schreibst?
Welche avr-gcc-Version nutzt du, und wo hast du den Compiler her?

Zip mal mal ein komplettes Projekt mit .C, .lss, .elf, und .hex Files 
zusammen und lade das hier hoch.

Oliver

[Peter D. (Gast)]

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

[S. Landolt (Gast)]

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.

[Selektiver Zitierer (Gast)]

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.

[Peter D. (peda)]

Ich verstehe die Ängste nicht, warum man sich so standhaft weigert, alle 
GND, VCC und AVCC anzuschließen. Der Chip wird schon nicht explodieren 
deswegen.

[Oliver S. (oliverso)]

Selektiver Zitierer schrieb:
> Aha. Doch ein Stunksucher.

Nein. Wo er Recht hat, hat er Recht. Es steht nirgends im Datenblatt, 
daß man alle GND-Pins anschliessen muß.

Peter D. schrieb:
> Ich verstehe die Ängste nicht, warum man sich so standhaft weigert, alle
> GND, VCC und AVCC anzuschließen. Der Chip wird schon nicht explodieren
> deswegen.

Ich auch nicht, aber der Prozessor explodiert auch nicht gleich, wenn 
man nicht alle GND-Verbindungen anschliesst.

Oliver

[900ss (900ss)]

Oliver S. schrieb:
> Es steht nirgends im Datenblatt, daß man alle GND-Pins anschliessen muß.

Doch es steht dort.
Der Pin ist mit GND bezeichnet, also verbinde ihn mit Ground.
Wenn er frei sein sollte, würde der Pin n/c (not connect) ö.ä. heißen.

Und was auch für ein Blödsinn, ihn nicht zu verschalten. Kostet das 
Taschengeld?

[Jens G. (jensig)]

>Doch es steht dort.
>Der Pin ist mit GND bezeichnet, also verbinde ihn mit Ground.
>Wenn er frei sein sollte, würde der Pin n/c (not connect) ö.ä. heißen.

Blödsinn.
Bei XTAL muß man auch nicht unbedingt einen Quarz anschließen, bloß weil 
da XTAL dran steht. Oder schließt Du da einen an, wenn du den internen 
RC-Oszi -Modus benutzt?

[Stefan F. (Gast)]

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?

[Jens G. (jensig)]

So viele, daß es für seinen Zweck einsatzfähig ist ...
Drei reichen eigentlich auch, wenn man diagonal gegenüber der 
"Fehlstelle" einen Ziegelstein drauflegt ;-)

[900ss (900ss)]

Jens G. schrieb:
> Bei XTAL muß man auch nicht unbedingt einen Quarz anschließen, bloß weil
> da XTAL dran steht

Stimmt. Aber für den Pin XTAL ist dann beschrieben unter welchen 
Bedingungen man ihn frei lassen kann. Das gibt es für GND nicht.

[MaWin (Gast)]

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.

[S. Landolt (Gast)]

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.

[S. Landolt (Gast)]

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

[c-hater (Gast)]

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.

[c-hater (Gast)]

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...

[S. Landolt (Gast)]

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

[c-hater (Gast)]

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.

[S. Landolt (Gast)]

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

[Volker A. (Gast)]

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:

   // *** test.c ***
   

   //     MCU:   ATmega16  oder  ATmega32

   #define F_CPU 1000000
   
   #include <avr/io.h>
   #include <util/delay.h>



   int main (void)
   {
      MCUCSR |= (1<<JTD);       // JTAG disable
      MCUCSR |= (1<<JTD);

      DDRC = 0xFF;


      // PORTC = 0b10101010;
      PORTC = 0b00000000;

      while(1) 
      {
      }

      return 0;
   }

Build Skript:

@echo off


rem  ***   buildhex.bat   ***


rem  Kompilation von test.c

rem  Übertragung des hex-Files auf Schaltung per ISP (ICSP) 
rem  mit Programmer TL866 II plus

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

avr-gcc test.o -o test.elf

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

pause

[Jens G. (jensig)]

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.

Inklusive Meßstrippen?

[S. Landolt (Gast)]

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

[S. Landolt (Gast)]

> 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.

[S. Landolt (Gast)]

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

[Martin V. (oldmax)]

Hi
Nun, so ein Verhalten hab ich bisher noch nicht gehabt, aber 
möglicherweisw hängt deine "reset"-Leitung in der Luft. Häng da mal 
einen 10 K gegen VCC dran.
Gruß oldmax

[Selektiver Zitierer (Gast)]

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.

[Peter D. (peda)]

Selektiver Zitierer schrieb:
> Wenn Du den auch zum Speisen der Schaltung mit dem Mega 16 benutzt, mußt
> Du Dich über dessen lustiges Verhalten nicht wundern.

Da wirst Du wohl recht haben, im Schaltplan ist keine Stromversorgung 
eingezeichnet.

[Volker A. (Gast)]

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

   // *** test.c ***
   

   //     MCU:   ATmega16  oder  ATmega32


   #define F_CPU 1000000
   
   #include <avr/io.h>
   #include <util/delay.h>



   int main (void)
   {
      MCUCSR |= (1<<JTD);       // JTAG disable
      MCUCSR |= (1<<JTD);
   
      DDRC = 0b11111111;
   
      while(1) 
      {
         PORTC = 0b00000000;      // -> LED  1011 1111 bei ATmega16 alt
                                  //         1011 1101              neu
         // PORTC = 0b10000000;      // -> LED  1000 0000
         _delay_ms(500);

         PORTC = 0b11111111;      // -> LED  1111 1111
         _delay_ms(500);
      }
   
      return 0;
   }


/*
   int main (void)
   {
      MCUCSR |= (1<<JTD);       // JTAG disable
      MCUCSR |= (1<<JTD);
   
      DDRC |= (1 << PC0 | 1 << PC1 | 1 << PC2 | 1 << PC3);
   
      while(1) 
      {
         PORTC ^= (1 << PC0 | 1 << PC1 | 1 << PC2 | 1 << PC3);
         _delay_ms(100);
      }
   
      return 0;
   }
*/

Build Skript

@echo off

rem  ***   buildhex.bat   ***

rem  Kompilation von test.c

rem  Übertragung des hex-Files auf Schaltung per ISP (ICSP) 
rem  mit Programmer TL866 II plus

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

avr-gcc test.o -o test.elf

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

rem  Laden mit ArduinoISP über COM3
rem  +++ avrdude -c avrisp -p atmega16 -P COM3 -b 19200 -U flash:w:test.hex

pause

[Stefan F. (Gast)]

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!

[OMG (Gast)]

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 ...)

[Peter D. (peda)]

Ich habs grad getestet auf dem STK500. Wie nicht anders zu erwarten 
gehen alle 8 LEDs an.
Der Code:

int main (void)
{
  MCUCSR = (1<<JTD);
  MCUCSR = (1<<JTD);
  DDRC = 0xFF;
  PORTC = 0x00;
  while (1)
  {
  }
}

Anbei das Listfile.

[900ss (900ss)]

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

Ja. Und auch die Abblockkondensatoren am Atmega. Autsch....
Aber vielleicht puffert es ja das C des Steckbretts ;)

[Stefan F. (Gast)]

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

Ich sehe da einen

[c-hater (Gast)]

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...

[S. Landolt (Gast)]

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.

[900ss (900ss)]

Stefan ⛄ F. schrieb:
> Ich sehe da einen

Ok, ich nehme das zurück. Es liegt entweder am Steckbrett oder den 
fehlenden Kondensatoren am Regler. Oder beides :)
Ich würde den Regler erstmal befriedigen.

Was ich mich frage weshalb man das weg lässt. Aber es ist wohl blankes 
Unwissen.

[Oliver S. (oliverso)]

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.

Die Frage zu Compilerversion und -quelle hat der TO ja bisher nicht 
beantwortet, und ein vollständiges Beispiel mit elf- oder hexfile 
hochgeladen hat er auch nicht.

Oliver

[S. Landolt (Gast)]

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.

[Volker A. (Gast)]

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:

@echo off

avr-gcc -mmcu=atmega16 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -std=gnu99 -g test.c -o test.elf
avr-objcopy -O ihex -R .eeprom test.elf test.hex
rem  +++ avrdude -c avrisp -p atmega16 -P COM3 -b 19200 -B 12 -U flash:w:test.hex:i

pause

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

[Peter D. (peda)]

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

Hättest Du mal das Listfile angehangen, hätte man schnell sehen können, 
ob da was im Argen liegt.
Man kann auch den gesamten Projektordner als Zip anhängen.
Aber Du zeigst ja nix.

[Stefan F. (Gast)]

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.

[Oliver S. (oliverso)]

Volker A. schrieb:
> Warum, weiss ich noch nicht, aber das kriege ich auch noch raus.

Zip doch einfach mal das ganze Direktory mit dem fehlerhaften Programm 
zusammen, und lad das hier hoch. Mit sourcefile, makefile, und allen vom 
compiler generierten Dateien.

Und nochmal die Frage: Welcche Compilerversion hast du (avr-gcc -v), und 
wo hast du die her?

Oliver

[Volker A. (Gast)]

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.

[Stefan F. (Gast)]

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:

-Wall             aktiviert alle Warnungen.
-O1               stellt die Optimierungsstufe ein, da kannst du auch 
                  gerne -Os nehmen.
-fshort-enums     Nutzt 8bit für Enums (standard wäre 16bit).
-mmcu=atmega16    Der Mikrocontroller Typ.
-DF_CPU=1000000   Taktfrequenz der CPU, wird für delay gebraucht. 
                  Kann man alternativ auch im Quelltext angeben, 
                  so wie du es gemacht hast.
-ffunction-sections 
-fdata-sections   Funktionen und Daten bekommen eigene Sektionen, 
                  so kann der Linker später ungenutzte Funktionen 
                  weg lassen.
-std=c99          Die C Version.
-lm               Bindet die math Library ein. Ist in deinem Fall
                  ungenutzt.
-Wl,--gc-sections Sagt dem Linker, dass er ungenutzte Funktionen weg 
                  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.

[Peter D. (peda)]

Da ja die Ausgabe von 0 fehlschlägt, scheint das Initialisieren des 
_zero_reg_ (R1) fehlzuschlagen. Schade, daß kein Listfile erzeugt 
wurde. Da würde man das sehen.

Der Linker muß natürlich auch -mmcu definiert bekommen.

[S. Landolt (Gast)]

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.

[Volker A. (Gast)]

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:

rem  ***   buildhex.bat   ***

rem  Kompilation von test.c

rem  Übertragung des hex-Files auf Schaltung per ISP (ICSP) 
rem  mit Programmer TL866 II plus

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

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

rem  Laden mit ArduinoISP über COM3
rem  +++ avrdude -c avrisp -p atmega16 -P COM3 -b 19200 -U flash:w:test.hex

pause

[OMG (Gast)]

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!

[Stefan F. (Gast)]

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ß.

[Volker A. (Gast)]

OMG (Gast) schrieb:
> blabla

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

[OMG (Gast)]

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.

[Stefan F. (Gast)]

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?

[BlaBla (Gast)]

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

[BlaBla (Gast)]

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.

[Stefan F. (Gast)]

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!

[BlaBla (Gast)]

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

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

[Stefan F. (Gast)]

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.