ADCC - nur zuckeln am Eingang!

[PIC-Besitzer (Gast)]

Servus,

ich betreibe derzeit einen PIC18F26K40 in einer größeren Schaltung. 
Läuft alles prima (ist auch unerheblich), aber der ADCC macht größte 
Probleme.

Ich habe jetzt testweise NUR ein Poti dran, welches mir an einen PIN 
0-3,3V anlegt. Hier mein (mit MCC erzeugter) Code.

Ziel war erstmal das Interruptbasiert zu machen, da zuckelt auch alles 
rum. (Zuckeln heißt - wenn das Poti z.B. mittig steht, erhalte ich werte 
von 300-600, also wirklich nicht nur ein MSB flattern. Der Analogeingang 
ist aber absolut save, ein Blockkondensator ist auch am PIC. Schaltung 
anbei, BAT_AN_IN wird mit einem Poti "befeuert".

Jeglicher Rat ist hilfreich!

VG

void ADCC_Initialize(void)
{
   
    // set the ADCC to the options selected in the User Interface
    // ADDSEN disabled; ADGPOL digital_low; ADIPEN disabled; ADPPOL VSS; 
    ADCON1 = 0x00;
    // ADCRS 0; ADMD Basic_mode; ADACLR disabled; ADPSIS ADFLTR; 
    ADCON2 = 0x00;
    // ADCALC First derivative of Single measurement; ADTMD disabled; ADSOI ADGO not cleared; 
    ADCON3 = 0x00;
    // ADACT disabled; 
    ADACT = 0x00;
    // ADAOV ACC or ADERR not Overflowed; 
    ADSTAT = 0x00;
    // ADCS FOSC/128; 
    ADCLK = 0x3F;
    // ADNREF VSS; ADPREF VDD; 
    ADREF = 0x00;
    // ADCAP Additional uC disabled; 
    //ADCAP = 0x00;
    ADCAP = 0x1F; //Enable all PC-Caps??
    // ADPRE 0; 
    ADPRE = 0x00;
    // ADACQ 255; 
    ADACQ = 0xFF;
    // ADPCH ANA0; 
    ADPCH = 0x00;
    // ADRPT 0; 
    ADRPT = 0x00;
    // ADLTHL 0; 
    ADLTHL = 0x00;
    // ADLTHH 0; 
    ADLTHH = 0x00;
    // ADUTHL 0; 
    ADUTHL = 0x00;
    // ADUTHH 0; 
    ADUTHH = 0x00;
    // ADSTPTL 0; 
    ADSTPTL = 0x00;
    // ADSTPTH 0; 
    ADSTPTH = 0x00;
    
    // ADGO stop; ADFM right; ADON disabled; ADCONT disabled; ADCS FRC; 
    ADCON0 = 0x14;
    

}

void ADCC_StartConversion(adcc_channel_t channel)
{
    // select the A/D channel
    ADPCH = channel;  
  
    // Turn on the ADC module
    ADCON0bits.ADON = 1;

    // Start the conversion
    ADCON0bits.ADGO = 1;
}

bool ADCC_IsConversionDone()
{
    // Start the conversion
    return (!ADCON0bits.ADGO);
}

adc_result_t ADCC_GetConversionResult(void)
{
    // Return the result
    return ((ADRESH << 8) + ADRESL);
}

adc_result_t ADCC_GetSingleConversion(adcc_channel_t channel)
{
    // select the A/D channel
    ADPCH = channel;  

    // Turn on the ADC module
    ADCON0bits.ADON = 1;
  
    //Disable the continuous mode.
    ADCON0bits.ADCONT = 0;    

    // Start the conversion
    ADCON0bits.ADGO = 1;

    // Wait for the conversion to finish
    while (ADCON0bits.ADGO)
    {
    }

    // Conversion finished, return the result
    return ((ADRESH << 8) + ADRESL);
}

void ADCC_StopConversion(void)
{
    //Reset the ADGO bit.
    ADCON0bits.ADGO = 0;
}

void ADCC_SetStopOnInterrupt(void)
{
    //Set the ADSOI bit.
    ADCON3bits.ADSOI = 1;
}

void ADCC_DischargeSampleCapacitor(void)
{
    //Set the ADC channel to AVss.
    ADPCH = 0x3C;   
}

void ADCC_LoadAcquisitionRegister(uint8_t acquisitionValue)
{
    //Load the ADACQ register.
    ADACQ = acquisitionValue;   
}

void ADCC_SetPrechargeTime(uint8_t prechargeTime)
{
    //Load the ADPRE register.
    ADPRE = prechargeTime;  
}

void ADCC_SetRepeatCount(uint8_t repeatCount)
{
    //Load the ADRPT register.
    ADRPT = repeatCount;   
}

uint8_t ADCC_GetCurrentCountofConversions(void)
{
    //Return the contents of ADCNT register
    return ADCNT;
}

void ADCC_ClearAccumulator(void)
{
    //Reset the ADCON2bits.ADACLR bit.
    ADCON2bits.ADACLR = 1;
}

uint16_t ADCC_GetAccumulatorValue(void)
{
    //Return the contents of ADACCH and ADACCL registers
    return ((ADACCH << 8) + ADACCL);
}

bool ADCC_HasAccumulatorOverflowed(void)
{
    //Return the status of ADSTATbits.ADAOV
    return ADSTATbits.ADAOV;
}

uint16_t ADCC_GetFilterValue(void)
{
    //Return the contents of ADFLTRH and ADFLTRL registers
    return ((ADFLTRH << 8) + ADFLTRL);
}

uint16_t ADCC_GetPreviousResult(void)
{
    //Return the contents of ADPREVH and ADPREVL registers
    return ((ADPREVH << 8) + ADPREVL);
}

void ADCC_DefineSetPoint(uint16_t setPoint)
{
    //Sets the ADSTPTH and ADSTPTL registers
    ADSTPTH = setPoint >> 8;
    ADSTPTL = setPoint;
}

void ADCC_SetUpperThreshold(uint16_t upperThreshold)
{
    //Sets the ADUTHH and ADUTHL registers
    ADUTHH = upperThreshold >> 8;
    ADUTHL = upperThreshold;
}

void ADCC_SetLowerThreshold(uint16_t lowerThreshold)
{
    //Sets the ADLTHH and ADLTHL registers
    ADLTHH = lowerThreshold >> 8;
    ADLTHL = lowerThreshold;
}

uint16_t ADCC_GetErrorCalculation(void)
{
  //Return the contents of ADERRH and ADERRL registers
  return ((ADERRH << 8) + ADERRL);
}

void ADCC_EnableDoubleSampling(void)
{
    //Sets the ADCON1bits.ADDSEN
    ADCON1bits.ADDSEN = 1;
}

void ADCC_EnableContinuousConversion(void)
{
    //Sets the ADCON0bits.ADCONT
    ADCON0bits.ADCONT = 1;
}

void ADCC_DisableContinuousConversion(void)
{
    //Resets the ADCON0bits.ADCONT
    ADCON0bits.ADCONT = 0;
}

bool ADCC_HasErrorCrossedUpperThreshold(void)
{
    //Returns the value of ADSTATbits.ADUTHR bit.
    return ADSTATbits.ADUTHR;
}

bool ADCC_HasErrorCrossedLowerThreshold(void)
{
    //Returns the value of ADSTATbits.ADLTHR bit.
    return ADSTATbits.ADLTHR;
}

uint8_t ADCC_GetConversionStageStatus(void)
{
    //Returns the contents of ADSTATbits.ADSTAT field.
    return ADSTATbits.ADSTAT;
}

//Wird im 1ms zyklus aufgrufen, um wirklich 
//jegliches Prechargen abzuschließen

void proc_ADCC(void) {
    unsigned static char state = 0;
    
    switch (state) {
        case 0: 
            // select the A/D channel
            ADPCH = BAT_AN_IN;  
            state++;
            break;
        case 1: 
            // Turn on the ADC module
            ADCON0bits.ADON = 1;
            // Start the conversion
            ADCON0bits.ADGO = 1;
            state++;
            break;
        case 2: 
            if(ADCC_IsConversionDone()) {
                ADCON0bits.ADON = 0;
                adc_bat_an_in = ADCC_GetConversionResult();
                state=0;
            }   
    }
}

[Jacko (Gast)]

Ist das bei PICs wirklich sooooo kompliziert?

Was braucht man denn? (in Pseudo-C)

Erfolg = Init_ADC(Kanal,Uref,f_ADC,sonstige Mode-Parameter)

eventuell auch noch

Erfolg = Stopp_ADC()

dann, im Timer-Interrupt, der nicht schneller, als
die Conversion-Time ist:

Erfolg = read_and_restart_ADC(&Result)

Das reicht für 96,3% aller Anwendungen.

Was brauchst du mehr?

[Klaus (Gast)]

Jacko schrieb:
> Ist das bei PICs wirklich sooooo kompliziert?

Nein. Multiplexer schalten, warten bis der Samplekondensator geladen 
ist, Wandlung starten, wenn fertig auslesen. Ist in weniger als 10 
Zeilen erledigt.

Samplezeiten und Wandlerclock müssen zum CPU-Takt passen, Werte stehen 
im Datenblatt.

MfG Klaus

[PIC-Besitzer (Gast)]

@Jacko: sonstige Mode-Parameter ... Ja, dann viel Spaß in dem 
Datenblatt. Ich würde nicht fragen, wenn ich es wüsste.

in einem Standard-PIC mit dem normalen ADC kein Problem. Aber hier 
braucht man zig settings, damit überhaupt irgendwas geht.

[Harald W. (wilhelms)]

Jacko schrieb:

> Was brauchst du mehr?

Zusatzcode, damit es "zuckelt". :-)

