This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSPM0G3507: Porting GRLib for Kentec touchscreen

Part Number: MSPM0G3507
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

I am porting GRLib for the Kentec from the MSP432Pr01R to the MSPM0G3507

I understand that most of the setup needs to take place in syscfg, so that is not a problem. However, to read the touchscreen the program goes through gyrations like this:

/* Set X+ and X- as output and Y- as input (floating). */
    MAP_GPIO_setAsOutputPin(TOUCH_X_PLUS_PORT, TOUCH_X_PLUS_PIN);
    MAP_GPIO_setAsOutputPin(TOUCH_X_MINUS_PORT, TOUCH_X_MINUS_PIN);
    MAP_GPIO_setAsInputPin(TOUCH_Y_MINUS_PORT, TOUCH_Y_MINUS_PIN);

    /* Set X+ high and X- low. */
    MAP_GPIO_setOutputHighOnPin(TOUCH_X_PLUS_PORT, TOUCH_X_PLUS_PIN);
    MAP_GPIO_setOutputLowOnPin(TOUCH_X_MINUS_PORT, TOUCH_X_MINUS_PIN);

    /* Sample the Y+ ADC channel. */
    MAP_GPIO_setAsPeripheralModuleFunctionOutputPin(TOUCH_Y_PLUS_PORT,
                                                    TOUCH_Y_PLUS_PIN,
                                                    GPIO_TERTIARY_MODULE_FUNCTION);
    MAP_ADC14_clearInterruptFlag(TOUCH_X_PLUS_IFG | TOUCH_Y_PLUS_IFG);
    MAP_ADC14_disableConversion();
    MAP_ADC14_configureSingleSampleMode(TOUCH_Y_PLUS_MEMORY, false);
    MAP_ADC14_enableConversion();

    for(i = 0; i < TOUCH_OVERSAMPLE; i++)
    {
        MAP_ADC14_toggleConversionTrigger();
        status = MAP_ADC14_getInterruptStatus();
        while(status != TOUCH_Y_PLUS_IFG)
        {
            status = MAP_ADC14_getInterruptStatus();
        }
        average += ADC14->MEM[0];
    }

    /* Return the analog result. */
    average = (average >> TOUCH_AVERAGE_DIVISOR);
    return(average);

Measuring Y is the same, put voltage on the Y pins and measure the X pin.

Should I just do the same sort of thing? Will I get a settings conflict if I try to set up a GPIO pin at the same time as the ADC pin?

  • Hi Keith,

    Do you just mean to ask if you will run into issues jumping between the ADC function for a pin, and the GPIO function?

    The above snippet looks fine to me, so if measuring Y is done sequentially, after the above snippet, I see no issues.

    If you mean that you will need to interleave measuring X and Y in the same code, then you will run into issues trying to assign multiple pin functions to a singular pin at a time. At that point, your options are to switch to a sequential method, or to rapidly change the pin function between GPIO and ADC. In Sysconfig you'll need to initialize as one, and then in the application code you'll need to manually initialize the ADC channel, then switch pin functions during run time.

  • The above snippet is for the MSP432P401R. These functions don't really exist in the MSPM0G3507 Simplelink.

    It has to be done sequentially since the x and y interact.

    That is the problem with sysconfig, there are no examples on how to set things like the ADC up, I guess I can dive into the C code that sysconfig creates and copy it.

  • Ah I see.

    Re-reading the snippet, most of these functions should have MSPM0 counterparts, like setAsOutputPin, setAsInputPin, setOutputHighOnPin, set low, set as peripheral function, disable and enable conversion. Configuring the sample mode works a bit different but we still have a function for that. Toggling the conversion trigger would likely take a bit more. The enable interrupts and read status certainly has a counterpart.

    For having no examples for how to set something like ADC up, you just mean when you need to set up the ADC outside of Sysconfig, in the application code? If so, I do agree in a way, but typically I just set the peripheral up how I need in sysconfig, then copy over the generated code into the application code and then remove it from Sysconfig as you've mentioned. 

    That is helpful feedback, I figured that the above process would be typical for many of our customers. Is the view for the generated code just not easy enough to interact with? Or is it just that the different and admittedly kind of weird steps of having sysconfig generate it, then you copy it and move it are unusual? Do you have something in mind that would make that process better, aside from reverting to the former method of example codes that manually initialize everything?

  • I don't know, that is why I am asking. 8^)

    I have already found a bug in the auto generated code for the timers.

    I would just leave the sysconfig code as is - after all it will get regenerated every time I make a change - and make manual changes as needed.

    My problem is that the Resource Explorer DriverLib docs are really unfriendly. I much prefer the pdf version.

    Can I just set up the ADC and leave it? My reading of the I/O diagram is that it is pretty much independent of the GPIO, that is why I was asking about sysconfig conflicts. I figured, I would set the ADC up, and set the GPIO to High-Z to read the ADC.

  • Ah okay I think I see now.

    Could you please let us know what the bug you've noticed is, either here or in a separate thread? That way we can make sure we address it.

    As for the original issue, you will get an error trying to configure one pin as both an ADC input and as a GPIO in Sysconfig. So the way I'd recommend getting around this is to configure one of them in Sysconfig and copy the generated initialization code, then paste it into your application. Then remove that portion from Sysconfig, and initialize your other functionality. You could also copy paste this generated code into a helper function in your application code to make it as easy as possible to switch between initializations. Then in your application code you'll need to re-initialize the pin function when you want to switch. At least this is how I would do it. You could also manually create the initialization functions to implement in your code.

    You could initialize the ADC and GPIO in Sysconfig, the only problem is that you will need to choose a pin for both, and once you choose the same pin for both you will hit a resource conflict. A workaround might be to initialize the ADC to use a different pin and then switch it and complete the initialization later in your application code when you need to change that pin to use the ADC. This would probably look a bit messy though.

    Agreed that the Driverlib API guide in resource explorer is not super user friendly. Honestly I just read through the source code and it feels easier to read that the API guide. Maybe that is something we need to brainstorm on how to improve.