• Locked Locked
  • Replies 16 replies
  • Subscribers 32 subscribers
  • Views 1509 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

PinMux, seriously? It is not intended as a joke?

Tmas
Prodigy 80 points
Other Parts Discussed in Thread: TM4C123GH6PM, LM339

While trying to get the analog comparator on a TM4C123GH6PM working I also tried PinMux 1.0.4 at some point in time. I didn't post that in the other thread http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/350179/1228037.aspx to not convolute that thread. But I think it deserves a mention. And not an honorable one.

Here is the output of what PinMux 1.0.4 generates as code to initiate comparator 1:

void
PortFunctionInit(void)
{
    //
    // Enable Peripheral Clocks 
    //
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_COMP1);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);

    //
    // Enable pin PC5 for COMP1 C1+
    //
    MAP_GPIOPinConfigure(GPIO_PC5_C1+);
    MAP_GPIOPinTypeComparator(GPIO_PORTC_BASE, GPIO_PIN_5);

    //
    // Enable pin PF1 for COMP1 C1O
    //
    MAP_GPIOPinConfigure(GPIO_PF1_C1O);
    MAP_GPIOPinTypeComparator(GPIO_PORTF_BASE, GPIO_PIN_1);

    //
    // Enable pin PC4 for COMP1 C1-
    //
    MAP_GPIOPinConfigure(GPIO_PC4_C1-);
    MAP_GPIOPinTypeComparator(GPIO_PORTC_BASE, GPIO_PIN_4);
}

Of the nine lines of code at least four are wrong! 44%, and that is not counting what is missing. I mean, seriously? Is that supposed to be a professional tool?

One doesn't even need to try to compile it. Any mediocre C programmer immediately recognizes this. How could that PinMux tool manage to escape into the wild?

  • TI__Guru**** 244400 points

    Hello Tmas,

    Thanks for bringing this up and providing valuable feedback on the same. But as I would see it there are 3 lines which are not correct.

    Regards

    Amit

  • in reply to Amit Ashara
    Prodigy 80 points 
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_COMP1);

    1 - Wrong, as we have just learned there is no such module 1. And the macro is gone in 2.1, so it does not compile.

    MAP_GPIOPinConfigure(GPIO_PC5_C1+);

    2 - Wrong, illegal macro name, can't compile.

    MAP_GPIOPinTypeComparator(GPIO_PORTF_BASE, GPIO_PIN_1);

    3 - Wrong. GPIOPinTypeComparator sets the pins to input, but PF1 needs to be an output. Here is the code from TivaWare 2.1:

    void
GPIOPinTypeComparator(uint32_t ui32Port, uint8_t ui8Pins)
{
    //
    // Check the arguments.
    //
    ASSERT(_GPIOBaseValid(ui32Port));

    //
    // Make the pin(s) be inputs.
    //
    GPIODirModeSet(ui32Port, ui8Pins, GPIO_DIR_MODE_IN);

    //
    // Set the pad(s) for analog operation.
    //
    GPIOPadConfigSet(ui32Port, ui8Pins, GPIO_STRENGTH_2MA,
                     GPIO_PIN_TYPE_ANALOG);
}

    That still leaves the question open of what to do to get PF1 to work as comparator output and how to do the magic with TivaWare. 

     MAP_GPIOPinConfigure(GPIO_PC4_C1-);

    4 - Wrong, illegal macro name, can't compile.

  • in reply to Tmas
    Guru 117855 points

    You'll not like this - but I looked closely at your original code listings - and they were "near identical" (but for the handling of comparator output) to code we used under StellarisWare (9453) and indeed our analog comparator did and does work!

    Indeed the manuals need more (i.e. some) work to clarify the (newly added) comparator function.  Here's how we (successfully) got our Analog Comparator Output to function:  (note this on an LX4F device - and we only use StellarisWare - as insisted by key clients)

    ROM_GPIOPinConfigure(GPIO_PF0_C0O); //  Comp Output   *** note we harvested Comp_0 - you Comp_1...

    Note that PF0 contains a notorious (but "duly noted") pitfall - new or non-detail observant users always fall victim!  We had a strategic reason to choose PF0 - it being just 2 MCU pins removed from our PWM_Fault_Input pin.

    We could find no corresponding GPIOPinType() for Analog Comparator Output - the above is all we did.  We had long used an LM339 (jellybean) comparator - our MCU's performance matches that of the LM339 - while saving space/cost...

    Give this a try - we scratched our heads but w/over 1K boards in the field - our comparator works nicely and "kills" 3 channels of PWM upon each/every "over-current" transient detection...  (managed entirely by MCU's ana. comp.)

  • in reply to cb1_mobile
    Prodigy 80 points

    cb1_mobile said:
    You'll not like this - but I looked closely at your original code listings - and they were "near identical" (but for the handling of comparator output) to code we used under StellarisWare (9453) and indeed our analog comparator did and does work!

    Oh, I believe you and trust you very well.

    But I am rapidly losing trust in TI, and I have to make a decision really soon.

    Broken libraries, mysterious behavior, incomplete, misleading documentation, some of it oozing arrogance, e.g. spma043, code that doesn't make sense, do not instill trust in TI at all. Oh, and broken tools - and it really doesn't matter if it generates just 44% or "only" 33% wrong code. Especially not if it is advertised as, according to the build-in help

    Product Features and Benefits

    ...

    - Error free code, the first time.

    But was apparently written by the summer intern without any proper supervision.

    Yes, I am running out of patience with TI. I mean, we are talking about a very simple periphery. And they can't even get that right.

  • in reply to Tmas
    Guru 117855 points

    Feel your pain - I do.  Yet - having past worked at a large semi-firm - so much data is generated that such, "hopeful excesses" happen at all such firms - repeatedly!  The "announced" business goal of many (most?) such firms is to, "Outperform their market."  Data perfection may be unobtainable - thus not blip the radar...

    You/I seek more than the 1K+ pages resident w/in MCU manuals.  Many others do not. 

    Perfection - this time - this planet - may not be a reasonable goal.  (Others/I may do our small parts here to assist)

    Factory support for this/allied space is top cabin.  People here are skilled, caring.  (in contrast - other sites we visit "boast" of their, "near-zero" factory "intrusion."  (maddening)

    Analog comparator in question was one of the last (possibly the last) peripherals introduced to LX4F and rebrand MCUs.  As such - it's reasonable to suspect that, "Marketing's screams" cut into the time allocated for Analog Comparator's detailing.  As you note - focused Ana. Comp. data is sparse.

    All said - I bet that you/Amit & I can bring your Ana. Comp. to full life.  (I have provided our, "trial & error" method of achieving the Comparator Output config. you requested...) 

  • in reply to Tmas
    Guru 27665 points

    Tmas said:
    But was apparently written by the summer intern without any proper supervision.

    Having worked with multiple manufacturer's micros over too many years I would simply call that industry standard practice.

    I haven't even been tempted to try the Pinmux utility.  My experience has been that such manufacturer's utilities are worth considerably less than you pay for them.

    Robert

  • in reply to Robert Adsett
    Expert 2355 points

    Hi Robert,

    I'm smiling as I'm sure you know it's free!

    In all seriousness, I benefited from the pinmux utility to pin-out the device, but was never even tempted to use the code-output feature.

    Regards,

    Dave

  • in reply to SourceTwo
    Guru 27665 points

    SourceTwo said:

    I'm smiling as I'm sure you know it's free!

    Yep, as were all the other tools I was referencing.

    Cynicism, thy name is experience.

    Robert

     

  • in reply to Robert Adsett
    Prodigy 80 points

    Well, I don't see anything wrong with trying to "ask" a tool for a "third opinion" if the documentation lets you down and studying the library source code also doesn't really help.

  • in reply to Tmas
    Guru 27665 points

    @Tmas, In my experience you either get the tool agreeing with the bad example code or providing a third and wrong alternative.

    The TIVAWare source appears to largely buck the trend of the examples always being wrong.  I'd still trust the hardware guides over either TIVAWare or the helpful tools.

    Robert

  • in reply to Robert Adsett
    Guru 47900 points

    One notes the (hapless) Pin Mux Tool has made no attempt to defend itself...

  • in reply to cb1
    Guru 27665 points

    No doubt warming itself by it's few remaining matches as it watches the revelers stroll past.

     

    Not really seasonal I know.

    Robert

  • in reply to Robert Adsett
    Guru 47900 points

    Robert Adsett said:
    warming itself by it's few remaining matches

    One hopes a few of those (remaining matches) are available for a, "real LAUNCH" - 4 days out!   (i.e. USA's July 4)

    And that meets seasonal requirement...

  • in reply to cb1
    Guru 27665 points

    That'll be a little late for some of us ;)

  • in reply to cb1
    Prodigy 80 points

    The pin mux tool is certainly allowed to step forward and explain itself.

    And if a programmer of that tool wants to step forward I will happily explain a few common and standard software development practices.

    And should the manager who is responsible for the development and release of that tool dare to step forward. Uhm, can you hand me some matches, please ...

  • in reply to Tmas
    Guru 47900 points

    Pin Mux Tool last seen (I'm told) on CA:405 - heading north - at low speed - followed by multiple squad cars/TV choppers...  (or was that some other "suspect?")

    AC (Al Cowlings) unavailable for comment...