adarshw

The APP store or our favourite "Channels" should FEEL better on the headset.

True - You know what they say - if you aren't paying for the product, YOU are the product.

I really believe in AI-as-an-assistant to every job being used by a billion people in the next 5-10 years.

Oh man, I've been bullish on AR/VR for years - but it never took off. I think the technology ( read: Hardware) just never reached the level of convenience one needed to make it go mainstream.

Wait. I love that idea - Flipping the goal from getting acceptance to getting rejection is a really good idea. It suddenly seems way more plausible to achieve.

True - In my little experience, cold calling/ mailing people seems to not be well received. They would rather be connected through a 'warm' lead. How would I overcome this initial resistance?

This is great - thank you so much!

Oh I didn't know about the monthly feedback thread - it'll be awesome if they ever end up doing that. I was thinking of reddit too - but I am not in the right subreddits yet, so will need to figure that out. Will definitely try Linkedin!

I think TI does, but haven't worked extensively there.

While docker, can be used to build the firmware for SES, it is not a scalable solution as the docker image will have to be kept updated for each new update of SES. Segger being Segger, changes things in their toolchain very frequently. If you're interested in automating builds on SES using Docker, you can check out our docker image for SES on GitHub here: https://github.com/vicara-hq/ses-docker-images

However, most hardware toolchains and examples out there use Keil, which is Windows only and DOES NOT have a headless mode, making it utterly impossible for a docker image or a CI tool to automate the build process.

The best way to approach this would be to use Makefiles on Docker for the projects that we build, making it cross-platform as well as CI-friendly, which is an approach that we plan to take with the configuration tool, automating the entire process for ease of use in any environment.

Oh yes! In fact that's kind of where the inspiration for the project came from. We were like, hey - doesn't Nordic have anything like this?

Totally agreed! The reason we do this for a fully muxed system like Nordic is just to make life a little easier when starting a project from scratch. Because it's not just the pin configuration that's covered, it's also the sdk_config.h and the .emproj file. We also get to remove some of the bloat that example files tend to carry with them when we do this.

We do plan to support other manufacturers as well. This actually started as an internal tool for us to speed up our configuration. We thought it'd be helpful to make it available to other hardware devs as well.

We are working on the file format for the same and plan to open source both it and the tool sometime soon! So you won't have to be limited to this tool or the MCU's that we've actively developed.

Great question! We're actually working on a standard for the same and plan to open source it. We aren't currently aware of any other global standard for the same.

We intended it to be similar, but we hope to expand the functionality to more complex features like logic programming and inbuilt drivers. We definitely want it to be less shitty, so just for the sake of argument - what exactly did you find shitty about START?