• State
  • Locked Locked
  • Replies 135 replies
  • Subscribers 46 subscribers
  • Views 135653 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

What's Unclear? Tell T.I. ... Updates to, "DriverLib User Guide"

cb1
Guru 47900 points
Other Parts Discussed in Thread: ENERGIA, HALCOGEN

Greetings,

Amit has announced that updates are being prepared for the "DriverLib User Guide."   (well...not really!)

Vendor experts have prepared - yet the voice of user-clients offers a broad perspective - and may serve to enhance and/or speed this effort.

May make sense to attempt to "prioritize" any listing of such updates.     Goal may be, "Most good for the greatest number."

As some (equally critical) gatherings advise, "Speak now - or (forever) hold your peace."

[edit 12:05 CST, 16 May 2015  Title changed from, "Call for User Inputs"]

  • 0
    Guru 117855 points

    cb1- said:
    "Speak now - or (forever) hold your peace."

    Ok already - this reporter (instigator in this case) rises to the bait.    (99 first day views - not a single bite - headline writer needs, "talking to.")

    Follows several suggestions to strengthen the "DriverLib User Guide."

    a) Far more detail aimed at, "Care/Handling of the (external, user supplied) analog circuitry."     Again - this is (external) to the MCU - it describes the user's treatment of the analog signals (prior) to their presentation to the MCU!      Too often - as well noted here - user's allow the analog pins to "float" - and then "protest" when ADC readings seem (outside) their expectations.     ADC pins need to be properly connected/terminated - existing ADC "input specs" (rear of the manual) appear too complex for many, here.    Suspect that sample schematics - w/"general" part values - will go far to improve.

    b) uDMA was among the last peripherals added to these MCUs.    And - if memory serves - the written descriptions, number, and variety of (properly) detailed uDMA examples must be increased.     There are many "hooks" and sometimes even the sequence of uDMA set-up/config proves vital - especially when the uDMA manages & coordinates multiple MCU peripherals - running at high speed.     Suggest the "most likely peripherals" to benefit from the uDMA be well represented - w/detailed, application-ready examples.

    c) Interrupts - due to their inherent complexity and demanding requirements - require more detailed description & illustrative examples.     The (usual) requirement to define/detail the interrupt handlers w/in the "start-up" file is too often missed - signalling the need for greater emphasis.     And it cannot hurt to (gently) suggest that the (near) universal trend of placing, "Calls to the UART" w/in interrupt handlers (which should be quickly executed so as not to prove disruptive) should be resisted.     Simple toggle of test Leds far better confirms interrupt entry - w/out over-burdening the program.     (not a word to this guide exists...)

    d) JTAG - though not a "prime MCU feature" - when, "MCU cannot connect" - users are pretty much, "Dead in the water."     Indeed laundry list of, "What to do, now" exists - but forcing frustrated & already delayed users into google or site search - appears not the best/brightest method of advisement.

    I can list more - yet the richest response results from varied User Input - which Amit has invited.     (after just a "bit" of arm twisting)

    Here's a (rare) chance to, "Post your greatest, "DriverLib Update needs."      Pity if your key need is "missed" - which may be prevented - with your brief listing here!

    Should this thread remain, "empty/under-served" - a strong message that, "Users do (not) really care" seems sent - does it not?    Even a quick, single item is likely to "blip" this vendor's radar - this is our chance to gain, "some voice" in vendor's actions...

  • 0 in reply to cb1_mobile
    Guru 47900 points

    Hi Amit,

    As gleaned from, "Advertising 101" - if readers don't note & respond - change the "Headline!"

    "Monster ate my Tiva" (unfortunately - already taken) so I updated my past, "Call for Updates" w/"Tell T.I."    

    And now note that the "sticky" lost its adhesive properties in that process.      (may not be all bad - response was not what I had wished for/anticipated...perhaps "drift into obscurity" has been earned...)

  • 0 in reply to cb1
    Guru 47900 points

    Gang,

    Silence deafens - does everyone landing here have absolute mastery/understanding of each/every element of MCU's Bootloader?   

    That one "left open" so that "youse guys" could request.

    It's long said that we, "Get the G'ovt we deserve."    Might a similar fate await this updated DriverLib User Guide - minus any forum-user input?

  • 0 in reply to cb1_mobile
    Guru 20670 points
    I don't know why but I must have a problem with stickies - they are always there so I tend to miss new ones (always overlook them).

    I made some wishes here, not exactly specific to the user guide:
    e2e.ti.com/.../417472

    The driverlib user guide specifically I don't have complaints that I can remember now, it gives info about the functions and that's it.

    What I think is needed is examples and/or application guides/notes.
    I speak of what I've used, can't say (of course) anything about peripherals I rarely/never use.

    The DMA first, I think there is a bit of info lacking. Again not driverlib specific the problem, could use more info in for example the FIFO behavior with the DMA.
    A note about the differences about the TM4c1294 DMA vs the TM4C123 one. How to use the TM4C123 DMA interrupts (DMA done flag is in the DMA registers but it uses the peripheral ISR).
    And some more simple examples for understanding the use of it with the driverlib - could be just good codes to understand like toggle a GPIO with the DMA. Scather-gather I just ran way from that, it like has kinda good (I ran away after a while) info on the datasheet but could use more info directed to application using the driverlib.

    Basically I think that there should be a good guide in migrating from TM4C1294 to TM4C123. There are changes in hardware that can break a code. There are changes that I don't even know why they exist (some were explained to me as improvements later). I think it's a must so a sneaky change doesn't make users pull their hairs out.


    Can't remember more now...
  • 0
    Guru 10570 points
    The biggest issue is simply knowledge of its existence. I had to resort to the sage Google to find it and then I probably got the wrong manual.

    I suspect many do not rrealize the manual exists.

    Robert
  • 0 in reply to Robert Adsett72
    Guru 47900 points

    Indeed Robert - indeed.    Some here have suggested that ALL such data be immediately "clickable" from the red bar - atop this forum.

    That bar holds the (uber) critical, "Blogs, Groups, Videos" - clearly: "MCU data, App Notes, & vital DriverLib Guide" should be there too!

    Unclear, "How, when & why" the obscuring of vital data has resulted - and been (apparently) "cast in stone!"

  • 0
    Guru 27665 points

    Not manual but the library itself

    (u)int32_t is over used.  Some of the uses should be replaced with other types.  Obvious examples are

    • the SSI interface which should use void * for the data
    • the uart interface, UARTCharGet should return a uint8_t (char if it were restricted to printable characters).  The nonblocking should probably return an int, preferably it should be re-written so that the read byte is not returned via the exception interface.

    There should also probably be more general use of types rather than using the (near) bare compiler types for everything.

    Robert

  • 0 in reply to Robert Adsett
    Guru 20670 points
    I actually like the uint8_t, uint32_t, etc, use of near bare compiler types instead of int (char doesn't really matter it's always the same). THat way I know exactly the size of the variable... Though is mostly due to me using Energia in the past where there are lots of different platforms (plus Arduino).

    But that is just a personal preference :p
  • 0
    Guru 47900 points
    As suggested earlier today by Amit - following is copy/paste for "centralization:"

    You may create a function similar to the FlashUserGet to add the USER_REG2 and USER_REG3. Or you can modify the existing function and recompile the driverlib.

    BTW, that is a good suggestion to add to the existing driver files. I will file the same into the enhancement request

    Regards
    Amit
  • 0 in reply to cb1
    TI__Guru**** 244380 points
    Hello All,

    Changes to existing function will not be done, since most of them are ROM functions and this will break the continuity of the function in ROM and Flash. Instead functions shall be created to add capabilities.
    The main focus is on the documentation right now.

    Regards
    Amit
  • 0
    Guru 27665 points

    NMI

    Document, re-document and over document. Since the external NMI is, unfortunately, unlikely to be eliminated the potential victims need plentiful warning. Especially since it affects those who have absolutely no intention of using the thing.

    Robert

  • 0 in reply to Robert Adsett
    Guru 47900 points
    May I add - many (most) of those "potential victims" have neither "Awareness nor Intention" of such use!
  • 0 in reply to Luis Afonso
    Guru 27665 points
    Actually char isn't always the same. It can be signed or unsigned. The only guarantee is that it be at least 8 bits (and yes there are implementations that are larger).

    The reason for suggesting int in this case is that it is supposed to be the "natural size" for the processor that is at least 16 bits and it is guaranteed to be at least as large as a char so it makes the natural return candidate. Specifying the size actually makes the code more brittle in this case.

    That is, however, my less preferred option. Better would be

    bool UARTCharGet( BASE_TYPE base, uint8_t *byte);

    or

    STATUS UARTCharGet( BASE_TYPE base, uint8_t *byte);

    This separates the error and data which is more robust. It also makes the types for different functionalities distinct which increases the error catching possibilities. Finally by using BASE_TYPE calling with a bare integer constant should raise a warning or error if you are working with good tools.

    This could be done with the current ROM quite easily via a wrapper if needed.

    As far as the near bare compiler types comment I wasn't suggesting moving to bare types, quite the reverse. I'm suggesting narrower type defs are necessary. For example a number of calls return status information. These should not return uint32_t but rather something like TIVA_STAT defined so that you do not assign back and forth to logically incompatible type without having to change types. These would then have appropriate defines (of the appropriate type) for bits or enums types appropriately for list values. This can be done without modifying the current ROM to a large extent, simply requiring updated headers. In a few cases like the UARTCharGet above you can get significant improvement with small wrapper functions that call the ROM functions.

    Robert
  • 0 in reply to Robert Adsett72
    Expert 2415 points

    Robert Adsett72 said:
    The biggest issue is simply knowledge of its existence.

    Seconded. I didn't have trouble finding it since I knew it right from the start (had read it before receiving my first sample), but the forum has plentiful evidence of this. 

    I don't think I'm able to give good suggestions to the guide as I've read it through so many times (first timers would be able to give more objective feedback), augmenting with reading source code & the device datasheets - I sort of auto-fill the blanks that probably exist in the Guide. But I still always laugh at the code examples at the end of each section - the only really good example has actually been the Ethernet one - that got me 90% the way in that particular case. Most of the examples cover a section of 20-30 API functions with a code example of 5 lines (probably exaggerating, but you get the idea).

    Actually, an idea dawns now: Perhaps the Guide should incorporate some of the device datasheets - in the form of more in-depth documentation of what the functions actually do. In most cases in order to get full understanding I need to have the Guide, the datasheet and the actual function source code. More complete code examples should be removed from the Guide and instead an extensive library of app notes, focusing on each peripheral and a few select common combinations should be provided. Many of the existing example projects could be used as a basis for those app notes, Someone(TM) should just write a "walk-through" for them.

    As to feedback on a more generic level, more important than the documentation is that the code/devices actually match the documentation! That means either decently fast bug fixes or updating the Guide/datasheets with warnings (with HW bugs probably the latter). Don't let the 15-month (or so) fiasco of the last release repeat itself.

  • 0 in reply to Veikko Immonen
    Guru 47900 points

    @Veikko,

    Forum leader & this reporter "knew" you'd be arriving - and to my mind - just a great, inspired post.     Completely agree that multiple source documents - all open - aids immensely.

    I may add that - most always - the code examples which follow each peripheral section - "fail to perform the required peripheral configurations!"    Of course these may vary - depend upon the chosen peripheral_x - but at minimum the requirement to fully & properly "initialize" should receive (some) mention!   (as has long NOT been the case!)

  • 0 in reply to Veikko Immonen
    Guru 20670 points
    Maybe there could be a reference to the resources in the little manuals that come with the kits, launchpads, evaluation boards, etc.

    Like:
    Consult the datasheet on your device for all the info in hardware
    For more info on how to use the Tivaware library:
    -TivaWare peripheral driver library user guide
    - (...)

    For finding these manuals either for to www.ti.com and search for the respective name or go to www.ti/TheResourcesLinksAreHere.com.

    People would (maybe?) be more aware of the available resources this way no? Just the notion that they exist.



    One this cool would be, like Veikko said, explained examples in application notes. Like properly getting into info about the peripherals functions. That would be cool.
    Other thing I think there is missing, example-wise (and application notes) is simple examples... sometimes it seems so. Since they are just example codes, with little explanation, some in comments but still... it's hard to get going. It seems such a big leap sometimes.
    For example, for explaining the DMA most simple transfer I use an example with the GPIO. I think I should have made it simpler actually but oh well... It simply sends data from RAM to the GPIO data and you see the LEDs changing state. Really simple and with a explanation of all functions being used and why... it would probably take a ton of work to make application notes with explained examples, step by step... but many users would beneficiate (if they find them).
    Just my opinion.
  • 0 in reply to Luis Afonso
    Guru 47900 points

    @Luis,

    Believe that you make great sense - and thanks to you, Robert, Amit & Veikko - this once barren thread has topped 800 "hits."    (sponsor has to be (now) pleased)

    The care & effort you devote to your posts really shows Luis - and your suggestions do indeed seem logical and effective - I'm sure that all (reaching/reading) here thank you.     (cb1 surely does)

  • 0 in reply to cb1
    Guru 20670 points
    1 more thing, I think I referred it previously in a post that I did.

    I think there should be a note in "how to read the datasheet" and maybe for the more general manuals.

    I mean, the datasheet has really a lot of useful information. There are lot of times that someone asks me something, I can most of the times, if I don't know by head the info, find the info on the datasheet in a very short time. Why? Because I know how it is organized. Of course experience is probably the top reason but I can tell you that knowing how the datasheet is organized (btw I like it a lot) helps a lot.
    Like it's divided in "chapters" - each chapter is a peripheral.
    Each peripheral is divided the same way. There's the Initializations, the functional description, signals, register map (with useful short description to find it quickly then go to the detailed description).

    Especially for students beginning 1.5k+ pages can be scary. Having a little "map" could be such a big deal for them, just for the simple reason, it would be a short text showing that the giant datasheet is not that scary to read.
  • 0 in reply to Luis Afonso
    Guru 47900 points

    As you bring up the MCU manual - here's a trick which may benefit many.      Not each/every page has the same "vital" content.     We find it most helpful to, "Copy & Paste" between the critical parts of the MCU manual and our, "MCU Manual Summary" file - which as you note - is broken down by "peripherals or chapters."     As we paste in data - we also add the (original MCU) page number for completeness.

    Via this method - we're able to significantly "compact" the MCU manual - yet have the "full document" available, "when and as needed" in unmodified form.

    We use "MS Word" for this purpose - as it allows eased copy/paste - as well as chart & image entry.   By consolidating in this manner - we often "capture the essence" and drastically reduce the size of the document.

    There's another technique/advantage for those in small biz or at school.    When any @ my small firm make a "discovery" we copy/paste to a special file marked, (drumbeat please) "discovery" and after a few days we decide if it should be "promoted" to "key info."     (did I say there's a cash reward, too?)

    Anything which "spreads the word" - "maintains interest" - and "prevents stumbling along the same (unmarked) trail!"     (PF0/PD7 gang may take notice)

    Small biz - to survive - must be efficient - repeating the same mistakes cannot be accepted...

  • 0 in reply to Luis Afonso
    Guru 15175 points
    I've noticed that several Datasheet Microcontrollers, the provider gives examples of code for its peripherals settings, making it a little more understandable way using their microcontrollers, I'm personally more attached to the Hercules RMx family, the fact that she has HalCoGen GUI that really facilitates work with any MCU Hercules, this prevents my having the need to go to a datasheet for how the configuration fuses to MCU function.

    maybe sometime TI can create a graphical interface as HalCoGen for TM4C family.

      Note: I have also knowledge of tivaware but not tube success learning to use it.
  • 0 in reply to Martin Valencia
    Guru 117855 points

    Martin Valencia said:
    HalCoGen GUI that really facilitates work with any MCU Hercules, this prevents my having the need to go to a datasheet for how the configuration fuses to MCU function.  

    While I cannot fault your pleasure with the speed & ease which the GUI provides - might there be a (serious) downside, as well?     Yours is a powerful MCU - and as no GUI tool has the ability to optimally set-up, configure & deploy "all" MCU features - might your (avoidance) of the data manual cause you to "miss" - or inadequately employ - certain complex, yet key MCU capabilities?

    Anything you do to ease and/or encourage efficiency is good - yet I don't believe (inadequate) read/review of the MCU manual serves your best - long term - interests.

  • 0 in reply to cb1_mobile
    Guru 15175 points
    you are right!

    Well, actually the GUI does not display all features of the Hercules complex but that is supplemented by programming in C++, so I would say that the Hercules MCU Family is configuration to be worked with GUI and C++ commands.

    Sure, there are times when I don't know how to start an order of commands, so necessarily I have to resort to a datasheet or user manual.
  • 0 in reply to Martin Valencia
    Guru 117855 points

    Don't believe this rises to, "Right/Wrong" - again that MCU's "GUI assist" (as you rightly note) serves both development speed & ease.

    Yet - over time - the MCU manual provides much of interest & value - which cannot be fully/properly noted (and surely not detailed) in a (necessarily) condensed GUI. 

    Our tech firm finds it best to "start" with a quick read of the MCU manual - focused upon the central MCU operations & peripherals of most interest.    Usually much of value results from that effort.     Only then do we move to the GUI - and our use of the GUI is most always, "eased & improved" by that (earlier) review of the MCU manual.  

    Yet - when both are combined - most here will realize the best, fullest, and least stressful performance from their MCU - whatever its class & nameplate...

    And - as unpleasant as it is - read of MCU's errata can save much "lost time & heartache" - should be added to user's, 'MCU To Do List."

  • 0 in reply to cb1_mobile
    TI__Guru**** 244380 points
    Hello All,

    Thanks for posting your views on this thread (and I know this is going to continue for some more time). Though not a bullet proof solution yet, this is what my view and take away from the post:

    1. Structure: The web page needs to be more flowing that what it is. Information scattered and at times disconnected makes a user nightmare on how to go about TM4C12x devices
    2. Content: The Application Note, User Guide and Data Manuals are way too bulky to make emphasis. Rather use Application Notes more peripheral oriented and separate each application note by chapter and examples. The application note must refer to an "corrected and updated" Peripheral DriverLib Guide so that every API's (attempt to have 100% coverage from examples) practical use in an example can be illustrated well beyond the 20-30 lines of comments. The tricky part I anticipate are external IO peripherals as not every mode or function may be covered with a system device so a use of two launchpads may be required.
    3. Time and Urgency: In my opinion JTAG and I2C are good candidates from TM4C12x perspective as we start digging into this approach. At the same time we as TI need to internally start connecting the dots on the web for information flow than "hyperlinks" to eliminate over-statements and dead ends.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 20670 points


    Hi Amit,

    About :

    Amit Ashara said:
    The tricky part I anticipate are external IO peripherals as not every mode or function may be covered with a system device so a use of two launchpads may be required.


    Which one might you be talking about?

    SPI you can connect 2 SSI modules together no? I2C the same, UART could also if there is something the computer interface simply does not support (don't know any though). Could CAN be done the same way? If not, a extra launchpad would not solve it.
    Basically anything that normally requires 2 launchpads could be done with just 1 no? There's always 2 or more communication peripherals and things like timer capture can use a PWM signal.

    Only see things like QEI, EPI, CAN if not possible between launchpads is what I see it needs extra stuff.

    And even so, for communication peripherals there could be examples using simple, generic, ICs from TI itself no? There are lots of DIP chips that I usually use to teach my friends about the communication peripherals (taking advantage of the sample program). 
    Anyway, stuff like QEI can use any quadrature enconder, so that needs to ensure he has the material.
    As for functions that require more complex stuff (extremely technical term right there) isn't that what boosterpacks are for? 

  • 0 in reply to Luis Afonso
    Expert 2415 points

    Luis Afonso said:
    Could CAN be done the same way? If not, a extra launchpad would not solve it.

    CAN would require a tranceiver also. And even with the tranceiver, at least on the 123 launchpad, pins from only one CAN module are broken out - the other one is on PA0/1 ie. the debugger UART pins and isn't available without hw modification. So you would need two launchpads. IIRC, there is some kind of loopback mode in CAN as well, but loopbacks don't really represent how things work.

    Luis Afonso said:
    Anyway, stuff like QEI can use any quadrature enconder,

    Or a timer-triggered GPIO sequence - had to do this once when I had to test QEI code without an actual encoder.

    But indeed, connecting signals between two peripherals on the same board is a viable option for demo purposes. It also allows spying on the traffic using a logic analyzer!

  • 0 in reply to Veikko Immonen
    Guru 20670 points

    Veikko Immonen said:
    Or a timer-triggered GPIO sequence - had to do this once when I had to test QEI code without an actual encoder.




    I suppose if there was a simulation function ready to use that gave a simulated enconder output then it could be a good possibility. Of course the function comment would say that the function content is not relevant to understanding the QEI. Could even be multiple functions like "simulate_forwards", "simulate_backwards", that accepts various RPM as parameter so the user could see the QEI input vary.

  • 0 in reply to Luis Afonso
    Guru 117855 points

    Luis Afonso said:
    Basically anything that normally requires 2 launchpads could be done with just 1 no?    There's always 2 or more communication peripherals

    First - (another) series of great posts from Luis - as well as Veikko - thanks guys.    Indeed - we agree w/Veikko - CAN xcvrs (2) are mandatory - not an option.

    May I suggest what I believe to be a superior means to gain, "Real World" experience w/MCU's "communication peripherals?"     My small tech firm much prefers, "Dedicated communication peripheral ICs" - the simpler the better.     Justification for this preference follows:

    There's (some) "method to this madness" - employing either a single launchpad (per Luis), or two (interconnected) launchpads (per Amit) - forces one of those communication peripherals (either on the same board or 2nd) to operate in the (far lesser used - & usually more complex) SLAVE mode - does it not?     And thus an entirely (new) "can of worms" is admitted!     We've now forced the (new) user into mastering both Master & Slave!     Not good - nor smart - delay & heartache are the (usual & predictable) result!     Surely "Slave" operation - at some point - is likely - but "never" should this be promoted to, "First effort!"

    Again - through experience - we find that the, "simplest, Dedicated IC communication peripheral" - enables the user to most, "Quickly & Easily" gain "mastery" of that MCU communication peripheral.    No "Slave" communication peripheral, "set-up/config." is thus required - and inevitably we find those "Slave" settings both more complex and more "limiting" than when the peripheral is allowed to operate in its (intended) "Master Mode!"      As a critical example - does not this vendor's SPI peripheral, "grind to near halt" - when directed into "Slave" mode?      And - if we tie 2 LPads - or "loop-connect" a single MCU - we have forced BOTH "master & slave" peripherals into complying with the (rather) strict demands enforced by the (by far) minority usage SLAVE!      That cannot be good!

    The desire for "low" or even "no" cost is understandable - but "hidden costs" very often arise - and may (vastly) exceed any/all "savings!"     Instead - if we choose - a simple yet "useful" communication peripheral (i.e. GPIO expander seems ideal) - we've added "real/useful" capability - focused entirely (properly) on the critical "Master Mode" - and have not (misspent) time demanded by the (far lower priority) Slave usage demands...

    Small tech biz - to survive - must constantly search for, "best practice" - and, "steer tightly & correctly" to course - trust (some) case has been made for this 3rd (simplest) alternative...

  • 0 in reply to cb1_mobile
    TI__Guru**** 244380 points
    Hello All,

    Again a great series of posts.

    Approach #1:Loopback onto the same launchpad has one major drawback: Variables are easily carried between the "independent" modules, making it tougher for split to be done. The advantage is the same set of code with the cost of a single LaunchPad.

    Approach #2:Connection to another Launchpad has it merits and demerits: Cost, how many shall afford 2 LP's to get an example set working. Advantage is of course that the codes are really independent.

    Approach #3:Using a 3rd board with real time devices: Cost involved in getting the board. Also not all features may be supported.

    I would rather suggest using the 3 approaches in a weighted manner to be able to answer some long outstanding post, yet have codes to do the required features well exemplified. Personally Approach #2 and #3 appeal a lot for data transfer protocols. Control protocols are a beast to be looked at separately.

    Regards
    Amit
  • 0 in reply to cb1_mobile
    Guru 20670 points

    cb1_mobile said:
    Again - through experience - we find that the, "simplest, Dedicated IC communication peripheral" - enables the user to most, "Quickly & Easily" gain "mastery" of that MCU communication peripheral.    No "Slave" communication peripheral, "set-up/config." is thus required - and inevitably we find those "Slave" settings both more complex and more "limiting" than when the peripheral is allowed to operate in its (intended) "Master Mode!"      As a critical example - does not this vendor's SPI peripheral, "grind to near halt" - when directed into "Slave" mode?      And - if we tie 2 LPads - or "loop-connect" a single MCU - we have forced BOTH "master & slave" peripherals into complying with the (rather) strict demands enforced by the (by far) minority usage SLAVE!      That cannot be good!



    Although I like the idea of using a external slave interface, I do not think that slave mode should be ignored all-together. Might be me reading it wrong, but it seemed a bit like you were suggesting that.
    If possible I would like a example of that yes but there should be also a example of slave mode in all the communication modules. There could be a note showing the weighting both methods though.
    I personally don't like using slave mode so that would be appreciated.

    @Amit,
    What variables could you be speaking off? (or are you really speaking about data variables?)

  • 0 in reply to Luis Afonso
    Guru 47900 points

    Luis Afonso said:
    Although I like the idea of using a external slave interface, I do not think that slave mode should be ignored all-together.

    "Ignoring Slave Communication all-together" was neither my intent nor suggestion!    What was suggested was the, "Elimination of "holding the (much higher importance) Master Communication "Hostage" to the set-up/config - and full compliance with the (rather severe) demands of the Slave!"    Read again - the use of the Slave was NOT to be "ignored" - merely postponed - and removed from its unearned/poorly thought, "Hold the Communication Peripheral Hostage" role!

    Most peripheral devices - targeted by the MCU for serial communication (via: I2C, SPI, CAN) will serve as, "pre-configured and well-knowing Slaves" and all communication may be achieved strictly via the MCU as familiar Master - without forcing it into the more complex (and limited), "Slave Mode."

    Rather than, "ignoring all-together" (neither my words nor intent) - when the time & opportunity proves right - the Slave mode may be investigated.    Yet again - by huge margins - use of "Master Mode" overwhelms "Slave Mode" - especially so when "new user applications" are in play.

    Attachment of a, "Dedicated communication peripheral IC" does not always require a special or costly pcb.     Many such ICs are available in dip or soic packages - both w/in the ability of most hobby/MCU users - and represent a small fraction of the LPad's size & cost...     And - best of all - adoption of such dedicated commo IC - leads to an immediately usable - "Real World/Capable" - Application Solution - which the other suggestions lack...

  • 0 in reply to cb1
    Guru 20670 points
    I am a fan of using DIP packaged ICs for learning purposes.
    TI(like some other manufacturers) gives sample to students so maybe examples with simple external ICs (that TI has available for sampling) is a really good idea instead of examples with 2 launchpads, no?
  • 0 in reply to Luis Afonso
    Guru 47900 points

    Pressed the "Like" button "one more time" for Luis!

    Use of such, "Simple, ready to go (i.e. no set-up/config/added programming) communication IC greatly speeds/eases/enhances the study and quick mastery of multiple, serial communication modes.    Has long been suggested by this reporter - to silence... (and few likes - while overwhelming all alternatives...)

  • 0 in reply to cb1
    TI__Guru**** 244380 points
    Hello All,

    Looks like we do 2 sets of code then for the new application notes. One which uses 2 LP's and one which is modified for use with an external peripheral on a very similar transfer. If not any more suggestion we can begin the work...

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Hello Amit,

    May I - as the forum "content provider" - directed by you to initiate this thread - respectfully (and gently) protest?

    Your (most recent) writing suggests that "just two" additions to the "DriverLib User Guide" will be made.    Or that "just those two" sets of code will be produced.    Are either - or both - correct?    

    If so - have not the serious deficiencies w/in the existing "DriverLib User Guide" - identified at/near the very top of this thread - been totally dismissed?  

    Do not the following topics require "improvement & greater detail" w/in this guide:

    a) ADC - code implementation along w/proper "care/handling" of input circuitry

    b) uDMA - highly complex - far more specific examples & narrative explanation required

    c) Interrupts - always troublesome

    d) JTAG - universal "plague" everyday do not 5-10 such posts arrive?

    e) USB - HID seems atop this requirement

    Hope still exists that, "All of the above" have not "fallen off the earth" so that "Communication Peripherals" - ALONE - receive greater attention!

    To (further) strengthen this appeal - minus those "critical 5 MCU areas" - is not the, "MCU's communication value/usefulness" vastly reduced?      And then - what is the point?

  • 0 in reply to cb1
    TI__Guru**** 244380 points
    Hello cb1,

    Thanks for the protest as my writing was clearly deficient.

    Features that can be handled by using an external device shall be implemented with code example with an external device (as cost may not be high for some devices). Some features that require say another uC, shall use a Second LP. This shall not be handled by the DriverLib User Guide but by dedicated application notes that would be peripheral specific. While the above list (a)-(e) are all equal candidates, to start the activity I have picked (d) and added I2C. Note that we have enough forum post on the latter, especially with the TM4C129 polling method. Not to lose out on mentioning that FIFO and uDMA features of I2C have not been touched yet.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points
    Hi Amit,

    Thank you - as long term, caring, outsider (hooked to some few here) I try hard to bring about the most gain for the greatest user base.

    List has been presented - has been present long enough for most to note - "sticky release" button now calls to Amit for service...

    Thanks for the opportunity to provide the forum community their chance to influence T.i.!
  • 0
    Guru 27665 points
    This is both a manual and a library suggestion. The libraries are starting to get variations in what is supported for various chips. This has noticeably caused users to trip over the different methods to determine clock frequency. This should, of course be well noted in the manual for both the original and replacement functions.

    Especially since the library already requires use of defines to identify the processor, the library should also be modified to produce a compile time error if an unsupported/deprecated function is referenced with information referencing the appropriate replacement(s)

    Robert
  • 0 in reply to Robert Adsett
    TI__Guru**** 244380 points
    Hello Robert,

    It is not a fool proof solution though. I have seen projects coming without the use of TARGET_IS_TM4C12?_R?? which is used during compile time. Also the only check that is placed is on CLASS_IS_TM4C12x which is a run time define replacement. Not to mention ROM functions do not have the same flexibility.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 27665 points

    Amit Ashara said:
    I have seen projects coming without the use of TARGET_IS_TM4C12?_R?? which is used during compile time

    Should not a missing definition also produce a compile time error?

    Amit Ashara said:
    Not to mention ROM functions do not have the same flexibility.

    The presence of the error checking would not affect the ROM image, it would not affect the generated library code at all.

    Robert

  • 0 in reply to Robert Adsett
    TI__Guru**** 244380 points
    Hello Robert

    Adding a check for missing definition can be done. Let me check the code base to what is possible.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 27665 points

    I think that would be a good idea.  

    I've been thinking a bit about the other part of the problem (detecting unsupported functions). I'd probably use PC-Lint for the detection but that won't work for a released library like TIVAWare. At first the best I could come up with was something like

    #ifndef SUPPORTED_FEATURE_X

    #define function_y(a,b,c) Function_y_not_supported()

    #else

    size_t function_y( int32_t a, void *b, void *c);

    #endif

    That would work but delays the detection until link time.

    Poking around I've found a relatively recent addition to the C standard, the static assert1. Then this becomes something like

    #ifndef SUPPORTED_FEATURE_X

    #define function_y(a,b,c) static_assert(0, "function_y not supported on this processor, use function_z instead");

    #else

    size_t function_y( int32_t a, void *b, void *c);

    #endif

    I've not tested this so there's probably errors in it.

    Not all compilers are likely up to date so you may need to be prepared to add your own with something like the method outlined by pixelbeat2 and add a definition like the following to a common include

    #include "assert.h"

    #ifndef static_assert

    ...

    provide private definition of static assert

    ...

    #endif

    I did, of course, find this information in the reverse order but it presents better in this order.

    The static assertion structure can be implemented in the header files similarly to a check on the processor define and would not need new ROM binaries to support.

    Robert

    1 - en.wikichip.org/.../static_assert

    2 - Method described in www.pixelbeat.org/.../static_assert.html.  It uses a compile time divide by 0 to flag an assertion failure and it appears it would work with any of the C standards.

  • 0 in reply to Robert Adsett
    Guru 47900 points

    Robert Adsett said:
    I did, of course, find this information in the reverse order but it presents better in this order.

    Mais certainement mon ami.     Might it ever happen - otherwise?   

    Good stuff - Bravo...

  • 0 in reply to Amit Ashara
    Guru 27285 points

    Amit Ashara said:
    Approach #2:Connection to another Launchpad has it merits and demerits: Cost, how many shall afford 2 LP's to get an example set working. Advantage is of course that the codes are really independent.

     Amit, I am afraid read this, so this is really forum just supporting free of charge?

     What about who invested some thousand monetary unit to buy multiple development kit? I own more than one launchpad to support multiple communication and to prevent don't have one spare at hand in case of failure. I bought 4 by type and one DK. On stellaris I invested a lot of money, motor kit not 10$ display kit no more produced and now what to do with these crappy stuff?

     At end of Year who can be interested maybe I sell for a fraction cost.

     Who used old Stellaris wish have some exchange pin to pin why no plan is in this direction to save investment?

     Altera saved me from TI producing MAX10 series so I don't need more external devices than MSP, the 20 year real industry standard.

     About tm4c123 I pointed a long time ago 64 pin series has only one mapping of first CAN channel overlapping debug serial. I pointed to many other wrong but I got worst idea of my work.

  • 0 in reply to Luis Afonso
    Guru 27285 points

    Luis Afonso said:
    I am a fan of using DIP packaged ICs for learning purposes.
    TI(like some other manufacturers) gives sample to students so maybe examples with simple external ICs (that TI has available for sampling) is a really good idea instead of examples with 2 launchpads, no

     No more, now you pay more than buying from distributor, so if you need an adapter board for DUAL CAN Driver and RS485 so8 and SO16 isolated I can proudly send you two board for free just to you as thank for help on DMA troubleshooting.

     I WAS using on Launchpad now on competitor ARM board to evaluate porting before to rework board.

     RS485 are TI chip, Dual CAN is from competitor OnSemi or NXP.

  • 0
    Prodigy 40 points
    how to find value for delay and configure perfect delay through timers
  • 0 in reply to Roberto Romano
    Guru 20670 points

    Roberto Romano said:

     No more, now you pay more than buying from distributor, so if you need an adapter board for DUAL CAN Driver and RS485 so8 and SO16 isolated I can proudly send you two board for free just to you as thank for help on DMA troubleshooting.

     I WAS using on Launchpad now on competitor ARM board to evaluate porting before to rework board.

     RS485 are TI chip, Dual CAN is from competitor OnSemi or NXP.



    I actually don't pay for samples at all. But only for some ICs.

    Thank you very much for the offer Roberto but CAN is not something I have the need to get into :)

  • 0 in reply to JUNAID RANA
    Guru 47900 points

    Thank you, Junaid - starting with these complex, multi-featured Timers, is a bit over-whelming for first time users.    (and for those who "should know better - but are rushed/inattentive...i.e. "moi")

    While the MCU manual does list the, "Max times achieved via various values" a brief listing of timer settings - to quickly/easily achieve, "Most usually desired" timings would indeed be welcome...

  • 0 in reply to cb1_mobile
    Prodigy 60 points

    But then, there are some of us out here that NEED the system to operate in Master or Slave mode. Slave operation for us is just as critical as master operation. This is the fault I find now with the TM4C12x I2C documents.  Almost every example is set up for Master mode, with practically nothing on Slave operation.  (We jokingly say TI does this intentionally because they think their systems are too good to be slaves.)  You can't claim slave operation is unnecessary because you find it that way for your system.

    While the documentation for the I2C (and other peripherals)  lists the INTs that are called by that periph, there's nothing that describes how or when the specific interrupts are triggered. As I found, when I think an interrupt should be called is not necessarily when it actually occurs. For example, when trying to convert from the time-wasting while loops in the I2C examples to more efficient interrupt driven drivers, a better explanation along these lines can do wonders in getting the code to work properly.  Right now I feel like I'm in a "Hunt the Wumpus" game mode trying to discern how and when these INTs trigger.

  • 0 in reply to Bob Repas
    Guru 47900 points

    Believe that you make very valid points - I'm in no disagreement - yet I've the impression that you're targeting "moi" as, "Fan of the little or poorly explained."   

    If you're able - or care to - describe "how/where/why" you've come to this conclusion I'll gladly (and quickly) respond.

    In defense of this vendor (and my having past worked at a similar semi "giant") we note that - in general - Slave operation most always is, "less detailed."    Tech writers are under time pressure - and it's not unusual for the "Slave write-ups" to be achieved - w/out benefit of fully present, exercised & tested HW...  

    I don't offer this as a proper excuse - but it is "reality" - and can be corrected via "flagging" - just as you've done here...

    I'm simple user-specifier - similar to you - was merely asked to launch this thread...

1 2 3