Direct Register + Tivaware Namespace Conflicts

Hello Mike,

Yes, we know that a mix of DRM macros and driverlib will cause an issue. And we are trying to change this model to remove the DRM altogether. As you can see in 2.1.2.111 release the example code for the blinky has moved away from DRM to TivaWare.

Regards
Amit

As a workaround, you might put your performance-critical functions in separate modules (files), which would allow you to choose the includes, i.e. DRM or driverlib. It would have the second advantage of applying more aggressive optimization settings to the "smallest amount" of code.

BTW, in my experience a good optimizing compiler is most often far more effective than human "coding for speed".

Hello Amit,

We have used a mix of direct register access and DriverLib for years and not encountered any namespace conflicts, so I was quite surprised by Mike's post.  More importantly, I was shocked and alarmed by mention of a intent to eliminate DRM entirely.

TI: PLEASE do not eliminate the ability for us to use DRM where we see fit!  Some other device manufacturer's have made (and are continuing to make) the mistake of eliminating support of a Standard Peripheral Library or such in favor of auto configuration software.  They seem to be pandering to hobbyists or those wishing to throw together a proof of concept ( which is fine), but hurting mainstay users in the process!  I use DriverLb for all initializations but, as Mike alluded to, DRM within interrupt routines.  DRM not only eliminates procedure calling/routine overhead, but gives the compiler further insight and optimizing license.

Please reassure us the DRM support will not be abandoned!!!?

Best Regards,

Dave

Hello Dave,

Let me clarify a few points here

1. We are not eliminating DRM in favor of a auto configuration software
2. The DRM examples have been converted to TivaWare but DRM still remains there
3. The inc\hw_XYZ.h file still exist that can be used instead

While for an experienced developer DRM may be OK, but a lot of start up developers "want to learn the uC" using DRM, which creates a lot of support issues as the code is not well structured and the wheel is being re-invented.

Regards
Amit

Amit Ashara said:

the code is not well structured and the wheel is being re-invented.

And that "wheel" has none of the hundreds/thousands of past, successful usage enjoyed by the API.   Each DRM usage is an, "adventure" - and most always crashes/burns - winds up (begging) for help here.

As Amit notes - skilled users may exploit the advantages DRM (may) offer - but DRM users must recognize, acknowledge & accept the added complexity and slowed code development as, "known trade-off!"

I don't believe Amit (earlier) meant to suggest that DRM was being eliminated.   Language is crucial - DRM (may) be being "kicked to the curb" - but its elimination would be unwieldy (if even possible) - so Dave's alarm bell may restore to normal...

Amit and CB1,

Thanks for putting my paranoia to rest! As you can see, this is a very sensitive area for some of us "cycle counters"...

Regards,
Dave

@Da_Source,

So long as that, "cycle counting" does not cause you/firm to "MISS" that critical/early (i.e. spectacularly profitable) time-frame - be our guest.

Time & again we've seen client firms - large & small - obsess over "features/functions/performance" which proved "not" of special interest to the mass user-base.

In contrast - those "early arrivals/introducers" (i.e. Neanderthal API Users (cb1 firm)) receive vital, early feedback from "real" (not imagined) users - and can (then) - and only then - best react.  

Shooting for "perfection" - most always - results in "gunshot wound to one's foot!"   Missing that critical/early market window will cause investors to flee - those (few) "counted cycles" may (unfortunately) yield "late product release" - to a mature & competitive market - when profit margins have shrunk.

Counting Sales Dollars trumps "counting cycles."   Use/Prosper from the superb API - count & optimize only later - and only as/if (& where) needed!

Might the time "LOST" during cycle count & other, unforgiving/mundane efforts (get every single bit - in every register - exactly right) be instead - better spent - by adding features & functions - maximizing the user experience (of course via the "discarded" API) - while (still) releasing early?   (when profits are noticeably higher!)

In my observation performance of TIVAWare has not been an issue, where I have run into performance issues it has not been because of such access but because other workload has dominated. "Premature optimization is the root of all evil". Always measure before resorting to fine twiddling.

My concern would be that the TIVAWare library does not and probably cannot effectively address all use cases with becoming an unwieldy monstrosity and as such DRM access will always be needed for some cases. Thankfully, it has been indicated it will remain.

My secondary concern, and this is perhaps even larger, is that the direction TI is heading in is more error prone and is likely to result in a lower quality library. Rather than taking advantage of type differences and the compilers ability to check for errors they are going towards something that eliminates any differences, delaying detection of classes of errors until testing. In my own opinion the re-write of their library is going in exactly the wrong direction. It also appears to avoid proper use of const volatile and const, perhaps removing some optimization possibilities but that's pretty minor. More important in those cases would be error catching opportunities that are missed.

Robert