10 years, 1 month ago.

Apparent conflict between USRT and TSI modules (maybe ADC?)

Hello,

I believe this one is tough, and directed to the people who take care of the mbed basic library.

Some days ago I have posted a low-level TSI library, it can be found at:

https://mbed.org/users/quevedo/code/TSIHW/

I have tested that with TSI channel 5, and it worked perfectly. Now I am extending it for more sensors, and I have found a problem. I have a shield board with electrodes on TSI channels 5, 13, 14, and 15. I created a program to initialize all 4 pins (this part is OK), and then read 100 scans for each electrode to average them and get a baseline. Then, I started scanning all 4 electrodes, to get the values and control the onboard RGB LED .

I run the program, and it did not work. Then, I decided to place PRINTFs on strategic points in the program to see what was going on. Strangely, it started working! Then I noticed that if I removed any printf (from baseline routine or scan routine), the program stopped at that point.

The only exception was exactly for channel 5, I can remove any printf before or after the scan and the program keeps running. I noticed that the corresponding pin (PTA4) is MUXed for the specific TSI function. The other 3 electrodes (PTC0, PTC1, and PTC2) are MUXed for TSI or ADC.

So, now I am stuck. I have no idea on why using printf after each scan avoids the program to lock on the next scan, and why it happens to the electrodes who share the function with ADC.

Below is the whole code, with all the PRINTFs.

Cheers,

Antonio

Low-level TSI test

#include "mbed.h"
#include "TSIHW.h"

TSI touch(0,0,0,2,2);
DigitalOut lr(PTB18);
DigitalOut lg(PTB19);
DigitalOut lb(PTD1);

uint16_t b1, b2, b3, b4, s1, s2, s3, s4;

void GetBase() {
    int t1, t2, t3, t4;
    char k;
    uint16_t t;
    
    t1 = 0;
    t2 = 0;
    t3 = 0;
    t4 = 0;
    for(k = 0; k < 100; k++) {
        t = 0;
        printf("Baseline 1\r\n"); // THIS PRINTF CAN BE REMOVED WITHOUT PROBLEMS
        touch.Start(5);
        while(!t) {
            t = touch.Read();
        }
        t1 = t1 + t;
        t = 0;
        printf("Baseline 2\r\n");
        touch.Start(13);
        while(!t) {
            t = touch.Read();
        }
        t2 = t2 + t;
        t = 0;
        printf("Baseline 3\r\n");
        touch.Start(15);
        while(!t) {
            t = touch.Read();
        }
        t3 = t3 + t;
        t = 0;
        printf("Baseline 4\r\n");
        touch.Start(14);
        while(!t) {
            t = touch.Read();
        }
        t4 = t4 + t;
    }
    b1 = t1 / 90;
    b2 = t2 / 90;
    b3 = t3 / 90;
    b4 = t4 / 90;
}

void Check() {
    s1 = 0;
    printf("Sensor 1\r\n"); // THIS PRINTF CAN BE REMOVED WITHOUT PROBLEMS
    touch.Start(5);
    while(!s1) {
        s1 = touch.Read();
    }
    s2 = 0;
    printf("Sensor 2\r\n");
    touch.Start(13);
    while(!s2) {
        s2 = touch.Read();
    }
    s3 = 0;
    printf("Sensor 3\r\n");
    touch.Start(15);
    while(!s3) {
        s3 = touch.Read();
    }
    s4 = 0;
    printf("Sensor 4\r\n");
    touch.Start(14);
    while(!s4) {
        s4 = touch.Read();
    }
}

int main() {
    lr = 1;
    lg = 1;
    lb = 1;
    
    touch.ActivateChannel(5); // OK button
    touch.ActivateChannel(13); // LEFT button
    touch.ActivateChannel(14); // RIGHT button
    touch.ActivateChannel(15); // CANCEL button
    
    GetBase();
        
    printf("BASELINES: %d, %d, %d, %d\r\n", b1, b2, b3, b4);
    while(1) {
        Check();
        printf("SIGNALS: %d, %d, %d, %d\r\n", s1, s2, s3, s4);
        if(s1 > b1) {
            lr = 0;
        } else {
            lr = 1;
        }
        
        if(s2 > b2) {
            lg = 0;
        } else {
            lg = 1;
        }
        
        if(s3 > b3) {
            lb = 0;
        } else {
            lb = 1;
        }
                
        wait(0.3);
    }
}

I don't see a reason why the UART has an effect on TSI.

Regarding your lib, using the pin_function() function, and possibly also PinMap structures it might work easier/clearer. That said it shouldn't affect your program. What if you replace your printfs with wait statements? And/Or using LEDs to show the state and figure out where it hangs.

posted by Erik - 26 Sep 2014

Haven't looked at your code, just writing from experience.

There are timing constraints when using TSI. I faced them couple of times. You an even find some delays in the TSS library (the code which is open). I dont think it's related to uart anyhow. ADC and TSI using the same mux (analog which is 0).

Your code is hard to read. those hardcoded 32bit values are hard to identify what they do. Have you thought about using interrupts?

posted by Martin Kojtal 26 Sep 2014

Martin's consiousness is uploaded to the mbed servers, thats why he is aware of your code without having looked at it :P

posted by Erik - 26 Sep 2014

Hello,

I will try and reply all thoughts with this message.

I may use pin_function() and PinMap in future versions. Erik, you were right, the problem was not with printf, but with delays. I have changed all printf statements for wait_us(5), and it works nicely. The 5us value was found empirically.

As for interrupts, I intend to implement them in the future also.

Cheers,

Antonio

posted by Antonio Quevedo 29 Sep 2014

1 Answer

10 years, 1 month ago.

Great, delays solved it.

Regards,
0xc0170