[Cerberus (Gast)]

Was sagt denn die Simulation bzw. der Debugger oder benutzt du
die nicht?

Ich vermisse ein bisschen sinnvolle Kommentare, denn dafür ist
die Funktion doch da.

[Dirk K. (knobikocher)]

PIC-Besitzer schrieb im Beitrag #5098811:
> Ich habe jetzt testweise NUR ein Poti dran, welches mir an einen PIN
> 0-3,3V anlegt.

Wo? Sehe ich nicht im Schaltplan.
Das Signal an RA3 vielleicht? Wenn da wirklich NUR ein Poti dran ist -> 
kein Filter vor dem ADC -> zuckeln.

PIC-Besitzer schrieb im Beitrag #5098811:
> Der Analogeingang
> ist aber absolut save

Bitte "save" definieren.

[Harald W. (wilhelms)]

Dirk K. schrieb:

> Bitte "save" definieren.

https://de.wikipedia.org/wiki/Save

:-)

[PIC-Besitzer (Gast)]

@Cerberus, Debugger spuckt auch dieselben RAW-Werte aus. Also einen 
stark schwankenden, absolut unbrauchbaren Wert. Dazu haben alle Kanäle 
Crosstalk.

Was genau kann/soll ich testen? Wie kann ich das Problem eingrenzen?

