Atmega8 stop nach wenigen sec.

[Sören (Gast)]

Hallo,

mein Atmega8(ohne quarz) beendet nach wenigen sec. seinen Programm.
Wenn ich das Programm mittels Tastendruck start läuft es ganz normal los 
aber nach wenigen sec. stop es und läuft nicht weiter. Ich kann es dann 
neustarten über erneuten Tastendruck aber es passiert wieder das selbe 
nach wenigen sec. Wenn ich allerdings das Programmierttool AVR Dreagon 
angeschlossen habe dann läuft es ganz normal so wie es sollte.
Gibt es hier für eine einfache erklärung oder ist das ein häuferes 
Problem?

Wenn der schaltplan und Code benötigt wird, kann ich den gerne noch 
hinzufügen.

Grüßle

[Linksammler (Gast)]

Wie ist der Reset-Pin beschaltet? Wenn offen => versuch einen Pullup 
daran.
Wie schaut die Stromversorgung aus? Hat der Chip noch seine 5V, wenn er 
"steht"?

[Falk B. (falk)]

@ Sören (Gast)

>Wenn der schaltplan und Code benötigt wird, kann ich den gerne noch
>hinzufügen.

Dann tu das.

[Sören (Gast)]

der Code ist etwas umfang reich. Also wäre gut wenn ihr mir sagen 
könntet welche stellen sinnvoll zu zeigen sind ;).

[Falk B. (falk)]

Lies mal was über Netiquette und denk drüber nach!

[oldmax (Gast)]

Hi
Also, erst einmal, das Programm kann nicht nach ein paar Sekunden 
beendet werden. Ein Controller läuft immer. Nur eben nicht da, wo du 
glaubst. Ursachen gibt es dafür viele. Eine davon ist ein Interrupt mit 
einer nicht vorhandenen ISR. Ein Überlaufender Stack oder das 
Überschreiben des Stack durch indirekt adressierte Speicherzellen im 
SRAM. Finden tut man sowas, indem man den Code lesen kann und nicht 
einen Blick auf das Board wirft. Die Funktion oder Nichtfunktion liegt 
nun mal im Programm. Und wenn es ein paar Sekunden tut, was man 
erwartet, wird sich die Platine nicht umverdrahtet haben....
Deshalb, wenn du dein geheimes Programm nicht öffentlich stellen willst, 
wirst du wohl selber auf die Suche gehen müssen. Aber ein Tip: Wenn du 
schön modular programmiert hast, dann kannst du auch einzelne Funktionen 
nach und nach testen.
Gruß oldmax

[Martin (Gast)]

Kleb doch den Start-Knopf fest, dann müsste das Programm immer 
funktionieren.

[Sören (Gast)]

Okay, dann stell ich die Frage dazu.

Ist es ein Hardware oder ein Software Problem oder kann man das nicht so 
einfach sagen?

Will ja nicht das ihr die arbeit für mich macht! Sonder wollte nur einen 
Tipp wie der von Linksammler.

[Karl H. (kbuchegg)]

Sören schrieb:
> Okay, dann stell ich die Frage dazu.
>
> Ist es ein Hardware oder ein Software Problem oder kann man das nicht so
> einfach sagen?

Man kann es fast nie einfach so aus der hohlen Hand an irgendwas 
festmachen. Dazu sind die Möglichkeiten zu vielfältig.
Da du aber scheinbar am Reset Pin nichts schlimmes veranstaltet hast, 
wird es wohl ein Software Problem sein.

Kannst du ja mal ausprobieren.
Lass einfach nur in einem Testprogramm eine LED blinken. Wenn die nach 2 
Stunden immer noch vor sich hinblinkt, dann wird es wohl eher kein 
Hardware Problem sein.

Dann könntest du mal dein Programm etwas "komplizierter" machen, indem 
du Teile von deinem Programm da reinpappst und vielleicht nur ein 
Subsystem aktivierst. Läuft der µC dann nach 20 Minuten noch?

> der Code ist etwas umfang reich.
wie kann der umfangreich sein und du erst jetzt drauf kommen, dass dein 
µC nach ein paar Minuten steht? Du solltest mal deine Entwicklungs- und 
Teststrategien überdenken.

[Sören (Gast)]

danke Oldmax, ich versuchs erstmal selber zu finden wenn ich gänzlich 
scheitere dann würde ich den Code mal rein geben oder zumindest teile 
davon. Geheim ist er nicht aber wollte euch nicht unnötig arbeit 
aufheimsen ;).

Start-Knopf festkleben geht nicht hab ich schon versucht :D

[Falk B. (falk)]

@Sören (Gast)

>Ist es ein Hardware oder ein Software Problem oder kann man das nicht so
>einfach sagen?

Du bist ein echter Schetzkekes! Wie soll man an hand deiner 
"Informationen" dazu eine gescheite Aussage machen? Wir können nicht 
hellsehen!

>Will ja nicht das ihr die arbeit für mich macht! Sonder wollte nur einen
>Tipp wie der von Linksammler.

Siehe Fehlersuche.

[Sören (Gast)]

Okay,

hab das jetzt mit dem Blicken ausprobiert und siehe das selbst das will 
nicht mehr :/. Also nur wenn das Board mit der ISP verbunden ist gehts. 
Ich check jetzt nochmal das Board und den Code schritt für schritt und 
wenn ich nicht drauf komme würde ich ganz gerne nochmal auf euch zurück 
kommen und dann auch mit einer Ordentlichen fehler beschreiben mit Code, 
Schaltplan und vielleicht auch Schoki ;).

Danke schon mal für die ersten Tipps!

[Ingo (Gast)]

Sören schrieb:
> stop es und läuft nicht weiter
Die Beschaltung sieht erstmal ok aus. Dann liegt es wohl am Programm.
Also: Code zeigen. Was heisst läuft nicht weiter? Irgenwo ne Schleife 
die nicht abgebrochen wird?

[Karl H. (kbuchegg)]

Sören schrieb:
> Okay,
>
> hab das jetzt mit dem Blicken ausprobiert und siehe das selbst das will
> nicht mehr :/.


Nur so als Sicherstellung.

Mit: du ziehst den Programmer ab meinst du aber schon, dass du den 
Programmer vom Board abziehst und nicht einfach nur den Programmer vom 
PC abstöpselst aber ansonsten am Board lässt.

