Atmeg führt reset ohne Grund durch

[Tobi (Gast)]

Hallo,

ich habe eine kleine Regelung mit einem PID-Regler wie in AVR221 
beschrieben aufgebaut. Der Istwert wird über den ADC 0 einglesen 
Sollwert über ADC1, die Stellgröße wird über PWM gesteuert. Die Regelung 
kann ich über RS232 starten, indem ich die Dezimalzahl 11 schicke.
Ich verwende eine ATmega1284.
Nun zum Problem:
Das ganze funktioniert ganz gut bei dem interen Takt von 1 MHz. Jetzt 
will ich das ganze mit einem 20 MHz Quraz laufen lassen.
Sobald ich jetzt die Regelung über die RS232 starte, beginnt die 
Regelung zu arbeiten, aber der Mikrocontroller startet jedes mal neu bei 
der Initialisierung. Erkenntlich dadurch, das bei jeder Initiaisierung 
über die RS232-Schnittstelle die Dezimalzahl 12 geschickt wird.

Hat jemand eine Idee warum das so ist.

Hier noch der Code:

#include <avr/io.h>
#include <avr/interrupt.h>
#include "pid.h"
#include <stdio.h>
#include <stdint.h>

#define F_CPU 20000000UL // Frequenz des AVR 20Mhz
#define BAUDRATE 19200UL // Festlegen der Baudrate für RS232 Übertragtung.

#define P_MATLAB -5
#define I_MATLAB 20
#define D_MATLAB 0.01


void init_USART (void);
void send_USART0 (uint8_t data);
void init_ADC (void);
void init_PWM (void);
void init_Port(void);
void set_PWM (uint16_t soll, uint16_t max_wert);
void init_Timer (void);
void init_PID(void);
uint16_t read_ADC(uint8_t channel);

volatile uint8_t i;
volatile uint16_t soll;

//! Parameters für PID Regler
struct PID_DATA pidData;


int main(void)
{
  init_Port();
  init_ADC();
  init_USART();
  init_PWM();  
  init_PID();
  send_USART0(12);
  
  
  
  sei(); // Aktivieren der Interrupts
    while(1)
    {
    
        //TODO:: Please write your application code 
    }
}
ISR (USART0_RX_vect)
{
  uint8_t buffer;
  uint16_t;
  buffer = UDR0;
  if (buffer == 11)
  {
    init_Timer(); // Startet Regelung
  }
  send_USART0(buffer);
}

ISR (TIMER0_COMPA_vect)
// Timer0 Interruppt
{
  uint16_t  ist;
  uint16_t pwm_signal;
  int16_t Stellgr;
  ist = read_ADC(0); // Istwert an ADC0 einlesen
  soll = read_ADC(1); // SOllwert über AC1 einlesen
  Stellgr = pid_Controller(soll,ist,&pidData);
  if (Stellgr<0)
  {
    Stellgr = 0;
  }
  pwm_signal = Stellgr;
  set_PWM(pwm_signal,32768);
}
void send_USART0 (uint8_t data)
//Sendet Daten über den USART 0
{
  while ((UCSR0A & (1<< UDRE0))== 0)
  {} // Warten bis Senderegister leer ist
  UDR0 = data; // Daten in das Senderegister schieben
}

void init_USART (void)
// USART 0 wird initialisiert
{
  UBRR0 = (F_CPU/(16UL*BAUDRATE))-1; //Einstellen der Baudrate
  UCSR0B |= (1<<RXCIE0)|(1<<RXEN0)|(1<<TXEN0); // Empfangsinterupt ein, Empfangen und Senden möglich
  UCSR0C = 0; // asynchroner Modus, keine Parity,  1 Stopbit
  UCSR0C |= (1<<UCSZ01)|(1<<UCSZ00); // 8-bit Datentransfare
}

void init_ADC (void)
// initialisiert den Analog-Digital-Wandler
{
  uint16_t result;
  ADMUX = 0; // Referenz Vacc mit 100nF an Aref, kein Gain
  ADCSRA = (1<<ADPS2)|(1<<ADPS1)|(1<<ADPS0); // Register auf 0 setezen und nur den Prescaler auf 128 (156kHz bei 20Mhz)
  //ADCSRA = (1<<ADPS1)|(1<<ADPS0);// Register auf 0 setezen und nur den Prescaler auf (8 125kHz bei 1Mhz)
  ADCSRA |= (1<<ADEN); // ADC aktiviert
  ADCSRA |= (1<<ADSC); // Starten konvertierung
  while (ADCSRA & (1<<ADSC)) {}  // Warten bis Konvertierung fertig
  result = ADC; // Dummy-Auslesen des ADC's
}


