Closed KevWal closed 1 year ago
That would be a really cool feature to have, but I haven't even gotten it to work on my mac. It takes about three minutes to open the new IDE, and even though I have lots of manually installed Arduino cores, none of them shows up.
But is there initial support for AVR debugging in the new IDE? I thought it was only for ARM chips...
Thanks for the quick reply! They say:
https://blog.arduino.cc/2021/03/01/announcing-the-arduino-ide-2-0-beta/
As of today, the debugger supports all the Arduino boards based on the SAMD and Mbed platforms (MKR family, Nano 33 IoT, Nano 33 BLE, Portenta, Zero). Maintainers of Arduino cores for third-party boards can add support for debugging by adding the relevant configuration parameters; a technical guide for this is coming. You’ll need to connect a debugging probe such as the Segger J-link to the JTAG pins on the board and you’ll be ready to go.
The new IDE is based on the Eclipse Theia framework, which is an open source project based on the same architecture as VS Code (language server protocol, extensions, debugger). The front-end is written in TypeScript, while most of the backend is written in Golang.
even though I have lots of manually installed Arduino cores, none of them shows up
They aren't supported yet: https://github.com/arduino/arduino-ide/issues/126
But is there initial support for AVR debugging in the new IDE? I thought it was only for ARM chips...
There is some interesting discussion about it here: https://github.com/arduino/arduino-ide/issues/87
This is the debugger: https://github.com/Marus/cortex-debug which says:
Debugging support for ARM Cortex-M Microcontrollers with the following features:
but there was this interesting issue thread: https://github.com/Marus/cortex-debug/issues/13#issuecomment-381001391
As for supporting other MCUs that are not Cortex-M based - I'm not really opposed to the idea. Looks like for use within the platform.io ecosystem you'd be interested in MSP430, Pic 32, and AVR
but I don't see any evidence of progress on that.
@per1234 I haven't followed the IDE 2.0 discussion on Github, but are there know issues related to the macOS port?
I tried to install the latest 2.0 beta on my Windows computer, and manually installed packages did show up and I was able to compile code with them. However, I was only able to select a board (e.g ATmega1284), not any of the other options like BOD level, bootloader/no bootloader, EEPROM retain etc.
However, on my mac it doesn't show any of the manually installed boards, and none on the boards manager boards either. The boards manager menu is also empty.
Log:
Thanks @MCUdude. I investigated the issue and submitted a report to the developers.
When a platform is installed to {directories.user}/hardware
without a version folder, Arduino CLI uses the platform.txt version property to identify the platform's version.
We are accustomed to be able to use previously defined properties within property definitions in the platform configuration files, and having those properties be expanded. However, this is not currently supported by Arduino CLI for the version
field, which causes a panic when this is done due to the version not being parsable according to "relaxed semver".
You can see that DxCore does this: https://github.com/SpenceKonde/DxCore/blob/1.3.4/megaavr/platform.txt#L8-L14
versionnum.major=1
versionnum.minor=3
versionnum.patch=4
versionnum.postfix=
versionnum.released=1
version={versionnum.major}.{versionnum.minor}.{versionnum.patch}{versionnum.postfix}
$ git clone https://github.com/SpenceKonde/DxCore --depth 1 -b 1.3.4 ~/Arduino/hardware/DxCore-dev
...
$ arduino-cli core list
panic: no major version found
goroutine 1 [running]:
go.bug.st/relaxed-semver.MustParse(...)
/go/pkg/mod/go.bug.st/relaxed-semver@v0.0.0-20190922224835-391e10178d18/parser.go:19
github.com/arduino/arduino-cli/arduino/cores/packagemanager.(*PackageManager).loadPlatforms(0xc0000c79c0, 0xc000859080, 0xc000b1e720, 0xa, 0xc0009a5dc8)
/home/build/arduino/cores/packagemanager/loader.go:175 +0x17f3
github.com/arduino/arduino-cli/arduino/cores/packagemanager.(*PackageManager).LoadHardwareFromDirectory(0xc0000c79c0, 0xc000a8c4a0, 0x0, 0x0)
/home/build/arduino/cores/packagemanager/loader.go:120 +0x56c
github.com/arduino/arduino-cli/arduino/cores/packagemanager.(*PackageManager).LoadHardwareFromDirectories(0xc0000c79c0, 0xc000a8c4b0, 0x2, 0x2, 0x0, 0x0)
/home/build/arduino/cores/packagemanager/loader.go:45 +0x6f
github.com/arduino/arduino-cli/arduino/cores/packagemanager.(*PackageManager).LoadHardware(0xc0000c79c0, 0xc00012f980, 0x0)
/home/build/arduino/cores/packagemanager/loader.go:34 +0x46
github.com/arduino/arduino-cli/commands.createInstance(0x120df20, 0xc0000940b0, 0xf43c00, 0xc000a87a01, 0xc000a8de30, 0xc000ac7b18)
/home/build/commands/instances.go:713 +0x84c
github.com/arduino/arduino-cli/commands.Init(0x120df20, 0xc0000940b0, 0xc00051fc68, 0xc000a87aa0, 0xc000a8de30, 0x50, 0x50, 0xc0000753b0)
/home/build/commands/instances.go:135 +0x5c
github.com/arduino/arduino-cli/cli/instance.getInitResponse(0x6010100, 0x1, 0xc000ac7d78)
/home/build/cli/instance/instance.go:51 +0xd1
github.com/arduino/arduino-cli/cli/instance.CreateInstance(0xc0000753b0, 0xa, 0xa)
/home/build/cli/instance/instance.go:41 +0x2d
github.com/arduino/arduino-cli/cli/core.runListCommand(0xc000605600, 0x19d14a8, 0x0, 0x0)
/home/build/cli/core/list.go:52 +0x3b
github.com/spf13/cobra.(*Command).execute(0xc000605600, 0x19d14a8, 0x0, 0x0, 0xc000605600, 0x19d14a8)
/go/pkg/mod/github.com/spf13/cobra@v1.0.1-0.20200710201246-675ae5f5a98c/command.go:846 +0x2a4
github.com/spf13/cobra.(*Command).ExecuteC(0xc0000d38c0, 0x0, 0xc000a7d680, 0x0)
/go/pkg/mod/github.com/spf13/cobra@v1.0.1-0.20200710201246-675ae5f5a98c/command.go:950 +0x350
github.com/spf13/cobra.(*Command).Execute(...)
/go/pkg/mod/github.com/spf13/cobra@v1.0.1-0.20200710201246-675ae5f5a98c/command.go:887
main.main()
/home/build/main.go:31 +0x8c
Thanks for your reply @per1234!
We are accustomed to be able to use previously defined properties within property definitions in the platform configuration files, and having those properties be expanded. However, this is not currently supported by Arduino CLI for the version field, which causes a panic when this is done due to the version not being parsable according to "relaxed semver".
So this means that there isn't anything wrong with MightyCore or DxCore, it's the IDE that struggles to parse the version?
Because version=2.1.2
seems correct to me according to semver?
The MightyCore version
value should be perfectly fine. If anyone observes any problems with MightyCore and Arduino CLI, please let me know.
It's the unusual approach taken in DxCore that is problematic:
versionnum.major=1
versionnum.minor=3
versionnum.patch=4
versionnum.postfix=
versionnum.released=1
version={versionnum.major}.{versionnum.minor}.{versionnum.patch}{versionnum.postfix}
I don't see any reason why that shouldn't be supported, so at this point I would say that it's a bug in Arduino CLI that it is not working. If the decision is that properties expansion is not done the version
field, then I would like to find some way to clearly document this limitation.
MightyCore works with IDE 2.x now.
Hi
Would you consider adding live debugger support for MightyCore to Arduino IDE 2.0, or is that something you would see remaining only on Platform IO? Trying to decide what IDE I use for my upcoming 1284 project....
Thanks very much Kevin