[Sören (Gast)]

Ja genau ich lose das Flachbandkabel der ISP vom Board!

Arbeite mich gerade durch. Hab jetzt alles auskommentiert und 
kommentiere es jetzt stück für stück wieder ein.

[Sören (Gast)]

So jetzt hab ich es,

hab gestern zum Spaß mal eine Funktion geschrieben mit zwei for 
schleifen (siehe unten). Die mag er scheinbar nicht so recht. Des 
weiteren hab ich noch die RS232 funktionen alle auskommentiert da ich 
sie der Zeit nicht benötige.

Teste das ganze jetzt noch paar stunden und Optimieren den Code noch 
etwas und dann sollte das passen :)

 
void ALL_DIMM( void )
{
  uint8_t i;
  uint8_t j;
  for ( i = 0x00; i <= 0xFF; i++ )
  {
    for ( j = 0; j <= 11; j++ )
    {
      Led[j] = i;
      Led[j] = i;
      Led[j] = i;
      Led[j] = i;
      Led[j] = i;
      Led[j] = i;
      Led[j] = i;
      Led[j] = i;
      Led[j] = i;
      Led[j] = i;
      Led[j] = i;
      Led[j] = i;
            
      _delay_ms(50);
      PCA9635();
    }
  }
}
void PCA9635( void )
{
  uint8_t i;

  // First TLC59116 Chip:
  TWIM_Start( PCA9635_ADD1, TWIM_WRITE );
  // Autoincrement ALL registers, start at reg 0 - we're initting
  TWIM_Write( AUTO_INCREMENT_ALL_REGISTERS );
  // Reg 0x00 = MODE1 - set to 0x80 - autoincrement enabled (this is readonly?), do not respond to subaddresses or allcall
  TWIM_Write( Mode1 );
  //TWIM_Write( Mode1_1 );
  // Reg 0x01 = MODE2 - set to 0xFF - noninverted logic state, open-drain
  TWIM_Write( Mode2 );
  //TWIM_Write( Mode2_1 );
  
  // output 0 - 5
  for( i = 0; i < 6; i++ )
  {
    TWIM_Write( Led[i] );
  }
  
  // 2 not used outputs
  TWIM_Write( Led_off );
  TWIM_Write( Led_off );

  // output 6 - 12
  for( i = 0; i < 6; i++ )
  {
    TWIM_Write( Led[6 + i] );
  }
  
  // 2 not used outputs
  TWIM_Write( Led_off );
  TWIM_Write( Led_off );

  // Reg 0x12 - Group PWM - should not matter
  TWIM_Write( Group_PWM );
  // Reg 0x13 - Group Freq - should not matter
  TWIM_Write( Group_Freq );

  // Reg 0x14-0x17 - LED Output State Control - all 0xAA (output state for each LED = 0x2)
  for( i = 0; i < 4; i++ )
  {
    TWIM_Write( Led_output[i] );
  }
  TWIM_Stop();
}

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

Sören schrieb:
> Die mag er scheinbar nicht so recht.
In welcher Form äussert sich das?

> hab gestern zum Spaß mal eine Funktion geschrieben
Diese zigmal wiederholte Zuweisung an Led[j] ist unnötig. Was wolltest 
du damit bezwecken?

[Sören (Gast)]

Hast du ja völlig reicht :D.

Hatte zuerst eine for schleife die nur den Hex wert geändert hat und da 
waren die zig aufrufe notwendig. Beim weiter rum spielen hab ich dann 
einfach nicht mehr nachgedacht würde ich sagen :D.

Aber danke! Stimmt einfach die anderen Zuweisungen raus, das spart auch 
wieder was.

Das äussert sich so das er nicht mehr reagiert. Bzw. der rest taster 
auch ohne funktiopn und wirkung ist. Das einzige was hilft ist Strom 
weg.

[Linksammler (Gast)]

Sören schrieb:
> Das äussert sich so das er nicht mehr reagiert. Bzw. der rest taster
> auch ohne funktiopn und wirkung ist. Das einzige was hilft ist Strom
> weg.

Wieviel Strom verbraucht der Mega in diesem Zustand?
Spannungsversorgung in der Strombegrenzung?
Wird er evtl. Warm?
=> würde auf einen Latch-Up hinweisen.
Da wäre der Rest der Schaltung dann interessant.

[Karl H. (kbuchegg)]

Sören schrieb:

> Das äussert sich so das er nicht mehr reagiert.

Wann werdet ihr endlich mal lernen, dass Variablendefinitionen bzw. die 
jeweiligen Datentypen integraler und wichtiger Bestandteil eines 
Programms ist.

[Falk B. (falk)]

@ Sören (Gast)

>Teste das ganze jetzt noch paar stunden und Optimieren den Code noch
>etwas und dann sollte das passen :)

Jaja, klingt nach Berliner Flughafen . . .

>void ALL_DIMM( void )
>{
>  uint8_t i;
>  uint8_t j;
>  for ( i = 0x00; i <= 0xFF; i++ )

Das erzeugt eine Endlosschleife, denn die Laufbedingung ist IMMER wahr!

[Teo D. (teoderix)]

Sören schrieb:
> uint8_t i;
...
> for ( i = 0x00; i <= 0xFF; i++ )

Wann und wie wird diese Schleife wohl beendet?

[Ulrich F. (Gast)]

> uint8_t i;
> for ( i = 0x00; i <= 0xFF; i++ )
Da ein uint8_t unglaubliche Probleme damit hat, über 255 zu kommen, 
würde ich diese klassische Endlosschleife mal als Programmierfehler 
einstufen.

Es darf nur eine Endlosschleife geben, und die sollte in main() sein, 
oder?
Funktionen, die nie zurückkehren sind mir sehr suspekt.....

In dem Schaltplan ist auch ein Bock
Eine der LEDs wird wohl so nie leuchten.

Edit:
Viel zu spät abgesendet.....
Aber besser spät, als gar nicht.

[Sören (Gast)]

Karl Heinz schrieb:

>Wann werdet ihr endlich mal lernen, dass Variablendefinitionen bzw. die
>jeweiligen Datentypen integraler und wichtiger Bestandteil eines
>Programms ist.

Okay, gut kläre mich bitte auf wo mein fehler liegt.

Falk Brunner schrieb:

>Das erzeugt eine Endlosschleife, denn die Laufbedingung ist IMMER wahr!

Hab jetzt geändert in for( i = 0x00; i < 0xFF; i++)...
Aber jetzt hab ich doch das problem das ich nie die 0xFF erreiche. also 
mit anderen worten nie LED voll anschalte :/

[Ulrich F. (Gast)]

Ja, so ist das!

Vielleicht der falsche Datentype?

[Sören (Gast)]

Ulrich F. schrieb:

>In dem Schaltplan ist auch ein Bock
>Eine der LEDs wird wohl so nie leuchten.

:D Du meinst die LED3? Da hast du in der tat recht. Auf der Platine ist 
sie richtig montiert ;).

