ATtiny88 funktioniert nur mit Analyzer. Warum?

[Flo (Gast)]

Hallo Zusammen,

nachdem ich jetz schon einige Tage rumsuche und rumprobiere, komme ich 
an einem eigenen Thread nicht vorbei. Ich habe folgendes Problem:

Ich habe mit einem ATtiny88 einen Berührungssensor aufgebaut. Als 
Rückmeldung leuchten einige LEDs wenn ein bestimmter Schwellwert 
erreicht wird. Das funktioniert alles wunderbar, jedoch nur wenn ich im 
QTAnalyzer auf Start Reading gedrückt habe. Beende ich den Lesevorgang 
bleibt der µC in seiner aktuellen Position stehen. (Wenn beim Beenden 
die LEDs geleuchtet haben, bleiben sie auch an). Ich habe zur Kontrolle 
eine LED auf dauerlicht geschaltet. Diese Leuchtet immer. Irgendwas muss 
er also doch machen.

Ich habe irgendwie den Verdacht dass die Interne Clock nicht Arbeitet. 
Die SUT_CKSEL ist aber auf die interne (default) Clock eingestellt. Am 
~Reset PIN liegt über einem 1k Widerstand VCC (3,3V). Zum Flashen per 
SPI benutze ich das Controlboard vom QT600.
Ich Programmiere mit Atmel Studio 6 mit der QTouch extension.
Bitte um Hilfe, bin bei µC Programmierung noch sehr neu.

Habe auch versucht über ein Labornetzgerät nur die Spannungsversorgung 
auf das Board zu bringen. Der µC Startet aber auch hier nicht. (Aber 
Kontroll LED Leuchtet)



Vielen Dank schonmal für eure Hilfe

Gruß Flo

[Karl H. (kbuchegg)]

Flo schrieb:

> Ich habe irgendwie den Verdacht dass die Interne Clock nicht Arbeitet.

Vergiss diese Vermutungen gleich wieder.
Die internas des µC sind etwas, dass zwar nicht über jeden Verdacht 
erhaben ist, welche man allerdings als allerletztes verdächtigt. Gleich 
nach einem Fehler des Compilers.

Sehr viel wahrscheinlicher, und zwar mit Prozentzahlen größer als 99%, 
ist es hingegen, dass das Problem von dir durch entweder die 
Aussenbeschaltung und/oder das Programm verursacht wurde.

> Vielen Dank schonmal für eure Hilfe

Schaltpläne + Programm.
Sonst kann dir hier keiner weiter helfen.

[Flo (Gast)]

Das Grundgerüst des Programms wurde vom QTouch Assistenten erstellt, von 
mir ist lediglich die LED Ansteuerung. Ich kann auch das Projekt 
hochladen wenn das Sinnvoll ist.

#include <avr/io.h>
#include <avr/interrupt.h>
#define __delay_cycles(n)     __builtin_avr_delay_cycles(n)
#define __enable_interrupt()  sei()

#include "touch_api.h"
#include "touch.h"
#include "QDebug.h"
/*----------------------------------------------------------------------------
                                    macros
----------------------------------------------------------------------------*/

#define GET_SENSOR_STATE(SENSOR_NUMBER) qt_measure_data.qt_touch_status.sensor_states[(SENSOR_NUMBER/8)] & (1 << (SENSOR_NUMBER % 8))
#define GET_ROTOR_SLIDER_POSITION(ROTOR_SLIDER_NUMBER) qt_measure_data.qt_touch_status.rotor_slider_values[ROTOR_SLIDER_NUMBER]

/*----------------------------------------------------------------------------
                                   LED Controll
----------------------------------------------------------------------------*/

void LED_ON (void) {
  
  DDRB = 0xFF;
  DDRD = 0xFF;
  
  PORTB &= ~((1<<6) | (1<<7));
  PORTD &= ~((1<<5) | (1<<6) | (1<<7));


}


void LED_OFF (void){
    
    DDRB = 0xFF;
    DDRD = 0xFF;
    
    PORTB |= ((1<<6) | (1<<7));
    PORTD |= ((1<<5) | (1<<6) | (1<<7));
}