uint16_t read_ADC(uint8_t channel)
// führt eine ADC-Wandlung an dem übergebenen Channel durch
// Falls der channel außerhalb des zulässigen Bereiches liegt wird der Wert 0xFF zurückgegeben.
{
  uint16_t result=0;
  uint8_t n = 0;
  if (channel<8)
  {
    ADMUX = channel;  
    ADCSRA |= (1<<ADSC); // Starten konvertierung
      while (n<3)
      {  while (ADCSRA & (1<<ADSC)) {}  // Warten bis Konvertierung fertig  
        result = result + ADC;
        n = n+1;
      }
    result = result/3;
  }
  else
  {
    result = 0xFF;
  }
  return result;
}


void init_PWM (void)
// Initialisiert PWM
// Timer 1 für PWM 16 bit
{
  TCCR1A |= (1<<COM1A1); // nicht invertierende Modus OC1A
  TCCR1A |= (1<<WGM11);
  TCCR1B |= (1<<WGM12)|(1<<WGM13); //Fast PWM Mode, TOP ICR1-Register
  TCCR1B |= (1<<CS10); //Prescaler 1
  ICR1 = 499; // PWM-Frequenz 40KHz gitl bei 20 Mhz
  //ICR1 = 50; //PWM-Frequenz 5 kHz bei 1 Mhz
  OCR1A = 0; // PWM auf 0
  
  PORTC |= (1<<PORTC1);
}

void init_Port(void)
//Initialisiert die Ports
{
  DDRD = 0b11110000; // PD4-PD7 als Ausgang
}

void set_PWM (uint16_t soll, uint16_t max_wert)
// Stellt den PWM ein, max_wert gibt den Maximalen Wert an, was soll erreichen kann
{
  uint16_t  max_register;
  uint32_t soll_register;
  max_register = ICR1;
  //soll_register = (soll/(max_wert/max_register));
  soll_register = soll/65; 
  OCR1A = soll_register;
}

void init_Timer (void)
// Initialisiert Timer für die Diskretisierung
{
  TCCR0A |= (1<<WGM01); //CTC Modus
  TCCR0B |= (1<<CS00); //Prescaler 1
  OCR0A = 199; // 50kHz bei 20 Mhz
  //OCR0A = 199; //2,5 kHz bei 1 Mhz
  TIMSK0 |= (1<<OCIE0A); // Interrupt compare A ein
  PORTB |= (1<<PINB0); // setz Pinb0 auf 1 wenn regelung aktiv ist.
}

void init_PID(void)
//Initalisiern PID_Regeler
{
  int16_t KP,TI,TD;
  KP = P_MATLAB*SCALING_FACTOR;
  TI = P_MATLAB*SCALING_FACTOR*I_MATLAB;
  TD = P_MATLAB*SCALING_FACTOR*D_MATLAB;
  pid_Init(KP, TI  , TD, &pidData);
}

Kurz Erklärung zum Code:
TimerO -> Ist für die gleichmäßige Abtastung während der PID-Regelung 
verantwortlich
Timer1 -> Generiert das PWM Signal
Funktion pid_Controller -> berechnet die Stellgröße für des PID-Reglers.

[Tobi (Gast)]