[Teo D. (teoderix)]

Sören schrieb:
> Hab jetzt geändert in for( i = 0x00; i < 0xFF; i++)...
> Aber jetzt hab ich doch das problem das ich nie die 0xFF erreiche.

http://www.c-howto.de/tutorial-schleifen-do.html

[Ulrich F. (Gast)]

> Hab jetzt geändert in for( i = 0x00; i < 0xFF; i++)...
Vielleicht wäre eine Fußgesteuerte Schleife an der Stelle 
praktischer....

[Karl H. (kbuchegg)]

Ulrich F. schrieb:
> Ja, so ist das!
>
> Vielleicht der falsche Datentype?

Und die Definition des Arrays würde ich auch gerne sehen.
Wer sowas schreibt

    for ( j = 0; j <= 11; j++ )

dem traue ich nicht mehr über den Weg, bis ich mich davon überzeugt 
habe, dass in der Array-definition wirklich 12 und nicht 11 steht.

[Sören (Gast)]

Ulrich F. schrieb:

>Vielleicht der falsche Datentype?

aber uint16_t dafür zu benutzen hab ich als bissel fett angesehen und 
dacht das von 0 ... 255 der uint8_t reicht. siehe auch: 
(http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial)

[Udo S. (urschmitt)]

Denk mal nach:
Wie viele Werte kannst du mit dem uint8 darstellen.
Und bei welchem (wievielten) Durchlauf soll die Abbruchbedingung wahr 
werden.

[Max H. (hartl192)]

Sören schrieb:
> dacht das von 0 ... 255 der uint8_t reicht
Dann muss du die Schleife aber z.B. so bauen:

  i = 0;
  do
  {

  }while(++i);

Damit deine Abbruchbedingung erfüllt ist, muss i aber 256 annehmen.

[Vlad T. (vlad_tepesch)]

Karl Heinz schrieb:
> Und die Definition des Arrays würde ich auch gerne sehen.
> Wer sowas schreibt    for ( j = 0; j <= 11; j++ )
> dem traue ich nicht mehr über den Weg, bis ich mich davon überzeugt
> habe, dass in der Array-definition wirklich 12 und nicht 11 steht.

Sören schrieb:
> // output 0 - 5
>   for( i = 0; i < 6; i++ )
>   {
>     TWIM_Write( Led[i] );
>   }

und

Sören schrieb:
> // output 6 - 12
>   for( i = 0; i < 6; i++ )
>   {
>     TWIM_Write( Led[6 + i] );
>   }

spricht dafür, dass zumindest der Teil stimmt ;)

[Sören (Gast)]

Okay, beim nächsten mal Lese ich mich nochmal richtig in die schleifen 
geschichte rein. Aber ich könnte auch mit dieser nicht wirklich gut 
geschriebenen schleife das rausbekommen was ich wollte und zwar ob man 
255 Dimmstuffen hat und sieht. :D

Danke für die Tipps und Hilfe!

[Pepe (Gast)]

Sorry, wenn ich jetzt mal in eine ganz andere Richtung denke:

Der LED Driver hängt doch per I2C dran. Wahrscheinlich doch auch etwas 
weiter weg und per dünnen Äderchen verbunden?
Kann es sein, dass der I2C Bus nicht sauber funktioniert. Wenn z.B. ein 
Acknowlegde nicht sauber kommt, kann es schon mal vorkommen, dass der 
Bus geklemmt bleibt und kann kommst Du nämlich auch nicht mehr per 
Prozessor-Reset raus ( weil ja der PCB9635 hängt und den I2C blockiert 
). Dann musst Du nämlich den Strom abklemmen...

[Sören (Gast)]

Pepe schrieb:

> Der LED Driver hängt doch per I2C dran. Wahrscheinlich doch auch etwas
> weiter weg und per dünnen Äderchen verbunden?
> Kann es sein, dass der I2C Bus nicht sauber funktioniert. Wenn z.B. ein
> Acknowlegde nicht sauber kommt, kann es schon mal vorkommen, dass der
> Bus geklemmt bleibt und kann kommst Du nämlich auch nicht mehr per
> Prozessor-Reset raus ( weil ja der PCB9635 hängt und den I2C blockiert
> ). Dann musst Du nämlich den Strom abklemmen...

Guter Gedanke, die Kabel sind recht "dick" und auch recht kurz also max. 
6cm.
Hab das signal amanfang mit dem Ozi überprüft da sah es sehr gut aus. :)

[Ulrich F. (Gast)]

Sören schrieb:
> ich wollte und zwar ob man
> 255 Dimmstuffen hat und sieht.

Eben sachtest du noch, dass dir 255 Stufen zu wenig sind....

Siehe:
> Aber jetzt hab ich doch das problem das ich nie die 0xFF erreiche.

[Sören (Gast)]

Ähh.. ich glaube das war etwas ungünstig ausgedrückt. Der PCA9635 hat 
256 Stufen oder 8bit PWM und die würde ich ja schon gerne alle benutzen 
können :).
Du meinst ich sehe der Zeit nur 254 Stuffen der Dimmung?
Ja das stimmt! Aber ab einer gewissen Stufe sieht man mit dem Auge keine 
wirklichen unterschied mehr.

[Felix N. (time2ride)]

Bei PWM fehlt dir immer 1 Wert, je nach PWM Einstellung kannst du 
entweder ganz an also immer auf high aber dafür nie ganz auf low (bleibt 
immer ein Spike von einem Taktzyklus) oder eben ganz auf low aber dafür 
nie auf ganz high.

[Karl H. (kbuchegg)]

