Digispark (or clone) and 5v vs 3v 2 wire

[DougWilkinson]

Hi, Not sure if this is the right place for this question, but was curious to know if the 2 wire schematic should also work if using ~5v on data pins? I am powering the NRF24L01 with 3.3v, but the signals are using 5v from a digispark clone (attiny85). As I understand it, the data pins are 5v tolerant (something I learned after the fact!)

I wired up the same hardware using the full 5 wires and it works fine. When I tried the 2 wire it does not work.

Should the RC values in the schematic be adjusted? I'm thinking yes, since the logic levels will be hit before the time it would if using 3.3v instead of 5v. If so, any suggestions for what the values might need to be to meet the timing requirements?

I don't have an oscilloscope to really dig into this. I was planning to buy some bare attiny85 chips though, so that might be my next option.

Thanks! --Doug

[dparson55]

Hi Doug,

I think it is other components sharing connections with pins that is the issue. Looking at the Digispark schematic it seems like ATtiny85 physical pins 5 and 7 are completely free and would work successfully with the 2-pin operation.

Figuring out which physical pins and which digital pins the Digispark defines might be a challenge. The code here in NRFLite maps the digital pins to physical pin registers of the microcontroller, and the mapping works ok when using the MIT High-Low Tech and SpenceKonde's ATTinyCore libraries. Hopefully the Digispark library will work as well but I don't have a Digispark to confirm the mappings, so hopefully you can do some experimenting to determine which pins will result in ATtiny85 physical pins 5 and 7 being used...and hopefully the schematic I referenced is accurate for your particular Digispark model. There might be different models where the on board LED is on a different pin.

[DougWilkinson]

Hi Dave, I just want to thank you again for all your help! As it happens, I am using PB0 and PB2 (pins 5 and 7). This happened out of sheer laziness in that I was just leaving SCK and MOSI where they were and rewired the rest. The LED is in PB1 on my clone too (nice for debugging). If you don't think the 5v vs 3v has anything to do with the problem, then I might just buy some bare ATtiny85 chips to try this "fresh". My final project will need to use the bare chips anyway for battery operation. I appreciate your going the extra mile on this one! If I can ever repay the favor to test something for you, do not hesitate to ask! --Doug

[dparson55]

Sure thing, well if it helps here is a sketch to help determine if the pin mapping is correct. The pin you are using for the 2-pin MOMI (master out master in) pin should light for half a second and the 2-pin SCK pin should light for two seconds.

uint8_t momiPin = 0; // Digispark physical pin 5 being tested for MOMI pin usage
uint8_t sckPin = 2;  // Digispark physical pin 7 being tested for SCK pin usage

volatile uint8_t *_momi_PORT;
volatile uint8_t *_sck_PORT;
uint8_t _momi_MASK, _sck_MASK;

void setup()
{
    _momi_PORT = portOutputRegister(digitalPinToPort(momiPin));
    _momi_MASK = digitalPinToBitMask(momiPin);
    _sck_PORT = portOutputRegister(digitalPinToPort(sckPin));
    _sck_MASK = digitalPinToBitMask(sckPin);
}

void loop()
{
    // Turn on the MOMI pin for 1/2 second
    *_momi_PORT |=  _momi_MASK;
    delay(500);
    *_momi_PORT &= ~_momi_MASK;
    delay(500);

    // Turn on the SCK pin for 2 seconds
    *_sck_PORT |= _sck_MASK;
    delay(2000);
    *_sck_PORT &= ~_sck_MASK;
    delay(500);
}

[DougWilkinson]

I flashed your sketch and the leds I connected to PB0 and PB2 match up with the timing, so I think it's mapping them correctly.

I'll order the bare chips and try that to make sure I'm not making some other assumptions with the digispark clones. There could be something else going on there.

Thanks and happy Holidays! --Doug

[dparson55]

Had another thought, after uploading your code to the Digispark, try unplugging it from the USB and powering it in some other manner. Maybe the USB communication is interfering with the specific timing that is required.

Happy holidays!

[DougWilkinson]

As it happened, I was powering the TX unit with just a power brick after programming because I was using the same USB port on my PC for the receiver unit (monitoring over serial)! So I don't think anything is interfering there. But good idea!

I've ordered the attiny85 chips which should arrive tomorrow. I'll let you know how that goes! --Doug

[dparson55]

Ok too bad. I am away from home at the moment but have the components to make a Digispark there, so when I get home I'll try making one and see if I can figure out the problem.

Good luck with the ATtiny85!

[DougWilkinson]

So at least I am not going crazy, I have this working now with the ATtiny85 chip. I'll go back and double check my testing with the digispark clone just to be sure.

EDIT: I powered the digispark with 3.3v directly to the 5v pin (not using USB power) and it is working. Not sure if it's USB related or 5v related. Best bet is to just use 3.3v to be sure. I'd also suggest that the digispark board for this use case may not be the best fit given the power requirements for the NRF24L01. --Doug

[dparson55]

Ok good deal, so ultimately just a power issue.

Just for fun I tried making a DIY Digispark but didn't have any luck getting it to be recognized as a valid USB device, so glad you were able to prove the 2 pin hookup worked fine.

[dparson55]

@DougWilkinson Another person ran into a problem with the Digispark (issue #61) and during the investigation, I discovered the resistor between the radio's MISO and MOSI pins should be lowered to 5K (I had been recommending 10K). This change fixes a potential issue when powering a microcontroller at 5V while powering the radio at 3.3V, as is the case with a Digispark. I've updated the readme and schematic with this change.