Hab gleich eine Nachtrag.
Ich hatte als Referenzspannung bei der AD-Wandlung intern auf AVCC 
zugegriffen. Wenn ich jetzt auf die exteren Refernzspannung AREF wechsel 
und von AVCC nach AREF eine Brücke lege stecke und den Code ändere läuft 
die Regelung auch bei 20MHz wie gewollt.
Scheint das Problem gelöst zu sein, aber warum??
Kann mir das nicht erklären, hat jemand eine Idee?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Tobi schrieb:

 ISR (TIMER0_COMPA_vect)
 // Timer0 Interruppt
 { 
   ...
   ist  = read_ADC(0); // Istwert an ADC0 einlesen
   soll = read_ADC(1);

 uint16_t read_ADC(uint8_t channel)
 {
       while (n<3)
       {  while (ADCSRA & (1<<ADSC)) {} // Warten bis Konvertierung 
 fertig

Im Interrupt 6 mal auf den AD-Wandler warten? Das ist eine schlechte 
Idee...

Und dann noch das:

    result = result/3;

Wenn das wenigsten 4 gewesen wären. Oder 2. Denk mal drüber nach, dass 
ein uC binär in Zweierpotenzen toll und schnell arbeiten kann...

Tobi schrieb:
> Hab gleich eine Nachtrag. .....  hat jemand eine Idee?
Wie sieht die Schaltung und das Layout aus?

[Pandur S. (jetztnicht)]

Im UartRx interrupt den Timer aufzurufen und den UartTx auch gleich noch 
kannst vergessen. So wird das nie was.

Das Zauberwort heisst Zustandsmaschine. Alles wird im Main abgehandelt, 
in einem Interrupt fast nichts.

[MWS (Gast)]

Tobi schrieb:
> OCR0A = 199; // 50kHz bei 20 Mhz

Laut meiner Rechnung sind das 100kHz.

> // Register auf 0 setezen und nur den Prescaler auf 128 (156kHz bei
> 20Mhz)

Der ADC benötigt für eine Wandlung 13 ADC-Clocks = 13 x 128 = 1664 
µC-Clocks.
Zweimal wandeln dauert also mehr als 3328 µC-Clocks, den Rest-Code außer 
acht gelassen.

Aufgerufen wird die OC0-ISR und damit die ADC-Wandlungen alle 200 
µC-Clocks. Wie soll das gehen?

> Wenn ich jetzt auf die exteren Refernzspannung AREF wechsel
> und von AVCC nach AREF eine Brücke lege stecke und den Code ändere läuft
> die Regelung auch bei 20MHz wie gewollt.

Da kannst Du Drähte hinstecken wo Du willst, das funktioniert mit dem 
gezeigten Code nicht wie's soll, denn das zeitbestimmende Element ist 
tatsächliche die Durchlaufzeit der ISR und nicht die Aufrufrate der ISR.

[Karl H. (kbuchegg)]

Mal abgesehen vom Rest.

Jag den Compiler über dein Projekt drüber.

Danach scrollst du mal hoch und korrigierst ALLE Warnungen, die du vom 
Compiler kriegst.

Und PS:
Eine derartige Warnung

C:\Projekte\AVR\M1284_PWM\M1284_PWM\M1284_PWM.c(60,1): 'USART0_RX_vect' appears to be a misspelled signal handler [enabled by default]

ist eine, die man nicht ignorieren darf.

Einige Warnungen kann man ignorieren. Manche allerdings nicht.
Blöd natürlich, wenn es in deinem Projekt einige Warnungen gibt und du 
die nicht so wichtigen von den tatsächlich wichtigen nicht trennst. Mach 
es dir zur Maxime: Ein Projekt muss komplett ohne Warnungen kompilieren. 
Selbst wenn es eine tatsächlich harmlose Warnung ist, wird ihre Ursache 
beseitigt.

[Tobi (Gast)]

>Tobi schrieb:
>- OCR0A = 199; // 50kHz bei 20 Mhz

>Laut meiner Rechnung sind das 100kHz.

Ich muss doch die Freqeunz über

$$f = \frac{f_{clk_I/O}}{2*N*(1+OCRNA})$$

 berechnen, da komm ich auf 50 kHz.

>Aufgerufen wird die OC0-ISR und damit die ADC-Wandlungen alle 200
>µC-Clocks. Wie soll das gehen?

Die Lösung ware es die Abtastfreqeunz nach unten zu schrauben??

Haltet ihr das für sinvoll den Messwert zu Mitteln oder soll ich mir das 
sparen??

[Karl H. (kbuchegg)]

Tobi schrieb:
>>Tobi schrieb:
>>- OCR0A = 199; // 50kHz bei 20 Mhz
>
>>Laut meiner Rechnung sind das 100kHz.
>
> Ich muss doch die Freqeunz über

$$f = > \frac{f_{clk_I/O}}{2*N*(1+OCRNA})$$

 berechnen, da komm ich auf 50
> kHz.

Das mag schon sein, dass du das willst.

Aber bei 50kHz Interrupt Frequenz hat dein AVR gerade mal 20Mhz / 50Khz 
oder gleich 400 Takte Zeit um all das abzuarbeiten, was in deiner 
Timer-ISR vorkommt.

Und das geht sich nun mal nicht aus.

Wenn du zur Herstellung eines Werkstücks 5 Stunden brauchst, dann kann 
sich dein Boss Kopf stellen und sich wünschen du würdest ihm 20 Pro 
Stunde herstellen. Was nicht möglich ist, ist nicht möglich.

[Thomas E. (thomase)]

Karl Heinz schrieb:
> Einige Warnungen kann man ignorieren. Manche allerdings nicht.
> Blöd natürlich, wenn es in deinem Projekt einige Warnungen gibt und du
> die nicht so wichtigen von den tatsächlich wichtigen nicht trennst. Mach
> es dir zur Maxime: Ein Projekt muss komplett ohne Warnungen kompilieren.
> Selbst wenn es eine tatsächlich harmlose Warnung ist, wird ihre Ursache
> beseitigt.

Gar keine Frage. Aber "ISR(USART0_RX_vect)" ist der richtige Handler 
beim Atmega 1284.


Tobi schrieb:
> Die Lösung ware es die Abtastfreqeunz nach unten zu schrauben??
>
> Haltet ihr das für sinvoll den Messwert zu Mitteln oder soll ich mir das
> sparen??

Ich mittel die auch eher selten.

Aber sowas ist doch keine Lösung. Ein Programm stürzt nicht ab, weil man 
Messwerte mittelt.

mfg.

[Karl H. (kbuchegg)]

Tobi schrieb:

> Ich muss doch die Freqeunz über

$$f = > \frac{f_{clk_I/O}}{2*N*(1+OCRNA})$$

 berechnen, da komm ich auf 50
> kHz.

Und nein.
Du hast die falsche Formel benutzt.

Lass mal die Formel Formel sein und überleg dir lieber, wie oft die ISR 
pro Sekunde aufgerufen wird.

FAQ: Timer

[Karl H. (kbuchegg)]

Thomas Eckmann schrieb:
> Karl Heinz schrieb:
>> Einige Warnungen kann man ignorieren. Manche allerdings nicht.
>> Blöd natürlich, wenn es in deinem Projekt einige Warnungen gibt und du
>> die nicht so wichtigen von den tatsächlich wichtigen nicht trennst. Mach
>> es dir zur Maxime: Ein Projekt muss komplett ohne Warnungen kompilieren.
>> Selbst wenn es eine tatsächlich harmlose Warnung ist, wird ihre Ursache
>> beseitigt.
>
> Gar keine Frage. Aber "ISR(USART0_RX_vect)" ist der richtige Handler
> beim Atmega 1284.

Mein Atmel-Studio behauptet da was anders.


Für einen Prozessor-Reset gibt es 2 Möglichkeiten
* Hardware
* falsche oder fehlende ISR

Dass seine Regelung nicht funktionieren wird, steht ausser frage. Aber 
das ist kein Grund für einen Reset. Das Thema muss man natürlich 
adressieren, ganz klar. Aber um den Prozessor-Reset zu finden ist es 
erst mal Nebenschauplatz.

Seine Hardware kann ich nicht testen. Aber mein Atmel Studio behauptet, 
aus welchem Grund auch immer, dass sich

USART0__RX_vect

mit 2 Stück Underscores (in Summe also 3) schreibt.

[Karl H. (kbuchegg)]

Karl Heinz schrieb:

> Seine Hardware kann ich nicht testen. Aber mein Atmel Studio behauptet,
> aus welchem Grund auch immer, dass sich
>

> USART0__RX_vect
>

> mit 2 Stück Underscores (in Summe also 3) schreibt.


Wenn ich hingegen, anstatt einem Mega1284 einen Mega1284P einstelle, 
dann ist USART0_RX_vect wieder richtig. :-)

[Arduinoquäler (Gast)]

>> Atmeg führt reset ohne Grund durch

Die Aussage bezweifle ich. Der Prozessor mag zwar vielleicht
einen Reset durchlaufen aber sicherlich nicht ohne Grund.

Und der Grund liegt sicher nicht im Fehlverhalten des Prozessors.

[Tobi (Gast)]

>Danach scrollst du mal hoch und korrigierst ALLE Warnungen, die du vom
>Compiler kriegst.

Tut mir leid, aber bei mir kommt keine Fehlermeldung.



Ich werde auf jeden Fall meine Regelung überarbeiten, sodass die auch 
Funktioniert.

Kann das mit dem Reset daran leigen, das zuviel ISR aufgerufen werden?

[Tobi (Gast)]

>Die Aussage bezweifle ich. Der Prozessor mag zwar vielleicht
>einen Reset durchlaufen aber sicherlich nicht ohne Grund.

Hast recht, blos mir erschließt sich der Grund noch nicht ganz.

[Pete K. (pete77)]

Abblockkondensatoren?

[Tobi (Gast)]

Hier mal der Schaltplan. EAGLE hatte den 1284 als Layout nicht. Ist aber 
kompatibel zum Atmega 32

[Tobi (Gast)]

Jetzt mit Anhang

[Arduinoquäler (Gast)]

Tobi schrieb:
> Hier mal der Schaltplan.

Ein sogenannter NullSchaltplan. Analog zur NullDevice ....

[Arduinoquäler (Gast)]

Tobi schrieb:
> Jetzt mit Anhang

Ah jetzt ja.

--> keine Keramischen Abblock-Cs an allen Vcc Pins !

Schwerer Fehler.

[MWS (Gast)]

Tobi schrieb:
> berechnen, da komm ich auf 50 kHz.

Die Aufrufrate der ISR ist ClkIO / (Prescaler * (OCR + 1)).

Karl Heinz schrieb:
> Aber mein Atmel Studio behauptet,
> aus welchem Grund auch immer, dass sichUSART0__RX_vect
> mit 2 Stück Underscores (in Summe also 3) schreibt.


Da musst Du wohl mal ein Update machen, Atmel hat wohl im AVR-Studio 5.1 
beim iom1284.h ein paar Unterstriche reingemurkst, die im iom1284p.h und 
in einer aktuellen Toolchain nicht drin sind.

> Wenn ich hingegen, anstatt einem Mega1284 einen Mega1284P einstelle,
> dann ist USART0_RX_vect wieder richtig. :-)

