David Gironi's NRF24l01+ driver. Questions...

Go To Last Post
22 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi to all AVR freaks.
I have a couple of questions regarding the NRF24lo1+ boards and the driver circuit/program from david Gironi via
http://davidegironi.blogspot.co.uk/2012/03/nrf24l01-atmega-library-and-development.html

I would like to know if anyone out there has built these drivers and got them working with the code supplied by My Gironi. (Mr Gironi, if you're out there, HI!)
I have built both circuits on breadboards(see pix)

I am using an ATmega 88pa's as opposed to an Atmega 8. They both have the same pinout so I am assuming the code doesn't have to be modified. I built these as I am experimenting with wireless at the moment and these seem like a great way of starting with wireless. I have had success on Arduino.
The code has been burned onto the chips using AVR dragon running AVR studio 6. No apparent problems with uploading the code.
I am getting no response form the devices though. One is supposed to press a switch on one of the modules and an LED lights up on both modules. However,
No lights.
The wiring is all correct as far as I can see. The schematic ( see pix) doesn't have a crystal attached but i'm not sure what it is supposed to be set to..

Could anybody help me here?

Should there be a problem with me using an 88PA as opposed to an ATmega 8?
Thanks again.
Steve.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

They both have the same pinout so I am assuming the code doesn't have to be modified.

Why would you assume that?

It would need to be rebuilt for the correct target processor, at a minimum.

Have you looked for a migration app note? (the changes are not extensive IIRC but could be critically important in some apps.)
http://www.lmgtfy.com/?q=atmega8...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys. I got a message from david. He did say he didn't think there would be any conflict between the two devices... I have found the application note for migration from 8 to 88. I'm looking through it now and looking at the code. The "main" is below:



#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include "uart.h"
#define UART_BAUD_RATE 2400

#include "mirf.h"

uint8_t txrxrole = 0; // 1 transmitter 0 receiver

#define buffersize mirf_PAYLOAD
uint8_t buffer[buffersize];

uint8_t rxaddr[5] = {0x01, 0x02, 0x03, 0x04, 0x05};
uint8_t txaddr[5] = {0x01, 0x02, 0x03, 0x04, 0x05};

#define BUTTONROLE PC0
#define ROLETX 1
#define ROLERX 0
#define BUTTONSEND PC1
#define LEDOUT PC5
#define LEDOUTPAUSE 300

//main here
int main(void)
{
	mirf_init();
	_delay_ms(50);

	DDRC &= ~(1<<BUTTONROLE) | ~(1<<BUTTONSEND);
	DDRC |= (1<<LEDOUT);
	PORTC &= ~(1<<LEDOUT);

	uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );

	sei();

	mirf_config();

	mirf_set_rxaddr(0, rxaddr);
	mirf_set_txaddr(txaddr);

	if ((PINC & (1<<BUTTONROLE)) == 0)
		txrxrole = ROLERX;
	else
		txrxrole = ROLETX;

	if(txrxrole == ROLETX) {
		PORTC |= (1<<LEDOUT); _delay_ms(LEDOUTPAUSE);
		PORTC &= ~(1<<LEDOUT); _delay_ms(LEDOUTPAUSE);
	} else if(txrxrole == ROLERX) {
		PORTC |= (1 << LEDOUT); _delay_ms(LEDOUTPAUSE);
		PORTC &= ~(1 << LEDOUT); _delay_ms(LEDOUTPAUSE);
		PORTC |= (1<<LEDOUT); _delay_ms(LEDOUTPAUSE);
		PORTC &= ~(1<<LEDOUT); _delay_ms(LEDOUTPAUSE);
	}

	for(int i=0; i

The libraries are the uart library from P.Fleury and the mirf library. Would I have to change the register names to fit the changes for the 88PA?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Would I have to change the register names to fit the changes for the 88PA?

Yes. At the very least all the 88 registers and bitnames have an additional 0 in then so UDR becomes UDR0 and so on. However it's possible the Fleury code is young enough to know about this and already has an adaptation for this.

EDIT: Yes he does this:

#elif  defined(__AVR_ATmega8__)  || defined(__AVR_ATmega16__) || defined(__AVR_ATmega32__) \
  || defined(__AVR_ATmega8515__) || defined(__AVR_ATmega8535__) \
  || defined(__AVR_ATmega323__)
  /* ATmega with one USART */
 #define ATMEGA_USART
 #define UART0_RECEIVE_INTERRUPT   SIG_UART_RECV
 #define UART0_TRANSMIT_INTERRUPT  SIG_UART_DATA
 #define UART0_STATUS   UCSRA
 #define UART0_CONTROL  UCSRB
 #define UART0_DATA     UDR
 #define UART0_UDRIE    UDRIE
#elif defined(__AVR_ATmega48__) ||defined(__AVR_ATmega88__) || defined(__AVR_ATmega168__) || defined(__AVR_ATmega48P__) || defined(__AVR_ATmega88P__) || defined(__AVR_ATmega168P__) || defined(__AVR_ATmega328P__)
 /* ATmega with one USART */
 #define ATMEGA_USART0
 #define UART0_RECEIVE_INTERRUPT   SIG_USART_RECV
 #define UART0_TRANSMIT_INTERRUPT  SIG_USART_DATA
 #define UART0_STATUS   UCSR0A
 #define UART0_CONTROL  UCSR0B
 #define UART0_DATA     UDR0
 #define UART0_UDRIE    UDRIE0

So that should adapt as long as you set the build for the right target device. Note that "knows" about __AVR_ATmega88__ and __AVR_ATmega88P__ but not __AVR_ATmega88PA__ so if your build options give you the choice of "88", "88P" and "88PA" choose one of the first two, not the latter as it post dates Fleury's code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

my library is based upon tinkerer.eu, so you could check if with tinkerer lib it works.

one of the two board should be the trasmitter and one the reciver, in the lib example i check PC0 to select the role (tx or rx).

check using a scope what happens on spi.

if you do not have a scope debug using uart in the mirf_write and mirf_read function.

try to use an arduino library and check if with the arduino lib it works.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys. Thanks for keeping with me.

Quote:
one of the two board should be the trasmitter and one the reciver, in the lib example i check PC0 to select the role (tx or rx).

The role is changed by connecting pin23 to +5v correct? In the video, when David presses the button, the leds on both boards light up. So this would suggest that the LED lighting up is a basic part of the circuit anyway. Neither of my boards light up when i press my switch.

Quote:
check using a scope what happens on spi.

How do i do this? I have a scopex in the room.Check for pulses? :\

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

How do i do this? I

SPI is synchronous serial which means everything that happens is slaved to the clock signal. As such you would usually make SCK your oscilloscope trigger signal and then (depending on how many channels the scope has) also probe MOSI and/or MISO. As SCK pulses and triggers the scope (best if it also has a storage mode so you can capture the event for later study) you look at MOSI and see if what is going out from the master is the bit pattern you expect and that it's edges are occuring in the right place with reference to the clock (the CPOL and CPHA allow for four variations of this). Meanwhile you can look at MISO when the master is generating SCK to see what the salve is returning. Again is it what you expected and are the edges occurring at the right point in the timed sequence?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the led on the tx button light up because of the pressed button

rx side is light up if the mirf_read_ready is true, so if there is something to read
a more accurate way should be send a data buffer and check it is the same rx and tx

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Again Clawson & Hozone. . My Oscilloscope, although 2 channel, is old and cranky with a fuzzy screen. I am getting trigger pulse signals on the SCK channel and the MOSI/MISO channels but it is blurry so hard to read. :(

. I eventually swapped the Atmega88s for Atmega 8 chips and am still having trouble. The LEDs now flash when the reset button is pressed.( good ). Unusual behaviour on pressing the transmit button though: If the Role connection is set to Transmit ( Role pin connected to +5v), the LED flashes twice and stops. If it is set to Recieve, it flashes continuosly. Is this normal behaviour?
The transmission doesn't work however and the signal doesn't transmit to the recieving NRF board. Is it normal for the LED to continuously flash if it is waiting for a signal or is this not normal. ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

but it is blurry so hard to read.

A decent (digital storage) scope is an invaluable tool for a software engineer. Maybe consider an upgrade? A "free" solution is to write the SPI software to it goes so slow it's actually using frequencies in audio range (sub 40kHz) then use a "soundcard scope" which uses the soundcard in your PC as a scope. The (free!) software will do things like letting you capture a burst of activity then study it in detail afterwards. NOTE you have to be very kind to your soundcard - it will not tolerate anything over 1V being input. If you do this it may be time to say goodbye. So you (a) need a potential divider to get a (typically) 5V signal to 1V and (b) you have to be POSTITIVE you never violate this by accidentally applying a higher voltage (even just touching the "probe" on the wrong bit of a circuit might do this).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OOh,Ooh! . I Do have a Freescale Demojm board which has an on board Logic Analyser ( 2 channel ) which sends logic signals to a software Logic Analyser by PEMICRO. The DEMOJM board uses pins INT0 and INT1 as the capture channels. Maybe I could use this.. I'll give it a try.
If you want to see what I'm talking about, the URL is:
http://www.pemicro.com/fixedlinks/DEMOToolkit.cfm#1
Cheers!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the new version of the library contains some (a lot) of bugfix, http://davidegironi.blogspot.it/...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The most serious bugfix should be the schematic that puts 5V onto the NRF24L01+ VCC pin.

The NRF24L01 is a 3V chip. It is rather cruel to offer tutorials that will/may destroy the chip.

Note that you can apply 5V signals to MOSI, SCK, CSN, CE etc because the GPIO pins are 5V tolerant. The chip itself should be powered at 3.3V. Three regular diodes in series with VCC should drop 5V down to a 'safe' level. e.g. 5.0V - 1.8V = 3.2V

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i know david, but my ebay cheap NRF24L01 board "tolerate" 5v input, and for semplicity i've made this schematic. so.
but you are right, to correct this design issue, i will add 3 x 1n4004 to the vcc pin input of the NRF24L01 board. right?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the use of the uart?
Is F_CPU defined (used by uart_init)?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uart is for debug.

i use eclipse with avrgcc for testing, in eclipse avrgcc projects F_CPU is defined in environment.
anyway you could define it if is not defined (es. #define F_CPU 1000000UL)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
The most serious bugfix should be the schematic that puts 5V onto the NRF24L01+ VCC pin.

The NRF24L01 is a 3V chip. It is rather cruel to offer tutorials that will/may destroy the chip.

Note that you can apply 5V signals to MOSI, SCK, CSN, CE etc because the GPIO pins are 5V tolerant. The chip itself should be powered at 3.3V. Three regular diodes in series with VCC should drop 5V down to a 'safe' level. e.g. 5.0V - 1.8V = 3.2V

David.

i've add 3 diode, and one caps near the power, now it works without plug the power line of the NRF24L01 directly on +5v.
can you check my circuit? tks ;)

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The diodes look fine. You should be fine with any non-schottky diodes. After all, the module only draws 15mA. Signal diodes should manage 15mA ok.

I do not understand your 100R for a LED. Seems rather low.
Nor the pull-downs on PC0 and PC5. Normally you use an internal pull-up, and provide a jumper from pin to GND. i.e. no external resistors.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you!

100R, cause i want it bright :)

I've always use pull-down button :) i will try internal pull-up.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hrm. I'm having similar problems getting these working on the breadboard. I've got the code compiling without any warnings or errors, and am using atmega328p chips.

I get either a single flash, or double based on the mode I have selected (RX/TX) using the PC0 jumper. After that nothing, no serial messages whatsoever.

I downloaded the UART library directly and tried it myself using the demo program and it worked fine. So I know this isn't a F_CPU issue. Also, interestingly I tried to put another flash of the led in after the program sends a message to UART but I get nothing at all. It does work if I comment out the uart_puts though, strange!

I've been at this one for hours now, any help you guys can give would be greatly appreciated! I really want to get these things going!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fixed it. I replaced the uart.c and uart.h with the ones from Peter Fleyry's site and it works fine now. Strange!

But I'm very stoked to have this running. Thanks a lot to Davide!