void Kontroll_LED (void)
{
  
  DDRA = 0xFF;
  PORTA &= ~(1<<3);
}


/*----------------------------------------------------------------------------
                            My Variables
----------------------------------------------------------------------------*/
uint32_t i=0;
uint32_t count=0;
uint16_t My_Delta=0;
/*----------------------------------------------------------------------------
                                prototypes
----------------------------------------------------------------------------*/
extern void touch_measure(void);
extern void touch_init( void );
extern void init_system( void );
extern void init_timer_isr(void);
extern void set_timer_period(uint16_t);


/*----------------------------------------------------------------------------
                            Structure Declarations
----------------------------------------------------------------------------*/

/*----------------------------------------------------------------------------
                                   Touch Delta
----------------------------------------------------------------------------*/

/*void my_touch_data (void)
{
  
  if (qt_measure_data.channel_signals[CHANNEL_0]<30u)
    { My_Delta = qt_measure_data.channel_signals[CHANNEL_0];}
  else{ My_Delta = 100;}
  
}

/*----------------------------------------------------------------------------
                                global variables
----------------------------------------------------------------------------*/
/* Timer period in msec. */
uint16_t qt_measurement_period_msec = QT_MEASUREMENT_PERIOD_MS;
uint16_t time_ms_inc=0;
extern uint8_t my_sensor_delta;
/*----------------------------------------------------------------------------
                                Delay Loop
----------------------------------------------------------------------------*/
/*void delay (void)
{ 
  count = (4*65536);
  for (i=0;i<count;i++);
  
}

/*----------------------------------------------------------------------------
                                static variables
----------------------------------------------------------------------------*/

/* flag set by timer ISR when it's time to measure touch */
volatile uint8_t time_to_measure_touch = 0u;

/* current time, set by timer ISR */
volatile uint16_t current_time_ms_touch = 0u;

/*============================================================================
Name    :   main
------------------------------------------------------------------------------
Purpose :   main code entry point
Input   :   n/a
Output  :   n/a
Notes   :
============================================================================*/

int main( void )
{ 
  
   /* initialise host app, pins, watchdog, etc */
    init_system();

    /* configure timer ISR to fire regularly */
    init_timer_isr();

  /* Initialize Touch sensors */
  touch_init();

    /* enable interrupts */
    __enable_interrupt();
  
    /* loop forever */
    for( ; ; )
    {
    extern void Transmit_Delta(void);
        touch_measure();
    
    Kontroll_LED();

      
  
    if( my_sensor_delta > 1u){
      
      LED_ON();
      }
      
    else {  LED_OFF();
        
        
        }
    
    
    /*  Time Non-critical host application code goes here  */
  
                  }
  
}

[Flo (Gast)]

Ach ja, Ich Flashe mit JP1 und lese dann mit JP2 aus.

Es soll aber wenn es fertig ist nur über den XF2J Betrieben werden

[Karl H. (kbuchegg)]

Zuallererst mal haben wir wieder mal das übliche:
Keine Blockkondensatoren an den Versorgungsspannungsanschlüssen.
Praktisch jeder Thread, in dem von seltsamen Problemen berichtet wird, 
bzw. in dem jemand bittet über seine Schaltung drüber zu schauen, hat 
immer wieder das gleiche grundsätzliche Problem: keine 
Blockkondensatoren. Die sind nicht da, damit die Kondensatorindustrie 
auch etwas verdient! Die haben eine Funktion!


Das hier

