Hi @hollie, @Timur,

 

Feedback is always appreciated, so if you have specific comments for Simplicity Studio, we'd love to hear it.  I will ensure @jpitt is looped into the conversation and can feed it back into the development team.

 

Thanks for the input regarding the SDK.  I will reach out to the firmware development team to discuss this in more detail and will let you know if I have any updates.

 

I've also updated github readme pages with a notice that they're not currently being updated.

 

~Tabi

Hello @Tabitha,

 

OK, thank you.

 

Best regards,

 Lieven.

Hi @Tabitha & @jpitt

 

It's nice to know that you are interested in this sort of customer input.

So, my trouble with Simplicity Studio is:

• Startup time is very slow
• Searching for updates and downloading updates is slow
• Downloading assets (datasheets, appnotes, etc.) is very slow
• Debugging is unreliable (although this has been improved since v3) in DEBUG OUT mode:
  sometimes it just doesn't recognize the connected EFM32, when JLinkExe does
  sometimes debugging hangs right after start
  (NOTE: restarting Simplicity Studio, and/or 'siagentarm' along with deleting all breakpoints sometimes can fix these issues)
• Minor issues (these I could live with):
  the dark theme can hand or crash studio entirely
  studio's code model gives unreasonable warnings sometimes

With the approach to use JLinkGDBServer with Qt Creator, I all of the "very slow" issues are eliminated, and this setup feels a lot more reliable too.

 

Hope this helps,

Timur

Hi @Timur,

 

Thanks for the feedback, it is always appreciated.  We do try to make improvements to Simplicity Studio as we go.  We have been working on the start up speed of Simplicity Studio in the most recent releases as that is one of the most common complaints, though we still have a way to go.  Changing how often Simplicity Studio checks for updates is a simple way to have some effect on the start up speed.

 

I know it takes time, but for the debug reliability issues, it would be good if either a forum topic or support case is raised when an issue is found, especially if there are repeatable steps.  We will create a bug report and then work on getting that quickly fixed.

 

We have also been working on improving the dark theme across the various perspectives and OS platforms, but I don't know if we've heard of it crashing or hanging Simplicity Studio.  The changes aren't complete yet, but will hopefully be rolled out within a few releases.

 

As far as the code model warnings, these are for the most part configurable in the C/C++ Code Analysis preferences.

 

Any way it does sound like you have figured out a development approach you are happy with using JLinkGDBServer with Qt Creator, so that is the main thing.  If you give Simplicity Studio a try again, please continue to point out any issues you find that hinder your development.

 

Thanks again,

jpitt

Hi @Tabitha,

 

It really is a shame that you have abandoned the Gecko SDK on GitHub. I was really hoping that it being there indicated that more software was to follow, and that you were heading in a more open direction instead of the other way around. I assume that your software distribution model is driven mainly by a desire to show click-through license agreements.

 

It makes a lot of sense to distribute your libraries and sample code as a git repository, because that is how software developers are used to handling code. It makes it very easy to include the libraries in our products (as a git submodule), and it's straight forward to see when there are updates (git pull) and what was updated (git log). At the very least, you should let us download versioned packages from an open server with stable URLs.

 

The process right now to find updates to software is to start Simplicity Studio, go for a coffee while it downloads updates, then dig around in its installation directory to see what might have changed. This might seem friendly to new users, but it quickly gets very tedious. Having an absolute requirement on Simplicity Studio also makes it difficult in situations when it's not installed, such as working remotely, helping out on colleagues' projects, or in three years when you have inevitably moved on to something else.

Hi @j-n,

 

Thanks for the feedback!  I've passed this along to the internal teams for discussion, and I will let you know as soon as I have more information.

 

~Tabi

Hi @Tabitha,

I just wanted to mention that I regret the decision very much.
In my case, I do not use Simplicity Studio at all. I use only open tools for developing. Especially since this was very easy with Silabs devices in the past, I chose Silabs MCUs.  Now I have to install  Simplicity Studio only to download the SDK.

Important arguments for Github are:
- issues can be tracked easily according to versions
- people can contribute their improvements 
- Gecko SDK can be easily included in own projects, e.g as git submodule
- easy access to the SDK without Simplicity Studio

I would appreciate it if Silabs continues to support Github.

Best Regards,

jobroe

Hi Tabitha,

Is there any update on this?

I am very surprised to see this action taking place, despite the difficulties with maintenance. Which on the surface make sense, but really it sounds your SDK team just need to find a better way of operating: syncing segments of a package to a repo shouldn't be difficult. If it is then you need to find better people.

Is it just maintenance troubles or does management actually think people want to use SimplicityStudio? Isn't that just a token IDE for prototyping? I'm not sure about Silabs' impression of the industry, but it's certainly not standard practice to engage in long-term development through vendor specific environments. Vendor-IDEs should be reserved for teaching in the classroom and evaluating in the boardroom, period.

 

If Silabs continue forcing the use of SS, just to access vital product code, then I'm afraid I will have to look elsewhere for a vendor with a more professional outlook.

 

Thanks

MM25

Having and supporting an (open!) SDK without a bloatware IDE makes perfect commercial sense for any mcu vendor. A (semi) lock-in via some IDE makes the choice for EFM32 a harder to justify. All of a sudden STM32 seems like a good option now: STM32 arguably the line of cortex-M MCU's with the best open SDK, framework, SDK and language (Rust anyone?) support. 

C'mon SiLabs, get your stuff together. You're dropping the ball. 

 

Ps. Look what happened to Espressif -the other way 'round- by embracing the OOS community (and fully supporting a full featured, well documented open SDK)  Support for Espressif products has been unprecedented since.

 

Hi all,

Unfortunately, this issue is more complicated than just using git to push the SDK releases on Github, as there are several licensing and legal complications. We’re continuing to discuss this internally and will let you know when we have more we can share.

~Tabi

I want to adhere to the opinion of the many developers here:

- I also have downloaded Simplicity Studio just for downloading the SDKs

- Please consider at least distributing the free bits (Gecko SDK/emlib/emdrv/etc) using git (not necessarily Github) or something similar.

- For instance: you recently announced that you will be dropping Silabs Thread in favour of OpenThread. OpenThread continuous integration (here: https://github.com/openthread/openthread/blob/master/.travis/script.sh) can build all platforms, except for Silabs', just because there is no way to obtain the SDK. Look at what Microchip is doing (here: https://github.com/openthread/openthread/blob/f0a753c0a93c5fc79cbf63a67a6c0cea51ce4d05/.travis/script.sh#L317); at least they provide a downloadable link.

- I take the opportunity to ask you to make RAIL open source also. It really would help the EFR32 reach more developers.

Thank you.

 

Diego.

Hi Diego,

This is very helpful feedback, and I've passed this along internally for consideration.

All,

If there's any other feedback about what would be helpful in how we distribute the libraries and code, please let us know.  As I mentioned, we're continuing to discuss how we can do this in a better way internally, so the more feedback the better!

~Tabi

The Silicon Labs Gecko SDK is software development kit developed by Silicon Labs for the EFM32, EFR32 and EZR32. It contains the basic software needed for development, covering everything from the low-level hardware abstraction layer (HAL) and peripheral drivers to communication stacks and example code. The Gecko SDK is also part of the Simplicity Studio toolsuite from Silicon Labs. Downloading Simplicity Studio also gives you access to a large range of tools, like Configurator and Energy Profiler together with access to all software and documentation.

This will help in our discussion for adding this support.

 

Thanks,

gbwhatsapp