• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 515 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.

TMS570LS1224: HALCOGEN usage by more designers and influence of the modifications

Stefan Agasvari
Intellectual 835 points

Part Number: TMS570LS1224
Other Parts Discussed in Thread: HALCOGEN

“Our goal is to have only one developer who will work with HALCOGEN safety package, but on other hand we have few developers in Brno and Bangalore and they need to change setting for different peripherals and they need to add/modify USER CODE in generated files. The challenge is how to serialize requests … Change in one peripheral may affect other and it may modify USER CODE, we have seen this phenomena before L Modify mean: Once is some peripheral enabled and user code is entered, it disappears once peripheral is disabled and enabled again. This may happened accidently L Other case is one developer modify configuration, generate files commit those files into SVN, other developer perform same task in parallel and duplication of the user code is created.  We need to minimize this L is there any recommended usage of HALCONGE by TI? “

  • 0
    TI__Guru 59540 points
    Hi Stefan,

    There are no specific recommendations from TI on how to use HalCoGen in a distributed development environment. However, just as in any project, there should be some top level project files that are controlled. In this case the .hcg and .dil files that control the code output of Halcogen should be key files controlled under your CMS tools.

    One possible method would be to allow anyone to make updates to the hcg and dil files. Anyone making changes to them would need to check them out, modify and check them back in. This way any content that is updated for their specific part of a project is kept in synch with the other module configurations controlled/owned by others on the team. Also note that although Halcogen will create all the files over again, only the driver files and parts outside of the sections marked "USER CODE SECTION" are updated. All this would involve some fairly detailed discipline in configuring and using the driver files.

    A second approach would be to only give select persons access to the .hcg and .dil files for Halcogen in the CMS tool. i.e., limit personnel that can make updates to the baseline code to aid in control of the overall project. Effective ness depends on the size of the team and project and proximity of the engineers working on the project.

    A third option would be to have an initial config using Halcogen, but then build on top of this base build the old fashioned way and make manual updates. The ability to updgrade to new HalCoGen generated code for corrections or improvements becomes trickier in this scheme since the code becomes separated and out of synch from Halcogen.

    Finally, each developer could use Halcogen to configure and output code for the specific drivers. After driver generation, only the files that apply could then be copied into the mainline project and uploaded to the CMS system. In a sense, this is almost the same as traditional development. i.e., check out task related files, update, test updates in local project copy, then check in the task related files to the bigger mainline project. This scheme would obviously need to include the hcg and dil files as well so the targeted IP starting point was in synch with the project that is checked in and subsequent changes are also checked in.

    Hope these ideas help. In the end, its creative use of the tool and control of the .HCG and .DIL files.