void LED_ON (void) {
  
  DDRB = 0xFF;
  DDRD = 0xFF;

no.
erstens willst du nicht ständig am DDRx Register rumfummeln, sondern das 
macht man genau einmal, nämlich am Programmanfang.

Zweitens ist das 'Ich setze einfach mal alle Pins auf Ausgang' nicht die 
Methode der Wahl. WEnn du von einem Port nur 3 Pins auf Ausgang 
brauchst, weil dort 3 LED hängen, dann schalte gefälligst auch nur die 3 
Ausgänge auf Ausgang und lass die anderen Pins in Ruhe! Andere 
Programmteile verlassen sich unter Umständen darauf, dass sie die 
Datenrichtung für 'ihre' Pins einstellen und anderer Code ihnen da nicht 
ins Handwerk pfuscht.

[Karl H. (kbuchegg)]

Karl Heinz schrieb:
> Zuallererst mal haben wir wieder mal das übliche:
> Keine Blockkondensatoren an den Versorgungsspannungsanschlüssen.
> Praktisch jeder Thread, in dem von seltsamen Problemen berichtet wird,
> bzw. in dem jemand bittet über seine Schaltung drüber zu schauen, hat
> immer wieder das gleiche grundsätzliche Problem: keine
> Blockkondensatoren. Die sind nicht da, damit die Kondensatorindustrie
> auch etwas verdient! Die haben eine Funktion!

Oder sollen C4 und C3 die Blockkondensatoren darstellen?
In dem Fall, und wenn die baulich an den µC-Pins sitzen, nehm ich alles 
zurück und behaupte das Gegenteil.

[Flo (Gast)]

Hallo karl Heinz,

danke für deine Antwort

Karl Heinz schrieb:
>
> Zweitens ist das 'Ich setze einfach mal alle Pins auf Ausgang' nicht die
> Methode der Wahl. WEnn du von einem Port nur 3 Pins auf Ausgang
> brauchst, weil dort 3 LED hängen, dann schalte gefälligst auch nur die 3
> Ausgänge auf Ausgang und lass die anderen Pins in Ruhe!

Ich hatte vorher nur die Pins die ich brauche auf Ausgang, allerdings 
funktionierte dann das Auslesen nichtmehr, nachdem ich alle als Ausgang 
definiert hatte funktionierte das wieder.
Ich werd das dann im Programm weiter nach oben schieben.

C3 und C4 sind zwischen VCC und Ground geschalten und auch physikalisch 
nahe am µC.

Kannst du mir erklären warum es funktioniert wenn der Analyzer läuft, 
aber nur mit Spannung nicht? Wie gesagt, ich hatte den verdacht dass die 
interne Clock nicht angeschaltet ist, scheint aber flasch zu sein.

[Karl H. (kbuchegg)]

Flo schrieb:

> Ich hatte vorher nur die Pins die ich brauche auf Ausgang, allerdings
> funktionierte dann das Auslesen nichtmehr

das wird aber nicht besser, wenn du der QTouch Lib ins Handwerk pfuscht.

>, nachdem ich alle als Ausgang
> definiert hatte funktionierte das wieder.

Wenn überhaupt, dann war das Zufall.
Das es in Wirklichkeit nicht funktioniert, siehst du ja. Sonst würdest 
du nicht fragen.


> C3 und C4 sind zwischen VCC und Ground geschalten und auch physikalisch
> nahe am µC.

Gut. Dann nehm ich alles zurück.

> Kannst du mir erklären warum es funktioniert wenn der Analyzer läuft,
> aber nur mit Spannung nicht? Wie gesagt, ich hatte den verdacht dass die
> interne Clock nicht angeschaltet ist, scheint aber flasch zu sein.

Weil dein Analyzer als Messgerät auch irgendwie das Messobjekt 
verändert. Wo genau ist der denn angeschlossen?
Wie sieht die Anbindung der kapazitiven Sensoren aus?


Hast du deinen Tiny schon mal ohne diesem QTouch einem Test unterzogen?
Einfach nur 2 LED blinken lassen und sonst nichts? Läuft er dann? 
Sozusagen ein "ist die grundsätzliche Hardware eigentlich in 
Ordnung"-Test?

[Flo (Gast)]

> das wird aber nicht besser, wenn du der QTouch Lib ins Handwerk pfuscht.

Ich weis es leider nicht besser, wenn ich nur die benötigten Pins für 
die LEDs als Ausgang schalte kann ich keine Auswertung mit dem QTouch 
Analyzer machen.

> Wenn überhaupt, dann war das Zufall.
> Das es in Wirklichkeit nicht funktioniert, siehst du ja. Sonst würdest
> du nicht fragen.
>
> Weil dein Analyzer als Messgerät auch irgendwie das Messobjekt
> verändert. Wo genau ist der denn angeschlossen?
> Wie sieht die Anbindung der kapazitiven Sensoren aus?
>

Nur um sicherzugehen dass wir vom selben sprechen, mit Analyzer meine 
ich das Auswerttool von Atmel Studio das mir auch die Intensität des 
Touchs ausgibt. Keinen Spektrumanalyzer.

> Hast du deinen Tiny schon mal ohne diesem QTouch einem Test unterzogen?
> Einfach nur 2 LED blinken lassen und sonst nichts? Läuft er dann?
> Sozusagen ein "ist die grundsätzliche Hardware eigentlich in
> Ordnung"-Test?

Ja das habe ich und darauf begründet sich auch meine Frage. Wenn ich den 
QT weglasse leuchtet nur die Kontroll LED, sonst passiert garnichts.

[Karl H. (kbuchegg)]

Flo schrieb:

> Wenn ich den
> QT weglasse leuchtet nur die Kontroll LED, sonst passiert garnichts.

Dann lass uns erst mal den Teil abklären.

Testprogramm

#define F_CPU 1000000UL

#include <avr/io.h>
#include <utils/delay.h>

#define LED1  PA3
#define LED2  PB6

int main()
{
  DDRA |= ( 1 << LED1 );
  DDRB |= ( 1 << LED2 );

  PORTA &= ~( 1 << LED1 );
  PORTB &= ~( 1 << LED2 );

  _delay_ms( 1000 );

  PORTB |= ( 1 << LED2 );

  while( 1 )
  {
    PORTA |= ( 1 << LED1 );
    _delay_ms( 500 );
    PORTA &= ~( 1 << LED1 );
    _delay_ms( 1000 );
  }
}

erwartetes Verhalten:
Wenn der µC resettet wird (entweder nach dem Brennen oder nach dem 
Anlegen der Betriebsspannung) leuchten die beiden LED, die in deinem 
Schaltplan mit LED1 und LED2 bezeichnet sind.

Nach 1 Sekunde geht LED2 aus und darf danach nie wieder aufleuchten, 
während LED1 zu blinken anfängt. Die Dunkelphasen sind ca. 0.5 Sekunden 
lang, die Hellphasen der Led sind ca 1 Sekunde lang.


Und das darf sich nicht ändern. Egal ob du einen Analyser drann hast 
oder nicht. Weder darf LED1 zu blinken aufhören, noch darf LED2 erneut 
aufleuchten (es sei denn du nimmst den Strom weg und legst ihn wieder 
an). Auch müssen die Zeiten ziemlich gut stimmen (ich geh mal davon aus, 
dass du nicht an den Fuses gespielt hast und der Tiny noch immer auf 
1Mhz eingestellt ist)

Wenn das so ist, dann ist dein µC einsatzbereit und die Hardware so 
gesehen erst mal in Ordnung. Probier alles mögliche aus, was du in 
Verdacht hast, dass es den µC beeinflussen könnte. Weder darf das 
Blinken aufhören oder sich verhaspeln, noch darf LED2 erneut 
aufleuchten.

[Flo (Gast)]

Habe den Code von dir jetz mal draufgeladen, allerdings erkennt er bei 
mir die
> #include <utils/delay.h>

nicht. hab das rausgetan und die delays durch entsprechende 
"for-schleifen" ersetzt. Ich weis. ist nicht so schön wie die interrupts 
:D

uint16_t i;

for(i=0;i<65000;i++;)

es tut sich leider garnichts, weder mit dem QT noch ohne

Hab zwischenzeitlich nen neuen µC draufgepackt weil ich mich durch 
rumprobieren ausgeschlossen hab :D

[delay (Gast)]

Flo schrieb:
>> #include <utils/delay.h>
sollte bestimmt
#include <util/delay.h>
heißen, dort ist wohl ein s dazwischen gerutscht.

[Karl H. (kbuchegg)]

delay schrieb:
> Flo schrieb:
>>> #include <utils/delay.h>
> sollte bestimmt
> #include <util/delay.h>
> heißen, dort ist wohl ein s dazwischen gerutscht.

:-)
Ja das passiert mir öfter.

