Radig NetIO Atmega644P Scannerzeile auslesen

[Stefan F. (fanfan)]

Für meine Bachelorarbeit soll ich einen CCD-Zeilensensor auslesen und 
per Netzwerk an einen PC zur Weiterverarbeitung schicken.

Gelöst habe ich die Aufgabe mit einem Pollin NetIO auf dem Ulrch Radigs 
Firmware (natürlich abgewandelt) läuft.
Mit dem original Atmega 32 läuft die ganze Schaltung auch schon. 
Allerdings hat der Atmega zu wenig RAM, so dass ich nicht die ganze 
Zeile auf einmal auslesen kann.
Deshalb habe ich mir jetzt einen Atmege644P besorgt, der ja mehr RAM 
hat.
Die Portierung von Atmega 32 zu 644 bereitet mir jedoch Probleme.

Für den Originaltimer von Herrn Radig habe ich folgendes:

#if Atmega644P
      TCCR1A |= (1<<WGM12);  //CTC(compare match mode)
      TCCR1B |= (1<<CS10 | 0<<CS11 | 1<<CS12);  //clk/1024 prescaler
      TCNT1 = 0;    //Zählerregister = 0
      OCR1A = (F_CPU / 1024) - 1; //Zählgrenze für UEberlauf
      TIMSK1 |= (1 << OCIE1A);  //ISR wenn Grenze A (OCR1A) erreicht
    #else
      TCCR1B |= (1<<WGM12) | (1<<CS10 | 0<<CS11 | 1<<CS12);  //CTC(compare match mode)|clk/1024 prescaler
      TCNT1 = 0;    //Zählerregister = 0
      OCR1A = (F_CPU / 1024) - 1; //Zählgrenze für UEberlauf
      TIMSK |= (1 << OCIE1A);  //ISR wenn Grenze A (OCR1A) erreicht
    #endif  //Atmega

Der Atmega644P-Teil wurde von mir ergänzt.

Für meinen eigenen Sensor-Clock-Timer habe ich:

#if Atmega644P
    TCCR0A       |= (1<<WGM01);  // Timer im CTC-Mode, Top=OCR0; 8 bit timer
    TCCR0A        &= ~(1<<WGM00);  // kein PWM
    TCCR0B        |= (1<<CS00);
    TCCR0B        |= (1<<CS01);
    TCCR0B        &= ~(1<<CS02);    // Prescaler 64 -->16MHz/64 = 250 kHz
    OCR0A          = 25;      // 250 kHz/25 = 10 kHz Schalttakt, aber 1xAn+1xAus= Periode  
                    // 10 kHz/2 = 5 kHz = Fclock
                    //jedes Mal wenn der Timer 239 erreicht gibt es einen Interrupt
    TIMSK0        |= (1<<OCIE0A);
  #else
    TCCR0        |= (1<<WGM01);  // Timer im CTC-Mode, Top=OCR0; 8 bit timer
    TCCR0        &= ~(1<<WGM00);  // kein PWM
    TCCR0        |= (1<<CS00);
    TCCR0        |= (1<<CS01);
    TCCR0        &= ~(1<<CS02);    // Prescaler 64 -->16MHz/64 = 250 kHz
    OCR0          = 25;      // 250 kHz/25 = 10 kHz Schalttakt, aber 1xAn+1xAus= Periode  
                  // 10 kHz/2 = 5 kHz = Fclock
                  //jedes Mal wenn der Timer 239 erreicht gibt es einen Interrupt
    TIMSK        |= (1<<OCIE0);  // Tmr/Cntr0 CompareA interrupt enabled

Stimmen die Anpassungen für den Atmega644P?
wenn ich den Atmega32 definiere läuft wieder alles wunderbar. Beim 
644P-er nichts mehr. Bzw. ist er nicht mehr per Netwerk erreichbar.

Fehler beim Compilieren werden nicht gemeldet und auch das Flashen 
bereitet keine Probleme.

[holger (Gast)]

#if Atmega644P
      TCCR1A |= (1<<WGM12);  //CTC(compare match mode)

Da würde ich aber noch mal ins Datenblatt schauen;)

[Joachim B. (jar)]

Stefan Foydl schrieb:
> Stimmen die Anpassungen für den Atmega644P?

puh ist lange her, mein Pollin NETIO läuft schon lange auf m1284p

