update micronucleus

[sanbeg]

The micronucleus bootloader is bundled with a command line utility. Although this command has backwards compatibility to allow the command to work with older bootloaders, it doesn't have forwards compatibility, and thus will refuse to work with newer bootloaders.

It appears that ATTinyCore bundles an old alpha of this command from 2015, which is no longer listed in the release page https://github.com/micronucleus/micronucleus/tags (IIRC, the same version that was used by the long since unmaintained Digistump core).

When trying to flash a Digispark clone with an updated bootloader, I get this error:

Warning: device with unknown new version of Micronucleus detected.
This tool doesn't know how to upload to this new device. Updates may be available.
Device reports version as: 2.4

Although may cheap clones still use very outdated bootloaders which will work with this old tool, an updated tool would work with both old and new bootloaders.

[pcfreak1201]

Duplicate of #442 Have a look at https://github.com/ArminJo/micronucleus-firmware

[SpenceKonde]

I took the version from what appeared to be the most recent official digispark package - I would love to get a newer version, are there any prebuilt packages to use, or do I need to get a build environment set up to compile it?

[SpenceKonde]

To expand on that - I've seen that repo, but I am not familiar with the process of compiling for desktop computers, only microcontrollers. That's more or less what we got to last time it came up - well, great, there's a new version, but it's source code, and we need binaries for multiple platforms, and I don't know how to get there from here.

[pcfreak1201]

You are write, I was on the MC side. On Linux (and may be other OS?) there is no problem to rebuild the commandline-tools with the sources on https://github.com/micronucleus/micronucleus/tree/master/commandline as desribed in #442 You only need the binutils and libusb-dev to recompile. Now I tried to CrossCompile for Windows x86, and there was a problem, because I don't know how to change the environment to MinGW. So I tried to generate a batch file xcompile.sh and it seems to work (finally no erros or warnings). But I can't test it. I've uploaded them to https://github.com/pcfreak1201/micronucleus_commandline It is really quick and dirty! Gladly Tim (@cpldcpu I think ?!) has written some interesting infos in the German Forum mikrocontroller.net, so I started my testing - but may be he is the better person to cooperate with, because of his experieces?

[sanbeg]

That would explain it. I don't think there are binary releases, I've just been building from source as needed. I have the binaries for the Linux command line and the default bootloader if that helps; I could probably get the other bootloaders & Mac binary without too much difficulty also.

[cpldcpu]

Hm... not sure what to say about this. This is the kind of clusterf* you get into when people start making rogue forks.

AFAIR the commandline tool needs MINGW32 to compile under windows due to a dependency on an old version of libusb. That is something that could be fixed, but it takes time. What would actually be preferrable is to clean up the micronucleus reposititory and add CI/CD so there are precompiled releases.

interesting infos in the German Forum mikrocontroller.net,

Which did you mean exactly? Maybe I have answered the same questions some years ago :)

[pcfreak1201]

Year, therfore I didn't make a fork, only put some code together, to make it more clear... I hope ;-)

I think, Spence wants to have a repository, which could generate a new build for each release, automated. So fixing would be much more reliable on each OS/platform.

On Linux I needn't to fix or use an old version of libusb. With installing libusb-dev and make, the new build was ready.

mikrocontroller.net is always my preferred source for solutions - and at the end there was clearly descibed, what to do to compile on (for) Windows. And Google found it because of the stuff, you put there, years ago ;-)

[SpenceKonde]