@Dirk,
Wo? Sehe ich nicht im Schaltplan. -> "Ich habe jetzt testweise NUR ein 
Poti dran, welches mir an einen PIN 0-3,3V anlegt." Wie willst du mir 
helfen, wenn du nicht Mal lesen kannst?

"Das Signal an RA3 vielleicht? Wenn da wirklich NUR ein Poti dran ist ->
kein Filter vor dem ADC -> zuckeln." -> In zig Anwendungen mit alten 
Pics ohne Zusatzkomponenten gemacht. Notfalls Softwarefilter dahinter, 
mit dem ADCC Average Mode. Selbst ohne zuckt da vll das LSB. Wieso zig 
Kondensatoren auflöten? Machen kaum mehr Geräte - wenn auch aus 
Kostengründen. Aber was will man erwarten, bei so ner sinnfreien 
Antwort.

bzgl Save, entschuldige die fehlende Definition - Laut Oszilloskop liegt 
ein stabiles Signal, also auch kein grobes Rauschen, an. Wobei auch ein 
Rauschen - wie es ja hier im 300-400mV Bereich sein müsste - nicht mal 
das schlechteste Poti hat. Dachte das wäre selbsterklärend.

Jungs, was is mit euch los? Wollt ihr mir helfen, dann fragt / sagt was 
ihr wissen wollt / ich tun soll. Ich mache jede Messung, beantworte 
Fragen, alles. Aber was soll euer dämliches Geklugscheiße, in welchem 
ihr in keinem Satz helft?! Man man man...

