Arduino 2.0 Known Issues with megaTinyCore #760
Replies: 7 comments 12 replies
-
|
Thanks. What's the big deal with 2.0.0? What does it do that makes it so exciting? It is pathetic that we have to solve problems like this ourselves. And this is a "Release Candidate" version? When they haven't even fixed the bug any product manager I worked with professionally would consider a blocking issue introduced way back in 1.8.14. |
Beta Was this translation helpful? Give feedback.
-
|
I totally despise the 1.x IDE as a code editor. It's bloated awful java that is slow as molasses. Its code navigation, refactoring, autocomplete, and other such things an IDE should do are terrible to the extent they exist at all. Open a half a dozen sketches even on a powerful machine and watch it crawl ... while doing less for you than vim. If I wanted a dumb editor + build I would use the CLI + vim. If I am going to run a bloated IDE it might as well do the things an IDE is supposed to do. I'm also generally averse to letting myself get stuck on obsolete software (which tends to happen in the embedded space). The further behind you fall the harder it is to catch up. I usually assume there are security bugs getting fixed in head of tree and never backported. For example, the version you recommend has an old vulnerable version of Log4J that allows trivial code execution. I'd rather not think deeply about under what conditions it might be exploitable. It takes some work but I now have an example of getting a fairly horrible 2.0 bug fixed in a couple days by pointing out the issue in GitHub didn't really demonstrate the severity. I agree with your assessment that the RC feels more like a beta but such is life. Your cores are popular enough that I am pretty sure if we identify the bugs that stop us from recommending head of tree and make the breakage clear enough on the Arduino issue tracker they will get fixed. |
Beta Was this translation helpful? Give feedback.
-
|
The other thing that 1.x is truly terrible at is concurrent work on sketches that target different architectures. I often have more than one MCU on a board. Often a change in firmware on one side requires a corresponding change in the other side. Often esp + avr. 1.x does not handle switching between sketches that target different boards well. For example the serial port is global. And menu options tend to get copied between them randomly. 2.0 is at least tolerable there with each window having its own target. |
Beta Was this translation helpful? Give feedback.
-
|
guys, if you really want far better code editor, then if you just have installed Arduino IDE, then install VSCode and add only Microsoft Arduino extension into it. Its breeze, everything works, only thing impossible is to upload by programmer in case you havent installed Arduino CLI. I just returned to work on Arduino/C project and edited also keybindings to 4 my current IDE I need (DEV-Cpp, AtmelStudio, VS2022 and VSCode) for UNIFIED debugging and editing expereience between them, it took 2 days, so I also backed up + unified syntax coloring etc... its very nice, will thi publish to github soon too. I have some code/functions shared between C and unsafe C# in VS2022 and the code I need to debug is also very well editable and debugable by Dev-Cpp as desktop project - thats the reason I switch between them often - debugging of hw independent code in Dev-Cpp is probably 100x faster than anywhere else ... just immediate. |
Beta Was this translation helpful? Give feedback.
-
|
I think the bug @SpenceKonde was complaining about having broken in V1.8.14 was just fixed in 2.0: arduino/arduino-cli#1823 Since I doubt it will be fixed in any hurry in V1.8.19+ is it worth changing the version number to the format that V1.8.14+ will accept? The workaround is a 1-line change in platform.txt at which point that bug no longer matters: -version={versionnum.major}.{versionnum.minor}.{versionnum.patch}{versionnum.postfix}
+version=2.6.0Are there other specific problems with 2.0 or V1.8.19 you are aware of @SpenceKonde? Happy to try to push resolution. |
Beta Was this translation helpful? Give feedback.
-
|
Well my problem is that empirically I was unable to manage version numbers until I switched to that system, and the version numbers were often wrong or self inconsistent. In other words, I was incapable of implementing your solution. I tried notes to myself, etc, and nothing worked. Like I would release 1.2.3, but the version would still be reported as 1.1.7 or stuff like that. I couldnt manage to do the numbering reliably. (anyone who reads my posts here can see that I suffer from ADHD) That would imply that I would have to cease development of all cores, because I couldn't manage the versioning But with the boards.txt generator, a platform.txt generator could be added that would build platform.txt from platform.txt.top version = x.y.z platform.txt.bottom. Or replace with a regex if I can figure out python''s re module, which doesn't work quite the same as the regexes i;m used to. |
Beta Was this translation helpful? Give feedback.
-
|
Pull request submitted for a generator that uses Python's re module. Agree that there was a substantial learning curve when I started using that module. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I wish re worked more like regular expression find-replace in sublime. routinely do that by hand instead of scripting because re is such a pita. That code will need to be relocated because it needs to go in the middle of a step in release scripts. but having the code is enormously helpful. It looks like it should work on all three cores? |
Beta Was this translation helpful? Give feedback.
-
|
yeah it will work on all of them as long as you use the same common version prefix. I was semi-careful to make it general enough to continue working if you add another component or have slight differences and at least complain loudly if it doesn't succeed |
Beta Was this translation helpful? Give feedback.
-
|
Ok 2.0 is no longer a beta, it's an official release. It also lacks any known issues. What else needs to happen before we consider it supported. |
Beta Was this translation helpful? Give feedback.
-
|
I spoke too soon. arduino/arduino-cli#1880 - this one can be worked around and only affects people who install via board manager and also manually, in which case the board manager version is used even when the IDE claims it is using the one in sketchbook. @per1234 anything else I should add to that report to hopefully get traction on it. |
Beta Was this translation helpful? Give feedback.
-
I don't see it being a high priority. I would consider it more of a user error. The standard approach of using a unique vendor folder name to avoid the name collision between the Boards Manager installation and the manual installation is actually beneficial rather than only a workaround. This approach allows you to use both installations. This means you can switch back and forth between the beta version and the release version, either to compare their behavior while beta testing, or when you want to switch between standard usage of the stable platform for your projects and beta testing of the unstable version. I would instead recommend putting the effort towards evaluating the "manual installation" instructions in this repository to see whether the correct installation procedure can be made more clear: https://github.com/SpenceKonde/megaTinyCore/blob/master/Installation.md#manual-installation The ZIP file approach will already incidentally produce a unique vendor folder name due to the way GitHub adds a Git ref suffix to the root folder name (e.g., |
Beta Was this translation helpful? Give feedback.
-
|
I tried renaming megaTinyCore to megaTinyCore-dev which did not fix the problem. This is a regression in 2.0.0, 1.9.19 works fine with this configuration. |
Beta Was this translation helpful? Give feedback.
-
|
interesting. there was no observable change after exiting 2.0.0, moving megaTinyCore in ~/Documents/Arduino/hardware to megaTinyCore-dev and restarting 2.0.0. However once I then used board manager to downgrade from 2.6 to 2.5.11 (I suspect any re-install works) it then displays both megaTinyCore and megaTinyCore (in sketchbook). I still think there is a bug in that it displays (in sketchbook) but uses the one not in sketchbook. |
Beta Was this translation helpful? Give feedback.
-
|
Huh, personally I:
* Upgrade only when forced to. Windows 10 is a downgrade in critical ways
vs Win XP. When my computer rebooted once a month in the win XP days, I
would start swapping out hardware and running diagnostics to find the
broken component (usually ram). On Windows 10, that's intended behavior. I
have lost considerable amounts of work to that. Wtihout Sublime Text
hotsave, I would not be able to maintain even one core.
* Have hated every IDE I used except Arduino. Arduino just works, you don't
have to fuck around for days to configure it and make it do what you want
it to do. .
…On Sat, Aug 6, 2022 at 4:13 PM ObviousInRetrospect ***@***.***> wrote:
I totally despise the 1.x IDE as a code editor. It's bloated awful java
that is slow as molasses. Its code navigation, refactoring, autocomplete,
and other such things an IDE should do are terrible to the extent they
exist at all. Open a half a dozen sketches even on a powerful machine and
watch it crawl ... while doing less for you than vim. If I wanted a dumb
editor + build I would use the CLI + vim. If I am going to run a bloated
IDE it might as well do the things an IDE is supposed to do.
I'm also generally averse to letting myself get stuck on obsolete software
(which tends to happen in the embedded space). The further behind you fall
the harder it is to catch up. I usually assume there are security bugs
getting fixed in head of tree and never backported. For example, the
version you recommend has an old vulnerable version of Log4J that allows
trivial code execution. I'd rather not think deeply about under what
conditions it might be exploitable. It takes some work but I now have an
example of getting a fairly horrible 2.0 bug fixed in a couple days by
pointing out the issue in GitHub didn't really demonstrate the severity. I
agree with your assessment that the RC feels more like a beta but such is
life.
Your cores are popular enough that I am pretty sure if we identify the
bugs that stop us from recommending head of tree and make the breakage
clear enough on the Arduino issue tracker they will get fixed.
—
Reply to this email directly, view it on GitHub
<#760 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW7SOU6SJF4N2D2SLI3VX3BN7ANCNFSM55YVEFFA>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
--
____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore <https://github.com/SpenceKonde/ATTinyCore>: Arduino support for
all pre-2016 tinyAVR with >2k flash!
megaTinyCore <https://github.com/SpenceKonde/megaTinyCore>: Arduino support
for all post-2016 tinyAVR parts!
DxCore <https://github.com/SpenceKonde/DxCore>: Arduino support for the AVR
Dx-series parts, the latest and greatest from Microchip!
Contact: ***@***.***
|
Beta Was this translation helpful? Give feedback.
-
|
This I agree with. The tools menu settings need to be saved on a per board
basis not globally.
…On Sat, Aug 6, 2022 at 4:15 PM ObviousInRetrospect ***@***.***> wrote:
The other thing that 1.x is truly terrible at is concurrent work on
sketches that target different architectures. I often have more than one
MCU on a board. Often esp + avr. 1.x does not do that well. 2.0 is at least
tolerable there.
—
Reply to this email directly, view it on GitHub
<#760 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW45MZBAMJNAB6QUNYLVX3BW7ANCNFSM55YVEFFA>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
--
____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore <https://github.com/SpenceKonde/ATTinyCore>: Arduino support for
all pre-2016 tinyAVR with >2k flash!
megaTinyCore <https://github.com/SpenceKonde/megaTinyCore>: Arduino support
for all post-2016 tinyAVR parts!
DxCore <https://github.com/SpenceKonde/DxCore>: Arduino support for the AVR
Dx-series parts, the latest and greatest from Microchip!
Contact: ***@***.***
|
Beta Was this translation helpful? Give feedback.
-
|
One very annoying bug is that when I open the 2.1.0 IDE, it does NOT open the last sketch I worked on, nor for the last board. Rather it seems stuck on some much earlier thing I was working on. /home/ken/.arduino15/packages/DxCore/hardware/megaavr/1.4.10/cores/dxcore/UART.cpp: In member function 'virtual void UartClass::begin(long unsigned int, uint16_t)': |
Beta Was this translation helpful? Give feedback.
-
|
@wa2mze - Update DxCore to the latest version. The compile errors are coming from DxCore 1.4.10 which was based on Microchip's 1.x.x headers, yet somehow, it has come to use the toolchain with the 2.x.x headers, likely because you installed the latest megaTinyCore, which pulls in the toolchain and headers based on the 2.x.x ATPACKs from Microchip. (this is something the IDE has long handled poorly, isolation between cores is not complete). 1.5.6 of DxCore will not generate those errors since I went through and fixed every instance where I had an old named variable (yes, that ATpack update's main consequence was renaming of several thousand constants. Ask Microchip what the fuck they were thinking if you disagree. Maybe if enough people do it, they'll think a little harder before they push out a massive breaking change to assuage someone's OCD about how constants should be named. (the difference is that for a multi-bit bitfield within a register, what was previously PERIPH_BITFIELD0_bm (bit 0 of multibit bitfield "BITFIELD" of peripheral "PERIPH", as a bitmask) is now PERIPH_BITFIELD_0_bm. The reason being that there are a few cases where the name of a bitfield ends in a number, and that could lead to things like PERIPH_BITFIELD00_bm where the first 0 was part of BITFIELD0 identifying the name of the bitfield, and the second 0 was the number of the bit within that bitfield we're talking about. Yes the new way is obviously better, but I don't think fixing that was warranted after parts with the old names had been shipping for years. But to support the new chipps we need to keep up with the latest ATPACKs, so I don't have a choice on this. As for the not opening the same sketch as you were last using, that bug isn't new :-P happens in 1.8.x too. |
Beta Was this translation helpful? Give feedback.
-
|
When I was using arduino 2.2.1, I copied the URL code into the preferences and started downloading, but I got an error and the message was displayed: Some indexes could not be updated. Get "https://github.com/SpenceKonde/megaTinyCore": read tcp 192.168.31.44:3540->20.205.243.166:443: wsarecv: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.: https://github.com/SpenceKonde/megaTinyCore |
Beta Was this translation helpful? Give feedback.
-
So while the official stance is that Arduino 2.0 is unsupported, if you are using it let's collect known issues related to megaTinyCore here. When you run into issues or what seem like strange bugs immediately load the sketch in 1.8.13 (or 1.8.19 if you use boards manager and don't manually install the cores) and try to reproduce. You'll save yourself a lot of grief. Also definitely do that before reporting.
Currently as of 2.0.0 release:
If you install both manually and via boards manager the boards-manager installed libraries (and possibly other stuff) takes precedence even while the IDE claims it is using the version in sketchbook.
arduino/arduino-cli#1880
The work-around for this is to rename the one in the sketchbook to add a suffix such as -dev or -git (so megaTinyCore-dev). You then need to uninstall and re-install megaTinyCore via boards manager after which both versions will show up in the boards menu.
Beta Was this translation helpful? Give feedback.
All reactions