I did not know until just now that there was any work going on in the micronucleus official repo! I looked in master - it was a ghost town (I'm used to the (commit to master, branch releases off of that) rather than doing work in branches that you won't immediately see,

I'm sad to see that we've made different decisions on the MCUSR handling. Honestly, I've turned against preserving MCUSR entirely; i'm going to be lobbying hard to clear it whenever we go to the app, stashing it's contents into GPIOR0 and clearly and vigorously documenting that, because otherwise, you really can't guarantee that you honor the requested entry conditions.... and relying on people in Arduino land to check MCUSR? You're just deluding yourself if you think even 1% of them will.

IMO one of ideals of a good bootloader is that - barring self programming by the app to overwrite the bootloader on parts where it's not restricted to boot section, of course - the only thing that the application shuold ever be able to do that has anything to do with the bootloader is confirm that the bootloader is there (by reading the flash) and enter the bootloader, either from it's start, by resetting, or (in the case of that thing to allow write from app on parts that don't allow that), via a designated entry point. A poorly written app should not be able to cause the bootloader to not honor it's entry conditions.

[SpenceKonde]

The reason that none of my work was ever contributed back to @ArminJo (who I thought was the closest thing to someone who had taken over development of what I thought was the abandoned project, hence why I started from his code) was that after making hash of the build directory (this was after the hdd failure, so it's backed up in multiple places, I then got pulled away onto a few other more pressing matters, and I need to get DxCore and megaTinyCore to a state where people aren't screaming quite so loudly about their deficiencies - objectively, those are probably a more important thing for me to work on, even though micronucleus is fun). I've actually got two new pieces of hardware for IMO the most obvious candidates for micronucleusing among the Classic tinyAVR parts, because I felt like they deserved to have micronucleus... (though I'm getting like another 12+ other new designs in the same batch, so these won't be processed immediately,) plus gimped tiny841 micronucleus boards (it's like the Wattuino one, electrically... but built around the SOIC-14 package, so it cant compete on size, as I didn't want to steal anyone's thunder... but I couldn't seem to DIY one that worked, was like hrrrumph, it's just gotta be the lousy geometry of the wires, a custome PCB will work for sure.... And as I had already drawn something that was sssoooOOOOooo close, I figured I might as well do it.

Not sure what my approach going forward is going to be regarding the bootloader itself (I definitely intend to generate a large number of versions of the bootloader for each part, to cover any plausibly useful entry condition, on every part. Azzy cores tend to try to expose every conceivably useful option

[SpenceKonde]

And finally - as I've alluded to wanting to do, one day I hope to say a prayer to the lord of the AVR architecture, and armed with a sturdy laptop, clear screen, pure heart, and a copy of the bible ( http://ww1.microchip.com/downloads/en/DeviceDoc/AVR-Instruction-Set-Manual-DS40002198A.pdf ), sequester myself in my room for a some days, and port VUSB to AVRxt. From there, making the rest of the micronuclues bootloader work on the new parts would be a cake walk ((hell then it could also be a "real" bootloader, without having to fiddle with vector tables! Not that I don't think that's part of the fun...). Plus we could run them all at 20 MHz... a ATtiny3217 USB would be pretty sweet... Further beyond, once the code worked on tinyAVR, you'd have it done for the Dx-series as well (no differences in timing), just would need workaround to allow the larger flash (they can go faster than 20, but don't have to) - could use the MVIO o get rid of the need for the zener diodes (Dx series is full speed range over full voltage range - I think core is running at same voltage no matter what the input voltage is, which I don't think was how older AVRs worked). Lot of really awesome things could be made possible.... It's an exciting thing to dream of, but I have more pressing things to attend to...

[SpenceKonde]

But no matter what. somehow we need to get binary packages of a current version of micronucleus for all the relevant OS's... we don't need anything fancy like continuous delivery, but we need something reasonably recent that works with the current version of the firmware, since Arduino board packages (whcih is how like 99% of people install "board packages" now) is needed to make that experience work out... If that means someone like @pcfreak1201 building it when something big happens, directing me to the files, and me swapping out the micronucleus exe with the new one, so be it... heck, it might only need to be done every time a board that broke compatibility suddenly became supported or something.... We don't need perfectly up to date micronucleus tool.... just something recent enough to be usable without problems...

[pcfreak1201]

Well, I lost the track to Windows since XP, so it is more likely @sanbeg or @cpldcpu who will build EXEs ;-) And I think https://github.com/ArminJo/DigistumpArduino would be an nice start, to set up the sources for these 5 years old binaries. As long as the protocoll is the same as in 2.04a we don't come in a hurry!? Even for me "software-usb" is only fun, because the price for a STM32 or ESP32Sx is not soo high and I get USB in hardware. My personal favorite is still the t16x4 with CH340. Possible to solder by my own, 16k and for most ideas enough pins and interfaces.

[sanbeg]

Well, I lost the track to Windows since XP, so it is more likely @sanbeg or @cpldcpu who will build EXEs ;-) And I think https://github.com/ArminJo/DigistumpArduino would be an nice start, to set up the sources for these 5 years old binaries. As long as the protocoll is the same as in 2.04a we don't come in a hurry!?

We may be thinking about the opposite thing. I don't think it's necessary to set up sources for the 5 year old binaries; but rather, a way to automatically set up binaries for the current sources. For the current bootloader, the protocol isn't the same as the 2.04a version. So if you buy one of these boards now and decide to update your bootloader to a recent release, you also need to overwrite the command line tool from the core with the recent one.

I took a quick look through the core, and I wasn't quite able to track down where the core is configured to use 2.04a; so they only way I was able to make it work was by copying in the tool, then replacing packages/digistump/tools/micronucleus/2.0a4/micronucleus with a symlink to the packages/ATTinyCore/tools/micronucleus/2.04/micronucleus which I added.

[per1234]

I took a quick look through the core, and I wasn't quite able to track down where the core is configured to use 2.04a

It's defined in the package index's packages[].platforms[].toolsDependencies[].

Here: https://github.com/SpenceKonde/ReleaseScripts/blob/b53dc05fb66b14ee1007ffd3795e654f8fe5d85a/package_drazzy.com_index.json#L814-L818 and here: https://github.com/ArminJo/DigistumpArduino/blob/aa2d5529c83ec1eb866ec3e6e8d3672eaeffbaaf/package_digistump_index.json#L152-L156

[SpenceKonde]

And - the reason I use that version was that that was the only version of binaries that I was able to find! I was unaware that there even WAS an updated version of those tools... and the people I was talking to and who were driving this project forward were ALSO using those old versions of the tools, because that's the version that was there...

[SpenceKonde]

I was not at all suggesting that we start some new system for hosting ancient binaries, but rather - if there's a new version, and people who know how to build it, can we please get some builds made and start using them?

Like, a way to automatically build them is lovely, but let's not let the perfect be the enemy of the good... just building a recent snapshot that we can pull in with an Arduino core and hosting them somewhere (github?) would be better than anyone has done since, well, since 2.04a!!!

[pcfreak1201]

And - if I remember correctly, all these USB implementations are based on V-USB or am I wrong? And this exists since 2005 - so old is relative ;-)