Kein Wunder.

[Dietrich L. (dietrichl)]

Tobi schrieb:
> Hier mal der Schaltplan.

- man sieht nicht, welche Kreuzungen verbunden sind => da fehlen die 
Punkte!
- 100µF ist vermutlich falsch? => 100nF Keramik!
- jedes VCC-GND-Pärchen braucht einen eigenen C
- wie ist das Layout? => die Cs müssen sehr nah an µC sein, der GND muss 
'solide' sein, d.h. wenig 'zerrupft'.

Gruß Dietrich

[Paul B. (paul_baumann)]

Karl Heinz schrieb:
> Und PS:
> Eine derartige
> WarnungC:\Projekte\AVR\M1284_PWM\M1284_PWM\M1284_PWM.c(60,1):
> 'USART0_RX_vect' appears to be a misspelled signal handler [enabled by
> default]
> ist eine, die man nicht ignorieren darf.

Thomas Eckmann schrieb:
> Gar keine Frage. Aber "ISR(USART0_RX_vect)" ist der richtige Handler
> beim Atmega 1284.

Karl Heinz schrieb:
> Aber mein Atmel Studio behauptet,
> aus welchem Grund auch immer, dass sichUSART0__RX_vect
> mit 2 Stück Underscores (in Summe also 3) schreibt.

