Go Down

Topic: attiny 85, any pointers?/ (Read 50273 times) previous topic - next topic


Hi All,

Ok some more strangeness.

Still no joy talking to the Uno from the ATTiny84, but I used the radio.testCarrier() method to see if there was any activity.

On the ATTiny84, I could see the carrier flag being set/unset while the Uno was transmitting, which to my mind would imply that the channel at least was configured correctly. However when reversing the order I saw nothing on the Uno while the ATTiny was supposed to be transmitting.

Any thoughts?




Success - sort of.

Put some debug statements in (Using SoftwareSerial and an external USB Serial port.) and suddenly things are working.  It appears that there is a timing issue in the version of the Attiny RF24 libraries.

If I remove the debug statement it stops working, or works intermittently. Putting in a delay(1) here and there improves the situation.

Need to investigate further, but thought Id put this information here in case anyone else is attempting this.



This thread has been a huge help to me and I wanted to add a little more in case it's a help for others.  Thanks everyone for all this information.

I have a working proof of concept that gives you extra outputs when using an ATtiny85 with the nRF24L01 without disabling the ATtiny's reset pin.  The concept is based on finding a pin state combination that would never exist when using the nRF24L01 and an "AND" gate made of transistors.  Since SPI communication with the nRF24L01 is activated by setting the CSN pin low, you would never have CSN high and SCK high at the same time.  There would be no point to that since the nRF24L01 would not be listening.  So given that fact you have unique pin state combinations.

