commercial IDE for microchip parts including Amel SAM stuff

[westfw]

>> The next-generation MPLAB IDE is based on Microsoft Visual Studio Code and Eclipse Theia™, providing existing VS Code® users with a familiar development environment.

> You mean they have seen the light and will release a new MPLAB based on visual studio?

Note that "Visual Studio" and "Visual Studio Code" are two significantly different products.

[tellurium]

I am interested in an IDE paid is fine to work on microchip/atmel sam parts. Any recommendations? I'm not after a ton of libraries, I am really just interested in an IDE that works without being a computer scientist and linux guru.

Can you be more specific about the target MCU, please?

Also, what are the most important things you're looking for?

[Simon]

I am interested in an IDE paid is fine to work on microchip/atmel sam parts. Any recommendations? I'm not after a ton of libraries, I am really just interested in an IDE that works without being a computer scientist and linux guru.

Can you be more specific about the target MCU, please?

Also, what are the most important things you're looking for?

I'm a bare metal programmer. Fact is a micro is not a PC, there is no standardization, only across the same line from the same vendor so I don't go in for the STM-HAL style stuff. So my needs are limited. I just want it to work on a 4K monitor like any modern program should and be able to write and compile code. Debugging would be preferable.

[PlainName]

Fact is a micro is not a PC, there is no standardization, only across the same line from the same vendor

That is exactly why I use a third-party IDE/Editor. In my case it's Slickedit but if could be VSC or Eclipse or whatever floats your boat. The fact is you're going to be spending most of your time editing, so something you are used to and can drive blindfold would be ideal for any and all projects. It won't happen if you use ANOther manufacturers IDE, as you note.

So that's why I suggested you say what's important to you, and concentrate of a solution for that. If your choice of editor doesn't do source-level in-circuit debugging it's not the end of the world - you should need that debugger not very often, and in those cases it's surely not that onerous to just switch to the 'official' IDE just for that. But any serious editor will let you run, say, DBG under the bonnet and likely then provide in-editor source-level debugging anyway. If it's a proper developers editor you'll be able to run CLI commands from it, so the edit-compile-fix cycle can still be done in that editor.

The massive advantage of that approach is that you won't be here asking this again because whatever you are working on, your tool is already sorted and will be the same for all of them. It's just the compiler and flasher/programmer commands that change, and all that should involve is a profile in your editor.

[Rafiki]

I'm also a long time Slickedit user (on different platforms). I always set in Slickedit the build command to <F5> which calls the compiler/make. Be it make, nmake, wmake, crossbuild, uVision, .... For Cortex-Mx I use Rowley Crossworks as programmer/debugger set to 'auto reload external changed source files'. Only drawback for using different 'IDEs' is, you've to manage the project files in two different programms (Crossworks and Slickedit). But I find this less annoying than relearning different editors every time I switch targets.

[tellurium]

I'm a bare metal programmer. Fact is a micro is not a PC, there is no standardization, only across the same line from the same vendor so I don't go in for the STM-HAL style stuff. So my needs are limited. I just want it to work on a 4K monitor like any modern program should and be able to write and compile code. Debugging would be preferable.

Then IMO it is largely a matter of taste, and tastes vary a lot.

I spend quite a time writing bare metal, and my preferred way is to use just plain GCC + make + editor. No IDE.
Debugging - printf, but in rare cases when I need an interactive debugger - Segger Ozone.
If you want to try this approach, here's how:

1. Setup your environment (ARM GCC, git and make): https://mongoose.ws/documentation/tutorials/tools/
2. Build test project:
    git clone https://github.com/cesanta/mongoose
    cd mongoose/examples/microchip/same54-xpro/device-dashboard
    make

That will give you a working bare metal app for SAME54.
Remove all mongoose stuff, and you'll get a baremetal skeleton with simple HAL on top of CMSIS, which you can expand the way you want.

[Perkele]

what I lack is how to set up the entire tool chain. So I aim to learn to do it on the command line so that I understand the entire process. then I can go looking for another IDE an understand how to set it up. Looked at uVision 5 it's crap, it won't do uint8_t type, types, as soon as I include inttypes.h the compiler does not like it's contents.

inttypes.h was introduced in C99. Could it be that you've selected C90 or C89 as the C standard in project's options.