1/20/2024 0 Comments Rfm69 esp8266 arduino![]() ![]() Serial. Serial.print(String(MsgMatch) + String(MsgMatch) + String(MsgMatch) + String(MsgMatch) + String(MsgMatch) + String(MsgMatch) + String(MsgMatch) + String(MsgMatch) + String(i) + "- ") Here is the code I am using, it partially uses the library " GitHub - kobuki/RFM69OOK: A general OOK transceiver library for RFM69": #include You can see this in the attached images (top is RFM69, Bottom is RXB6). If I use a RXB6 OOK Reciever it picks up the signal perfectly. However it is not the correct data that has been transmitted. ![]() I have been able to get it to pick up the transmission of the bell when looking at the Data output pin DIO2 using a logic analyser. We're now trying to enforce what checks we can, which resulted in a user here hitting the check in this library, which doesn't officially support the ESP, thereby stopping bad usage.Hi I am trying to setup a RFM69W to pickup my Door Bell OOK transmitter. However, new users are rarely aware of such things, and then they end up with weird crashes or unexpected behavior. Our stand is that 3rd party libraries that explicitly state support for the ESP are ok, and those that don't mention support probably contain dragons. Or you can choose to not support ithe ESP (you said it isn't officially) in which case you likely should be explicit about it to your users so that they don't assume. You can choose to support the ESP platform, in which case this quirk is needed. ![]() We call these RadioFruits, our take on an microcontroller with packet radio transceiver with built-in USB and battery charging. You obviously have demand for support on the ESP. Adafruit Industries, Unique & fun DIY electronics and kits Adafruit Feather RP2040 RFM69 Packet Radio - 868 or 915MHz RadioFruit and STEMMA QT : ID 5712 - This is the Adafruit Feather RP2040 RFM69 Packet Radio (868 or 915 MHz). So we don't "reverse fix all the code in the world", but rather let users who require support make such requests from the library author on a case by case basis. users request support for the platform in question. "All the code in the world" deal with such portability problems by implementing the specific quirks for the specific platforms in their library code, and this is usually done based on user demand, i. It is related to hardware, and at this time there is no known way to work around it, or make it stating that we "should fix it" is not realistic, 100% compatibility across all platforms can't really be achieved when the platforms are fundamentally different. The fact that code executed while in an ISR must be in instruction RAM and not in flash is one of the quirks of the ESP/ESP32. Not all Arduino-ish platforms are created equal, they all have some quirk or other that needs to be handled in some special way. This is history on the ESP platform from the beginning. Cache fill needs external SPI flash transactions and that does not work well while in an ISR, so we need to direct ISR functions in ram section to avoid those random crashes. Ram is used as a cache for the flash, this is implemented in hardware. We are doing what we can to avoid that type of issue and things are not always easy as a snap of a finger. The proposed change is lighter than that. That's the arduino way of trying to be the most compatible with every platform. If you look at numerous arduino examples, you'll see tons of ugly #ifdef this and #ifndef that. What if every platform now requires some weird attribute to be added You'll have now a good reason to close the issue: "Ludicrous" arduino core on the ESP platform. That will bring more people back to your repository asking why things fail sometimes. You are perfectly in the right to refuse it. The fix that is proposed to your library is indeed Ludicrous in its size or intrusion factor. I still think it's just very new and undocumented. Because of Ludicrous I feel I can answer to that. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |