Close
/////////////Basics////////////////////////////////////////////////////
Developing legacy WICED BT projects in ModusToolbox requires the shared project wiced_btsdk to be correctly configured in the workspace. For details creating project wiced_btsdk, see below:
Q: Will Library Manager do the work?
Normally, to update the libraries in a project, we use Library Manager provided by ModusToolbox.
In this case, Library Manager won't give much help here. Because it can only update the Libraries and WICED BSPs inside the project wiced_btsdk, while it can't update the whole project itself, a.k.a. the framework. So if only Library Manager is used, then you will be using the latest BSPs via the old wiced_btsdk framework, which will cause you errors. (This is because the directories like btsdk-include in wiced_btsdk will stay in older version in this situation, which won't provide the correct reference to the latest BSPs).
We notice that, wiced_btsdk is managed by Git, a version control system. Hence we can use Git to update the entire project to the latest version, to avoid the issue stated above.
So this blog illustrates how to use Git to update wiced_btsdk in ModusToolbox. For better practise, the demonstration uses Eclipse IDE for ModusToolbox 2.2.
Q: Can I only follow the universal process of using Git in Eclipse to get the job done?
Normally, to update a project in Eclipse, you can right-click on wiced_btsdk and then choose Team => Pull.... Somehow this universal process doesn't fit in wiced_btsdk because it adopts different library management in it.
In order to update wiced_btsdk soundly, you should follow the flow stated below.
Q: Will this blog apply to ModusToolbox 2.2 or later?
The answer only depends on whether the project wiced_btsdk exists in your workspace. The version of ModusToolbox is irrelevant.
If you import the latest version of WICED BT code examples that support MTB flow, then it won't require the project wiced_btsdk (Instead wiced_btsdk and it's BSPs are moved to the new shared project named mtb_shared). So the project wiced_btsdk won't exist in your workspace. Hence this blog won't apply to this situation. This kind of projects follow the unified workflow and they are called the unified MTB projects in this blog.
But if you insist to develop WICED BT applications in the legacy style (i.e. staying in the old versions of the code examples) that support LIB flow, then the project wiced_btsdk is still needed and wiced_btsdk probably exists in your workspace already. Hence this blog will apply to this situation. This kind of projects follow the legacy workflow and they are called the legacy MTB projects in this blog.
In other words, all versions of ModusToolbox (<MTB2.2 or >=MTB2.2) support legacy MTB projects. Since wiced_btsdk is a legacy MTB project, this blog applies to all versions of ModusToolbox, including 2.2 or later.
In fact, the main purpose of this blog is trying to enable the legacy WICED BT projects to get the latest wiced_btsdk (2.8.0 or later) while preserve the old developing workflow.
This is useful when you have a heavily customized legacy WICED BT projects that you have difficulties migrating it to unified MTB projects, but you still want to get the latest wiced_btsdk and the latest ModusToolbox for it.
Besides, this blog applies to all ModusToolbox projects in all versions of ModusToolbox, no matter what dependency flow it follows (LIB flow or MTB flow), and what version ModusToolbox is, (<MTB2.2 or >=MTB2.2). This is because, It's merely about version control. It's not about dependency flow or ModusToolbox features.
/////////////Demonstration////////////////////////////////////////////////////
/////////////Note////////////////////////////////////////////////////
/////////////Reference////////////////////////////////////////////////////
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.