Karl Heinz schrieb:
> Wenn ich hingegen, anstatt einem Mega1284 einen Mega1284P einstelle,
> dann ist USART0_RX_vect wieder richtig. :-)

Tobi schrieb:
> Tut mir leid, aber bei mir kommt keine Fehlermeldung.

Das ist ja eine feine Sache, wenn das Kompilieren des gleichen 
Quelltextes bei mehreren Leuten unterschiedliche Resultate liefert.
Mit so etwas kann man sich die Schwindsucht an den Hals ärgern...

SCNR Paul

[Arduinoquäler (Gast)]

Dietrich L. schrieb:
> - 100µF ist vermutlich falsch? => 100nF Keramik!

Der Elko kann zwar Ladung speichern, aber schnelle Spannungseinbrüche
von Prozessor-Stromschwankungen puffern/abblocken sicherlich nicht.

[Arduinoquäler (Gast)]

Paul Baumann schrieb:
> Das ist ja eine feine Sache, wenn das Kompilieren des gleichen
> Quelltextes bei mehreren Leuten unterschiedliche Resultate liefert.

Man bräuchte ja bloss mal den gleichen Compiler und die
gleichen Compiler-Flags verwenden .....

[Tobi (Gast)]

Dietrich L. schrieb:
> - man sieht nicht, welche Kreuzungen verbunden sind => da fehlen die
> Punkte!
> - 100µF ist vermutlich falsch? => 100nF Keramik!
> - jedes VCC-GND-Pärchen braucht einen eigenen C
> - wie ist das Layout? => die Cs müssen sehr nah an µC sein, der GND muss
> 'solide' sein, d.h. wenig 'zerrupft'.

