I actually doubt that the problem is anything to do with your sketch, but as you can probably see, using the code tags makes it easier to see and copy for examination should it be necessary
Can you upload a simple sketch such as Blink to your Arduino ?
Did you get the warning about the fuse setting when uploading the blink sketch? Use LED_BUILTIN instead of 13 for the pin number, the led is on a different pin on that board.
From what I can find, that fuse5 warning is normal and can be ignored.
There is a vast difference between an Arduino UNO WiFi and an Arduino UNO WiFi Rev 2. The rev 2 uses an atmega4809, and there are a lot of libraries that are incompatible with that processor.
// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin LED_BUILTIN as an output.
pinMode(LED_BUILTIN, OUTPUT);
}
// the loop function runs over and over again forever
void loop() {
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}
This is the code I used. It works perfect on my normal arduino uno but that wont work for my initial program
Unfortunately the megaavr architecture generates tons of compiler warnings, mostly related to the WiFi and Ethernet libs and of course the “fuse5” thing. Upon inspection, the warnings are generated from use of untyped macros that don’t expand properly, improperly typed values, duplicate definitions and other issues all related to the poor programming practices of the developers.
The gcc compiler bundled with the Arduino IDE is fully ISO C++ compliant, yet most of the API looks like it was written by a fifth-grader. That’s what happens when you use macros and ints for everything or change type declarations Willy-Nilly.
That’s just my opinion, I could be wrong, but I doubt it.
Really? I tried the sketch here, and the only warning generated by the compile was the one about register emulation, and that's quite intentional.
Also, the OP's reported problem (the FUSE issue) has nothing to do with the compiler, and more to do with avrdude and the platform/boards definitions.
OTOH, I think that's pretty much a red herring - the FUSE warning is just a warning, and shouldn't interfere with actual operation. Unfortunately, they seem to have ghosted before resolving their issues.
Obviously, most people are able to get Blink working on an Uno WiFi 2, in spite of avrdude warnings and core code deficiencies.
Here’s a pic of the output window when compiling anything that uses the WiFiNINA or megaavr Ethernet libs - and that’s just what fits on one screen! It’s full of duplicate definitions, overflows, bad type conversions and more. The type of stuff that no professional developer would ever let out the door. But then again ….
I’ve spoken to several maintainers of the avr libs on Git and they’ve all kind of had it up to here with all the warnings, the redefinition of data types with no documentation or even a heads-up from Arduino.
I’m a few decades past writing “Blink” sketches, so maybe you can understand our frustration. Lab Automation
But that looks like you've included both WiFi and Ethernet libraries in the same sketch. While I guess that that should theoretically be possible, I'm not at all surprised that it doesn't work right.
And why exactly would that not be possible? My comms objects need to support both. Who writes libs that aren’t interoperable? I expect things to work, or documentation clearly stating otherwise.