Installing BT SDK on Linux using Wine is tedious, has filename capitalization errors. Copy BT SDK files manually?

Is BT build on Mac OSX being 'beta' and 'experimental' imply that it is more (or less?) robust than build on Linux?  Beta implies to me that TI plans to evenutally support it (when it goes from beta to final), while experimental implies it is not even beta quality.  While the Linux page says Linux build  is not supported by TI, only by users.

The Mac OSX Beta page says you can just copy the files from a Windows installation.  Could you please just provide said files in an archive?

(Also that page says said it would help to build BT Stack on Windows first because it creates needed libraries, but why wouldn't those libraries be cross-compiled for the target and thus completely portable, not necessary to build on any specific host OS?)

Now I find that it is not Wine at fault, but the fact that Windows filesystem is case insensitive. It seems the code includes a file '#include "Foo.h"' and the file is really named foo.h. (I used the installer on a Windows platform, the file name IS foo.h) So on Windows this code compiles, but not on any other platform. Is that correct?

Are there any plans to change this situation?

Is the BT stack open and is there a repository with a version where this might have been changed?

Thanks. Re support: I suppose there is a difference between official upper-case Support where one has privileged access to a TI support website, and lower-case support such as this forum and the helpful FAQ and wiki pages for other platforms.

Re Github: I don't think the capitalization issues are limited to the example source code.  So volunteers cannot submit patches for the capitalization issue.

Just to be clear about what would be nice:

1.  Fix capitalization issues in the code  e.g. #include "F.h" where the file is actually named "f.h", depending on what your definition of Is is.

2.  Fix capitalization issues in the project's linked resource variables and paths

3.  Add one more level of project linked resource path e.g. BLE_SDK_ROOT and use it wherever "C:\ti\ble_sdk..." is used.

4.  Provide an archive of the SDK not wrapped by an installer.

IMHO those changes are low risk and benefit TI's hacker/maker/learner user base.

I blogged about patching TI's lib_search tool for linux.

Now I am working a seg faulting ARM linker issue that apparently TI's compiler group has  has already fixed.

Hi Lloyd,
maybe I can add something to the confusion, as I’m a software developer (like you seems to be) too :-) The TI BLE build process consists of two (nearly) independent projects. One is an image that implements the BLE core features (Link layer, etc) and one implements the rest and your application.


The layout in flash memory is that your application image starts at the flash start address, while the stack image is placed at an address that is defined through two configuration files (css_compiler_defines.bcfg/css_linker_defines.cmd [same syntax and {better} same content]). When you build the application image, a map file is written, both as human readable text and as xml. When the stack image is build, prior to linking, there is a CDT preprocessing step that reads the xml form of the applications image map file to determine how much RAM and ROM that application image consumed. That frontier/border preprocessing tool now generates that configurations (css_compiler_defines.bcfg/css_linker_defines.cmd).


But more important, it defines the start address of the stack image to the application image and thus a function pointer that is placed at the beginning of the stack image use by the application image to „communicate“ with the stack image. And thus you have to rebuild the application image, if the application images size exceeded the next flash page.


Sounds complicated? Yes, it is. When I’ve asked, why we can’t have just a bunch of headers and (static) library files, the answer was: „because this architecture allows the application and the stack to be updated on it’s own“. As the OTA (over there air updates) process is implemented within the application stack and the start of the stack image is compiled into the application stack, it’s (nearly) impossible to change that border afterwards. So you better decide on you own, how much memory to reserve for your application and how much to spend for the stack image. The frontier tools is a nice tool, but I wouldn’t use it if I where interested in OTA.


The second tool is the lib_search.exe that determines a set of libraries that have to be linked into the stack image according to a configuration that defines which bluetooth features to be supported by the application image. In my case (the famous SimplePeripheral) this results simply in three libraries being added to the linker command line, when building the stack image. Don’t ask me, why we need a tool to determine the libraries to link against! Maybe there are thousands to pick from and I’m just lucky with this three. And I don’t understand why we couldn’t just add _all_ libraries files to the linker and just let the linker do it’s job and add missing symbols.


@Dear TI people, please bear with me if there are mistakes in my descriptions. I know that your main target audience are electronic engineers which are asking for „working examples“.

cheers
Torsten

OTA is also known as OAD (in the TI code e.g. #ifdef OAD).  I have no use for it, it just complicates the build process.  90% of the build complexity for 10% of the use cases.   If products are throw-away devices, why would you need OTA in your product.  To fix security flaws?  Who builds the supporting machinery: internet connection or a central server of the updates? Does it happen automatically, or does the consumer have a GUI to authorize the OTA?  I suppose it looks forward to washing machines controlled from your browser.

Re the capitalization issues and build tools.  In building Project Zero (on CCS Cloud and CCS Desktop) I was surprised to find it does not suffer the capitalization issues and doesn't use pre and post build tools (or at least not the same tools?)  I could be wrong but it seems like TI has already changed the  build process and that only some example projects use an older build process.  (I have not succeeded in building a working Project Zero in either CCS Cloud or CCS Desktop, using Linux)