Sind natürlich 100 nF.

Wie erkenne ich welche vcc-gnd zusammen gehören.

Kondensatoren sind dierekt am Mikrocontroller. Die gnd-leitungen sind 
alle möglichst kurz, soweit das auf einem Steckbrett möglich ist.

[Arduinoquäler (Gast)]

Tobi schrieb:
> Wie erkenne ich welche vcc-gnd zusammen gehören.

Es gehört alles zusammen. Alle 5V gehören nah zusammen, und
alle GND Pins gehören nah zusammen. Und nah dazwischen die
Abblock-Cs.

Nackter Prozessor auf Steckbrett ist schon mal verdächtig.

Am Besten zu zeigst (in bewährter Salami-Taktik) jetzt auch mal
deinen Breadboard-Aufbau.

[0815 (Gast)]

Karl Heinz schrieb:
> Für einen Prozessor-Reset gibt es 2 Möglichkeiten
> * Hardware
> * falsche oder fehlende ISR

... oder als dritte Möglichkeit einen überlaufenden Stack durch:

Tobi schrieb:
> Kann das mit dem Reset daran leigen, das zuviel ISR aufgerufen werden?

[Joachim B. (jar)]

Tobi schrieb:
> Wie erkenne ich welche vcc-gnd zusammen gehören.

du machst doch den Plan also legst du fest welche VCC und welche GND 
zusammen gehören, es ist DEINE Schaltung, wobei alle GND zusammen 
gehören (selten AGND noch mal extra geführt wird) und AVCC evt. 
fremdversorgt wird oder an VCC geklemmt, aber das entscheidest doch du 
als Planer.

[Arduinoquäler (Gast)]

Tobi schrieb:
> Kondensatoren sind dierekt am Mikrocontroller. Die gnd-leitungen sind
> alle möglichst kurz, soweit das auf einem Steckbrett möglich ist.

Wenn ich Steckbrett höre wird's mir schon schwummrig ....

Ich möchte mal provokativ eine voreilige Frage stellen:

Warum hat ATMEL die Quarz-Anschlüsse 7, 8 direkt neben einen
Ground Pin (6) plaziert?

[Mark B. (markbrandis)]

Karl Heinz schrieb:
> Für einen Prozessor-Reset gibt es 2 Möglichkeiten
> * Hardware
> * falsche oder fehlende ISR

Zählt ein eventuell falsch konfigurierter Watchdog als Hardware? :-)

[F. F. (foldi)]

Karl Heinz schrieb:
> Für einen Prozessor-Reset gibt es 2 Möglichkeiten
> * Hardware

Das ließe sich leicht mit irgendeinem trivialen Programm testen, um so 
auszuschließen, dass es die Hardware ist.

[Karl H. (kbuchegg)]

0815 schrieb:
> Karl Heinz schrieb:
>> Für einen Prozessor-Reset gibt es 2 Möglichkeiten
>> * Hardware
>> * falsche oder fehlende ISR
>
> ... oder als dritte Möglichkeit einen überlaufenden Stack durch:
>
> Tobi schrieb:
>> Kann das mit dem Reset daran leigen, das zuviel ISR aufgerufen werden?

