BGM13P Integration

[rockaport]

I'm working on integrating a BGM13P22F512GA device (BGM13P22 Blue Gecko Module Radio Board BRD4306A) and I'm running into an issue regarding the linker script. Well probably more than just the linker script. There are different linker scripts depending on the device and I didn't want to duplicate the entire BGM13P directory just to change the linker script.

Do you have any suggestions for the best approach here or am I missing something? I'm also wondering about the sdk/hardware subdirectory. Is the intent of this repository to just support chips and not modules or kits?

[ryankurte]

I'm running into an issue regarding the linker script

what kind of issue?

There are different linker scripts depending on the device and I didn't want to duplicate

if you need to be able to override the default linker script it would be viable to add a check here to skip inferring which script to use if LINKER_SCRIPT is already defined.

Is the intent of this repository to just support chips and not modules or kits?

yeah the intent is chips/modules but not kits/boards. recommendation would be to copy any board support stuff you need into your project, on the basis that most projects tend to move to custom hardware anyway it seems simpler to leave that to users / impossible to solve for all users.

if there's stuff that's generically useful for the BGMs that'd be a good addition.

[rockaport]

That seems to be it for now. There are different linker scripts depending on the module/device. Here's an example of the BGM13/Source/GCC dir

andrew@mega:~/work/efm32-base/device/BGM13/Source$ tree GCC/
GCC/
├── bgm13.ld
├── bgm13p22f512ga.ld
├── bgm13p22f512ge.ld
├── bgm13p32f512ga.ld
├── bgm13p32f512ge.ld
├── bgm13s22f512ga.ld
├── bgm13s22f512gn.ld
├── bgm13s32f512ga.ld
├── bgm13s32f512gn.ld
├── startup_bgm13.c
└── startup_bgm13.S

When I copied over the device directory there was a slew of other devices that showed up. I didn't dig into the rest, just an FYI.

andrew@mega:~/work/efm32-base/device$ git status
On branch bgm13p22-v2.6

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        BGM1/
        BGM13/
        BGM21/
        EFM32GG12B/
        EFM32TG11B/
        EFR32BG14P/
        EFR32BG21/
        EFR32BG22/
        EFR32FG14P/
        EFR32FG14V/
        EFR32FG22/
        EFR32MG14P/
        EFR32MG21/
        EFR32MG22/
        EFR32ZG14P/
        MGM1/
        MGM12/
        MGM13/
        MGM21/
        ZGM13/
        em31x/
        em34x/
        em355x/
        em358x/
        em359x/
        em35x/
        sky66107/

if you need to be able to override the default linker script it would be viable to add a check here to skip inferring which script to use if LINKER_SCRIPT is already defined.

That seems reasonable. It was kind of a back and forth between adding a switch on the device family versus allowing more fine grained configuration. Another place this showed up was in regex parsing the CPU_FAMILY in efm32-base.cmake since the device directory is BGM13.

yeah the intent is chips/modules but not kits/boards. recommendation would be to copy any board support stuff you need into your project, on the basis that most projects tend to move to custom hardware anyway it seems simpler to leave that to users / impossible to solve for all users.

That sounds reasonable. I'm in the middle of integrating the hardware/kit/libraries and it's a lot more involved and probably difficult to maintain and support going forward.

And to think all of this started with just trying to integrate jlink targets into CLion so that I could run & debug from there. I stumbled on this repo and it looks pretty good. Thanks for contributing!

After I get through this I'll have a better idea of what makes sense for a PR to support the BGM13.

[ryankurte]

There are different linker scripts depending on the module/device.

ahaha oh nooo

Another place this showed up was in regex parsing the CPU_FAMILY in efm32-base.cmake since the device directory is BGM13.

nothing highlights how erratic the vendor tools and naming schemes are like trying to parse them 😅 expanded regexes and special cases for devices where required seems reasonable to me.

After I get through this I'll have a better idea of what makes sense for a PR to support the BGM13.

neat! definitely happy to receive any PRs ^_^