Refactor sdk sources into a single subdirectory

[rockaport]

In preparation for submitting a PR for bluetooth support I'd like to refactor the directory structure of sdk components into a single subdirectory. There's a couple of reasons for this.

1. The directory names are different e.g. cmsis vs CMSIS
2. It better supports a copy script that we could make to easily update the sdk sources for future sdk releases (assuming SILabs doesn't do any major refactoring). For the last PR I was doing this manually which kind of sucked.

I have the bluetooth/rail sample working, but I need to clean some things up before submitting that PR. Here's the branch that has all the current changes I'm proposing.

andrew@mega:~/work/efm32-base$ tree -L 2 sdk
sdk
├── app
│   └── bluetooth
├── hardware
│   ├── CMakeLists.txt
│   ├── kit
│   └── module
├── platform
│   ├── base
│   ├── bootloader
│   ├── CMSIS
│   ├── Device
│   ├── emdrv
│   ├── emlib
│   ├── halconfig
│   ├── hwconf_data
│   ├── micrium_os
│   ├── middleware
│   ├── radio
│   └── release-highlights.txt
└── protocol
    ├── bluetooth
    └── flex

[ryankurte]

hey seems like a great idea to me! i love the idea of scripted updating, and possibly having it self-bootstrap by downloading an SDK image so this repo could be so much simpler (though there wasn't a source to download the SDK outside of simplicity studio when i wrote this).

branch looks p good, do common/source/include need to be in the root? looks like they're all Silabs provided files at the moment? (the idea initially was to have a simple / minimal project layout that you could clone and work from, but if it's full of SDK stuff this might not be so clear?)

heads up that i'd like to land #10 before we make that super difficult again, so there will probably be rebasing down the track.

[rockaport]

hey seems like a great idea to me! i love the idea of scripted updating, and possibly having it self-bootstrap by downloading an SDK image so this repo could be so much simpler (though there wasn't a source to download the SDK outside of simplicity studio when i wrote this).

No, I don't think there is a source to download the SDK components outside of Studio. I've been downloading everything through that and copying it over. The idea is you would point the copy script at STUDIO_SDK_DIR or something and it would handle the local copy.

branch looks p good, do common/source/include need to be in the root? looks like they're all Silabs provided files at the moment? (the idea initially was to have a simple / minimal project layout that you could clone and work from, but if it's full of SDK stuff this might not be so clear?)

No, I would revert back to your minimal main.c example. This is just showing a working project of the SiLabs bgm13 app example. The thought crossed my mind to to have branch specific sample implementations with source/common/include specific code.

common is kind of funky because sdk components have circular dependencies on app specific header files. I think that could be left alone or removed, it doesn't matter. I'm going to revert source and include or make them git branch based examples. Probably the latter.

heads up that i'd like to land #10 before we make that super difficult again, so there will probably be rebasing down the track.

That's fine. I probably won't be ready for another few weeks anyway. I just wanted to run this past you.

[eflukx]

edit: Only just saw this issue is a year old now, is this issue still active?

Was just planning to move all sdk stuff into its own directory. Seeing this issue, backing off for now as someone else seems to be already fixing this! 😉 👍 Have a lean efm32-base (without a few 100mb's of SDK cruft) I can only applaud! Would it be an idea to host the SDK stuff in a separate Repo? (don't know if Silabs licencing allows this. though..)

[rockaport]

I did the refactor and SDK integration and it's still in this branch from last year. Since it's been so long the SDK is probably outdated, but my changes did work for the BG device I was working on.

I'll leave it up to you on next steps. I don't have the badwidth right now to make any further changes, so if you'd like to review and cherry pick changes that might be best.

[ryankurte]

@eflukx i'm happy to land this if you do cherry pick things. unsure whether it is valuable to put the SDK in a separate repository given the reasonably tight coupling between components, but, okay either way.

there was a brief period of time where the sdk was available on github, which, would have been perfect. the next best option might be to embed the download url that simplicity uses (which may require the user input their credentials) and ExternalProject_Add it.

[jerrylogansquare]

why not have Gecko SDK as a git submodule? or use the Repo tool with manifest?

[ryankurte]

why not have Gecko SDK as a git submodule?

i am cautious of the external dependency as this repo has existed and been removed in the past, but we could submodule in a fork (or, contribute this collection of CMake back upstream i suppose!)