PinMux Tool Cloud: Suggestions for Improvement

I haven't confirmed, but also a colleague told me a couple of days ago that the JTAG-only pins are not shown in PinMux?

twelve12pm said:

Two suggestions to improve PinMux tool

Have, "Liked" your idea - yet might it too - be improved?

My group must choose devices from across the (entire) ARM MCU landscape - not just the (sole) Cortex M4 ones - resident here.    Clients "demand & expect" that our small firm will stay "active - up to date" and be able to choose from a large "pool" of candidate devices.      Note that many/most (other) MCU vendors provide similar, "Selection Aids."

The "Compare/Contrast" of Multiple MCUs - expanded to include Multiple Vendors - appears to offer (even) higher, more compelling value.

As no individual vendor tool provides this level of (needed) accommodation - might a "Spreadsheet Program" - capturing data (as much & as easily as possible) from (individual vendor selection tools) fill this (currently) "Unmet Compare/Contrast" gap?     We have started such effort - and noted (immediately) that almost always - vendors sequence their data differently - and do not "fill their lists" with great consistency.

Firm/I believe a disservice is done - when designers/developers limit their investigation - to Just ONE vendor!"      Can the expectation - that one vendor - at all times - will have the best: "Feature sets, Performance, Device Variety (M0, M3, M4, M7 etc.) Development Aids, Availability and Price" (ever) hold true?      Has not a full/proper "search" been avoided - thus compromised?

Use of Excel (or other spreadsheet program) appears the best & fastest means to achieve your goal - and possibly extend/expand it!       Especially if one "buys into" the fact that "one and only one" vendor source promotes "familiarity/ease" over the (more important) "widening" (oft demanded of any "real" investigation!)

cb1_mobile said:

Have, "Liked" your idea - yet might it too - be improved?

Your idea sounds great and could be expanded much further to a full-fledged cloud-based crowdsourced website... But that's a big undertaking and all I wanted was two small improvements in PinMux to display the part number and allow changing it after peripheral pins have already been activated, to aid in specifying parts for new designs, or perhaps for migrating from one part to another.

Hi,

Acknowledge that there is room for improvements.

May I ask which MCU device you are using the pinmux tool for?

I just used the cloud-based Pinmux tool for TM4C129. Please see below screen capture. I confirm the upper right the device name but not the actual part number.  However, I don't see how the tool can save the work that you entered for one experiment (a given part number, i.e. 128QFP package) and be reused in another new experiment (another part number, i.e. 212BGA package). The package layout, pin layout are completely different. A same signal name may be mapped to pin x in a 128QFP packaged while mapped to something like B8 in a BGA package. I don't think the meta file saved for each package type is compatible to a different package type. 

Please note the .csv file is also generated that you can maintain in excel. 

Charles Tsai said:

Please note the .csv file is also generated that you can maintain in excel. 

And - that ".csv file" often occurs w/in (similar) APPS of (other) MCU vendors.     (as our opening post noted.)

Vendor's Charles and my firm (both) have found - and appear to agree - that such comparisons must be (somewhat) initially focused.     Package type/size - thus far - appears most successful.

And again - multiple vendor device inclusion - yields a "far richer, vastly more expansive/capable" search/compare/contrast user experience!

Poster's "all i wanted" claim is unlikely to withstand, "Test of Time" - especially as the ARM Cortex field includes SO MANY - w/multiple class devices: (M0, M3, M4, M7 etc.)

I can confirm JTAG-only pins were not shown when configuring Tiva-C TM4C123AH6PM.

Charles Tsai said:

However, I don't see how the tool can save the work that you entered for one experiment (a given part number, i.e. 128QFP package) and be reused in another new experiment (another part number, i.e. 212BGA package). The package layout, pin layout are completely different. A same signal name may be mapped to pin x in a 128QFP packaged while mapped to something like B8 in a BGA package. I don't think the meta file saved for each package type is compatible to a different package type. 

Pins already mapped could perhaps become "any" pins when the part number is changed.

A Q related to this, but perhaps hovering at only 10k feet?
With my first foray into PinMUX, I'd hoped to use it to test my thinking on connecting an SPI device to a EK-TM4C129EXL board...
( Think we've got wiring correct using just the BoosterPack pin diagram, but... )
Isn't this the kind of thing PinMux should be exactly good at? I don't see any selection available at all for SPI.
This is a learning experience. Please set me straight if I've got it all wrong.