[Flo (Gast)]

Stimmt, Ja.

Funktioniert leider trotzdem nichts :/

[Karl H. (kbuchegg)]

Flo schrieb:
> Habe den Code von dir jetz mal draufgeladen, allerdings erkennt er bei
> mir die
>> #include <utils/delay.h>
>
> nicht. hab das rausgetan und die delays durch entsprechende
> "for-schleifen" ersetzt. Ich weis. ist nicht so schön wie die interrupts
> :D

Sind auch keine Interrupts.
_delay_ms expandiert ebenfalls zu Warteschleifen.
Nur funktionieren die dann auch, weil man dem Compiler verbietet sie 
wegzuoptimieren.

Also. Die _delay_ms wieder rein, und den Directory Namen korrigieren.

[Flo (Gast)]

Hab ich gerade gemacht, hat sich jetzt ein bisschen überschnitten. 
Leuchtet leider nichts :/

[Karl H. (kbuchegg)]

Flo schrieb:
> Stimmt, Ja.
>
> Funktioniert leider trotzdem nichts :/

Dann ist aber was mächtig faul im Staate Dänemark mit deiner Hardware
Denn ein noch einfacheres Testprogramm kann es kaum geben.

[Karl H. (kbuchegg)]

Also: ganzen Prozess nochmal durchgehen.

Hast du das richtige Hex-File gebrannt?
Gibt es vom Brenner eine Fehlermeldung?
Kannst du das gebrannte Programm vom µC wieder auslesen und stimmt das 
mit dem Hex-File überein? (die Verify Funktion im Brennprogramm)
Welcher Pegel liegt am Reset-Pin des Tiny an?
Sind alle Versorgunsspannungen am Tiny dort wo sie hingehören?
Sind vielleicht die LED verkehrt rum eingelötet?

Sichtung der Platine: Kurzschlüsse? Leiterbahnunterbrechungen?

(Als letztes: Wenn möglich, alles bis auf die beiden LED und ihre 
Widerstände  mal runternehmen, so dass garantiert nix anderes den µC 
beeinflussen kann)

[Flo (Gast)]

Karl Heinz schrieb:
> Also: ganzen Prozess nochmal durchgehen.
>
> Hast du das richtige Hex-File gebrannt?

Ja, ich hab extra nachgesehen ob er das .hex oder das.elf auswählt

> Gibt es vom Brenner eine Fehlermeldung?

Nein,
Erasing device...OK
Programming Flash...OK
Verify Flash...OK

> Kannst du das gebrannte Programm vom µC wieder auslesen und stimmt das
> mit dem Hex-File überein? (die Verify Funktion im Brennprogramm)

Verify funktioniert. Wenn ich das HEX mit Read auslese und es im 
Texteditor vergleiche, sieht es für mich so aus als hätte er das ganze 
"aufgefüllt" mit vielen FFFFFF.
Die ersten 10 Zeilen sind identisch, das Original endet hier.

> Welcher Pegel liegt am Reset-Pin des Tiny an?

3,3V

> Sind alle Versorgunsspannungen am Tiny dort wo sie hingehören?

VCC und AVCC sind an 3,3V

> Sind vielleicht die LED verkehrt rum eingelötet?

Nein, hab ich extra nochmal überprüft
>
> Sichtung der Platine: Kurzschlüsse? Leiterbahnunterbrechungen?

Hab jetzt fragwürdige stellen nochmal nachgelötet (zwischen den Beinchen 
des µC)

> (Als letztes: Wenn möglich, alles bis auf die beiden LED und ihre
> Widerstände  mal runternehmen, so dass garantiert nix anderes den µC
> beeinflussen kann)

Hab jetzt nochmal ein komplett jungräuliches Projekt erstellt nur mit 
deinem Code drin. Jetz funktionierts.

Es passiert folgendes.

Sobald spannung anliegt Leuchten LED1 und LED2 gleichzeitig für ca 0,5-1 
sek, danach erlischt LED2. LED1 blinkt etwa mit 1HZ.

[Flo (Gast)]

Also das Testprogramm geht jetzt.

habe gerade nochmal versucht in meinem Programm nur die Pins die ich 
auch wirklich brauche als Ausgang zu definieren sowie die Pins die die 
SPI Schnittstelle richtig zu definieren. hat allerdings keinen 
sichtbaren Erfolg gebracht. Der µc bleibt nachwievor einfach in seinem 
Zustand sobald man das Auslesen beendet. Mit Spannung alleine Startet er 
erst garnicht. nur die Kontroll-LED leuchtet.

[Karl H. (kbuchegg)]

> Hab jetzt nochmal ein komplett jungräuliches Projekt erstellt nur mit deinem 
Code drin. Jetz funktionierts.


Das ist dubios.
Das legt bei mir die Vermutung nahe, dass in deinem ursprünglichen 
Projekt zb der falsche Prozessor eingestellt war.

[Flo (Gast)]

Soo, ich habe jetz wieder ein Jungfräuliches TouchSensor Programm vom 
Assistenten generieren lassen und einfach eine einzelne LED blinken 
lassen.

Jetz hat sich herrausgestellt dass ich diese LED niewieder löschen kann. 
Hab den Chip zwar jetz schon mindestens 10x gelöscht bevor ich ihn neu 
beschrieben habe, aber die LED bleibt auf dauerlicht gestzt, obwohl der 
CODE auskommentiert ist. :/ wird irgendwie immer seltsamer

[Karl H. (kbuchegg)]

Flo schrieb:
> Soo, ich habe jetz wieder ein Jungfräuliches TouchSensor Programm vom
> Assistenten generieren lassen

Wie umfangreich ist dieses QTouch Zeugs?
Wenns nicht zu umfnagreich ist, dann stell doch bitte mal hier ein.
Ich verwende dieses Zeugs nicht (und auch keinen Assistenten :-), daher 
kann ich dazu nicht viel sagen.

Aber ich kann mir mal ansehen, was der Assistent da eigentlich so alles 
erzeugt :-)

[Flo (Gast)]

Ich hab das ganze Projekt jetz mal gepackt und angehängt. Ich kann ncht 
ganz beurteilen wie umfangreich das ist :D die Main hab ich ja schon 
gepostet.
In diesem projekt hab ich jetzt nur die blink LED drin. die touch 
erkennung habe ich in einem anderen Projekt aus der QDEBUG.c genommen, 
aus "Transmit_delta".

[Karl H. (kbuchegg)]

2 Dinge sind mir in deinem Code aufgefallen.

Du hast zwar eine schöne Funktion Output_Settings, rufst sie aber nie 
auf