[Jacko (Gast)]

Lieber PIC-Besitzer,

du stellst uns eine einfach klingende Frage:
" warum zuckelt es?"

Ich glaube, allen anderen geht es genauso: Wozu braucht man
28 Funktionen, deren Zusammenhang mit Nebeneffekten nachzu-
vollziehen echt unzumutbar ist...

Wenn es doch nur um
- wähle Kanal, Wandler-Mode und Referenz
- starte den ADC
- lese das Ergebnis aus
- stoppe, oder re-starte den ADC
geht.

Das ist kein Klugscheißen.
Aber: Warum sollen wir in 28 Funktionen nachschauen, wo dein
Fehler liegt, wenn das jeder andere mit 3...5 Funktionen
erledigt hätte?

Dann frage ich mal gezielt:
Was ist an deiner Messung so Besonderes, dass sie 28
unübersichtliche Funktionen braucht, statt 3...5?

[PIC-Besitzer (Gast)]

Hallo Jacko,

kein Problem. Ich habe geschrieben, das ist nunmal der Standardcode, den 
der MCC erzeugt. Gerne kann ich das auch auf die von mir verwendeten 
Teile kürzen - allerdings gab es da bis dato ja auch IMMER Beschwerden 
:-)

Nochmal - Ziel wäre es im Moment, einfach mal überhaupt eine Messung im 
Basic mode hinzukriegen. Langfristig wäre ja auch der Average Mode etc 
super interessant, aber deswegen erstmal ein Schritt zurück.

void ADCC_Initialize(void)
{
   
    // set the ADCC to the options selected in the User Interface
    // ADDSEN disabled; ADGPOL digital_low; ADIPEN disabled; ADPPOL VSS; 
    ADCON1 = 0x00;
    // ADCRS 0; ADMD Basic_mode; ADACLR disabled; ADPSIS ADFLTR; 
    ADCON2 = 0x00;
    // ADCALC First derivative of Single measurement; ADTMD disabled; ADSOI ADGO not cleared; 
    ADCON3 = 0x00;
    // ADACT disabled; 
    ADACT = 0x00;
    // ADAOV ACC or ADERR not Overflowed; 
    ADSTAT = 0x00;
    // ADCS FOSC/128; 
    ADCLK = 0x3F;
    // ADNREF VSS; ADPREF VDD; 
    ADREF = 0x00;
    // ADCAP Additional uC disabled; 
    //ADCAP = 0x00;
    ADCAP = 0x1F; //Enable all PC-Caps??
    // ADPRE 0; 
    ADPRE = 0x00;
    // ADACQ 255; 
    ADACQ = 0xFF;
    // ADPCH ANA0; 
    ADPCH = 0x00;
    // ADRPT 0; 
    ADRPT = 0x00;
    // ADLTHL 0; 
    ADLTHL = 0x00;
    // ADLTHH 0; 
    ADLTHH = 0x00;
    // ADUTHL 0; 
    ADUTHL = 0x00;
    // ADUTHH 0; 
    ADUTHH = 0x00;
    // ADSTPTL 0; 
    ADSTPTL = 0x00;
    // ADSTPTH 0; 
    ADSTPTH = 0x00;
    
    // ADGO stop; ADFM right; ADON disabled; ADCONT disabled; ADCS FRC; 
    ADCON0 = 0x14;
    

}

bool ADCC_IsConversionDone()
{
    // Start the conversion
    return (!ADCON0bits.ADGO);
}

adc_result_t ADCC_GetConversionResult(void)
{
    // Return the result
    return ((ADRESH << 8) + ADRESL);
}

    //Returns the value of ADSTATbits.ADLTHR bit.
    return ADSTATbits.ADLTHR;
}

