Software Upgrade Loader V1.00

[Imelda Matchett]

Loaders now return typed data. This addition of types into previously untyped code can generated type errors in existing applications. These type errors can just be a result of the typescript compiler making sure your application knows what it is doing, but they can also mean that you have been making wrong or unsafe assumptions about what is being returned from the loader in question. We recommend you review the errors rather than just defeat them with comments as some may be valid and should be fixed in the application.

Some loaders can return multiple formats, often controlled with the loader options shape parameter. Note that many returned data types now also include a shape field which contain a string value the specifies the shape of the data. This goal is that this should result in a "discriminated union". Switching on the returnedData.shape field will then allow typescript to correctly determine which type of data was returned.

On the upside, the new Apache Arrow API is more modular and "tree shakeable" (meaning that only the Apache Arrow functionality your application is actually using is included in your application bundle).

If you are referencing table schemas returned by loaders, they will no longer be Apache Arrow schemas, but instead equivalent "serialized" lower-overhead loaders.gl schemas. You can recover Arrow schemas as follows

If you were relying on @loaders.gl/polyfills module to install a global fetch()function under Node.js that supported fetching from local files.loaders.gl v4 uses the built-in fetch in Node.js v18+ (which doesn't support fetching from local files), so fetch from local files, you now need to use fetchFile() instead.

Details: The expectation is that loaders.gl v4.0+ will be used with Node.js version 18 and higher,which now provide a built-in browser-compatible fetch() function by default.This new built-in Node.js fetch function does not support reading from the file system,and loaders.gl v4.0 aligns with this practice.

Default number of worker threads for each loader has been reduced from 5 to 3 on non-mobile devices and to 1 on mobile devices to reduce memory use. Generally, increasing the number of workers has diminishing returns.

Note that automatic packing of binary data (aka "packed JSON" support) was only implemented in the v1 GLTFLoader and has thus also been removed. Experience showed that packing of binary data for .glb files is best handled by applications.

A couple of functions have been deprecated and will be removed in v2.0. They now emit console warnings. Start replacing your use of these functions now to remove the console warnings and ensure a smooth future upgrade to v2.0.

It took me a while to find - but there was a new boot loader released with the newer Arduino IDE - under ToolsBoard you'll now see a new Processor option, eg Arduino Nano (Old boot loader). If you get stuck - try selecting that option.

Thanks for the info. Arduino Nano (Old boot loader) only showed up on my Windows7 machine, not on two other Windows 10 machines. But it worked for me. Your post helped me not have to wonder about that.

It's actually not a new bootloader, it's just new to the Nano. It's the same excellent Optiboot bootloader that has been used on the Uno for years. The change was made in Arduino AVR Boards 1.6.21. There are no release notes for it but you can see the change here:

And to the people saying they had to downgrade to Arduino AVR Boards 1.6.20, I guess you didn't read the post carefully. You only need to select Tools > Processor > ATmega328P (Old Bootloader).

Possibly making things more complicated is that the new nanos are still shipping with fuses set for a 2 kB boot section, negating one of the biggest benefits of using Optiboot. I suspect they will correct that soon but I'm not sure what the implications are of having some Nanos with ATmegaBOOT and 2 kB boot section, some with Optiboot and 2 kB boot section, and some with Optiboot and 0.5 kB boot section.

I have 2 nanos (clones) and more 2 on the way, I think I'll upgrade them all to optiboot.
I have an USBASP and the converter from 10 to 6 pins, so I should have all I need to do the upgrade.
Can it be done from the IDE ? Maybe selecting the processor as ATmega328p (not the Old bootloader option I'm using now) and programmer USBASP and then just selecting the "burn bootloader" option ? Do I need to do something to get the fuses right ?

That's what I do with all mine. Other than the complexity of the process for a beginner (which is mostly caused by people using "Arduino as ISP" programmers instead of a dedicated programmer), it's really a win all around.

No, if you do that then you get the outdated bootloader that was replaced by Optiboot. That bootloader takes up 2 kB of your flash memory and has a bug that causes an endless reset loop after a watchdog reset. If you have an ATmege328P-based Nano, rather than the rare ATmega168 based ones, then the process is this:

There is one tiny catch. The Nano actually uses a different variant file (named eightanaloginputs) than the Uno's variant (standard). This is because the Uno does not have pins A6 and A7 broken out. All that eightanaloginputs file consists of is this:

So there is no difference from the Uno other than the value of NUM_ANALOG_INPUTS. That's actually not a big deal because NUM_ANALOG_INPUTS isn't really used anywhere. The only place I've seen it is in the Firmata library. It's not used anywhere in the Arduino core or in any of the other official Arduino libraries.

Tools > Burn Bootloader actually does two things: Set fuses, then flash the bootloader file to the microcontroller. The correct fuses are already defined in the boards.txt entry for the board you have selected from the Tools > Board menu. So you don't need to worry about it unless you want different fuses from the standard ones. If so you could edit boards.txt as required or if you're using MiniCore it adds extra Tools menus that let you easily configure the most common fuse settings from inside the Arduino IDE.

I was able to flash it with Uno and MiniCore bootloaders. I had an hard time making USBASP work, in the end it was the driver, I had to set it up with the libusbK driver, but I don't know why, thanks God by programs like ZADIG.

So now I'm looking into the process of upgrading it, I only have one usbasp but I have one USBtinyisp v2.0 and several flavors of ftdi equivalents (yes, I kinda collect programmers, if they are cheap I buy one, you never know when you need it).

update: after some more reading it looks that that error is not important and some things should not be messed with unless it is really needed (if it is not broken...) .
I tried programming the Nano bootloader with a USBtiny instead of the usbasp... It works exactly the same, just choose a different programmer from the menu.
In windows I used ZADIAG again and installed the libusbK driver.

but it's pretty rare that you would actually need to do an Upload Using Programmer with the ATmega2560 since it has so much program memory that the part taken by the bootloader is not really significant. The regular USBasp firmware works fine for burning bootloaders to the ATmega2560.

I also have a programmer collection but I much prefer my USBasp to my USBtinyISP because the only minor limitation of the USBasp can be easily overcome but I'm not aware of any means by which it's possible to do the same for the USBtinyISP.

I think the cause of the driver confusion is that the answer has changed over time and also differs from person to person somehow. The official firmware comes with the libusb-win32 driver and that used to work fine for me until Arduino's release of AVRDUDE 6.3. Then it stopped working until someone was kind enough to point me to libusbK. Other people can use AVRDUDE 6.3 with libusb-win32 no problem. In fact I can use the official build of AVRDUDE downloaded from their web page with libusb-win32. I reported this to Arduino:

I've never heard of anyone having problems with libusbK so I think that's always the best driver choice but advice to use libusb-win32 is not specifically wrong because for the person writing the advice I'm sure that driver worked fine.

c80f0f1006