logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

How to connect nRF905 to ESP32-WROOM-32 v1.1? Transmit/receive not working

amidar 1755 12
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
Reply | New topic
  • #1 17735156
    amidar
    Level 10  
    Hi,

    I would like to use the nrf905 module (433 and 868 radio on SPI) with the ESP32 WROOM 32 controller....
    I found a library to support this module for arduino, from the website
    http://blog.zakkemble.co.uk/nrf905-avrarduino-librarydriver/
    For testing I used the sources ping_client, and ping_server on 2 sets of ESP32 +nRF905. One was to work as a client, the other as a server.

    The library itself required a little pin remapping, additionally I switched the SPI from VSPI to HSPI on pins 12-15.
    The other pins used were:
    CD - 6,
    AM - 27,
    DR - 7,
    PWR - 11,
    TxE - 0
    CE - 34
    Module supply voltage 3.3V
    Probably everything....

    The examples compile without any major problems, load into ESP.... and they seemingly work, but.... don't transmit, or at least one can't see the other.

    Question is, has anyone tried plugging the nRF905 into the ESP32, did it work, maybe there is some other library, dedicated to the ESP?
    Oh and one more thing, I use Sloeber for compilation.

    Attached the client and server sources + library after correction.
    And one more detail in the SPI library, I changed a line at the end to switch the pinology to HSPI
    //SPIClass SPI(VSPI);
    SPIClass SPI(HSPI);


    Thanks in advance for any suggestions....
    Attachments:
    Do you have a problem with Arduino? Ask question. Visit our forum Arduino.
  • ADVERTISEMENT
  • Helpful post
    #2 17735297
    khoam
    Level 42  
    The library you refer to does not support the ESP32 architecture, which is clear from its source code - I don't know how you managed to compile it for ESP32.
    I would suggest that you first use the information on RadioHead .
  • #3 17736294
    amidar
    Level 10  
    khoam wrote:
    The library you refer to does not support the ESP32 architecture, as is clear from its source code - I don't know how you managed to compile it for ESP32.
    I suggest that you first use the information on RadioHead .
    .

    Thanks for the leads, I'll have something to do tonight :) .

    As for that library I knew it was written for the arduino, although I assumed that after changing the pinology (it's directly in the sources) it would still fire.... Well... It didn't fire. And from this, it follows that my knowledge of ESP is still too small.
  • ADVERTISEMENT
  • #4 17736545
    kaczakat
    Level 34  
    It could have worked, but just with V, the easiest way is to print yourself Serial.print(MOSI) and so each SPI pin, you will find out under which GPIO pins are mapped by default. You can reconfigure this as long as you don't use GPIO 6-11, these are used for the flash built into the ESP32 (and you use them too). Of course the GPIO no. doesn't have to coincide with that number on the board, you can still confirm by flashing the led on that pin just to be sure. Unfortunately it's messed up, but surely if you define the pin as 6 it's GPIO6, meaning to flash, and on the board marked as 6 it could be the GPIO34 pin.
    Helpful post? Buy me a coffee.
  • #5 17736648
    khoam
    Level 42  
    Today I tried to access http://blog.zakkemble.net/nrf905-avrarduino-librarydriver/ and received a message like the following :) .

    How to connect nRF905 to ESP32-WROOM-32 v1.1? Transmit/receive not working .

    Added after 1 [minute]:

    kaczakat wrote:
    May have been successful
    .
    The author of this software doesn't know anything about it yet. From the blog on this site it appears that support for ESP32 has not been tested, nor is it planned.
  • ADVERTISEMENT
  • #6 17736727
    kaczakat
    Level 34  
    If the library communicates at a defined interface level, e.g. any to GSM using the UART then it is indifferent to how the UART is handled by UNO, ESP or DUE. If it sets something in registers itself to activate/control low level from UART/SPI then it will fail. But the Arduino uses ready-made functions like SPI.begin() and this will work the same on all of the above. The library is just meant to be a building block of what to send over SPI, together with the building block provided by installing all the data into the ESP32 it should work the same.
    In ESP32, the default pins for SPI can be found at the ESP32 installation site in the "variants" directory, on most boards:
    Quote:
    static const uint8_t TX = 1;
    static const uint8_t RX = 3;

    static const uint8_t SDA = 21;
    static const uint8_t SCL = 22;

    static const uint8_t SS = 5;
    static const uint8_t MOSI = 23;
    static const uint8_t MISO = 19;
    static const uint8_t SCK = 18;
    .
    Of course, I've done some flimsy tests with SD and some I2C sensors, but I haven't installed any special libraries for this. If you want to use something more than the default defined, though, you'll probably have to do more messing around. E.g. you have to remap UART1 from the flash pins to use it, but it's possible to fire all 3 on the ESP32.
    Helpful post? Buy me a coffee.
  • #7 17737441
    khoam
    Level 42  
    @kaczakat it's not just about getting the "pinology" right. As you probably know, the ESP32 has two cores, and on one of them goes the WiFi stack. If the Arduino code blocks execution on the latter for an extended period of time, there will be a hang or a reboot of the whole thing. To make things funnier, using Arduino delay() is quite correct, and sometimes advisable in ESP32, as it calls yield() cyclically. The code referenced by the Author was not designed to run correctly on ESP32, it was designed for AVR only.

    Source (applies to ESP8266 and ESP32).
  • #8 17737654
    kaczakat
    Level 34  
    I didn't test that much, and I even thought that yield() was just not needed anymore in ESP32, because it's the WIFI that runs itself on a separate core, you can use it without a problem, but anyway the default is only core1, core0 runs itself with WIFI support. And from the esp guru I found this quote:
    Quote:
    igrr says:
    October 31, 2016 at 9:20 am
    In ESP32 Arduino core we run the “sketch” (setup and loop and everything they call) on CPU1, while the WiFi stack is running on CPU0. This allows messing with interrupts at will, and running more or less timing critical code. No more yield, yay! Interrupts attached through Arduino APIs also run on CPU1.

    If you want to run something on CPU0 from Arduino, you have to use FreeRTOS function to start a new task, with task affinity set to CPU0. That’s it! Then use some FreeRTOS synchronization primitives to communicate with the new task.
    .
    So your entry is pretty much just for ESP8266, I'll test it sometime next time I play with ESP32, maybe the entry is out of date and something came up along the way.
    Also no library should hang around waiting for a response, you can do this by dividing the function into stages and despite calling it cyclically only execute the stage remaining to be executed, and keep in a variable only the stage number to be executed, e.g. waiting for a response. Alternatively, you could count the time of each stage and set a limit for each, and simply report an error/start again when the timeout expires. In any case, whatever should work, at most it would spill resets. It certainly won't work if it uses proprietary pins.
    Helpful post? Buy me a coffee.
  • #9 17738388
    khoam
    Level 42  
    kaczakat wrote:
    maybe the entry is out of date and something has come up along the way.
    .
    Actually, I'm the one who hasn't updated. I spent too much time with the ESP8266 ;) .

    I only have one doubt about the code from post#1. Enabling and disabling interrupts is for the Arduino version of the code done "traditionally" by noInterrupts()/interrupts().
    For ESP32, you should rather use portENTER_CRITICAL/portEXIT_CRITICAL in as short intervals as possible - at least that's what I've read on several forums.
    noInterrupts() for ESP32 only blocks interrupts on CPU1, so it's hard to say that you can create critical sections this way.
  • #10 17738836
    kaczakat
    Level 34  
    Logically, if there is a separate core then 100% of core1's power is for the Arduino code, even if there are interrupts on core0 it won't affect core1, it's harder to synchronise them to work together because it's actually done "manually" than to negatively affect one on the other - each one flies independently. Sort of like how an active PWM in an AVR stops for the duration of an interrupt.
    Helpful post? Buy me a coffee.
  • #11 17738849
    khoam
    Level 42  
    kaczakat wrote:
    as logically as there is a separate core then 100% of core1 power is for the Arduino code,
    .
    The Arduino framework for ESP32 also allows tasks to be performed on CPU0, not just WiFi related functions.
  • #12 17815839
    mao73a
    Level 2  
    Amidar,
    did you manage to get this working?
    I am just trying to connect the NRF905 with the ESP8266 and have not been able to find a ready-made wiring diagram on the web.
    Is it necessary to switch to HSPI?
    I found a page Link where it describes how to connect the NRF905 and the raspberry and there the DR pin is connected via a resistor (220Ohm).
    Shouldn't it be similar here?

    Greetings,
    Mao73a
  • ADVERTISEMENT
  • #13 17818964
    amidar
    Level 10  
    Just as a quick aside, I also tested RadioHead. I don't know which solution is worse. For a while I thought about writing my own library, but I don't have time for that. The solution on the lowest line of resistance. An additional Arduino nano to connect to the Radio. It works...