uint8_t ADCC_GetConversionStageStatus(void)
{
    //Returns the contents of ADSTATbits.ADSTAT field.
    return ADSTATbits.ADSTAT;
}

//Wird im 1ms zyklus aufgrufen, um wirklich 
//jegliches Prechargen abzuschließen

void proc_ADCC(void) {
    unsigned static char state = 0;
    
    switch (state) {
        case 0: 
            // select the A/D channel
            ADPCH = BAT_AN_IN;  
            state++;
            break;
        case 1: 
            // Turn on the ADC module
            ADCON0bits.ADON = 1;
            // Start the conversion
            ADCON0bits.ADGO = 1;
            state++;
            break;
        case 2: 
            if(ADCC_IsConversionDone()) {
                ADCON0bits.ADON = 0;
                adc_bat_an_in = ADCC_GetConversionResult();
                state=0;
            }   
    }
}

[Witkatz :. (wit)]

Jacko schrieb:
> Was ist an deiner Messung so Besonderes, dass sie 28
> unübersichtliche Funktionen braucht, statt 3...5?

Der MCC generiert nun mal ~28 Funktionen. Man könnte 
ADCC_GetSingleConversion() statt der kompletten Statemachine benutzen, 
aber das ist mehr oder weniger Kosmetik. Wichtiger wäre die Frage, ob 
ADCC_Initialize() aufgerufen wird.

Ich würde auch mit dem Scope auf die VDD und RA3 gegen beide Vss 
schauen. Und zwar nicht irgendwo in der Schaltung, sondern direkt an den 
Pins. Es kann ja auch z.B. eine kalte Lötstelle zwischen einem "saven" 
Signal und dem Pin liegen.
Und was hast du mit den unbeschalteten PINs gemacht?

[Achim S. (Gast)]

maschinell generierten Code zu debuggen ist immer ein besonderes 
Vergnügen. Vielleicht findest du einen simplen (menschenerzeugten) 
Beispielcode in einem Tutorial, den du ausbauen kannst.

Zu deinem aktuellen Code fällt mir beim groben Drüberschauen als 
mögliche Fehlerursache ein: hat deine Ergebnisvarible den richtigen 
Datentyp? Obwohl dein Codeschnipsel riesig ist sehe ich weder, wie 
adc_result_t noch wie adc_bat_an_in definiert sind.

[Cerberus (Gast)]

Dirk K. schrieb:
> Wenn da wirklich NUR ein Poti dran ist ->

So eine Behauptung hat keinen Aussagewert.
Wie genau ist das Poti den angeschlossen?

[Klaus (Gast)]

Nur so eine Frage: warum schaltest du den ADC dauernd an und aus? Da 
gibts doch bestimmt irgendwelche Empfehlungen, wie lange man nach dem 
Einschalten warten soll, bis sich der ADC stabilisiert hat. Ich hab auch 
keine Vorstellung, ob dein Precharge des Samplekondensators überhaupt 
zählt, wenn der ADC aus ist.

PIC-Besitzer schrieb im Beitrag #5100156:

>     switch (state) {
>         case 0:
>             // select the A/D channel
>             ADPCH = BAT_AN_IN;
>             state++;
>             break;
>         case 1:
>             // Turn on the ADC module
>             ADCON0bits.ADON = 1;
>             // Start the conversion
>             ADCON0bits.ADGO = 1;
>             state++;
>             break;
>         case 2:
>             if(ADCC_IsConversionDone()) {
>                 ADCON0bits.ADON = 0;
>                 adc_bat_an_in = ADCC_GetConversionResult();
>                 state=0;
>             }
>     }

Und zum ausprobieren muß man doch nicht so einen Aufriss machen:

    ADCON0bits.ADON = 1;  // eigentlich am Ende von init
    ADPCH = BAT_AN_IN;
    __delay_us(50);
    ADCON0bits.ADGO = 1;
    while(ADCON0bits.ADGO) {
       ;
    }
    adc_bat_an_in = (ADRESH << 8) | ADRESL;

Wenn das dann funktioniert, kann man sich damit beschäftigen das delay 
zu optimieren.

Mfg Klaus

