In the same hardware configuration i have an oled screen and a RF radio, those work with the Adafruit library Adafruit_SSD1306 GitHub - adafruit/Adafruit_SSD1306: Arduino library for SSD1306 monochrome 128x64 and 128x32 OLEDs and the RF24 library GitHub - maniacbug/RF24: Arduino driver for nRF24L01.
Separately those two works ok, if I load just the code for the oled screen testing it works, if i load the code just for the rf modem testing it works, but if I initialize the RF modem and then the oled screen, just the modem starts and the screen remains black, no compiler errors.
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>
#include <SPI.h>
#include "nRF24L01.h"
#include "RF24.h"
#include "printf.h"
//RF DEFINITIONS
RF24 radio(9,10);
const uint64_t pipes[2] = { 0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };
bool done = false;
char data_in[9];
//OLED DEFINITIONS
#define OLED_DC 6
#define OLED_CS 7
#define OLED_CLK 13
#define OLED_MOSI 11
#define OLED_RESET 8
Adafruit_SSD1306 display(OLED_MOSI, OLED_CLK, OLED_DC, OLED_RESET, OLED_CS);
#define LOGO16_GLCD_HEIGHT 16
#define LOGO16_GLCD_WIDTH 16
void setup () {
Serial.begin(57600);
printf_begin();
//Radio config
radio.begin();
delay(1000);
/*radio.setDataRate(RF24_250KBPS);
radio.setChannel(1);
radio.setRetries(15,15);
radio.printDetails();
radio.openReadingPipe(1,pipes[0]);
radio.startListening();
*/
//OLED CONFIG
display.begin(SSD1306_SWITCHCAPVCC);
If I comment the line radio.begin the screen works, so im 100% sure there is a conflict between those two libraries, i checked the radio begin function but i dont see anything that could cause the problem:
void RF24::begin(void)
{
// Initialize pins
pinMode(ce_pin,OUTPUT);
pinMode(csn_pin,OUTPUT);
// Initialize SPI bus
SPI.begin();
ce(LOW);
csn(HIGH);
// Must allow the radio time to settle else configuration bits will not necessarily stick.
// This is actually only required following power up but some settling time also appears to
// be required after resets too. For full coverage, we'll always assume the worst.
// Enabling 16b CRC is by far the most obvious case if the wrong timing is used - or skipped.
// Technically we require 4.5ms + 14us as a worst case. We'll just call it 5ms for good measure.
// WARNING: Delay is based on P-variant whereby non-P *may* require different timing.
delay( 5 ) ;
// Set 1500uS (minimum for 32B payload in ESB@250KBPS) timeouts, to make testing a little easier
// WARNING: If this is ever lowered, either 250KBS mode with AA is broken or maximum packet
// sizes must never be used. See documentation for a more complete explanation.
write_register(SETUP_RETR,(B0101 << ARD) | (B1111 << ARC));
// Restore our default PA level
setPALevel( RF24_PA_MAX ) ;
// Determine if this is a p or non-p RF24 module and then
// reset our data rate back to default value. This works
// because a non-P variant won't allow the data rate to
// be set to 250Kbps.
if( setDataRate( RF24_250KBPS ) )
{
p_variant = true ;
}
// Then set the data rate to the slowest (and most reliable) speed supported by all
// hardware.
setDataRate( RF24_1MBPS ) ;
// Initialize CRC and request 2-byte (16bit) CRC
setCRCLength( RF24_CRC_16 ) ;
// Disable dynamic payloads, to match dynamic_payloads_enabled setting
write_register(DYNPD,0);
// Reset current status
// Notice reset and flush is the last thing we do
write_register(STATUS,_BV(RX_DR) | _BV(TX_DS) | _BV(MAX_RT) );
// Set up default configuration. Callers can always change it later.
// This channel should be universally safe and not bleed over into adjacent
// spectrum.
setChannel(76);
// Flush buffers
flush_rx();
flush_tx();
}
What do you think?