ob ich alle Anpassungen auf m644 / 644p noch finde weiss ich nicht, mal 
suchen !

in timer.h

#if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)

#define TIMSK TIMSK1

#endif

in stack.h

#if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)
  #define MAX_TCP_ENTRY 5  
  #define MAX_UDP_ENTRY 5
  #define MAX_ARP_ENTRY 5
  #define MTU_SIZE 1200
#endif

in timer.c

void timer_init (void)
{
  #if EXTCLOCK==1
    #if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)

      //Asynchroner Modus ein, Oszillator an TOSC1 und TOSC2 aktiv
      ASSR |= (1<<AS2);
      TCCR2B = 0x05;
      while(ASSR & 0x11);
      //Capture/Compare-Interrupt aktiv
      TIMSK2 |= (1<<OCIE2A);
    #else
      //Asynchroner Modus ein, Oszillator an TOSC1 und TOSC2 aktiv
      ASSR  = (1<<AS2);
      //CTC-Modus an (Clear Timer on Compare Match)
      TCCR2 = (1<<WGM21);      
      //dieser Wert ergibt eine Sekunde Periodendauer
      OCR2  = 31;  
      //lösche Prescaler 2        

      SFIE  = (1<<PSR2);      
      //Starte Timer 2 mit Prescaler gleich 1/1024
      TCCR2 |= (1<<CS22)|(1<<CS21)|(1<<CS20); 
      while(ASSR & 0x07);

      //Capture/Compare-Interrupt aktiv
      TIMSK = (1<<OCIE2);      
    #endif

in usart.h

  #if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)
    #define USR UCSR0A
    #define UCR UCSR0B
    #define UBRR UBRR0L
    #define EICR EICRB
    #define TXEN TXEN0
    #define RXEN RXEN0
    #define RXCIE RXCIE0
    #define UDR UDR0
    #define UDRE UDRE0
    #define USART_RX USART0_RX_vect   
  #endif

in enc28j60.h

  #if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)


    #define ETH_INT_ENABLE   EIMSK |= (1<<INT2)


    #define ETH_INT_DISABLE EIMSK &= ~(1<<INT2)


  #endif

in rtl8019.c

#if defined (__AVR_ATmega644__) || defined (__AVR_ATmega1284P__)
  //Set Addr Port Direction = Output
  DATA_ADDR_RLT = OUTPUT;
#endif

in rtl8019.h

  #if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)
    #define ETH_INT_ENABLE       EIMSK |= (1<<INT0)
    #define ETH_INT_DISABLE     EIMSK &= ~(1<<INT0)
    #define ETH_INT_TRIGGER_MODE    EICRA |= 0x03;
    #define ETH_INTERRUPT       INT0_vect
    #define ISA_CTRL
  #endif

[Stefan F. (fanfan)]

Ah, stimmt. Die Tabelle (13.5) steht zwar bei TCCR1A, aber das Bit WGM12 
ist trotzdem in TCCR1B

#if Atmega644P
   TCCR1B |= (1<<WGM12);  //CTC(compare match mode)

Danke Joachim. Am Anfang habe ich dummerweise alle für mich unnützen #if 
... Anweisungen entfernt um die Übersichtlichkeit zu verbessern. Das 
rächt sich jetzt.
Ich werde mal deine Hinweise alle durchgehen.

EDIT:
alle #if-Anweisungen sind sogar noch da. Es hat sich also nichts 
geändert und es klappt immer noch nicht.

Allerdings habe ich noch etwas paradoxes gefunden:
Beim atmega32 leuchtet die grüne LED an der Ethernetbuchse dauerhaft und 
die orangene blinkt.

Beim 644P ist es genau andersherum. Kann mir da jemand auf die Sprünge 
helfen?

[Joachim B. (jar)]

Stefan Foydl schrieb:
> Allerdings habe ich noch etwas paradoxes gefunden:
> Beim atmega32 leuchtet die grüne LED an der Ethernetbuchse dauerhaft und
> die orangene blinkt.

muss irgendwo in den #defines umgeschrieben werden !

der NETIO kennt eh nur 10Mbit und welche blinkt ist eigentlich egal

vielleicht finde ich das noch im Netzwerk Source !

im enc28j60.h

  #if defined (__AVR_ATmega32__)
    #define ETH_INT_ENABLE   GICR |= (1<<INT2)
    #define ETH_INT_DISABLE GICR &= ~(1<<INT2)
  #endif

  #if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)
    #define ETH_INT_ENABLE   EIMSK |= (1<<INT2)
    #define ETH_INT_DISABLE EIMSK &= ~(1<<INT2)
  #endif

im enc28j60.c

  #if defined (__AVR_ATmega32__)
    #define ETH_INT_ENABLE   GICR |= (1<<INT2)
    #define ETH_INT_DISABLE GICR &= ~(1<<INT2)
  #endif

  #if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)
    #define ETH_INT_ENABLE   EIMSK |= (1<<INT2)
    #define ETH_INT_DISABLE EIMSK &= ~(1<<INT2)
  #endif

irgendwo waren die LEDs vertauscht.....
http://home.arcor.de/chlercher/elektronik/enc28j60.htm

Leider ist es nicht möglich die Software von Ulrich Radig direkt auf den AVR NET IO zu laden, da eine Signalleitung zur Steuerung des ENC28J60 anders ist ! Es handelt sich hierbei um das Signal CS das einmal über PB3 und einmal über PB4 gesteuert wird.

Um die grüne LED auch als Link-LED nutzen zu können muss in der Datei "enc28j60.c "

der Eintrag enc28j60_write_phy(ENC28J60_PHY_PHLCON, 0x347A) von 0x347A auf 0x374A verändert werden

[Stefan F. (fanfan)]

Joachim B. schrieb:
> der NETIO kennt eh nur 10Mbit und welche blinkt ist eigentlich egal
Ja klar, aber es ist schon mal ein Anzeichen, dass ungewollt irgendwas 
schief läuft. Original mit Atmega32 passt es ja.

> im enc28j60.h
>

>   #if defined (__AVR_ATmega32__)
>     #define ETH_INT_ENABLE   GICR |= (1<<INT2)
>     #define ETH_INT_DISABLE GICR &= ~(1<<INT2)
>   #endif
> 
>   #if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || 
> defined (__AVR_ATmega1284P__)
>     #define ETH_INT_ENABLE   EIMSK |= (1<<INT2)
>     #define ETH_INT_DISABLE EIMSK &= ~(1<<INT2)
>   #endif
>

Das sieht bei mir auch so aus.


> im enc28j60.c
>

>   #if defined (__AVR_ATmega32__)
>     #define ETH_INT_ENABLE   GICR |= (1<<INT2)
>     #define ETH_INT_DISABLE GICR &= ~(1<<INT2)
>   #endif
> 
>   #if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || 
> defined (__AVR_ATmega1284P__)
>     #define ETH_INT_ENABLE   EIMSK |= (1<<INT2)
>     #define ETH_INT_DISABLE EIMSK &= ~(1<<INT2)
>   #endif
>

Diesen Eintrag finde ich in meiner enc28j60.c nicht. Bist du dir da 
sicher? Es ist ja immerhin der gleiche Code wie in der .h

> irgendwo waren die LEDs vertauscht.....
> http://home.arcor.de/chlercher/elektronik/enc28j60.htm
>
> Leider ist es nicht möglich die Software von Ulrich Radig direkt auf den
> AVR NET IO zu laden, da eine Signalleitung zur Steuerung des ENC28J60
> anders ist ! Es handelt sich hierbei um das Signal CS das einmal über
> PB3 und einmal über PB4 gesteuert wird.

Irgendewo konnte man auch einstellen auf welcher Plattform es läuft. Da 
wurden dann glaube ich diese Ports getauscht. Ich finde es aber auf die 
Schnelle nicht im Code.
>
> Um die grüne LED auch als Link-LED nutzen zu können muss in der Datei
> "enc28j60.c "
>
> der Eintrag

>enc28j60_write_phy(ENC28J60_PHY_PHLCON, 0x347A) von 0x347A 
> auf 0x374A verändert werden
>

Habe ich gemacht, ändert aber nichts daran, dass die LEDs nur beim 644P 
vertauscht werden.

Im Anhang ist mal das gesamte Projekt für winAVR.
Eventuell hilft das ja.

[Joachim B. (jar)]

Stefan Foydl schrieb:
> Diesen Eintrag finde ich in meiner enc28j60.c nicht. Bist du dir da
> sicher? Es ist ja immerhin der gleiche Code wie in der .h

Stefan Foydl schrieb:
>>enc28j60_write_phy(ENC28J60_PHY_PHLCON, 0x347A) von 0x347A
>> auf 0x374A verändert werden
>>
> Habe ich gemacht, ändert aber nichts daran, dass die LEDs nur beim 644P
> vertauscht werden.

es ist mein aktuell laufender Code denke ich, kann aber zwische Server 
@work und Server @home Differenzen geben

im Moment zu müde ich schaue später noch mal bezüglich der Versionen....

[Joachim B. (jar)]

so was ich gepostet hatte war aktuell

besonders auch der Aufruf:
enc28j60_write_phy(ENC28J60_PHY_PHLCON, 0x374A);

allerdings hatte ich beim Umstieg auf m644 und später zum m1284p

jede einzelne Zeile vom gesamten Code verfolgt, war ne Sisyphusarbeit
aber weder sinnlos noch ohne Erfolg oder Ende, mein Code läuft ja !

Ich musste an unzähligen Stellen #defines einfügen ändern anpassen, ich 
fürchte das kann ich nicht für dich leisten. Aber dir meinen Code zur 
Verfügung zu stellen könnte ich zwar, aber das hilft dir vermutlich 
wenig weil du dann Dinge bekommst die du evtl nicht brauchst willst oder 
um die loszuwerden müsstest du dich genau Zeile für Zeile 
durchackern.......

und halbe Projektcodes lassen sich auch so schwer kompilieren.

[Stefan F. (fanfan)]

Joachim B. schrieb:
> und halbe Projektcodes lassen sich auch so schwer kompilieren.

Das stimmt allerdings. Das du den Code nicht komplett durchsuchst ist 
mir klar. Aber schon mal danke für die bisherigen Tipps.

Ich hatte gehofft, dass die Umrüstung relativ einfach geht, da die Radig 
Firmware ja auch (anscheinend nur so halb?) für den 644P ausgelegt ist. 
Zumindest kann man den µC ja z.B. im Makefile auswählen und es sind 
schon einige defines drinnen.

[Joachim B. (jar)]

Stefan Foydl schrieb:
> für den 644P ausgelegt ist.

Das Problem, obwohl der 644 und 1284 m32 pinkompatibel ist haben die 
Atmels sich alle Mühe gegeben die RegisterNamen umzuändern.

Das Ulrich seine eigenen #defines aufsetzt macht es an der Stelle auch 
nicht einfacher, aber das musste wohl sein um zwischen TIMSK und TIMSK1 
z.B. einen Kompromis zu finden.

[Stefan F. (fanfan)]

Mittlerweile habe ich einige defines erstellt, aber es hat sich immer 
noch nichts geändert.

Allerdings habe ich etwas anderes bemerkt:
Beim Atmega644P fängt der 16MHz Quarz nicht das schwingen an.
Laut original makefile sind lowfuse 0xff und highfuse 0xdf.
Welche werte habt ihr denn da verwendet?

[holger (Gast)]

>Beim Atmega644P fängt der 16MHz Quarz nicht das schwingen an.

Dann läuft der wohl noch mit dem internen RC Osci.
Ohne schwingenden Quarz könntest du sonst gar nicht mehr
ISP programmieren.

>Laut original makefile sind lowfuse 0xff und highfuse 0xdf.

Programmierst du mit AVRdude? Wenn nicht sind die Werte Schall und 
Rauch.
Im Hexfile landen die Fuses nicht.

[Joachim B. (jar)]

Stefan Foydl schrieb:
> Laut original makefile sind lowfuse 0xff und highfuse 0xdf.

die habe ich mir nie angesehen weil ich mit einem Mk2 Clone direkt die 
Fuses im Studio 4.18 setze

[Stefan F. (fanfan)]

Dass der Atmega644 im internen Quarzmodus läuft ist klar. Aber das soll 
er ja nicht. Mir fehlt aber da ein bisschen die Erfahrung und will ihn 
mir nicht verfusen. Welche Einstellung brauche ich da? Das sollte doch 
über SUT_CKsel gehen, oder?

Ich programmiere dann letztendlich über AVR Studio 5 mit einen AVRISP 
II. Dort habe ich bisher die high/lowfuse direkt eingegeben.

[Joachim B. (jar)]

Stefan Foydl schrieb:
> Ich programmiere dann letztendlich über AVR Studio 5 mit einen AVRISP
> II. Dort habe ich bisher die high/lowfuse direkt eingegeben.

das ist aber gefährlicher als den auf extern ab 8MHz- zu setzen und den 
Haken Clock Divider 8 wegzumachen

[Stefan F. (fanfan)]

Die aktuelle Fuse Konfiguration ist im Anhang. eigentlich steht er doch 
auf externem Quarz als Clock, oder?

[Joachim B. (jar)]

ja sieht gut aus....

[Stefan F. (fanfan)]

Gerade bin ich noch mal dazugekommen meinen Atmega644P mit dem Oszi zu 
kontrollieren.
Der 16 MHz Quarz schwingt wirklich nicht, die SPI Kommunikation zum 
Ethernetkontroller läuft ebenfalls nicht und mein Clocksignal für den 
Zeilensensor bleibt dauernd auf high.
Flashen kann ich bzw. AVR Studio 5 ihn aber ohne Probleme und 
Fehlermeldungen..

Die Fuses sind aber wie oben gesetzt. Jetzt bin ich langsam ratlos.
Woran kann das noch liegen, dass der Quarz nicht schwingt und somit 
keinen Takt erzeugt? Am Atmega32 funktioniert die Beschaltung ja ohne 
Probleme.

[Joachim B. (jar)]

Stefan F. schrieb:
> Jetzt bin ich langsam ratlos.
> Woran kann das noch liegen, dass der Quarz nicht schwingt

am Quarz.....(oder selten an den 22pF am Quarz)

schmeiss den raus, nimm gleich einen 20MHz und passe im Projektfile 
F_CPU an

ggffs nimmst auch gleich einen m1284p

[Stefan F. (fanfan)]

Joachim B. schrieb:
> am Quarz.....(oder selten an den 22pF am Quarz)
Hätte ich auch vermutet, aber warum werkelt der Atmega32 dann 
einwandfrei mit dem Quarz?
Das gleiche Verhalten tritt übrigens auch an einem zweiten NetIO auf 
wenn ich diesen Atmega644P einbaue.

Und warum kann ich darauf zugreifen, wenn er doch im Externen Quarz 
Modus ist, dieser aber nicht schwingt? Eine Umprogrammierung auf den 
internen Quarz bringt auch keine Veränderung.


> schmeiss den raus, nimm gleich einen 20MHz und passe im Projektfile
> F_CPU an
Das überlege ich im Moment auch, bringt aber erst dann was, wenn der µC 
gescheit läuft.

[Joachim B. (jar)]

Stefan F. schrieb:
> Das überlege ich im Moment auch, bringt aber erst dann was, wenn der µC
> gescheit läuft.

vielleicht hast du das Problem mit einem m1284p nicht erst.

Ich weiss grad nicht ob der Kondi am Quarz oder sogar der Quarz von der 
MCU beeinflußt wird, aber bei deiner Beschreibung liest sich das fast 
so.

Stefan F. schrieb:
> nd warum kann ich darauf zugreifen, wenn er doch im Externen Quarz
> Modus ist, dieser aber nicht schwingt? Eine Umprogrammierung auf den
> internen Quarz bringt auch keine Veränderung.

wie kann man zugreifen wenn der Chip auf extern Quarz programmiert ist 
aber dieser nicht schwingt ?

[Stefan F. (fanfan)]

Joachim B. schrieb:
> wie kann man zugreifen wenn der Chip auf extern Quarz programmiert ist
> aber dieser nicht schwingt ?

Genau da liegt der Knackpunkt. :-P
Oben habe ich meine Fuse Konfiguration als Bild gepostet. Der Quarz 
schwingt aber nicht.
Flash und eeprom kann ich aber sowohl beschreiben als auch auslesen. Die 
Werte darin ändern sich auch.

Wenn ich den Controller resete ändert er den von mir programmierten Takt 
für den Sensor genau einmal von low auf high und verharrt dann so.

Im Moment überlege ich mir auch noch einfach einen 644 zu holen nur um 
auszuschließen, dass meiner defekt ist.

Die Sache mit den vertauschten LEDs scheint übrigens vom enc28J60 zu 
kommen. Wenn gar kein µC eingebaut ist passiert das nämlich ebenfalls.

[Joachim B. (jar)]

Stefan F. schrieb:
> Genau da liegt der Knackpunkt. :-P
> Oben habe ich meine Fuse Konfiguration als Bild gepostet. Der Quarz
> schwingt aber nicht.

vielleicht ist hier die Lösung?

Beitrag "Probleme mit Atmega16 beim auschalten der Lötstation"

Peter Dannegger schrieb:
> When CKOPT is programmed, the Oscillator output will oscillate will a
> full rail-to-rail swing on the output. This mode is suitable when
> operating in a very noisy environment

[Stefan F. (fanfan)]

Jetzt habe ich mal etwas einfacheres ausprobiert: Natürlich nicht auf 
dem NetIO, sondern auf einer anderen Platine. An PD7 und PA5 hängen zwei 
LEDs in low-active Verschaltung.

    /* //fuer Atmega32
    #define TCCR0A TCCR0
    #define TCCR0B TCCR0
    #define OCR0A  OCR0
    #define TIMSK0 TIMSK
    #define OCIE0A OCIE0
    #define TIMER2_COMPB_vect TIMER0_COMP_vect
    */

#include <stdlib.h>
#include <avr/io.h>
#include <avr/interrupt.h>      // Für Interruptbehandlung nötig
  
// CPU Frequenz
#define F_CPU 9600000UL
//      Setze Bit
#define SetBit(ADDR,BIT)        ((ADDR)  |=  (1<<(BIT)))
//      Lösche Bit
#define ClrBit(ADDR,BIT)        ((ADDR)  &= ~(1<<(BIT)))
//      Toggel Bit
#define ToggleBit(ADDR,BIT)     ((ADDR)  ^=  (1<<(BIT)))

volatile uint16_t counter;
//
void init(void);
void timer_init(void);  // Init Tmr/Cntr 0, 8-Bit auf 20 kHz = 50 µs
ISR(TIMER2_COMPB_vect);
 
 
void init(void){
  DDRD |= (1<<7);  //PD7 -> Ausgang
  DDRA |= (1<<5);  //PA5 -> Ausgang
  PORTD |= (1<<7);  //PD7 -> high
  PORTA &= ~(1<<5);  //PA5 -> low
  
  TC0TMR_init ();
}


// ============================================================================= =
// ===  Initialisierung des Timer0 ATmega32 für CTC
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 void timer_init(void)         // Init Tmr/Cntr 0, 200µs bei 9,6 Mhz = 5kHz
// - - - - - - - - - - - - - - - -
 {                         //
  TCCR0A        |= (1<<WGM01);  // Timer im CTC-Mode, Top=OCR0                 73
  TCCR0A        &= ~(1<<WGM00);  // kein PWM
  TCCR0B        |= (1<<CS00);
  TCCR0B        &= ~(1<<CS01);
  TCCR0B        |= (1<<CS02);  // Prescaler 256  =>  Clock = CPUclk/256            74
  OCR0A          = 255;      // Preset 239 für 200µs bei 9,6 Mhz  
                                // 200 µs <=> 2,5 kHz
                //jedes Mal wenn der Timer 239 erreicht gibt es einen Interrupt
  TIMSK0        |= (1<<OCIE0A);  // Tmr/Cntr0 CompareA interrupt enabled
 }              // Ende void TC0TMR_init(void)
// ============================================================================= =

 ISR(TIMER2_COMPB_vect){
  ToggleBit (PORTD, 7);  //  .. LED1 toggeln
  counter++;
  if(counter%10 == 0){
    ClrBit (PORTA, 5);    //LED2 an -> low active!
    counter = 0;
  }
  if(counter%10 == 1){
    SetBit (PORTA, 5);  //LED2 aus
  }
    return;
 }


int main(void){
  init();        //Initialisierung
  sei();        //Interrupts aktiviert
  
  while ( 42 ){
  }             // Ende while ( 1 ...
}                      //

Am Atmega32 toggelt er die eine LED schnell und die andere halt immer 
wieder mal. Also so wie es soll.

Beim Atmega644P geht die eine LED dauerhaft an, die eigentlich selten 
blinkende bleibt immer aus.

Habe ich da oben schon einen Schnitzer drin?

[derElf (Gast)]

möglicherweise die Resetschaltung nicht ganz sauber?

[Joachim B. (jar)]

Stefan F. schrieb:
> Habe ich da oben schon einen Schnitzer drin?

die ganzen Timerregister sind doch andere, entweder du machst #defines 
für die passenden Register oder je nach Prozzi andere ....

hatte ich das nicht schon gezeigt ?

[Stefan F. (fanfan)]

Joachim B. schrieb:
> die ganzen Timerregister sind doch andere

Die sollten für den Atmega644P angepasst sein. Nur die Kommentare sind 
nicht geändert.

Oben kann ich manuell per defines wieder auf den Atmega32 umschalten.

Danke für den Link. Ich lese ihn mir gerade durch.
Edit: ckopt gibt es beim Atmega644P leider nicht

@derElf: Laut Oszi liegt am Reset-Pin ein schönes high-Signal an.

[RAMfresser (Gast)]

Stefan,

der 644P verbraucht mehr RAM für Register und IO als der 328. Prüf' doch 
einmal, ob die RAM-Anfangsadresse auf den richtigen Wert für den 644P 
(ich glaube 0x100 statt 0x060) gesetzt wird.

Hans

[Joachim B. (jar)]

RAMfresser schrieb:
> 644P verbraucht mehr RAM für Register und IO als der 328

er hat ein Pollin NETIO und das wurde mit ATmega32 ausgeliefert, der 
644p ist Pinkompatibel (wie der m1284p) und hat sich bei mir nicht wie 
ein m328p benommen (von daher ist der Tipp wenig zielführend ?)

[Stefan F. (fanfan)]

Im vereinfachten Beispiel oben waren es nur ein paar Tippfehler. 
Mittlerweile klappt es mit der einfachen Beschaltung und dem internen 
Oszilator.

Am NetIO ist mir jetzt noch folgendes aufgefallen. Der Atmega32 liefert 
1,6V an den Quarz, der enc28J60 ebenfalls deutlich über 1,3V.
Der 644P dagegen aber nur 0,8V. Liegt das daran, dass ich die 
"P"-Variante habe?
Gibt es dann spezielle low-Power Quarze?

[spess53 (Gast)]

Hi

>Liegt das daran, dass ich die "P"-Variante habe?

Nein. Es kommt darauf an, ob du Low Power Crystal Oscillator oder Full 
Swing Crystal Oscillator mit den Fuses eingestellt hast.

MfG Spess

[Stefan F. (fanfan)]

Die Fuses sind oben als .png sichtbar. Da kann man in AVR Studio 5 
leider keinen Unterschied machen.
Die CKOPT Fuse gibt es beim 644P ja anscheinend nicht.
Wie stellt man das dann ein?

[Stefan F. (fanfan)]

Jetzt schwingt der Quarz. Ich habe einen online fuse-calculator benutzt.
Das ändert aber leider auch nichts an den Problemen, dass anscheinend 
nichts geht.
weder die Ethernet Schnittstelle noch die serielle antwortet.

[Stefan F. (fanfan)]

Letzte Woche habe ich mir dann noch mal einen normalen Atmega644 ohne P 
besorgt. Auf dem läuft eins zu eins der selbe Code einwandfrei.

[c-hater (Gast)]

Stefan F. schrieb:

> Die Fuses sind oben als .png sichtbar. Da kann man in AVR Studio 5
> leider keinen Unterschied machen.

Doch natürlich kann man das. Man muß dazu bloß die primitivsten 
Grundlagen der Bedienung von Desktop-Oberflächen beherrschen...

Dann sieht man, daß die Liste der gezeigten Combobox eine Trackbar hat, 
was bedeutet, daß die Liste mehr Einträge hat, als auf einmal angezeigt 
werden können. Die Trackbar braucht man dann bloß noch benutzen, um 
weitere Takt-Optionen in den sichtbaren Bereich der Liste 
reinzuscrollen. Darunter sind auch einige, deren Namen mit "FULLSWING" 
anfangen.

[Stefan F. (fanfan)]

Herzlichen Dank lieber c-Hater. Jetzt bitte nicht böse sein, aber wenn 
man die primitive Grundlage des Lesens beherrscht sieht man, dass ich 
das fuse-Problem auch am 644P schon gelöst habe. Der Fullswing-mode lief 
schon mit dem externen Quarz.
Dazu habe ich mir lediglich die Kenntnis aneignen müssen, was die 
CKOPT-fuse macht und wie das bei den moderneren Atmels gelöst wurde.
"Fullswing" taucht übrigens nirgends als Klartext in diesem Menü auf, 
sodass ich mich auch da erst mal kundig machen musste bevor ich etwas 
falsches einstelle.
Als "Übersetzungs-"Hilfe diente mir dabei der fuse-calculator.