[Witkatz :. (wit)]

PIC-Besitzer schrieb im Beitrag #5100156:
> //ADCAP = 0x00;
>     ADCAP = 0x1F; //Enable all PC-Caps??

Du schaltest den kapazitiven Spannungsteiler ein. Mach das mal aus.

Klaus schrieb:
> __delay_us(50);
>     ADCON0bits.ADGO = 1;
>     while(ADCON0bits.ADGO) {

__delay braucht er nicht wegen ADACQ = 0xFF; Das bewirkt eine 
automatische Acquisition Time in jedem Messzyklus, in dem Fall 433.5µs 
also mehr als ausreichend.

[Dirk K. (knobikocher)]

PIC-Besitzer schrieb im Beitrag #5100115:
> Wie willst du mir
> helfen, wenn du nicht Mal lesen kannst?

Lesen kann ich. Wie soll dir geholfen werden, wenn du keine Schaltpläne 
zeichnen kannst? Dort ist kein Poti eingezeichnet.

Siehe:

Cerberus schrieb:
> So eine Behauptung hat keinen Aussagewert.
> Wie genau ist das Poti den angeschlossen?

PIC-Besitzer schrieb im Beitrag #5100115:
> In zig Anwendungen mit alten
> Pics ohne Zusatzkomponenten gemacht. Notfalls Softwarefilter dahinter,
> mit dem ADCC Average Mode. Selbst ohne zuckt da vll das LSB. Wieso zig
> Kondensatoren auflöten? Machen kaum mehr Geräte - wenn auch aus
> Kostengründen.

Nyquist-Shannon-Abtasttheorem

PIC-Besitzer schrieb im Beitrag #5100115:
> Aber was will man erwarten, bei so ner sinnfreien
> Antwort.

Ab hier habe ich aufgehört zu lesen. Ich wünsche dir nicht viel Erfolg.

[Peter D. (peda)]

Man kann es mit der Funktionswut aber auch übertreiben.
So einen Code würde ich beim Review aber sowas von um die Ohren gehauen 
kriegen. Daß Dir da keiner helfen kann, verstehe ich.
Mach nen maximal 10-Zeiler ohne Unterfunktionen draus, damit das auch 
lesbar ist.

[Peter D. (peda)]

PIC-Besitzer schrieb im Beitrag #5098811:
> // Conversion finished, return the result
>     return ((ADRESH << 8) + ADRESL);

Den PIC kenne ich nicht, aber beim AVR muß man die Reihenfolge beachten 
und die ist in diesem Ausdruck unbestimmt. Das ist daher kein sauberes 
C.

Beim AVR gibt es neben ADCL und ADCH auch ADCW. ADCW ist 16Bit und der 
Compiler kümmert sich automatisch um den richtigen Zugriff.

[Klaus (Gast)]

Peter D. schrieb:
> Den PIC kenne ich nicht, aber beim AVR muß man die Reihenfolge beachten

Die Register ADRESH und ADRESL kannst du in beliebiger Reihenfolge und 
beliebig oft lesen, auf jeden Fall solange der ADC steht. Und das wird 
davor abgeprüft "while(ADCON0bits.ADGO)".

Dirk K. schrieb:
> Nyquist-Shannon-Abtasttheorem

Bei einem quasistationären Signal von einem Poti? Nyquist nicht 
verstanden, sondern nur mal aufgeschnappt, wenn sich Experten 
unterhalten?

MfG Klaus

[Witkatz :. (wit)]

Peter D. schrieb:
> Beim AVR gibt es neben ADCL und ADCH auch ADCW. ADCW ist 16Bit

Gibts bei XC8 auch: ADRES
In der PIC18F26K40.h definiert, die über xc.h automatisch includiert 
wird:

extern volatile unsigned short ADRES @ 0xF63;

[Dirk K. (knobikocher)]

Klaus schrieb:
> Bei einem quasistationären Signal von einem Poti? Nyquist nicht
> verstanden, sondern nur mal aufgeschnappt, wenn sich Experten
> unterhalten?
>
> MfG Klaus

Quasistationär? Woher die Annahme? Warst du bei ihm? Ansonsten: 
Glaskugel.

Vielleicht ist das Poti einfach viel zu hochohmig und er empfängt Radio. 
Leitungslänge zwischen Poti und ADC? Radio ist vielleicht auch für sein 
Oszi zu hochfrequent. Davon abgesehen, ist immer noch unklar, wie das 
angebliche Poti angeschlossen ist.

Aufgrund meiner Bildung bin ich ausreichend informiert über das Thema ;)