[SpenceKonde]

Yes, VUSB is one of several AVR bitbang USB implementations. Was developed quite a while ago. My understanding was that it's the best out of the lot, and seems to be what all the AVR-based USB devices using AVR's that don't have "real" USB are built on. The company that does it is still around, though I don't think they're actively developing it. I was considering buying a commercial license so I could keep my cards close to my vest when I finally dig out of enough other projects to get to try to port it to the new AVRs (I did look through the assembly - it's all hand-tuned assembly - and it definitely looked doable, and I love working that close to the metal...

In any event. the whole reason this came up, though is that the micronucleus upload tool is clearly too old, as there are lots of bootloaders living on boards in the wild that these upload tool binaries won't upload to. Arduino cores live in a world of board manager, so "just build micronucleus yourself" does not fly, heh... and I don't know how to program devices with more than 128k of program memory (I was born without an EIND register you see....)

(actually, that's not true - a few years ago, we needed a dual booting bootloader for an arduino mega2560, but it had to still work like a normal mega too, but also support another protocol on another serial port under certain conditions.... Luckily the Arduino bootloader was grossly bloated with some "monitor" thing nobody ever used. Without that, I had acres of space after the end of the bootloader, and stuck this other bootloader back there. Actually though, I think my poor understanding at the time of how that was handled contributed to some difficulties getting to it (though we worked around that easy enough...

[pcfreak1201]

Yes, the tools (binaries) are too old, but not the protocol. So we have to clean up the source "HAL" to get rid of unsupported/obsolete libraries as cpldcu mentioned:

AFAIR the commandline tool needs MINGW32 to compile under windows due to a dependency on an old version of libusb. That is something that could be fixed, but it takes time.

But as I said, Linux doesn't look like the problem ;-)

[sanbeg]

So not sure how I missed this until last night, but it looks like micronucleus does include a prebuilt windows binary mixed in with the sources. So with that I have mac, windows & linux 64; the only one I don't have yet is 32 bit linux. Since I still haven't found sources for the digispark launcher I reimplemented that in bash, since that seems better than distributing mystery binaries, and I think it's be portable across all the system we're talking about.

I've gathered up my work in progess @ https://github.com/sanbeg/MicronucleusArduino So far I've only tested on Linux, but I can do some more testing then clean and package that.

[SpenceKonde]

Oh! That's wonderful...

And wait, the whole purpose of launcher is just to rewrite the arguments passed to micronucleus executable?

Couldn't we just do that in platform.txt and do away with it entirely?

Something like... tools.micronucleus.upload.pattern="{cmd.path}" --type intel-hex --timeout 60 {build.path}/{build.project_name}.hex

(with the path adjusted to point to micronucleus instead of launcher?) I guess that wouldn't get us the message telling the user to plug in their device (which is wrong anyway, should be "plug in or reset" or something like that, since almost every device I've found in the wild had a working reset button that could be used to upload, and plan for next release is versions of the bootloader built to support every plausible reset entry mode).... I wonder if there's a way to execute two commands, either in a single command invocation, or two two lines in platform.txt. One thing I noticed and found intensely annoying is that the output didn't seem to get forwarded to the IDE during the upload, or only got passed in big chunks, so you don't see it as it's happening. I'm wondering if it's just because of the redirection that that happened....

