Digispark pins limitations doubts...

Hi! I’m doing a project with a Digispark (that later will be on a bare Attiny), but for now I must make it work on the Digispark for testing.

I’m using all input/output pins, and some pins have some limitations... so I have some doubts and if anyone could help it would be great.

From Digispark wiki:

“Pin 5 has some limitations it cannot handle as much current is outputs more like 3.6v - but works fine for most non-current sourcing uses.”

I need to use Pin 5 as an analog input through a voltage divider (to measure a 7.4V battery voltage).

Would it work normally on this pin for analogRead() ?

Another doubt is: if I have a complete code, working in the Digispark, with and I2C library, and I plan to burn it into a bare Attiny85, would it work as in the Digispark? Or the libraries adapted to the Digispark (for instance, the Wire.H) are exclusive for it and wouldn’t work on a bare attiny85?

Thanks for reading!

If you are using my core (ATTinyCore 1.4.1), Wire.h will work (my core supports both digispark and non-digispark)

If you are using any other core, Wire.h does not work at all, and you need to use a different library for I2C support, and modify any libraries you're using that depend on it to work with that USI I2C library (my core includes a modified version of Wire.h that transparently selects the correct implementation of I2C functionality for the hardware, using hardware I2C (on the few parts that have it, ohoh just the t48/88), USI (most classic Tiny parts, but not the 828 or 441/841),

As supplied, most digispark clones don't have pin5 set up to be an I/O pin - it's fused to work as reset. You need to use an ISP programmer (such as a USBAsp, or an uno/nano/etc running Arduino as ISP sketch) to set it to use the reset pin (PB5) as I/O (and un-doing this once you do it requires an HV programmer, not just an ISP programmer - you need to put 12v on the reset pin).

Also, you can't program them except via a bootloader (like the digispark USB one) once that pin is set to not be reset.

That quote from the wiki is gibberish.
PB5 when set to work as I/O pin works fine as an input, but as an output, it's' current is extremely limited. Basically all it can do is drive the input to a digital pin on something else...

DrAzzy:
If you are using my core (ATTinyCore 1.4.1), Wire.h will work (my core supports both digispark and non-digispark)

Yes, I'm using it!

As supplied, most digispark clones don't have pin5 set up to be an I/O pin - it's fused to work as reset. You need to use an ISP programmer (such as a USBAsp, or an uno/nano/etc running Arduino as ISP sketch) to set it to use the reset pin (PB5) as I/O (and un-doing this once you do it requires an HV programmer, not just an ISP programmer - you need to put 12v on the reset pin).

Also, you can't program them except via a bootloader (like the digispark USB one) once that pin is set to not be reset.

So, If I use a USBAsp (i do own) I can set this reset pin to be a normal input. But then I can no longer upload a sketch by using the USBAsp/Arduino IDE, except if I use a VH 12V programmer to get the PB5 back to reset state, and be able to normally upload sketches by the USBAsp/Arduino again. Is that right? So I must have a HV programmer. Is it easy to find one? I did a quick search on ebay and aliexpress and couldn't find one HV programmer.

Thanks so much for your detailed answer!

Regards, Rodrigo

Rimbaldo:
So, If I use a USBAsp (i do own) I can set this reset pin to be a normal input. But then I can no longer upload a sketch by using the USBAsp/Arduino IDE

Correct, you cannot upload again using USBasp, but if done correctly you can still upload from the ide using the usb connector. You need to use the USBasp to change pin 5 to an i/o pin without removing the DigiSpark bootloader.

High Voltage programming, what is needed.

PaulRB:
Correct, you cannot upload again using USBasp, but if done correctly you can still upload from the ide using the usb connector. You need to use the USBasp to change pin 5 to an i/o pin without removing the DigiSpark bootloader.

Ok, got it!

But if I plan to use a bare attiny85, which has no usb, then the only way is by re-enabling the reset with a high voltage programmer and then upload code normally wiith the USBAsp?

Thanks!!

Rimbaldo:
Ok, got it!

But if I plan to use a bare attiny85, which has no usb, then the only way is by re-enabling the reset with a high voltage programmer and then upload code normally wiith the USBAsp?

Thanks!!

Either that, or use digispark-bootloaded attiny85 and swap it between the target board and one of those digispark programmer boards.

Of course, you could always just step up to an attiny84?

DrAzzy:
Either that, or use digispark-bootloaded attiny85 and swap it between the target board and one of those digispark programmer boards.

Got it! Those digispark boards with an empty DIM socket, right? Could I program a SOIC attiny85 using those boards, provided I use a Dip to SOIC Adapter?

Of course, you could always just step up to an attiny84?

I wanted something like that.

I tried to use a Digispark PRO (with an Attiny167), but my TOF sensor, VL6180X, using I2c didn't work. I tried all libraries I could find. In the Attiny85 only one library worked (Sparkfun's) ..with some hangs...

Everything that runs on the Attiny85 (especially I2c) should run on the 84??

Thanks!

Did you try with my core? Not to sound arrogant, but my core is probably the only core that anyone should be using for ATtiny parts - it's the only one being actively maintained, the only one that implements the bloody obvious solution to the differences in hardware I2C/SPI support, and the only one that supports all the ways of uploading to these parts (ISP, Serial bootloader (optiboot), USB bootloader (Micronucleus as used by digispark), and so on...

My core provides that special version of Wire that should look (to libraries) just like the version of Wire that is present on the ATmega devices; any I2C device that works on ATmega and doesn't work on my core, please create an issue on my github about it and I'll attempt to fix or hold the library author's feet to the flames if the library is doing something that causes it to break, or make a fork that works if they tell me to get stuffed.

DrAzzy:
Did you try with my core? Not to sound arrogant, but my core is probably the only core that anyone should be using for ATtiny parts - it's the only one being actively maintained, the only one that implements the bloody obvious solution to the differences in hardware I2C/SPI support, and the only one that supports all the ways of uploading to these parts (ISP, Serial bootloader (optiboot), USB bootloader (Micronucleus as used by digispark), and so on...

My core provides that special version of Wire that should look (to libraries) just like the version of Wire that is present on the ATmega devices; any I2C device that works on ATmega and doesn't work on my core, please create an issue on my github about it and I'll attempt to fix or hold the library author's feet to the flames if the library is doing something that causes it to break, or make a fork that works if they tell me to get stuffed.

GitHub - SpenceKonde/ATTinyCore: Arduino core for ATtiny 1634, 828, x313, x4, x41, x5, x61, x7 and x8

Ok.. I checked in the boards manager and your core was not updated to the last. Now AttinyCore is in 1.4.1 version. I noticed many many more Attiny's in the drop down boards list.

Forgive me my .. ignorance..... but I was compiling the codes with the Digistump core versions (Digispark Default - 16.5Mhz) and Digispark Pro (Default 16Mhz). I should be using the the boards from your core....

For my Digisparks, normal and PRO, I should choose from your list the Attiny 85 (MicroNucleous Digispark) and the Atiiny167 (Micronucleous Digispark PRO). Then the process will be the same as compiling with the Digistump boards?

I'll give it a try tonight!!

Thanks!!
Thanks!

Yup, that's what you want to choose. Let me know how it works out with those sensors and/or if you encounter any issues.

DrAzzy:
Yup, that's what you want to choose. Let me know how it works out with those sensors and/or if you encounter any issues.

Hi!

Did some tests yesterday and today.

Your core rocks. All libraries worked normally on all chipsets I tested (Digispark, Pro and Pro- Micro.

I read all your readme in your github. I used two 100k pull-ups on the sda and scl for both the Attiny85 and 167, and even with the VL6180X sensor in the end of a 1.5m shielded cable, it worked normally on all chipsets.

So definitely your core handled pretty well the I2C.

The only library that didn´t work at all in the Attinys is the SmartEverything VL6180X. I wanted it to work because the example compiled with only 19% of memory usage on the Attiny85, and the other libraries used close to 40% just for the sensor.

In their repository in github the creator said he added compatibility to more arduinos, but nothing said about the Attiny.

Is there a forum, or place where I could have some answers about your core usage? There´s a lot of options, like to disable the reset, but I don´t know if a programmer (USBAsp) is needed, if it has to be done in command prompt or can be done directly in the arduino ide using USB.

Thanks a lot for your help, and using your core solved all my I2c Sensor problems!