Ich hatte schon ein krass gestörten I²C Bus gehabt. Alles "richtig" 
angeschlossen. Im Signalverlauf waren trotzdem unerklärliche 
Pegelwechsel gewesen. Ursache war letztendlich ein GSM-Modem. Für das 
verwendete Oszi zu hochfrequent, es stellte nur den gestörten I²C Bus 
mit "rechteckigen" Signalen dar. Immer wenn der Sendeburst vom Modem 
kam, war der Pegel auf unter 1V. Scheinbar ;) Abhilfe war, die Leitungen 
mit entsprechendem LC Filter gegen hochfrequente Signale zu filtern. Ein 
einfaches Poti hat das, meines Wissens nach, nicht eingebaut.

[Klaus (Gast)]

Dirk K. schrieb:
> Quasistationär? Woher die Annahme? Warst du bei ihm? Ansonsten:
> Glaskugel.

Nein, ich kann mir aber vorstellen, wie schnell man ein Poti verstellen 
kann.

Dirk K. schrieb:
> Ich wünsche dir nicht viel Erfolg.

Darauf erspar ich mir einen Kommentar

MfG Klaus

[Dirk K. (knobikocher)]

Klaus schrieb:
> Nein, ich kann mir aber vorstellen, wie schnell man ein Poti verstellen
> kann.

Mir geht es nicht um die Eigenschaften eines Potentiometer an sich. 
Sondern um die möglichen Störungen. Z.B. durch hochohmigkeit. Oder durch 
falschen Anschluss. Oder durch falsche Speisung. Nirgends ist für uns 
nach zu vollziehen, wie das Ding angeschlossen ist.

Nur: hier ist ein unvollständiger Schaltplan, ich habe da mal etwas 
angeschlossen. Geht nicht wie erwartet.

Da sage ich als Hardware Entwickler halt: Schaltplan auf den korrekten 
Stand bringen, damit wir vollständige Informationen haben. Geht beim 
Code doch auch. Würdest du ihm helfen, wenn er nur Codeschnipsel zeigt?

Ok, so nett habe ich das nicht ausgedrückt. Schande über mein Haupt. 
Meine Mittagspause war kurz. Dennoch gehört es doch zur Netiquette, 
vollständige Information zu geben, oder irre ich mich?

Klaus schrieb:
> Darauf erspar ich mir einen Kommentar

Werde ich pampig angemacht, werde ich halt auch pampig.

Gute Nacht ihr Jäger der Elektronen

[Witkatz :. (wit)]

PIC-Besitzer schrieb im Beitrag #5100115:
> Jungs, was is mit euch los? Wollt ihr mir helfen, dann fragt / sagt was
> ihr wissen wollt / ich tun soll. Ich mache jede Messung, beantworte
> Fragen, alles. Aber was soll euer dämliches Geklugscheiße, in welchem
> ihr in keinem Satz helft?! Man man man...

Und bist du besser? Tauchst als anonymer Gast auf, forderst sofortige 
Hilfe an, beschwerst dich lautstark, und dann... auf konkrete Nachfragen 
erfahrener, hilfsbereiter Mitdiskutanten gehst du gar nicht ein. Nachdem 
viele Leute sich Zeit genommen haben und jede Menge sachlicher Hinweise 
erarbeitet haben tauchst du ohne ein Wort ab. Man man man...

[PIC-Besitzer (Gast)]

Hello,

zuerst entschuldigt die verspätete Antwort, ich war beruflich länger im 
Ausland. Zudem wollte ich erst eure Vorschläge abarbeiten, um mich dann 
wieder zu melden.