[pcfreak1201]

Cool! Any yes, removing the launcher would be nice. But the Digispark hasn't a reset button! Yesterday, I found a notebook with dual-boot and Windows 7 on it. So I tried to use my built micronucleus.exe but it doesn't do anything (may be a problem with detection) - only starts. (I will repeat it with sandbegs binary.)

I also had a quick search for getting the actual libusb environment running for windows at my linux. And nope, I won't go down this rabbit hole. To start with quite well supported souces I think https://github.com/msys2 (only for LibUSB support on Windows!) looks very "promising"... Actually there seems to be support for Windows 7 to 10, x64 and x86 (and Mac, Android, Linux) but it seems to vary how to work with it. I'm a freak, not a specialist ;-) Ah, and during search, I also found that avrdude and the avr toolchain for windows also bases on MinGW - and avrdude needs LibUSB - may be another point to start?

[SpenceKonde]

The official digispark? Yeah that one may not have a reset button.

99% of the clones do, and don't come with reset disabled... so if we do need to keep the script for launcher, the text printed should reflect the fact that the correct course of action might be to reset it, it might be to plug it in, it might be to plug it in with a specific pin held low, and so on.....

And, somehow looking at it now, i see that his launcher script does indeed say plug in or reset.... how did I not see that last time, lol

[sanbeg]

Oh! That's wonderful...

And wait, the whole purpose of launcher is just to rewrite the arguments passed to micronucleus executable?

Couldn't we just do that in platform.txt and do away with it entirely?

Yeah, I think digistump designed it to pass through to avrdude, or to translate if you speci -c digispark. There's definitely some historical baggage there that could be cleaned up.

Something like... tools.micronucleus.upload.pattern="{cmd.path}" --type intel-hex --timeout 60 {build.path}/{build.project_name}.hex

That should work. --type intel-hex is the default, so we could omit that. we do want the --no-ansi --run options, though.