Felix C. schrieb:
> Bei PWM fehlt dir immer 1 Wert, je nach PWM Einstellung kannst du
> entweder ganz an also immer auf high aber dafür nie ganz auf low (bleibt
> immer ein Spike von einem Taktzyklus) oder eben ganz auf low aber dafür
> nie auf ganz high.

Sachte. Das ist bei der im AVR implementierten PWM so.

Beim PCA9635 (=LED Driver mit eingebauten PWM Stufen) ist das aber nicht 
so.

[Felix N. (time2ride)]

Karl Heinz schrieb:
> Sachte. Das ist bei der im AVR implementierten PWM so.
>
Lies mal die Threadüberschrift...

[Karl H. (kbuchegg)]

Felix C. schrieb:
> Karl Heinz schrieb:
>> Sachte. Das ist bei der im AVR implementierten PWM so.
>>
> Lies mal die Threadüberschrift...


Der Atmega stoppt.
Die PWM, um die es geht, kommt aber nicht von ihm, sondern von einem 
PCA, der per I2C angesteuert wird.
Lies den Code.

[F. F. (foldi)]

Sören schrieb:
> Wenn ich allerdings das Programmierttool AVR Dreagon
> angeschlossen habe dann läuft es ganz normal so wie es sollte.

Wie ist der Drache angeschlossen? Versorgst du damit die Schaltung?
Wenn ja, dann hast du ein Problem mit deiner Stromversorgung.
Da tippe ich mal ganz fest drauf.
Der Schaltplan sieht ja gut aus (bisschen dunkel ;-)), aber ist das auch 
wirklich so angeschlossen?
Was ist das für eine Platine? Lochraster mit Fädeldraht?

Such erstmal, wenn du vom Drachen den Strom nimmst und es damit 
funktioniert hat, nach dem Fehler in deiner Stromversorgung.

Wenn nicht, dann guck mal, ob dein Reset Taster defekt ist.

[Felix N. (time2ride)]

Karl Heinz schrieb:
> Felix C. schrieb:
>> Karl Heinz schrieb:
>>> Sachte. Das ist bei der im AVR implementierten PWM so.
>>>
>> Lies mal die Threadüberschrift...
>
>
> Der Atmega stoppt.
> Die PWM, um die es geht, kommt aber nicht von ihm, sondern von einem
> PCA, der per I2C angesteuert wird.
> Lies den Code.

Wohl wahr, hätte ich machen sollen. Mein Fehler, sry!

[Vlad T. (vlad_tepesch)]

Karl Heinz schrieb:
> Sachte. Das ist bei der im AVR implementierten PWM so.

und das auch nur, wenn man Fast PWM benutzt.

[Pepe (Gast)]

OK. Du hast oben geschrieben, dass es mit angestecktem Programmer 
durchläuft.
Dann kannst Du ja nicht den Debugger anhalten, wenn's hängt.
Aber Du kannst das Problem eingrenzen mit Deiner LED_MCU:

...
      Led[j] = i;
      Led[j] = i;

      _delay_ms(50);
      LEDEin();
      PCA9635();
      LEDAus();
    }

Dann kannst Du schon mal sagen, ob die I2C Ansteuerung hängt oder nicht.

Ich würde auch auf Spannungsversorgung tippen. Vielleicht zieht Dein 
Programmer die VCC etwas nach oben und dann reicht der Pegel fürs I2C...

[Pepe (Gast)]

Noch was: Dreh die LED aber vorher richtig, laut Schaltplan leuchtet 
wohl eher nichts ;-)

[Pepe (Gast)]

Noch was die zweite: Hast Du schon mal SDA bzw. SCL gemessen, wenn dein 
Programm hängt? Wenn eines der beiden auf LOW, treibt wohl einer den 
I2C.

Du kannst in SDA / SCL jeweils einen 100R in Serie reinhängen. Dann 
kannst Du über den Spannungsabfall rausfinden, welcher der beiden I2C 
Partner den Bus klemmt.

[Sören (Gast)]

So ich hab die LED im Schaltplan gedreht und alle andere sachen auch 
nochmal überarbeitet. Hier das abschliesende ergebnis. Tipps und 
Anregungen sind gerne gesehen :).

Code:

Main:

#include <stdio.h>
#include <stdint.h>
#include <stdbool.h>                // Variablentyp Bool
#include <avr/interrupt.h>              // AVR Routinen for Interrupts
#include <avr/io.h>                  // AVR IO Header

#include "General.h"
#include <util/delay.h>                // AVR Timemanager
#include "TWI_Master.h"
#include "PCA9635.h"
#include "Taster.h"

//#include "RS232.h"

//**************************
//** Ports initialisieren **
//**************************
void port_init(void)
{
  // Pin 0 und 1 auf Eingang und andere im ursprünglichen Zustand belassen:
  DDRC = 0x03; //&= ~((1 << DDC0) | (1 << DDC1));
  // Pin 5 und 2 auf Ausgang und andere im ursprünglichen Zustand belassen:
  DDRD |= (1 << DDD5);
  DDRC |= (1 << DDC2);
  
  // Pull Up von Pin 0 und Pin 1 setzen:
  PORTC = ( 1 << PC0 ) | ( 1 << PC1 );
}
//**********
//** Main **
//**********
int main (void)
{
  cli();
  //
/** Initzialisiere Ports **/
  
  port_init();
    
/** Configure debouncing routines **/

  KEY_DDR &= ~ALL_KEYS;                    // configure key port for input
  KEY_PORT |= ALL_KEYS;                    // and turn on pull up resistors
    
  TCCR0 = (1<<CS02)|(1<<CS00);                // divide by 1024
  TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5);  // preload for 10ms
  TIMSK |= 1<<TOIE0;                    // enable timer interrupt
    
/** Wait 1 second for POR **/

  _delay_ms(1000);

///** Initzialisiere RS232 **/
  //
  //uart_init();
  //uart_puts("RS232 [OK]...");  
//
/** Initzialisiere TWI Master Interface mit bitrate von 1000 Hz **/

  TWIM_Init (1000);

/** Wait 1 second for POR **/

  _delay_ms(1000);
  
  if (!TWIM_Init (1000))
    {
    printf ("Error in initiating TWI interface\n");
    while (1);
    }
    