Based on this concept you can add two transistors and resistors for their bases to create an "AND" gate (obviously Google it if you're unfamiliar with this type of circuit).  Then if you add an LED and its resistor, you will have a working proof of concept.  You'll be able to turn the LED on by setting the CSN and SCK pins high without interfering with the normal operation of the nRF24L01 or any code changes.  And when operating the nRF24L01 your LED will never come on since the CSN and SCK will never be high together, so you have effectively added a unique output that you can set high or low.  The only limitation is you can't have this output high when communicating with the nRF24L01.  You have to set CSN low to initiate SPI communication with the nRF24L01, so that will turn off the "AND" gate.

This idea works for the CSN and MOSI pins as well and it would only take one more transistor and resistor to create another "AND" gate for this pin combination.  So by having 3 transistors and resistors in your circuit, you can have 2 distinct outputs that can be controlled independently:  set the CSN + SCK pins high to get a high on output 1 and CSN + MOSI pins high to get a high on output 2.

There is one trick to using the MOSI pin though:  you may notice that you cannot control the pin (PB1) like you did the SCK pin (PB2).  The ATtiny85's Universal Serial Interface hardware implements SPI communication and when USI is engaged for this, it overrides the register that controls the PB1 pin.  You simply need to temporarily disable USI's wire mode to take back control of this pin and re-engage it before starting communication with the nRF24L01 later.  Page 117 of the ATtiny85 datasheet, table 15-1, mentions how USI's data output (DO) pin overrides the PORTB register when you're using USI for 3-wire (SPI) communication.  The DO pin is the MOSI pin and pin states are controlled by the PORTB register.  So that's why you cannot control PB1 when USI is engaged for SPI communication.

    // Set USIWM0 = 0 to allow changes to the MOSI pin, PB1.
    USICR &= ~_BV(USIWM0);
    // Set it back to 1 to re-enable USI's 3-wire (SPI) mode.
    USICR |= _BV(USIWM0);

The CSN and MISO pins are the 3rd combination that works.  The only trick is the MISO pin (PB0) is normally an INPUT so you need to update your SPI communication code to change the pin mode to OUTPUT and set it low immediately before setting CSN high.  Then later when you're about to initiate SPI communication again, set it back to be an INPUT before bringing CSN low.  After that code change you can add a 4th transistor and resistor to your circuit to get a 3rd output.

ATtiny85 pin states when nRF24L01 SPI communication is disabled (CSN = high)

    MISO PB0 = Partially high (it's an INPUT so change to OUTPUT and LOW before setting CSN high)
    MOSI PB1 = low (USI overrides pin control, must temporarily disable USIWM0 bit in USICR)
    SCK  PB2 = low
    CSN  PB3 = high (deactivates nRF24L01 from listening to SPI communication)
    CE   PB4 = low or high
    "AND" gate output 1 = CSN + SCK  = PB3 + PB2
    "AND" gate output 2 = CSN + MOSI = PB3 + PB1
    "AND" gate output 3 = CSN + MISO = PB3 + PB0

I'm going to use this technique for a small device that fits into your pocket that vibrates when a signal is received from a base station.  It will be able to receive the wireless notification and activate a small vibration motor all using an ATtiny85, nRF24L01, two PN2222A transistors and 10K resistors, motor reverse current protection rectifier diode, and small rechargeable 3.7V li-poly battery.  I'll need some way to limit the voltage to the nRF24L01 so I'll have to add a couple more parts, but in any event this concept is going to let me add the 1 extra output that I needed in order to activate the vibration motor.

The CSN high situation works for inputs as well.  When CSN is high you could make PB1 or PB2 inputs and read from them.  PB0 is already an input so there's no need to change it.  Obviously no transistors are needed, you'd just read the pins as normal.

So with an ATtiny85 and nRF24L01 you can get 3 nearly normal input/outputs with very little trouble and parts.  And theoretically you can get even more outputs, an "AND" gate with PB3 + PB2 + PB1.  Maybe it's time for a higher pin count micro-controller at that point though :)


Apr 27, 2014, 08:30 pm Last Edit: May 12, 2014, 12:56 pm by Stanley Reason: 1
With the attiny84/85, it is a real hassle to re-connect the USBtinyISP programmer every time I need to re-flash the IC...

As most of my attiny84 sketch hv  a SerialUSB (FTDI) with TinyDebugSerial ( http://www.ernstc.dk/arduino/tinycom.html ) connected to PB0 , I found the TinySafeBoot the perfect bootloader for these attiny...

Just using a command line to send the sketch to the attiny84 with the Serial Tx/Rx lines...
TinySafeBoot  ( http://jtxp.org/tech/tinysafeboot_en.htm )

The TinySafeBoot installation steps are ( not very details on the site )  :-

1. Generate the bootloader hex for attiny84 :-
tsb tn84 b1b0 ( b1 = rx/PB1, b0 = tx/PB0 )

2. Burn the bootloader to the attiny84 ( my programmer is USBtinyISP )
avrdude -c usbtiny -p t84 -U flash:w:<filename generated above.hex>

3. Set the fuse bits
avrdude -c usbtiny -p t84 -U efuse:w:0xFE:m ( Turn on SELFPRGEN bits )

4. Use tsb to send the attiny84 hex to attiny84 using USBSerial
RESET attiny84
tsb COM5 fw blink.hex

Hope this helps ...


Have you checked out the 'new breed' of Pro mini yet? Is there a pin layout drawing of this new version available?
I have several of the old style and would like to try a ISP friendly version, so I guess I'll order a couple also.

Found this image that might help.



Hi All

This is a fantastic thread ..thank you to all who have contributed.
I hope to do so as well sometime :-)

I already have a working sketch for TX and RX which is working between two Arduino UNO's and which I have been using with 433MHZ modules.
I have been batling for weeks to get the NRF24L01+ modules working and now finally moving them to the ATTINY85 platform.

My request (or problem I would like some help with) :

Could someone please explain step by step how to get the NRF24L01+ modules with the maniacbug RF24 library code to compile on the ATTINY85.
I believe the issue is trying to map the pins of the ATTINY85 with SPI library files.
The problem is I'm not sure where to do this and which pins i may omit and/or tie to high/low etc.

Looking forward to your replies.



Yes, A forum member .. Stanley Seow has done it for both the '84 and '85.. Among others, by fixing or rewriting the MIRF class..
My best advice would be to Always remember that "Mr. Google" is your best research friend..
Google sez.. "73400" replies to Stanley Seow.... And this is I think the most salient...
Also search the Forum for nRF24l00 + Stanley Seow, It returns 7 replies...

--> WA7EMS <--
"The solution of every problem is another problem." -Johann Wolfgang von Goethe
I do answer technical questions PM'd to me with whatever is in my clipboard


Hi Doc

Thanks for pointing out Stanley's links. I have been there and have been through it over and over as well as many others.

Like many others (1090 hits on google which are not specific matches to this search "nrf24L01 spi attiny85 RF24 " these are either not easy to fathom and crucial steps are sometimes left out, all have different libraries and versions.
Over and above that I am specifically looking to include SPI as well as RF24 from maniac bug., ie. not an already forked version.

I thought I would come to the forums as a last resort for help.

So you or anyone else have some more info tips etc, I would be most grateful.



From Stanley's advice I removed ALL of the nRF24lXX references from my IDE installation [ver 1.05] to avoid possible lib incompatibilities, at Stanley's advice) I then downloaded the nRF24l01 library for the Tiny84 and installed it under Users/../.My Documents/Arduino/libraries/... and was able to compile and program an '84 with the library.. although I never got around to testing it.
I had several issues, initially in comping his code and I PM'ed him about the issues.
His advice is what I mentioned above and it worked.
The '85 is a really nice little controller but there is one free pin... Two IF you disable the reset... I'd advise you to consider the 84... Most highly.
Stanley is approachable... PM him or extract his contact info from the Google search I mentioned and email him...

--> WA7EMS <--
"The solution of every problem is another problem." -Johann Wolfgang von Goethe
I do answer technical questions PM'd to me with whatever is in my clipboard


Aug 18, 2014, 12:13 am Last Edit: Aug 18, 2014, 01:53 am by joe4444 Reason: 1
Doc :-)

Thanks a million for the info !

I too had issues with the libraries and forks (and not just Stanley's) I have emailed Stanley who has been most helpful and he in turn sent me here :-)

You mentioned you have at most one free pin (assuming reset remains intact)

Do you perhaps have a PIN assignment /mapping that you used for the ATTINY85. ?

I currently have the following setup:
2 -D3/PB3   CE ?
3-D4/PB4   SS/CSN
7-D2/PB2   SCK/SCL
5-D0/PB0   mosi
6-D1/PB1   miso

If the ATTINY85 is going to be a receiver can CE (or any other pin) be left un-connected ?
And if so what do I set for this entry :
Code: [Select]
RF24 radio(2,3);

I only need one pin available for continuous output :-)

As always I look forward to any input or replies


EDIT by me:

OK I am officially stuck :-(

1. I made the changes to SPI (the one that ships with the Arduino)  , I edited mapping in the .cpp file. I include this in my code. ("RF24.h" and "SPI.h")

2.Wired up to NRF24 radio to ATTINY85 with code that make it TX with pin schema as:
ATTINY85          NRF
2 -    D3/PB3   CE
3-     D4/PB4   SS/CSN
7-     D2/PB2   SCK/SCL
5-     D0/PB0   mosi
6-     D1/PB1   miso
1 -     GND
2 - 3v3

Code works perfectly between 2 x Arduino Uno 3's

And code compiles fine on ATTINY85.

But when the ATTINY85 circuit is powered on I receive to response from it on RX side :-(

What should I check or where have I gone wrong ?



In re-reading your last post I realized I'd overlooked one crucial point.. When Stanley forked the nRF lib he rewrote both the Mirf and SPI libs
to accommodate the USI port available from the  Tiny 84 & 85's.  Due to the flash restrictions imposed by the 'small' code space.
This might help you in your search.
An Arduino port of the tinkerer.eu library. It works with most nRF24L01+ modules.


For this fork, I include :-
* SPI85 libs for attinyXX support
* attiny84 examples codes working with RF24

From xdarklight/arduino-nrf24l01 forks :-
This fork includes the following changes:
* Added support for the SPI85 library on ATtiny85 chips.
* Compatible with ATmega and ATtiny chips (tested with ATtiny85).
* Can connect to devices using the RF24 library by setting
 "Mirf.baseConfig = _BV(EN_CRC) | _BV(CRCO);" before calling
* Reduced binary size.

Other information:
* This library supports changing less popular registers without
 having to "hack" the libraries code. An example for changing
 the RF_SETUP register:
 "Mirf.configRegister(RF_SETUP, _BV(RF_DR_LOW));"


There is code for both the tiny 84's and the 85's in the examples.

--> WA7EMS <--
"The solution of every problem is another problem." -Johann Wolfgang von Goethe
I do answer technical questions PM'd to me with whatever is in my clipboard


I'm using the tiny cores from https://code.google.com/p/arduino-tiny/
See under hardware/tiny/avr/cores/tiny/pins_arduino.c
Code: [Select]

#if defined( __AVR_ATtinyX5__ )

//                           +-\/-+
//  Ain0       (D  5)  PB5  1|    |8   VCC
//  Ain3       (D  3)  PB3  2|    |7   PB2  (D  2)  INT0  Ain1
//  Ain2       (D  4)  PB4  3|    |6   PB1  (D  1)        pwm1
//                     GND  4|    |5   PB0  (D  0)        pwm0
//                           +----+

Different "tiny cores" maps the digital pins differently...

This is my working attiny85 pinout :-
Code: [Select]
// Pinout ( physical pin / Digital pins / nRF side )
// CE   - Pin 2 / D3 / nRF3
// CSN  - Pin 3 / D4 / nRF4
// GND  - Pin 4
// MISO - Pin 5 / D0 / nRF7
// MOSI - Pin 6 / D1 / nRF6
// SCK  - Pin 7 / D2 / nRF5
// Vcc  - Pin 8 ( 3.3V )

#define CE  PB3 //ATTiny pin2
#define CSN PB4 //ATTiny pin3


Hi Stanley

Thanks for your reply :-)
I am also using the tiny cores from https://code.google.com/p/arduino-tiny/

I have a few questions now:

1, When i check this file
(See under hardware/tiny/avr/cores/tiny/pins_arduino.c
it is exactly the same as you have BUT the path is different. The path is \Arduino\hardware\tiny

What should I be doing with it or in it ?
Can I check it is in the correct path ?

2 .Regarding the pinout I see MOSI and MISO are swapped ?

3. Where do you set these defines ??
Code: [Select]

#define CE  PB3 //ATTiny pin2
#define CSN PB4 //ATTiny pin3

4. What is meant by
Code: [Select]
#if defined( __AVR_ATtinyX5__ )

Thank you once again

I look forward to any further help as always :-)



Hi Joe,

1. As long as you are using the same tiny cores, you are good..

2. Yes, swap them and try to upload something to the attiny85

3. Ignore this statement, it was from my Mirf codes... just use the RF24 libs that are now supported for most of the platforms including attiny 85 & 84 ( but you do not have much space left )

4. The below is to check for X5 ( where X = attiny 25, 45 & 85 ) mcu and do the necessary define if you write codes for multiple platforms or mcu...

Code: [Select]

#if defined( __AVR_ATtinyX5__ )


Thanks again Stanley

Here are the steps I have completed so far:

1. Downloaded and installed the latest RF24 network library from maniacbug github

2. Edited the standard ardunio included SPI library (which seems to have support for attiny85) ..is this correct or rather use the SPI85 ?
The files I check are here : Arduino\libraries\SPI
and the files are :
SPI.cpp (this has pin mappings)  ..Do i need to map these to the correct pins as well ?
I changed these to match my pin connections to the nrf24:
Code: [Select]
#if defined(__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)
// see http://gammon.com.au/spi
# define DI   6  //was 0// D0, pin 6  Data In //MISO
# define DO   5  //was 1// D1, pin 5  Data Out (this is *not* MOSI) //MOSI
# define USCK 7  //was 2// D2, pin 7  Universal Serial Interface clock //sck
# define SS  2  //was 3// D3, pin 2  Slave Select //csn

This also has a #if_defined but where and when is it defined ?
I assume (could be wrong that all that is required is to INCLUDE the library in my code with
Code: [Select]
include SPI.h
is this correct ?

3. Loaded the tiny cores from https://code.google.com/p/arduino-tiny/
and as you metioned check the pin mappings  there too for ATTINY85.

4. Loaded my sketch (just a basic transmit loop which when tested on the arduino UNO to UNO works fine) using the arduino IDE which seems to compile fine. ....BUT ... I receive nothing yet :-(

Can you or anyone else possibly identify where I have gone wrong or provide some tips ?



Go Up