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.

Why are pins connected on EK-LM4F120XL ?

While reading the documentation for the launchpad, I came across this note:

a. J2.06 (PB7) is also connected via 0-Ω resistor to J3.04 (PD1).
b. J2.07 (PB6) is also connected via 0-Ω resistor to J3.03 (PD0).

Does anybody know why these pins were connected together? I am working on a booster pack and noticed that these pins can have conflicting SSI definitions depending on the port used.

Thanks

Henry

  • Hi Henry,

    It is for backward compatibility with MSP430 Launchpad. If you need those pins, you can desolder R9 and R10 (0 ohm resistors) from the board so that they are independent.

    Best regards,

    -Caner

  • @ Caner-

    What a great "get" - would have never thought of that! 

    However - does your answer imply (or suggest) that many/most of the Stellaris launchpad connector pins "match" those of the MSP430 launchpad?

    For ease of use - my team would have preferred key functions (i.e. SPI, I2C, CAN, UART, 8 bit Data Bus) to route to successive pins - on the same edge connector.  This seems not to be the case - thus "matching" an old convention brings along past limitations...

  • CB:

    I noticed the same thing. It makes it very difficult to mount a simple plug -- instead one must put individual single wire pins on units.

    It would be in the interest of TI to develop a "board standard" and bring out at least I2C, and SSI/SPI to connectors in the same way -- every time -- complete with GND and 3.3V and +5V for power to sensors.

    An alternative would be someone like yourself to produce a "screw terminal" board for connecting up sensors for quick prototyping -- with room for adds on and additional prototyping. Those boards are easy to find in the Arduino world and non-existant in this world. It's something you would think would be obvious...

    Also, simple breakout boards for TI temperature sensors, gyros, ADC chips Accelerometers etc would be welcome -- companies who do produce these produce simple boards with the necessary minimal components in the $10 to $20 range.

    Atmel has finally caught on and is producing simple boards with SSI and I2C that connect up to these same jacks on the boards -- it makes for very fast ans simple testing and prototyping with the simpler components.

    The awkward connector sequencing on the Launchpad series -- and indeed all others make this a serious pain for prototyping. Only my EK-LM3S811 can have pins soldered in and be popped into a breadboard -- the rest require spinning a new board.

    Where is the marketing department? Oh right... marketing the M3...

  • @Arctic-Dave,

    Great minds - mon ami - great minds...

    Launchpad likely designed for "ease of use" of layout guys - no thought for poor users!   However TI not alone in such - similar eval boards (even $7.99 M0) boards guilty as you've charged! 

    Your addition of necessity for 5V, 3V3 and ground (which I missed) should be included with each/every "logical" signal grouping.  In this manner - a single connector interface can serve double, triple (or higher) duty - time can be spent on a SW solution rather than insane hardware complications - brought about by too little thought/planning...

  • I will go further...

    There are two standards -- one for the MSP430 -- a new double row of pins for the C2000 and the Launchpad -- and others. All boards had differing number of rows and connector lengths -- with little thought as to signal grouping.

    The Double Row Connectors -- with feed through style of pins and a socket -- so that boards can be stacked -- is like Arduino -- that's good... But the connectors are "Special Order" -- dumb and dumber...

    Maybe less time should be spent on cancelling products and more time spent on "real" design -- as opposed to throwing products over the wall.

  • This forced interconnect - seemingly without any redeeming value - bothered me.  Like you - I reviewed the various signals available @ each pin - did not like what revealed.  At the minimum - it appears that the 0-ohm jumpers cost you two pins of functionality.  And - beyond that - if jumpers remain you must insure that if one jumped pin is used as an output - the other stays input/hi-Z. 

    W/in User Guide - pg. 20 - schematic appears to report that all 4 pins "uniquely" make it to headers.  (PB6,7 to J2; PD0,1 to J3) 

    For your purposes - suppose it best to remove "offending" 0-ohm R9 & R10 - and then confirm that all 4 pins "make it" (uniquely) to headers. 

    For those using this Stellaris Launchpad - you cannot use PB6, PB7 and PD0, PD1 - without potential difficulty - until you remove 0-ohm jumpers R9, R10 - which tie these pairs together.  (PD0 - PB6, PD1 - PB7)

     

  • I would like to take the opportunity to confirm and clarify some of what has been posted here.

    We understand that the zero ohm jumpers are not best for everyone. Where compromise had to be made we included the zero ohm's so that the default solution would be more robust than easily removed jumpers and could still easily be removed by those wanting different function.

    In creating Launchpads a company wide decision was made to create an interface standard based on the existing MPS430 launchpad.  That interface was developed as a simple fan-out of the MSP430 pins prior to anyone conceiving that it would take off (pardon the pun) as well as it did.  By the time Stellaris and C2000 decided to create launchpad's nearly 200,000 MSP LaunchPads were already with customers.  There is also the resulting 3rd party eco-system of BoosterPacks which we decided to support.

    Had we started from scratch, different decisions may have been made.  Given the pre-existing MSP430 LaunchPad environment it was discussed, debated and concluded that the best decision was not to discard the MSP430 LaunchPad foundation of users and BoosterPacks.

    The outer two rows of pins on all three launchpads are functionally equivalent per the standard. For more information see the BoosterPack design guidelines http://processors.wiki.ti.com/index.php/BoosterPack_Design_Guide. The inner rows are intentionally specified in the standard more vaguely to allow each MCU family flexibility to showcase its strengths.

    In the specific case of J2.06 and J2.07 the MSP has an serial module which presents an I2C and SPI interface on those pins.  The Stellaris and C2000 do not have a single MCU pin that can provide both of these alternate functions in the same way as the MSP430.  Therefore, the SPI function which is considered primary by most MSP BoosterPacks was connected directly, the zero ohm brings in the I2C functions for more complete pin level functional compatibility.  As previously suggested, either function can be used without modification by making certain that the unused MCU pins are configured as GPIO inputs. To use both SPI and I2C remove the zero ohm by de-solder or cutting.  However, also look at the pin mux options of the Stellaris, you will find that we have 4 I2C modules and 4 SPI modules which are pin muxed to a variety of locations.  Chances are high that a different combination of these modules and MCU pin mux will resolve the pin conflict.

    We apologize for the confusion and hope that this clarifies the situation and provides some understanding as to why we chose the pins as we did.

    Dexter

  • That still does not address the issue of why I2C and SPI connectors -- for example were not provided. It seems a simple add on...

    My workbench is a mess with trying to stick pins in the connector, balance the board on the edge and run cables to a breadboard and to displays and sensors...

    Also -- you did not address why feed through pin/plug connectors are not easily available -- I gave up on this issue. I can order enough for a manufacturing run (for my one board? yeah right!) -- but not one connector.

    Perhaps those issues are UN-adressable -- so I will not hold you to answering.

  • Agree connection blocks that are function specific are useful.  I will make the case for these on the next board.  On this board the idea was to use the existing pinout standard and enable folks to create BoosterPacks. Also to keep the board as simple, small and low cost as possible to enable a wider customer base.  The focus was not as heavy on wire wrap style protos.  That said, a BoosterPack that brings out from our LaunchPad connector and creates several different serial interface function blocks for easy wire wrap style protos would be a great addition to the ecosystem.  Also MikroElectronica has an adapter from our LaunchPad pins to their clik boards which have several very useful modules for prototyping.

    I acquired sample quantities of the feed through connector via the Samtec sample system for the prototype builds and evaluation of the early systems.  Samtec generally has a good sample system and can provide small quantities at little or no cost.

    Dexter

    Dexter

  • Stellaris Dexter:

    I wonder how they would feel about 2000, or 3 or 5 or 10,000 people requesting same? Not from TI, but from students or impecunious developers like me.

    Do you think they would take you off their Christmas Card list? I think so...

    I am well aware of Samtec -- I thought about it -- and did not even try... I would have a special bin for all those requests if I managed the sample program at Samtec.

    Perhaps a "package" of connectors when one introduces a launchpad -- surely the uptake is predictable -- or else arrange for Sametc to become part of the program and have those connectors in stock and readily available.

    I don't want to belabour this any more as surely some of these points are obvious. (???)

    The Mikroe Launchpad extender was not a great effort -- bare minimum -- no connector for external power with 3.3V regulators and 5V regulators for clean power -- no screw terminals or ability to add... Their larger effort with plug-in for many controllers was much better thought out. The small extender was to sell their Click boards -- carefully conceived for same and offers nothing more.. good for them -- not good for more than that.

    The LM4F232 was much better done -- not that I have one... and unlikely will now...

    The Make Controller V2 -- as another example was well thought out. Ardfuino had more and better thought put into it's marketing and development -- and the large community is evidence of same...

    Again, perhaps vendors should be brought in much earlier with a list of suggested add-ons so that when it's launched -- it can take-off -- not fizzle or limp.

    I suspect that users like me, CB and Andy Neil (though not necessarily us) might be pleased to do quick reviews for an alpha design -- which would lead easier use and greater sales in the short and the long run. We might even suggest packagaing more of your sensors, op amps and other add-ons for quick evaluation... just a thought...

    I expect the extras costs would be minimal on your scale -- but even if the price doubled to $25 -- would that be a problem? Or if ther were two or three versions?

    Enough of this -- take what suggestions you will and ignore the rest...

  • Stellaris Dexter said:
    Agree connection blocks that are function specific are useful.  I will make the case for these on the next board

    Rather than re-invent the wheel, perhaps you could adopt this:

      

    http://en.wikipedia.org/wiki/UEXT

    https://www.olimex.com/Products/Modules/UEXT/

    One gripe with that: there is no (specific) providion for the common "interrupt" line to accompany SPI or I2C...

     Edit:

    I should note here that I am in no way connected to Olimex, and this post is neither sponsored nor endorsed by them.

  • Dave Robinson said:
    I don't want to belabour this any more

    OK - so I will...!

    Dave Robinson said:
    surely some of these points are obvious. (???)

    You would have thought so, wouldn't you?!

    I had the same problem with some of TI's little RF and MSP430 boards: they came with tiny little headers, and it was very difficult to find specs or part numbers for the mating parts!

    Dave Robinson said:
    Perhaps a "package" of connectors when one introduces a launchpad

    Excellent idea!

    Or, at least, for each launchpad/devkit/etc, have a listing of "accessories" - orderable via the TI Store - to include all mating connectors.

    Dave Robinson said:
    We might even suggest packagaing more of your sensors, op amps and other add-ons for quick evaluation

    Indeed we might!

    We might also note that certain competitors are already doing this...

    But we're well off-topic from Stellaris now - these are general issues...

  • Thanks Andy -- hugs and kisses for taking up the fight. :-) roflmao

  • Stellaris Dexter said:
    We understand that the zero ohm jumpers are not best for everyone. Where compromise had to be made we included the zero ohm's so that the default solution would be more robust than easily removed jumpers and could still easily be removed by those wanting different function.

    As an alternate solution, how difficult is it to design new microcontrollers with a more flexible port maping function in the silicon?

    I am thinking along the lines of the Port Mapping Controller in the CC430F513x series. E.g. in the case where the UART Tx/Rx lines were swapped externally w.r.t. the default mapping I was able to correct the error just by changing the Port Mapping Controller.

    (I know this is an old thread, but found it why trying to figure out the reason for R9 and R10 which was preventing me from using all 4 SSI ports on the Stellaris Launchpad)

  • Chester,

    How difficult is a subjective question that i cannot really answer.  One of the challenges with LaunchPad was that we had a Stellaris GPIO system designed by Luminary Micro (prior to TI acquisition) and MSP430 GPIO system designed by TI.

    Moving forward as TI continues to grow and expand our MCU lineup i expect more design similarities and sharing across the company.  This will mean less need for the jumpers in future LaunchPads.  It will however likely take several generations of product as we balance the sharing with risk of integrating different IP into systems for which they were not originally designed.

    Dexter

  • Stellaris Dexter said:
    continues to grow and expand our MCU lineup

    Such "MCU growth/expansion" terminology may not be fully/properly representative.   

    Does not, "M3's NRND" troublesome demotion challenge, "continues"? 

    We user/specifiers - impacted by this horror - flinch upon its (casual) bypass...