/** Initzialisiere PCA9635 **/

  Init_PCA9635();
  PCA9635();
  
  sei();
  
  ////uart_gets( Line, sizeof( Line ) );
  ////uart_puts( Line );
  ////uart_puts("Hello World");


/** Endlosschleife **/

  while(1)
  {
    FullOn();
    PCA9635();
    _delay_ms(1000);
    FullOff();
    PCA9635();
    _delay_ms(1000);
    ALL_DIMM();
    _delay_ms(1000);

/** Write byte(s) to the slave **/
//
    if( get_key_press( 1<<KEY0 ))
    {
      PORTD = PORTD | ( 1<<PD5 );
      //Led[9] = 0xFF;
      FullOn();
      PCA9635();
      //ALL_DIMM();
      /*
      for( i = 0; i < 16; i++ )
      {
        Led[i] = 0xFF;
        PCA9635();
        _delay_ms(3000);
        Led[i] = 0x00;
      }
      */
    }
    if ( get_key_press( 1<<KEY1 ))
    {
      FullOff();
      PCA9635();
      PORTD &= ~( 1<<PD5 );
    }              
  }
return 0;
}

PCA9635.c:
#include <stdio.h>
#include <avr/interrupt.h>

#include "General.h"
#include <util/delay.h>
#include "TWI_Master.h"
#include "PCA9635.h"

void Init_PCA9635( void )
{
  uint8_t i;
  
  // Reg 0x00 = MODE1 - set to 0x80 - autoincrement enabled (this is readonly?), do not respond to subaddresses or allcall
  Mode1 = 0b10000000;    //Write 0x80
  
  // Reg 0x01 = MODE2 - set to 0xFF - noninverted logic state, open-drain
  Mode2 = 0x1F;
    
  // LED_OFF:
  Led_off = 0x00;

  // Reg 0x12 - Group PWM - Variablen
  Group_PWM = 0xFF;

  // Reg 0x13 - Group Freq - Variablen
  Group_Freq = 0x00;

  // Reg 0x14-0x17 - LED Output State Control - Variablen
  for( i = 0; i < 4; i++ )
  {
    Led_output[i] = 0xAA;
  }
}

void FullOff( void )
{
  uint8_t i;
  // set all LEDs of 0x00 ( all off)
  for( i = 0; i < NR_LEDS; i++ )
  {
    Led[i] = 0x00;
  }
}

void FullOn( void )
{
  uint8_t i;
  // set all LEDs of 0xFF (Full On)
  for( i = 0; i < NR_LEDS; i++ )
  {
    Led[i] = 0xFF;
  }
}

void PCA9635( void )
{
  uint8_t i;

  // First TLC59116 Chip:
  TWIM_Start( PCA9635_ADD1, TWIM_WRITE );
  // Autoincrement ALL registers, start at reg 0 - we're initting
  TWIM_Write( AUTO_INCREMENT_ALL_REGISTERS );
  // Reg 0x00 = MODE1 - set to 0x80 - autoincrement enabled (this is readonly?), do not respond to subaddresses or allcall
  TWIM_Write( Mode1 );
  //TWIM_Write( Mode1_1 );
  // Reg 0x01 = MODE2 - set to 0xFF - noninverted logic state, open-drain
  TWIM_Write( Mode2 );
  //TWIM_Write( Mode2_1 );
  
  // output 0 - 14
  for( i = 0; i < NR_LEDS; i++ )
  {
    TWIM_Write( Led[i] );
  }
  
  // 2 not used outputs
  TWIM_Write( Led_off );
  TWIM_Write( Led_off );

  // Reg 0x12 - Group PWM - should not matter
  TWIM_Write( Group_PWM );
  // Reg 0x13 - Group Freq - should not matter
  TWIM_Write( Group_Freq );

  // Reg 0x14-0x17 - LED Output State Control - all 0xAA (output state for each LED = 0x2)
  for( i = 0; i < 4; i++ )
  {
    TWIM_Write( Led_output[i] );
  }
  TWIM_Stop();
}
void ALL_DIMM( void )
{
  uint16_t i;
  uint16_t j;
  for ( i = 0x00; i < 0xFF; i++ )
  {
    for ( j = 0; j < NR_LEDS; j++ )
    {
      Led[j] = i;
            
      _delay_ms(50);
      PCA9635();
    }
  }
}

PCA9635.h:
#ifndef PCA9635_H_
#define PCA9635_H_

/**************************************
** TLC59116 device Address/Registers **
***************************************/

#define PCA9635_ADD1        0b0010101//0x60      
#define PCA9635_ADD2        0b0010111//0x61      



// Control register (three MSB control auto-increment)
#define NO_AUTO_INCREMENT          0x00
#define AUTO_INCREMENT_ALL_REGISTERS    0x80
#define AUTO_INCREMENT_BRIGHTNESS      0xA0
#define AUTO_INCREMENT_CONTROL        0xC0
#define AUTO_INCREMENT_BRIGHT_CONTROL    0xE0

// LED output state for LEDOUT0 to LEDOUT3
#define LED_OUTPUT_OFF            0b00
#define LED_OUTPUT_GROUP          0b11

#define NR_LEDS 14

/**************
** Variablen **
***************/

// Reg 0x00 = MODE1 - set to 0x80 - autoincrement enabled (this is readonly?), do not respond to subaddresses or allcall
uint8_t Mode1;    //Write 0x80
// Reg 0x01 = MODE2 - set to 0xFF - noninverted logic state, open-drain
uint8_t Mode2;
// LED_out_Variablen
uint8_t Led[NR_LEDS];
// LED_OFF:
uint8_t Led_off;
// Reg 0x12 - Group PWM - Variablen
uint8_t Group_PWM;
// Reg 0x13 - Group Freq - Variablen
uint8_t Group_Freq;
// Reg 0x14-0x17 - LED Output State Control - Variablen
uint8_t Led_output[4];


/************************
** PCA9635 Funktionen **
*************************/

void Init_PCA9635( void );
void FullOff( void );
void FullOn( void );
void PCA9635( void );
void ALL_DIMM( void );

#endif /* PCA9635_H_ */

[Pepe (Gast)]

Hast Du Dein eigentliches Problem immer noch ?

[Falk B. (falk)]

@ Sören (Gast)

>Anregungen sind gerne gesehen :).


>/** Initzialisiere PCA9635 **/