int main( void )
{

   /* initialise host app, pins, watchdog, etc */
    init_system();

    /* configure timer ISR to fire regularly */
    init_timer_isr();

  /* Initialize Touch sensors */
  touch_init();

    /* enable interrupts */
    __enable_interrupt();

    /* loop forever */
    for( ; ; )

du musst sie schon auch mal irgendwo aufrufen, damit sie einen Effekt 
hat und die Pins auf Ausgang schaltet.

Das andere ist.
In touch.h, ganz unten

/******************************************************************************
*   Debug Interface Settings
******************************************************************************/


#define _DEBUG_INTERFACE_

/*  SPI Master  */
#define  QDEBUG_SPI

d.h. da ist Debugging aktiviert und das Debugging findet auf der SPI 
statt. Sicher, dass du das willst? Denn dann gibt der Code alle 
möglichen Statusmeldungen über die eingestellte Schnittstelle aus. Was 
grundsätzlich nicht schlecht ist, aber natürlich auch wieder eine 
weitere Fehlerquelle darstellt.

Ich würde mich mal in touch.c

void touch_measure(void)
{

  /*status flags to indicate the re-burst for library*/
    static uint16_t status_flag = 0u;
    static uint16_t burst_flag = 0u;

    if( time_to_measure_touch )
        {

            /*  clear flag: it's time to measure touch  */
            time_to_measure_touch = 0u;

            do {
        #ifdef _DEBUG_INTERFACE_
            TIMESTAMP0;
        #endif

                /*  one time measure touch sensors    */
                status_flag = qt_measure_sensors( current_time_ms_touch );

        #ifdef _DEBUG_INTERFACE_
            TIMESTAMP2;
        #endif

                burst_flag = status_flag & QTLIB_BURST_AGAIN;
                
                #ifdef _DEBUG_INTERFACE_
                    /* send debug data */
                    QDebug_SendData(status_flag);
                    /* Process commands from PC */
                  QDebug_ProcessCommands();
                #endif
          
          #ifdef _DEBUG_INTERFACE_
              TIMESTAMP3;
          #endif

                /* Time-critical host application code goes here */

            }while (burst_flag) ;

        }
        
        #ifdef _DEBUG_INTERFACE_
            TIMESTAMP4;
        #endif
        
        /* Non-Time critical host application code goes here */
        
        #ifdef _DEBUG_INTERFACE_
            TIMESTAMP5;
        #endif
        /* Host sleep code goes here */

}

auf die while Schleife konzentrieren. Das ist eine potentielle 
Endlosschleife, wenn bust_flag nie FALSE wird.
Damit burst_flag FALSE werden kann, muss hier

                burst_flag = status_flag & QTLIB_BURST_AGAIN;

im status_flag das Bit QTLIB_BURST_AGAIN gelöscht sein.
status_flag kommt von hier

            status_flag = qt_measure_sensors( current_time_ms_touch );

d.h. in der Funktion würde ich mal reinschnuppern, wie da die Logik 
funktioniert.
Unglücklicherweise kann ich aber die Funktion dafür nicht finden. Ist 
die in der libavr25g1-4qt-k-0rs.a drinnen?

[Rudolph (Gast)]

Flo schrieb:
> Das funktioniert alles wunderbar, jedoch nur wenn ich im
> QTAnalyzer auf Start Reading gedrückt habe.

Das klingt nach aktiviertem Debug-Code.

Der Q-Touch Composer erzeugt leider auch in der neuesten Version etwas 
merkwürdigen Code.
Zum Beispiel ist es nicht möglich, einen Quarz ungleich 8MHz zu 
benutzen, das ganze Konstrukt ist auf den RC-Oscillator abgestimmt und 
der µC wird mit 4MHz betrieben.
Wenn man versucht das zu ändern muss man ziemlich tief im Code graben 
und dann funktionieren entweder die Buttons nicht mehr oder die 
Debug-Ausgabe oder gleich beides.
Und das mit ansonstem nackten Projekt, ohne eigenen Code.

Dokumentation findet genau wie beim ASF quasi nicht statt.

Ich hatte Atmel schon angeschrieben deshalb, die Antworten lassen mich 
aber stark vermuten, dass dort meine Fragen nicht verstanden wurden da 
ich auf nochmalige Nachfrage mit quoten derer Mail als Bezug erneut die 
gleiche nutzlose Antwort erhalten habe die ein wenig an der Frage vorbei 
ging.
Ist jetzt alles schon wieder ein paar Monate her und ich hatte mich auch 
nur damit beschäftigt um einen Kollegen zu unterstützen.

Aber Bock habe ich auf den Kram nicht mehr wirklich, gezwungen zu sein 
den µC auf 4MHz zu benutzen finde ich nicht wirklich komisch.
Und die nächste Version vom Q-Touch Composer hat das dann nicht etwa 
verbessert, der fragliche Code wurde noch schwerer zu finden. :-(

[Rudolph (Gast)]

Ach ja, wir haben ein Board mit einem Mega88PA und eines mit einem 
Mega164PA aufgebaut.
Beim Mega88PA erfolgt die Debug-Ausgabe per TWI, der Q-Touch Composer 
kann den Mega164PA nur per Software-SPI Debug-Ausgaben machen.

Wobei man villeicht noch erklären muss das Debug-Ausgaben sich auf die 
Messwerte der Touch-Sensoren bezieht, das kann man mit dem Q-Touch 
Analyser visualisieren wenn man denn das QT600-Kit hat das diese Daten 
auf den USB umsetzt.

Ich finde das Zeug reichlich halbgar.

[Uwe (Gast)]

> /* Process commands from PC */
>                  QDebug_ProcessCommands();

Wartet der µC hier auf eine Antwort ? (Die niemals kommt wenn du das 
Kabel abziehst !)
Am besten mal den Debugmode ausschalten und dann versuchen das Kabel 
abzuziehen.

[Flo (Gast)]

Vielen Dank für die vielen Tipps, werd mich heute wieder stark 
dahinterklemmen und eure Tipps durcharbeiten, gebe dann wieder 
Rückmeldung.

Es ist schon so, dass Ich mit dem Qtouch Analyzer die Messwerte des 
Touchsensors visualisiere. Das ist aber nur jetzt am anfang wichtig. 
Später wenn ich das Ding eingebaut habe und es funktioniert 
interessieren mich ja die Werte nichtmehr, nur die Funktion. Werde also 
versuchen den Debug-mode wie von euch beschrieben abzuschalten.

Viele Grüße, Flo

[Flo (Gast)]

Soweit ich das jetz sehe liegt das Problem in der Auswertung des 
Touches, die meiner Ansicht nach nur aktiv ist wenn der µC im 
Debug-Modus ist. Habe die Kontroll-LED mal auf blinken gemacht und nur 
vom Labornetzgerät die 3,3V angelegt. Das funktioniert!

Bis jetzt habe ich die Touch erkennung des generierten Codes genommen. 
Habt ihr eine Idee wie ich das anders machen kann? Habe die Variable 
delta aus QDebug.c dazu verwendet.

[Flo (Gast)]

Bin langsam echt am verzweifeln. Das muss doch gehen. Steuert die SPI 
schnittstelle evtl meinen µC und enabled die Touch-auswertung?

[Flo (Gast)]

Rudolph schrieb:

> Wobei man villeicht noch erklären muss das Debug-Ausgaben sich auf die
> Messwerte der Touch-Sensoren bezieht, das kann man mit dem Q-Touch
> Analyser visualisieren wenn man denn das QT600-Kit hat das diese Daten
> auf den USB umsetzt.

Ich verwende genau was du schreibst. Kann es sein dass die Messwerte nur 
verfügbar sind wenn der Analyzer angeschlossen ist? Ich verwende nämlich 
für meine Touchanzeige eine Variable aus der QDebug.c

[Rudolph (Gast)]

Habs nicht mehr im Kopf, da gibt es aber eine Funktion mit der man den 
Status von Buttons abfragen kann.

Also Delta ist ja nicht ganz richtig, Du willst ja wissen ob der Taster 
über der eingestellten Schwelle ist.

Das ganze Geraffel scheint mir im wesentlich Marketing zu sein, 
ernsthaft scheint man sich bei Atmel damit nicht zu beschäftigen.

Genauso wie diese undokumentierte Sammlung von inkonsistentem Code die 
Atmel ASF nennt.

Das könnte richtig hilfreich sein.

[Flo (Gast)]

Rudolph schrieb:
> Habs nicht mehr im Kopf, da gibt es aber eine Funktion mit der man den
> Status von Buttons abfragen kann.
>
> Also Delta ist ja nicht ganz richtig, Du willst ja wissen ob der Taster
> über der eingestellten Schwelle ist.


Stimmt, delta ist nicht ganz richtig, das Delta wird anscheinend nur 
gebildet wenn der Debugmodus aktiv ist.


Ich hab  jetzt nochmal ganz viel rumprobiert und es zum laufen gekriegt 
so wie ich es will. Es funktioniert jetz mir einer konstruktion aus 
Status_Flag und Burst_Flag.

Ich möchte mich bei allen die mir geholfen haben nochmals herzlichst 
bedanken. Danke, dass ihr euch die Zeit genommen habt und für eure mühe 
:)

Von meiner Seite aus kann man das Thema abschließen.