Fangen wir an:
@Dirk - sorry für meine zuerst raue Wortwahl. Aber wieso kann man nicht 
einfach gezielt Fragen stellen und nicht erst das zur Verfügung 
gestellte schlecht reden? Du willst wissen ob es hochohmig war? -> 
Antwort: Nein, es wurde mit 1k, 10k, 100k probiert. Willst du drei 
Schaltpläne? Es war NUR ein PIC und ein Poti.

Und das mit Nyquist war ja wohl ein schlechter Scherz ;)
Bzgl Radio: Selbst bei einem 100K oder gar MEG Poti müsste dann 
zumindest der niederohmige Potiteil stabile Signale liefern. Außer du 
sitzt auf dem Radiosender.

@Witzkatz, wie gesagt, sorry. Ich schreibe normal immer meine Lösungen 
rein.

... Wozu ich langsam komme ;)
Lustigerweise trat das Phänomen nicht mehr auf, als ich den Code für den 
ADCC mal selbst geschrieben habe. Sprich: Einfache 
Initialisierungsroutine, einfaches Basicsamplen. Ich habe dann über 
MCC/alten Code versucht, das Ganze wieder hinzukriegen bzw 
nachzustellen, aber das gelingt mir grad einfach nicht mehr. eventuell 
hat auch einfach ein anderes Modul reingefunkt, was ich währenddessen 
verändert habe. Fakt ist - vom 1k bis zum 100k Poti ist nun alles 
absolut fehlerfrei auslesbar. Danke dennoch für die Hinweise - manchmal 
sollte man dem MCC halt nicht trauen.

[S. R. (svenska)]

PIC-Besitzer schrieb im Beitrag #5111588:
> Lustigerweise trat das Phänomen nicht mehr auf, als ich den Code für den
> ADCC mal selbst geschrieben habe.

Für alle anderen kannst du ihn ja mal hier posten... dann hilft das auch 
anderen, die in die gleiche Falle tapsen.

[PIC-Besitzer (Gast)]

@S.R. mittlerweile ist es nun wieder MCC generiert (sagte ja - ich hab 
rumprobiert) und es geht auch damit ohne Probleme.

Ich vermute das Problem an ganz anderer Stelle in einem anderen 
Softwaremodul. Wenn ich die Tage Zeit habe, versuche ich mal über die 
MPLABX-History das Ganze nochmal nachzustellen, langsam finde ich es 
selbst interessant.

VG

[Dirk K. (knobikocher)]

PIC-Besitzer schrieb im Beitrag #5111588:
> Aber wieso kann man nicht
> einfach gezielt Fragen stellen und nicht erst das zur Verfügung
> gestellte schlecht reden?

Netiquette. Dazu gibt es hier auch einen Link, den ich gerade nicht 
finde :(

PIC-Besitzer schrieb im Beitrag #5111588:
> Nein, es wurde mit 1k, 10k, 100k probiert

Ok. Nicht besonders hochohmig. Was noch fehlt: wie wird das Poti 
gespeist? Woher kommen die 3,3V? Ich vermute: Versorgung des PIC. Mit 
kompletten Schaltplan müsste niemand vermuten. Da das Problem aber nicht 
mehr auftritt, ist ein Plan nicht mehr notwendig.

PIC-Besitzer schrieb im Beitrag #5111588:
> Und das mit Nyquist war ja wohl ein schlechter Scherz ;)
> Bzgl Radio: Selbst bei einem 100K oder gar MEG Poti müsste dann
> zumindest der niederohmige Potiteil stabile Signale liefern. Außer du
> sitzt auf dem Radiosender

Kein Scherz. Muss ja nicht Radio sein. WLAN, Bluetooth, GSM. Das alles 
steckt in deinem Smartphone und stört. Da das Problem aber nicht mehr 
auftritt, war dies wohl nicht die Ursache.


Bei jeder AD-Wandlung spielt Nyquist eine Rolle. Lässt sich nicht 
vermeiden. Wenn kein Filter am Eingang des ADC ist, werde ich deshalb 
aufmerksam und verweise auf des Thema. Eben weil ich diese Erfahrung 
schon im Negativen Sinne machen durfte ;)