(with the path adjusted to point to micronucleus instead of launcher?) I guess that wouldn't get us the message telling the user to plug in their device (which is wrong anyway, should be "plug in or reset" or something like that, since almost every device I've found in the wild had a working reset button that could be used to upload, and plan for next release is versions of the bootloader built to support every plausible reset entry mode).... I wonder if there's a way to execute two commands, either in a single command invocation, or two two lines in platform.txt. One thing I noticed and found intensely annoying is that the output didn't seem to get forwarded to the IDE during the upload, or only got passed in big chunks, so you don't see it as it's happening. I'm wondering if it's just because of the redirection that that happened....

I think the message in Digistump's binary is specific for their digisparks, which I believe had the reset pin disabled. I reworded that in my script because I usually breadboard a reset button onto the clones I've been using.

Ideally, micronucleus could emit the message at the right time, but if it doesn't I don't think the launcher script is a terrible approach. We could also simplify it if we don't need to translate avrdude options and either pass through its options directly, or just hard code most options, and just pass in the filename.

I actually hadn't noticed the issue with the data coming in chunks. If that's due to the binary buffering the output incorrectly, it should go away if we move to a script.

[stonehippo]

@sanbeg If you’re getting all of these built, any chance you can do arm, too? If so, it’s fix the issue I opened (#477).

I’m down to help get them built, too.

[stonehippo]

Well, that was dumb. After going back up the thread here, it turns out building micronucleus 2.04 on ARMv6/ARMv7 was trivial. I’ve put the it up at https://github.com/stonehippo/micronucleus-commandline-arm-builds if that will help move things along.

[SpenceKonde]

@stonehippo Would you mind specifying: What source tree you built from? What command was run to build it? Is this arm-linux-gnueabihf or aarch64-linux-gnu ? (gee, such clear names, huh?)

[SpenceKonde]

And, I would disagree that it was "dumb" - if people either suffered in silence, or built it themselves, we'd never end up with an automatically installable binary for board manager installation!

[stonehippo]

@SpenceKonde fair point. :)

The binary that I’ve got right now is for arm-linux-gnueabihf. I should be able to produce an aarch64 as well, but I’m going to have to pop a 64 bit Linux on one of my RPi to do, so it will probably not be until later today.

Here’s the build steps I performed to get this thing made (running on the latest Raspberry Pi OS Buster)

$ sudo apt install libusb-dev
$ git clone https://github.com/micronucleus/micronucleus.git
$ cd micronucleus/commandline
$ git checkout tags/2.04 -b 2.04-release
$ make

I’ve updated the README on my repo to reflect this.

[SpenceKonde]

Aaha! Isnt there a newer version of micronucleus source we should be building from? I think that's what was being discussed above in this issue...

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: spencekonde@gmail.com

On Tue, Nov 17, 2020, 07:49 George White notifications@github.com wrote:

@SpenceKonde https://github.com/SpenceKonde fair point. :)

The binary that I’ve got right now is for arm-linux-gnueabihf. I should be able to produce an aarch64 as well, but I’m going to have to pop a 64 bit Linux on one of my RPi to do, so it will probably not be until later today.

Here’s the build steps I performed to get this thing made (running on the latest Raspberry Pi OS Buster)

$ sudo apt install libusb-dev

$ git clone https://github.com/micronucleus/micronucleus.git

$ cd micronucleus/commandline

$ git checkout tags/2.04 -b 2.04-release

$ make

I’ve updated the README on my repo to reflect this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/ATTinyCore/issues/465#issuecomment-728906069, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW3DCEFGJH3K6YUPTBTSQJWOXANCNFSM4SNYOAIA .

[stonehippo]

