In file included from C:\Users\NH5\.platformio\packages\framework-arduino-avr-digistump\cores\dtiny/Stream.h:24:0,
C:\Users\NH5\.platformio\packages\framework-arduino-avr-digistump\cores\dtiny/Print.h:37:0: warning: "BIN" redefined
#define BIN 2
In file included from c:\users\nh5\.platformio\packages\toolchain-atmelavr\avr\include\avr\iotn85.h:38:0, from c:\users\nh5\.platformio\packages\toolchain-atmelavr\avr\include\avr\io.h:428,
c:\users\nh5\.platformio\packages\toolchain-atmelavr\avr\include\avr\iotnx5.h:55:0: note: this is the location of the previous definition
#define BIN 7
In file included from C:\Users\NH5\.platformio\packages\framework-arduino-avr-digistump\cores\dtiny/wiring_private.h:32:0,
c:\users\nh5\.platformio\packages\toolchain-atmelavr\avr\include\avr\delay.h:36:2: warning: #warning "This file has been moved to <util/delay.h>." [-Wcpp]
#warning "This file has been moved to <util/delay.h>."
You are right, the delay() is not recommended any more. I use milies(), but when I need to check something and not for “production”, I get lazy and use delay().
I didn’t know there is a delay.h lib, I will search for it.
Now that upload is completed, and my sketch is working. Thanks !
I might have too happy too soon. I installed the drivers and did the first programming, I cant up load any more. When I press (within VS code) upload, I don’t get the “please plug the device” message.
What am I doing wrong?
I followed the video (exactly as I did before), and I still get the same (A request for the USB device descriptor failed.).
Perhaps the bootloader within the Attiny is somehow damaged? The part that is communicating with the Windows USB when plugged in?
Problem (partially) solved.
It looks like I did the basic mistake of wrong assumptions - I added an ultrasonic sensor, using pins 4 as Echo (input) and 5 as trig (output). Looking at the datasheet, pin 4 is USB- and 3 is USB+. So probably pin 4, driven by the sensor, corrupts the USB connection. Once removing it, the driver is working well, and I can program it properly.
Perhaps I need to get used to programming the Attiny with external socket. if I need the pins, or make sure pins 3’4 will not drive any value for start (put a delay in setup?)
I think having the ultrasonic sensor attached alone to the board has caused this. The sensor will need extra current at startup and might be pulling the supply low, or the input pin of the sensor has some pull-down/pull-up logic which messes with the criticial USB- line which has some pullup/down network attached to it (see https://s3.amazonaws.com/digispark/DigisparkSchematicFinal.pdf on USB_M signal). If that’s the case then a delay will also not help because it doesn’t alter that the USB- line is loaded electrically differently now.
Re-allocating to a different pin or unplugging it before a new upload should solve it.