Das kann bei ihm nicht passieren.
Er hat keine sei() in der ISR (zumindest nicht in dem Teil, den man 
sehen kann)

[Karl H. (kbuchegg)]

MWS schrieb:

> Da musst Du wohl mal ein Update machen, Atmel hat wohl im AVR-Studio 5.1
> beim iom1284.h ein paar Unterstriche reingemurkst, die im iom1284p.h und
> in einer aktuellen Toolchain nicht drin sind.

Merci.
Hab den Update auf 6.2 SP2 gemacht und da ist dann alles so wies sein 
soll.

[Arduinoquäler (Gast)]

Nachdem es hier urplötzlich sooooo still geworden ist
funktioniert offensichtlich alles, oder der Prozessor
funktioniert nicht richtig, ist an allem schuld:

- der Steckbrett Aufbau ist sicherlich von höchster Güte und
übertrifft alles was sonst in aufwendiger Kleinarbei hand-
geroutet auf gedruckte Schaltungen gebracht wird.

- die 100uF Kondensatoren im Schaltplan sind gaaaaaaaanz
sicher in Wirklichkeit sehr gute 100nF Kondensatoren.
Ich schwör! Doppelschwör!

- die Lastkapazitäten am Quarz sind sicherlich päpstlicher
als der Papst vorschreibt verdrahtet.

Und das alles selbstverständlich auf dem Steckbrett wo alleine
der Mega1284 im DIL Gehäuse eine räumliche Ausbreitung von
52mm x 16 mm einnimmt was der Verbindung der einzelnen Power-
Pins auf jedem Fall nur förderlich ist. Ganz zu schweigen von
den Abblock Kondensatoren die ja innigst mit den Power Pins
verbunden sind.

Deswegen brauchen wir uns den Steckbrett-Aufbau auch gar nicht
erst anschauen.

[Herbergsvater (Gast)]

Arduinoquäler schrieb:
> Deswegen brauchen wir uns den Steckbrett-Aufbau auch gar nicht
> erst anschauen.

WIR?

Vielleicht ist der TO nicht gewillt, sich mit Trollen 
auseinanderzusetzen
und übergeht deshalb Deine Anwürfe? Möglich wäre das doch...

[Arduinoquäler (Gast)]

Herbergsvater schrieb:
> WIR?

Das mag schon sein dass du es nicht für notwendig hältst
seinen Schaltungsaufbau zu begutachten.

[Tobi (Gast)]

Arduinoquäler schrieb:
> Nachdem es hier urplötzlich sooooo still geworden ist
> funktioniert offensichtlich alles, oder der Prozessor
> funktioniert nicht richtig, ist an allem schuld

Vielleicht muss man ja auch Geld für sein Hobby verdienen und kann nicht 
immer hier folgen.

Hab jetzt noch ein bischen was ausprobiert und es klappt jetzt wieder.
Ich habe folgendes geändert:

- Alle Deklarationen aus den ISR raus
- Abtastfreqeunz nach unten geschraubt, sodass sich der µC nicht selbst 
einholt
- Regleralgorithmus in die main gepackt

Am Aufbau auf dem Steckbrett hab ich nichts verändert.

[Arduinoquäler (Gast)]

Tobi schrieb:
> Hab jetzt noch ein bischen was ausprobiert und es klappt jetzt wieder.
> Ich habe folgendes geändert:

Das steht allerdings in einem gewissen Widerspruch zu der
Aussage dass bei 1 MHz alles funktioniert hat .....

[Tobi (Gast)]

Arduinoquäler schrieb:
> Das steht allerdings in einem gewissen Widerspruch zu der
> Aussage dass bei 1 MHz alles funktioniert hat .....

So im Nachhinein, denke ich das es da auch schon nicht funktioniert hat. 
Blos es hat sich nicht so gezeigt.
Da hat schon die Abtastzeit des Reglers nicht gepasst. Da bei 1MHz das 
gleiche Problem mit der Rechenzeit auftritte wie bei 20MHz.
Hat halt blos irgendwie nicht den Reset bei 1MHz durchgeführt.

Problem erfolgreich vertrieben. Auch wenn mir der Weg noch nicht zu 
hundert Prozent klar ist.