It's a good question! There's a 2.5 branch, and master. Did a build from master, and that seems to be the exact same binary (diff'ed as the same). I could try building 2.5 and see what that renders.

That said, the version currently being pointed to on Digistump is 2.0a4, which is an untagged beta from 2015, versus 2.04, which is the last tagged release. Unless there's another repo, that what we seem to have to work with.

[pcfreak1201]

Yes, and I think the answer is to set up and compare a complete repo (sources) for all supported OS, because Spence needs a quality base for automated builds. The most work lately has been done on the MC-side, not the PC-side.

[stonehippo]

Ok, just to be sure, I built the command line tool from the version_2.5 branch. The resulting binary diffs as identical to the one from the 2.04 tag. ¯\_(ツ)_/¯

[stonehippo]

@pcfreak1201 right, I think there are two issues: first (for me) is that I can't even install 1.4.x because there aren't currently any PC binaries for ARM, and second, getting a handle on the latest V-USB to integrate them on the core. I'd love to get the first on settled out so that all platforms have a recent version of the command line tool, the get the second on fixed so we all have latest V-USB support.

[pcfreak1201]

@stonehippo Yes, I've read #477 But you already created and generated a repo for ARMv6/ARMv7 binaries, so you could fork this repo and integrate the necessary files (binaries and config) for your own and reporting us ;-) Looks like @per1234 knows what to do ... Spence is more on the MC side and as he wrote actually, he spends more time in the DX core. So if more user wants support for arm, I'm sure he will feature this. :-)

[stonehippo]

@pcfreak1201 yes, I could go a grab the binaries @sanbeg has built, mix them with mine, and send @SpenceKonde a PR. But since I just started looking at this last night, and there was work on fixing it already in motion, I figured I'd take the part that I could, and contribute it as part of an overall plan. And I did say I was "down to get them built".;-)

@SpenceKonde would you like me to make just such a PR? Given that the PC command line tool seems to be more or less static, this would remove the dependency on the builds from the Digitstump repo.

[per1234]

Looks like @per1234 knows what to do ...

Do you mean adding the definitions to the package index for the ARM host versions of the ATTinyCore:micronucleus tool? If so, I am willing to submit a PR for that once someone can provide me with a permanent URL for the archives of those builds.

[stonehippo]

@per1234 I'm working on that now, but it's less fun on some platforms. For example, the default makefile config on MacOS builds a dynamically linked binary (the version that @sanbeg had is his repo has this issue), which breaks if you don't have the libusb-compat package installed. But figuring out the right statically linked lib is a little off because the makefile is kinda old, so…

It's gonna take a little time to get the binaries for micronucleus is all I'm saying.

[SpenceKonde]

Strikes me as odd that both 2.04 and 2.5 have the same binary... like, doesn't it have a command option to print the version? Surely the version they print shouldn't be the same... but that's a question for the micronucleus folks, I reckon...

Thanks guys!

That would be wonderful - glad you caught the macos issue!

