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.

TM4C1294NCPDT: A suggestion on future TiVaWare upgrade

Part Number: TM4C1294NCPDT

When upgrading usb_dev_bulk from TiVaWare 2.10 to 2.14, compilation error occurs

In 2.10, we have 

uint8_t g_pui8USBRxBuffer[BULK_BUFFER_SIZE];
uint8_t g_pui8RxBufferWorkspace[USB_BUFFER_WORKSPACE_SIZE];
const tUSBBuffer g_sRxBuffer =
{
false, // This is a receive buffer.
RxHandler, // pfnCallback
(void *)&g_sBulkDevice, // Callback data is our device pointer.
USBDBulkPacketRead, // pfnTransfer
USBDBulkRxPacketAvailable, // pfnAvailable
(void *)&g_sBulkDevice, // pvHandle
g_pui8USBRxBuffer, // pi8Buffer
BULK_BUFFER_SIZE, // ui32BufferSize
g_pui8RxBufferWorkspace // pvWorkspace
};

but in 2.14, we have

uint8_t g_pui8USBRxBuffer[BULK_BUFFER_SIZE];
tUSBBuffer g_sRxBuffer =
{
false, // This is a receive buffer.
RxHandler, // pfnCallback
(void *)&g_sBulkDevice, // Callback data is our device pointer.
USBDBulkPacketRead, // pfnTransfer
USBDBulkRxPacketAvailable, // pfnAvailable
(void *)&g_sBulkDevice, // pvHandle
g_pui8USBRxBuffer, // pi8Buffer
BULK_BUFFER_SIZE, // ui32BufferSize
};

The last member of the structure is dropped in 2.14, if we can just keep the old structure but ignoring it, it will save time when upgrading project

  • Hi David,

    Thanks for the feedback! Honestly, not sure we'd revert that particular one because it's already released with one less member and many use 2.1.4 now, BUT that's good feedback to have in general should any other structure updates where elements are removed come up.
  • May I add (support) for vendor/friend Ralph's position?

    Think - instead of just "one generation" of separation - to three - even more!     What then - are accommodations to ALL of those past versions realistic?

    Does that not add (unduly) to vendor/developer's workload?

  • I generally avoid upgrade, unless for bug fixes or feature additions, to avoid exactly the kind of situations you are in.

  • Yet - does not such, "Avoidance of Upgrades" - but for bug fixes/feature additions - "invite" the exact issue this poster experienced?
  • I just looked at LM3S toolchain and I'm still on Stellarisware 4694, from 2008, ;)

    still a happy camper here.

  • Danny F said:
    still on Stellarisware 4694

    And our small firm has advanced to  "Stellarisware 9453 - the (only) version able to support (both) LM3S and LX4F.      (and TM4C123 - w/slight mod. to pin_map.h)

    That said - we (grudgingly) were forced to admit that (beyond several) "improvements" have arrived w/T_Ware.      (Added features, functions, benefits ... thank you IBM)

    We note that you - like us -  "have and/or had" an  "LX4F120 board."      (such being the first venture by this vendor into Cortex M4 territory.)    (your postings called it LM - really NO LM4s were ever produced - yours IS assuredly - just as is ours - an LX4F...)

  • My addition to this suggestion: If you want to leave old unused structure members around, I recommend putting ifdef guards around those things and allowing the developer to choose whether to include them by defining a single project-level compile-time symbol, such as "COMPAT" or "BACKWARDS_COMPAT" or something.
  • Thank you - that (initially, at least) registers as "well directed."
    Famed poster "Robert" should (soon) arrive - his "take" proves most convincing - especially in such "code structure" matters...

  • It isn't actually my idea. I've seen many libraries that use a define such as "COMPAT" or "BACKWARDS_COMPAT" (or some other name with similar meaning) to include or exclude such backwards compatibility code. Otherwise, one ends up with code full of old nonsense, and it quickly becomes very difficult to keep track of what's actually used and what's just sitting around for no reason.
  • No, "claim of idea's ownership" was awarded by an, "expression of thanks."    (law-school conveys (some) advantages)

    I must add that - in firm's/my experience - little of our (past or old) code is, "Full of old nonsense" - that's an "unfair, overly broad, and a "completely unsupported characterization" - is it not?

    You conclude that it, "Quickly becomes (very) difficult to, (track & know) what's used."     Such proves, "Not at all in our (nor our clients' ) case - not  (even) close!"

    Drawing such "broad & forceful conclusions" - without really knowing, "all of the facts" - is "highly risky business" - and is not generally recommended!

  • Hi All,

    Thanks for your feedback on this topic, I've recorded some of your comments/feedback so we can take them into consideration for the next release!
  • I'd note (again) that the one poster comment, "code full of old nonsense" - registers as unfair, inaccurate, and "indefensible."    (poster of course has made no attempt to justify/support - such (indefensible) opinion.)

    In fact - the special power of the API is its, "Segregation by Peripheral" - which enables much, "reduced effort & time-saving" - in regularly scanning the API - thus preventing the inclusion of (even) code "bordering upon little used" - should (slight) modification to the API prove useful/desired.      (and of course reviewed - w/each revision of the API...)