>  Init_PCA9635();
>  PCA9635();

Doppelt gemoppelt. Der Kommentar ist hyperliquide.

Strukturierte Programmierung auf Mikrocontrollern



>void FullOff( void )
>{
>  uint8_t i;
>  // set all LEDs of 0x00 ( all off)
>  for( i = 0; i < NR_LEDS; i++ )
>  {
>    Led[i] = 0x00;
>  }
>}

>void FullOn( void )
>{
>  uint8_t i;
>  // set all LEDs of 0xFF (Full On)
>  for( i = 0; i < NR_LEDS; i++ )
>  {
>    Led[i] = 0xFF;
>  }
>}

Anstatt zwei Funktionen wäre eine einfacher und besser, der man einfach 
das Füllmuster als Parameter übergibt.

>void PCA9635( void )
>{
>  uint8_t i;

>  // First TLC59116 Chip:
>  TWIM_Start( PCA9635_ADD1, TWIM_WRITE );
>  // Autoincrement ALL registers, start at reg 0 - we're initting

Ja was denn nun? Ist es ein TLC59116 oder ein PCA9635? Das sind 
vollkommen verschiedene ICs!



>PCA9635.h:
>#ifndef PCA9635_H_
>#define PCA9635_H_

>/**************************************
>** TLC59116 device Address/Registers **
>***************************************/

>#define PCA9635_ADD1        0b0010101//0x60
>#define PCA9635_ADD2        0b0010111//0x61

Hier das gleiche Problem! Ausserdem sind ZWEI Adressen ebenfalls 
hyperliquide und fehleranfällig! Man braucht nur EINE I2C Adresse, 
meistens die zum Schreiben (LSB = 0). Das Leseadresse ergibt sich durch 
eine Oder-Verknüpfung mit 0x01. Ausserdem schreibt kein Mensch das binär 
hin.

>/************************
>** PCA9635 Funktionen **
>*************************/

>void Init_PCA9635( void );
>void FullOff( void );
>void FullOn( void );
>void PCA9635( void );
>void ALL_DIMM( void );

Eine sinnvolle Nomenklatur (Namensgebung) wäre

TLC59116_Init()
TLC59116_FullOn()
TLC59116_FullOff()
TLC59116_Update()
TLC59116_Dimm()

#endif /* PCA9635_H_ */

[Sören (Gast)]

Ups, hab die Schaltpläne vergessen :D.

Okay Okay danke erstmal für die Tipps, den Zweiten Chips gibts schon 
nicht mehr. Ist quasi eine Codeleische. Das mit der Namensgeben ist ein 
guter einwand aber doch eigentlich meine sache oder spielt das wieder in 
die Code schreibweisen mit rein? Werdes berücksichtigen und ändern. Der 
TLC59116 ist der erste chip den ich benutz hab. Änder ich auch gleich. 
Sehe den Wald vor lauter Bäumen nicht :D

[Paul B. (paul_baumann)]

Hast Du die Schaltpläne in der Nachtschicht gezeichnet, so dunkel, wie 
sie
sind?
;-)

Ich habe ihn mal erhellt.

MfG Paul

[Falk B. (falk)]

@ Paul Baumann (paul_baumann)

>    Schaltplan_aus_Forum.jpg

>Ich habe ihn mal erhellt.

Schön. Aber hier sieht man besonders gut, warum das Format JPG für 
Schaltpläne ungeeignet ist. Siehe Bildformate (jaja, du kennst den 
Artikel, der OP aber nicht)

[Paul B. (paul_baumann)]

Falk Brunner schrieb:
> Aber hier sieht man besonders gut, warum das Format JPG für
> Schaltpläne ungeeignet ist.

Ich habe auch andere Formate ausprobiert (Irfanview kann in alles 
Mögliche
wandeln). Besser als jetzt hat es aber auch nicht ausgesehen...

MfG Paul

[Pepe (Gast)]

Wenn der Schaltplan zum PCA9635.jpg stimmt, dann musst Du auf alle Fälle 
noch einige Kondensatoren da mit rein nehmen. Ich würde 100nF direkt an 
den PCA, und nochmal 100nF || > 10uF über die 5V Versorgung (z.B. am 
Stecker). Sonst läuft das nicht wirklich stabil.

Ist VSS wirklich nicht angeschlossen? Keine Ahnung ob dies trotzdem 
funktioniert, aber laut Datenblatt heißt es dort "Supply Ground"

Außerdem hängt /OE in der Luft :-(

[Sören (Gast)]

Paul Baumann schrieb:

> Hast Du die Schaltpläne in der Nachtschicht gezeichnet, so dunkel, wie
> sie
> sind?
> ;-)
>
> Ich habe ihn mal erhellt.

Hab halt den Eagle Hintergrund auf Schwarz gestellt. Finde das 
angenehmer. Weiß nicht warum das hier öfter erwähnt wird. Sieht man da 
nicht genau so viel wie auf dem Hellen?
Naja diese Diskussion muss man jetzt nicht auf machen. Nicht zielführend 
;). Wenn man sich mühe gibt sieht man auch auf dem JPG alles :)

[Sören (Gast)]

Okay, gut. Änder ich das noch auf dem Board. Vss ist auf GND und der /OE 
ist so eine komische sache. Lass ich ihn offen gehts. Verbinde ich in 
mit GND oder über einen 10k mit 5V geht nix mehr... Offene PINs finde 
ich auch immer nicht so super.

[Pepe (Gast)]

Laut Datenblatt "Active Low Output Enable". Also würde ich sagen auf LOW 
legen und die LED müssten leuchten (wenn vom Controller aktiviert). HIGH 
wird wohl die LEDs abschalten.

[Paul B. (paul_baumann)]

Sören schrieb:
> Sieht man da
> nicht genau so viel wie auf dem Hellen?

Glaubst Du, daß ich das aus Langeweile gemacht habe?

Sören schrieb:
> Naja diese Diskussion muss man jetzt nicht auf machen. Nicht zielführend
> ;).

Spar Dir Dein neusprech -lade lesbare Pläne hoch!

Paul

[Sören (Gast)]

Pepe schrieb:

> Wenn der Schaltplan zum PCA9635.jpg stimmt, dann musst Du auf alle Fälle
> noch einige Kondensatoren da mit rein nehmen. Ich würde 100nF direkt an
> den PCA, und nochmal 100nF || > 10uF über die 5V Versorgung (z.B. am
> Stecker). Sonst läuft das nicht wirklich stabil.
>
> Ist VSS wirklich nicht angeschlossen? Keine Ahnung ob dies trotzdem
> funktioniert, aber laut Datenblatt heißt es dort "Supply Ground"
>
> Außerdem hängt /OE in der Luft :-(

So hab das gleich mal umgesetzt, das ganze sieht dann so aus.
Danke für die Tipps!

[Sören (Gast)]

Ups, die falsche erwicht. Sry!

[Sören (Gast)]

Pepe schrieb:

> Laut Datenblatt "Active Low Output Enable". Also würde ich sagen auf LOW
> legen und die LED müssten leuchten (wenn vom Controller aktiviert). HIGH
> wird wohl die LEDs abschalten.

das hab ich getest aber irgendwie wollte es nicht. Als ich ihn dann 
offen gelassen hab gings.

[Pepe (Gast)]

Ich hoffe Du damit keine Platine fertigen (lassen) ? Dann würde ich an 
deiner Stelle noch einiges ausprobieren.

Übrigens: Die 10uF hatte ich mit Absicht erwähnt... Sollen helfen die 
Versorgungsspannung auf der PCA-Platine stabil zu halten. Und den C1 
solltest Du möglichst nah an die Versorgungspin des PCA bringen.

G??gle mal nach "Blockkondensator" falls es Dich interessiert.

[Sören (Gast)]

Pepe schrieb:

> Übrigens: Die 10uF hatte ich mit Absicht erwähnt... Sollen helfen die
> Versorgungsspannung auf der PCA-Platine stabil zu halten. Und den C1
> solltest Du möglichst nah an die Versorgungspin des PCA bringen.

Die hab ich gerade etwas überlesen aber auf welcher Platine jetzt genau 
auf er vom PCA9635?

[Pepe (Gast)]

Strom funktioniert eigentlich ähnlich wie Wasser: Durch ne dünne Leitung 
kommt nur ne gewisse Menge. Wenn ich dann am Ende dieser Leitung ständig 
einen Eimer mit Wasser schöpfen möchte, brauch ich eine Wanne mit 
entsprechend Volumen, die ich vorher schon mal fülle. Sonst wackelt der 
Wasserstand in der Wanne zu stark.

Ich würde sogar sagen auf beide Schaltungen.

[Sören (Gast)]

kurze frage,

also hat der erfinder dieser Schaltung. Ebenfalls ein Problem mit seiner 
Spannungs versorgung?

http://www.tng-project.de/wordpress/wp-content/uploads/2013/10/pca96351.png

Quelle:
http://www.tng-project.de/2013/10/pca9635-i2c-pwm-led-driver/

[Sören (Gast)]

Pepe schrieb:

> Ich würde sogar sagen auf beide Schaltungen.

Okay dann bring ich das noch ein. Danke!

[Pepe (Gast)]

Pauschal kann ich das nicht wirklich beantworten. Ich würde mich bei der 
Originalschaltung nicht wohl fühlen. Die Schaltung mag so schon 
funktionieren.
Vielleicht hat er eine stabilere Spannung oder vielleicht hast Du eine 
kalte Lötstelle (wenn Du lötest).
Es kann vielleicht nur ne Kleinigkeit sein. Aber professionell ist das 
Original auch nicht.

ABER: Im Hobbybereich geht so einiges was nicht sauber ist... Hauptsache 
es läuft :-)

Mir ist aber gerade was aufgefallen: Im Original sind Deine R11 & R12 
nicht enthalten. (Die I2C PullUps) Hast Du eine Ahnung warum ? Oder 
warum hast Du welche rein ?

[Ausgeloggt (Gast)]

Kleine Verbesserung:

  // output 0 - 14
  for( i = 0; i < NR_LEDS; i++ )
  {
    TWIM_Write( Led[i] );
  }
  
  // 2 not used outputs
  TWIM_Write( Led_off );
  TWIM_Write( Led_off );

Hier hast du zwar die Anzahl der LEDs in ein #define gepackt, aber wenn 
die Anzahl sich ändert, musst du immer noch den Code anfassen:
nämlich die letzte 2 Zeilen.

Besser wäre also:

#define MAX_NR_LEDS 16

for(i = 0; i < NR_LEDS; i++)
{
  TWIM_Write(Led[i]);
}
for( ; i < MAX__NR_LEDS; i++)
{
  TWIM_Write(Led_off);
}

Oder einfach auch die nicht benutzte LEDs in dein Led[] Array 
mitaufnehmen und auf Led_off stehen lassen.

[Falk B. (falk)]

@ Sören (Gast)

>also hat der erfinder dieser Schaltung. Ebenfalls ein Problem mit seiner
>Spannungs versorgung?

>http://www.tng-project.de/wordpress/wp-content/upl...

Ja.

- es fehlen 100nF Keramk am LED-IC, welcher KEIN PCA9536 ist!
- es fehlen 100-330uF an der 5V Leitung. Denn wenn die PWM mal loslegt, 
müssen die Pulsströme irgendwo herkommen, der Spannungsregler allein 
kann das nicht so gut.
- es ist nicht sonderlich sinnvoll, einen TLC59116 mit nachgeschalteten 
ULN2003 zu verwenden. Ausserdem fehlt da an jedem Ausgang ein Pull-Up 
Widerstand. Warum nicht die LEDs direkt mit dem TLC treiben? Der kann 
das bis 80mA/Kanal

[Sören (Gast)]

Pepe schrieb:

> Mir ist aber gerade was aufgefallen: Im Original sind Deine R11 & R12
> nicht enthalten. (Die I2C PullUps) Hast Du eine Ahnung warum ? Oder
> warum hast Du welche rein ?

Ich hab den Plan nicht also vorlage benutzt, bin nur mal drüber 
gestollpert.
Also ich mich rein gelesen hab in die I2C sache hab ich irgendwo mit 
aufgenommen das es quasi empfohlen wird PullUps an die I2C schnittstelle 
zuhängen. Fand das auch garnicht so unschlüssig definierter 
schaltzustand und so.

