• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 85 subscribers
  • Views 426 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F280039C: Too few Bit-field based routines are not conducive to the development of application chips

tian kong
Prodigy 15 points
Part Number: TMS320F280039C
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE

At present, there are two main forms of program development, Bit-field based and Driverlib based. Both have their own advantages and disadvantages and should be treated equally.
At present, the main form of TI is Driverlib based form. However, at present, in the product development industry (power supply industry and motor industry), we mainly use Bit-field based form. I have consulted many engineers, and everyone still feels that Bit-field based code development is more flexible and convenient. However, the 280049 and 280039, as well as other new chips, have too few routines based on Bit-field based forms, which is not conducive to the development of applications. In recent years, many people should have reflected this problem to you, but you have not paid any attention to and reflected on it. You mistakenly believe that engineers have a Bit-field - based obsession. (It was actually the engineers who chose the advantages of a Bit-field based format).
At present, many engineers in the market still insist on using Bit-field based, which shows that this approach is not backward. I suggest that TI officials face up to this matter, and hope that you can reflect this problem upward and treat Bit-field based and Driverlib based equally. It also provides more bit-field-based routines for the current 280039 and other new chips, at least as much as Driverlib based routines. Engineers who develop code using Bit-field based formats continue to develop and use new chips.
The choice of technical route should be left to the market, which will choose it automatically. Before the market has given an answer, it is hoped that the two technical routes can be treated equally.

  • 0
    TI__Mastermind 28220 points

    Hi Tian,

    I appreciate your candid feedback on our bitfield-based support. Could you provide more specific examples on where more bitfield-based support is needed? Would you say TI is lacking in software examples for bitfield-based applications compared to driverlib? Provide as many examples as you wish as these will all be helpful in improving our collateral.

    As you may know, SysConfig is built purely on top of driverlib and not bitfield. SysConfig is a relatively new tool and we are open to implementing new features that will encourage customers to use it more frequently, since it is a reliable and speedy alternative to manually writing code. In your view, would customers like yourself be more willing to use SysConfig if it was capable of generating bitfield based code? I can see how SysConfig could be used as a tool for learning the bitfields themselves if we had support for a feature like this, since the generated code can be viewed in real time as the GUI is updated by the user.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 15 points

    At present, the routine code developed based on Bit-field based form is mainly stored in the following directory, such as C:\ti\c2000\C2000Ware_5_01_00_00\device_support\f28003x\examples. In fact, there are only 11 categories, a total of 15 routine code, such as the routine code without CAN, and some other peripheral use routines do not have. At present, routine code developed based on Driverlib based form (including Sysconfig) is mainly stored in the following directory, such as C:\ti\c2000\C2000Ware_5_01_00_00\driverlib\f28003x\examples. There are actually 44 classes, totaling about 224 routine codes. Bit-field based code is also organized differently from Driverlib based code. For chips such as 280049, 280039, and 28001X, if you use Bit-field based, there are not many routines to refer to directly.

    Bit-field based and Driverlib based have their own advantages and disadvantages. You also have comparison instructions on your website. At present, engineers insist on using Bit-field based, mainly because it is more flexible and convenient. Although Driverlib base is essentially the same as Bit-field based, both are required to write configuration to registers, Driverlib base is not intuitive in the form of code.

    Now because the Bit-field based routine is not enough, we insist on using the underlying configuration under the Driverlib based form (C:\ti\c2000\C2000Ware_5_01_00_00\driverlib\f28003x\driverlib), To write your own code manually, without using Sysconfig. The original Driverlib based code is less intuitive than Bit-field based, and less readable if generated using Sysconfig.

    We currently use 280049 or 280039 to develop charging pile modules, energy storage hybrid inverters, etc., the system architecture is more complex, the code is relatively large, and there will be many practical problems. We need to troubleshoot various problems frequently, and when troubleshooting, code readability and code organization are very important. In fact, the development of the code takes less time, and the real time is to analyze the code and troubleshoot the problem, which is the core of the problem. Therefore, the manually developed code is more intuitive, very readable, easy to add comments, easy to troubleshoot and analyze problems.

    Bit-field based is the most flexible and convenient in practical application, but it is undeniable that Bit-field based is not friendly to new people, and the threshold is relatively high, but if you want to use DSP to do various development, it is a very professional thing, there is no shortcut to go, and you must have a deep understanding to use it well. Trying to lower the bar by relying on Sysconfig doesn't help engineers understand and apply chips.

    In summary, enabling Sysconfig to generate Bit-field based or Driverlib based is not the key issue. In embedded applications, people are very concerned about the flexibility of the underlying configuration, the readability of the code, the subsequent maintenance, and whether there is enough comprehensive routine code to refer to. The previous 28335, the use of Bit-field based to develop code, its readability is very high, the routine is also very much, everyone likes to use.

    It is hoped that TI officials can treat Bit-field based and Driverlib based (including Sysconfig) equally, and provide the same technical data and reference routines for users to choose and use. The user is God. The user's choice represents the final technical route.

  • 0 in reply to tian kong
    TI__Mastermind 30185 points

    Hello Tian,

    We appreciate your honest feedback and I've passed this on to the software development team. As of now we cannot make any commitments as far as when a change like this might be addressed. If the software development team does decide to expand bitfield support, then the action will happen in the farther future. I will close this thread, since there is no further action that can be taken currently.