Once we have a repo with fixed makefiles that we can do a "release" from (and then attach the binaries to - (unless someone wants to get automated builds working; I'm not sure how likely it is that we'll see frequent updates here. I have one thing planned for future that would involve an update there but I'm miles away from that) we should be good to go. Adding the updated binaries to the board manager json I know how to do; it's getting the binaries to add that's "not my department" so to speak.

[stonehippo]

Yeah, micronucleus --help includes a version number. Build from the version_2.5 branch and you get…

Commandline tool version: 2.04

I diffed the 2.04 tag and the version_2.5 branch and the only file that changed in the command line folder was the README. At least for now, that 2.04 command line tool is the latest and greatest.

[stonehippo]

OH MY GOD I have to tell someone…

Ok, I've got a working, statically compiled version of micronucleus 2.04 for MacOS. I had to do the following to get it working:

1. Make sure that libusb and libusb-compat were installed
2. Modify the Makefile to use the static archives instead of the dylibs

Not a big deal, except that the Makefile didn't include both the compat and newer 1.0 archives. I fixed that, but it took longer than expected, because of a bug in libusb-config --cflags that didn't make it clear that the core library needed be included (which I was able to uncover with pkg-config --cflags libusb. Point is, it was a lot of chasing things down to get this silly tool to build.

diff --git a/commandline/Makefile b/commandline/Makefile
index 050f205..77da05e 100644
--- a/commandline/Makefile
+++ b/commandline/Makefile
@@ -14,10 +14,11 @@ else ifeq ($(shell uname), Darwin)
        EXE_SUFFIX =
        OSFLAG = -D MAC_OS
        # Uncomment these to create a static binary:
-       # USBLIBS = /opt/local/lib/libusb-legacy/libusb-legacy.a
+       USBLIBS = /usr/local/opt/libusb-compat/lib/libusb.a
+       USBLIBS += /usr/local/opt/libusb/lib/libusb-1.0.a
        # USBLIBS += -mmacosx-version-min=10.5
-       # USBLIBS += -framework CoreFoundation
-       # USBLIBS += -framework IOKit
+       USBLIBS += -framework CoreFoundation
+       USBLIBS += -framework IOKit
        # Uncomment these to create a dual architecture binary:
        # OSFLAG += -arch x86_64 -arch i386
 else ifeq ($(shell uname), OpenBSD)

Anyhow, I'll add that binary to my repo in a bit, along with the other ones, and patches to the commandline build makefile, etc. I'm also going to try to build the aaarch ARM version tonight, and see if I can confirm either @sanbeg's Windows and Linux builds or build my own.

[pcfreak1201]

@stonehippo Cool! ;-) Yes, I somewhere read you also need libusb-compat, if you want to use libusb-dev ... And I think V2.5 was the idea to release V2.0a4 with the usage of "new" libraries, but never done.

[cpldcpu]

The commandline tool as such has not been changed since the introduction of version 2. The protocol has remained the same. So I don't expect any issues using the version from the 2.04 repository. There are some issues with the windows version, since it has dependencies on the old version of libusb, but that does not affect the protocol. The Mac versions has not been recompiled for half a decade due to lack of contributors.

I hope that helps a bit.

[cpldcpu]

2.5 is not really officially released so far. The current state of micronucleus is a bit unfortunate, I may have to add some explanations later. But very short on time right now.

[stonehippo]

Thanks @cpldcpu. Sounds like I'm on the right track to get this done.

After installing an entire 64 bit OS, I've got the Linux ARM for aarch version built. Still a few builds to go. Everything is going in the newly renamed https://github.com/stonehippo/micronucleus-commandline-builds.

And I'm done for tonight. I hope to get everything else done over the next couple of days, assuming I get some free time.

[nerdralph]

sequester myself in my room for a some days, and port VUSB to AVRxt.

Have you seen the port of v-USB to the tiny0 and tiny1? https://www.avrfreaks.net/forum/v-usb-tinyavr0-tinyavr1-series?skey=v-usb%20port

[SpenceKonde]

Woah! Sounds like it has already been done? That is exciting news!

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: spencekonde@gmail.com

On Fri, Nov 20, 2020, 16:00 Ralph Doncaster notifications@github.com wrote:

sequester myself in my room for a some days, and port VUSB to AVRxt.

Have you seen the port of v-USB to the tiny0 and tiny1?

https://www.avrfreaks.net/forum/v-usb-tinyavr0-tinyavr1-series?skey=v-usb%20port

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/ATTinyCore/issues/465#issuecomment-731404602, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW2RKA6EWCYGTGMMRXLSQ3KGJANCNFSM4SNYOAIA .

[stonehippo]

@SpenceKonde does this mean I can avoid finishing getting builds of the micronucleus CLI for every platform? ;-)

[SpenceKonde]

Lol, oh no, it means that you will need to do another build once I adapt it to micronucleus, since it will require changes to the cli too!

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: spencekonde@gmail.com

On Fri, Nov 20, 2020, 21:11 George White notifications@github.com wrote:

@SpenceKonde https://github.com/SpenceKonde does this mean I can avoid finishing getting builds of the micronuclues CLI for every platform? ;-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/ATTinyCore/issues/465#issuecomment-731491169, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEWZWDBWJPHTAPA4I333SQ4OWLANCNFSM4SNYOAIA .

[stonehippo]

😱

Glad I'm taking time to document what I'm doing then (and each platform is easy—once it works once).