Ausgeloggt schrieb:
> Kleine Verbesserung:  // output 0 - 14
>   for( i = 0; i < NR_LEDS; i++ )
>   {
>     TWIM_Write( Led[i] );
>   }
>
>   // 2 not used outputs
>   TWIM_Write( Led_off );
>   TWIM_Write( Led_off );
> Hier hast du zwar die Anzahl der LEDs in ein #define gepackt, aber wenn
> die Anzahl sich ändert, musst du immer noch den Code anfassen:
> nämlich die letzte 2 Zeilen.
>
> Besser wäre also:#define MAX_NR_LEDS 16
>
> for(i = 0; i < NR_LEDS; i++)
> {
>   TWIM_Write(Led[i]);
> }
> for( ; i < MAX__NR_LEDS; i++)
> {
>   TWIM_Write(Led_off);
> }
> Oder einfach auch die nicht benutzte LEDs in dein Led[] Array
> mitaufnehmen und auf Led_off stehen lassen.

Danke, schau ich mir gleich nochmnal an!

[Pepe (Gast)]

Falk Brunner schrieb:
>  welcher KEIN PCA9536 ist!

Ich steig gerade nicht durch. Warum ist dies kein PCA9536?

[Pepe (Gast)]

@ Falk Brunner
Sorry Tippfehler: PCA9635

[Sören (Gast)]

Falk Brunner schrieb:

> - es fehlen 100nF Keramk am LED-IC, welcher KEIN PCA9536 ist!
> - es fehlen 100-330uF an der 5V Leitung. Denn wenn die PWM mal loslegt,
> müssen die Pulsströme irgendwo herkommen, der Spannungsregler allein
> kann das nicht so gut.
> - es ist nicht sonderlich sinnvoll, einen TLC59116 mit nachgeschalteten
> ULN2003 zu verwenden. Ausserdem fehlt da an jedem Ausgang ein Pull-Up
> Widerstand. Warum nicht die LEDs direkt mit dem TLC treiben? Der kann
> das bis 80mA/Kanal

Ich denke schon das es ein PCA9635 ist aber selbst wenn nicht ist das 
nicht ganz so wild der TLC59116 ähnelt sich sehr. Warum er die ULN2003 
verwendet kann ich dir auch nicht sagen aber ich hab da warscheinlich 
einähnliches problem wie er und zwas das ich LEDs ansteuere die 120mA 
brauchen. Ich hab das mit NPN-Transitor gelöst der als Schalter dient.

[Pepe (Gast)]

@ Sören:

"Ich hab das mit NPN-Transitor gelöst"

Kommt nach Deinem PCA wirklich noch ein NPN-Transistor pro Kanal? Dann 
sprechen wir ja von 12 x 120mA = 1,4A und nicht von 12 x 25mA. Dann ist 
die bisherige Beschaltung ja wohl nichts: Wie Falk schreibt größeren 
Elko auf beide Schaltungen. Und ich hoffe Du verwendest kein 
Steckernetzeil. Da kann es auch knapp werden...

[Falk B. (falk)]

@ Sören (Gast)

>Ich denke schon das es ein PCA9635 ist

OK, mein Fehler! Ich hatte einen Zahlendreher im Kopf! Ich dachte an den 
PCA9536! Weil der mich in dem Thread hier ziemlich beschäftigt hat!

Beitrag "Denkfehler mit PCA9536 (Problem)"

> Warum er die ULN2003
>verwendet kann ich dir auch nicht sagen aber ich hab da warscheinlich
>einähnliches problem wie er und zwas das ich LEDs ansteuere die 120mA
>brauchen.

Und das kann der PC9635 nicht, er schafft nur max. 25mA. Ausserdem hat 
er normale Totem-Pole Ausgänge, man braucht also keinen Pull-Ups. Mein 
Fehler.

> Ich hab das mit NPN-Transitor gelöst der als Schalter dient.

Ist OK.

[Sören (Gast)]

Pepe schrieb:

> Kommt nach Deinem PCA wirklich noch ein NPN-Transistor pro Kanal? Dann
> sprechen wir ja von 12 x 120mA = 1,4A und nicht von 12 x 25mA. Dann ist
> die bisherige Beschaltung ja wohl nichts: Wie Falk schreibt größeren
> Elko auf beide Schaltungen. Und ich hoffe Du verwendest kein
> Steckernetzeil. Da kann es auch knapp werden...

Ist nicht ganz so einfach zusagen. Ich verwende eine LED mit 120mA und 7 
mit 30mA und 4 mit 20mA. Bezüglich des einheitlichem Bild und ich dachte 
mir um den PCA nicht ganz so zu belasten hab ich auch die 20mA Ausgang 
mit einem Transitor versehen. Aber alles im allem komme ich ja quasi so 
nur auf 410mA also nicht ganz so schlimm. Dazu muss ich sagen das der 
Probeaufbau auf einer Lochleiterplatte ist mit "Freiluft" verdrahtung 
und Spannungswandler die mit recht großen Elkos versehen sind 220µ. Nur 
der C am PCA direkt fehlt. In der schaltung hab ich recht viel 
weggelassen quasi vereinfacht. Da war ich wohl mit dem Radiere etwas zu 
radikal :D. Danke euch dann weiß ich jetzt was ich noch zutun hab. Aber 
zu viele C sind auch wieder nicht gut oder. Also nicht das ich jetzt 
anfange wie ein wilder Cs in die Schaltung so bauen :)

[Pepe (Gast)]

Cs gehören mindestens an folgende Stellen:

- Stecker der Spannungsversorgung: Irgendwas 100nF + >100uF.
- Spannungsversorgungspin der Chips: 100nF Block-C, wenn mehrere 
Spg.Pins dann an jedes "Paar" einen C. ( z.B. Prozessoren )
- "Übergang" zur nächsten PCB: Je nach Anwendung nur 100nF oder eben 
auch einen größeren C

Was immer gut ist: Blick ins Datenblatt. Dort sind meistens 
Beispielschaltungen/Testschaltungen auch mit den Cs.

[Thomas (kosmos)]

auf deinem Board fällt mir der fehlende Kerko zw. Reset und GND auf. 
Dann hast du für VCC und AVCC nur 1 Kerko genommen. Vor den Kerko für 
VCC vielleicht nochmal 10µF einfügen.

Vielleicht ist deine Stromversorgung des Bords etwas schwachbrüstig und 
nicht stabil.