Reply | New topic
Report a violation of the law

Topic summary

The discussion addresses difficulties in interfacing the nRF905 radio module (operating at 433 and 868 MHz via SPI) with the ESP32-WROOM-32 v1.1 microcontroller. The original approach used an Arduino-targeted nRF905 library, requiring pin remapping and switching SPI from VSPI to HSPI on ESP32 pins 12-15, with additional control pins assigned to various GPIOs. Although the code compiled and loaded successfully, transmission and reception between two ESP32+nRF905 setups failed. Responses highlight that the referenced library lacks ESP32 support and may not handle ESP32-specific architecture, such as dual-core operation and interrupt management. SPI pin assignments must avoid GPIO6-11 due to flash memory usage, and proper GPIO mapping is critical. Suggestions include consulting the RadioHead library for radio communication, though it also may not fully support ESP32. The ESP32 Arduino framework requires careful handling of critical sections using portENTER_CRITICAL/portEXIT_CRITICAL instead of noInterrupts()/interrupts(). Timing and task scheduling must consider ESP32’s dual-core and WiFi stack to prevent blocking or resets. Additional hardware considerations include proper wiring of the DR pin, possibly with a resistor, and verifying power supply levels. Some users resorted to using an Arduino Nano as an intermediary to handle the nRF905 communication due to lack of a dedicated ESP32 library. Overall, successful integration demands ESP32-specific library support, correct SPI and GPIO configuration, and attention to ESP32 multitasking and interrupt handling nuances.
Summary generated by the language model.
Popular Topics
ADVERTISEMENT