Improve on random()
The original code doesn't check for what mode the radio is in and returns 0, if the radio isn't in listening-mode; this code-change waits until any queued packets have been transmitted, checks the current mode, changes it to listening-mode, gets the random value and then proceeds to change the mode back to whatever it was.
The loop shouldn't take that long. Did you try it, then, and it crashed?
On 26. syyskuuta 2018 12.00.20 Anthony Elder [email protected] wrote:
@torntrousers commented on this pull request. In src/LoRa.cpp:
@@ -582,7 +582,26 @@ void LoRaClass::setOCP(uint8_t mA) byte LoRaClass::random() {
- return readRegister(REG_RSSI_WIDEBAND);
- uint8_t currMode = readRegister(REG_OP_MODE);
- uint8_t retVal = 0;
- while(isTransmitting()); Does it need a yield() call in this loop so the WDT doesn't fire on platforms like ESP8266/32? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
The loop shouldn't take that long. Did you try it, then, and it crashed?
No I haven't tried it, just use ESP's a lot so wary of loops like this. It could take a bit of time to transmit bigger packets at high spreading factor / low bandwidth though.
Well, I suppose. I guess adding a yield() in there wouldn't hurt anyone.
I guess is a bad idea make the random function to change the module to receive mode. I use to generate a randomSeed on setup() and use the default random.
LoRa.receive();
// Generate a random seed with 32 bits
uint32_t seed = (uint32_t) LoRa.random() << 24 |
(uint32_t) LoRa.random() << 16 |
(uint32_t) LoRa.random() << 8 |
(uint32_t) LoRa.random();
randomSeed(seed);
Check the exemple. https://github.com/ricaun/arduino-LoRa/blob/master/examples/LoRaSimpleRandomSeed/LoRaSimpleRandomSeed.ino
I guess is a bad idea make the random function to change the module to receive mode.
Is a bad idea why?
Is a bad idea why?
Because of this while(isTransmitting()) yield(); and why a random function need to be so complex.
For a small code is ok, but when you have a more complex code, blocking the main code is a bad design. Could break others existents codes.
I know you want to improve the library, I want too.
But I don't see why change...
It's my opinion but not my library so...
👍
But I don't see why change...
Personally, I believe that a function with such a simple premise as returning a random byte should be as self-contained as possible. There's no good reason for why the user should have to bother messing with setting correct modes for the LoRa-chip for a one-off function-call with no long-term functionality.
Yes, my approach means that each call to random() takes longer than it originally did, but on the other hand, it makes the function a truly one-off thing, just as e.g. the C++ rand() is -- you call it when you need it and that's all there is to it.
If sandeepmistry doesn't approve of this approach then fine, I'll close the pull-request and just stick to my own fork, but until then I shall disagree with you.
Personally, I believe that a function with such a simple premise as returning a random byte should be as self-contained as possible. There's no good reason for why the user should have to bother messing with setting correct modes for the LoRa-chip for a one-off function-call with no long-term functionality.
I like your point, you are right.
If sandeepmistry doesn't approve of this approach then fine, I'll close the pull-request and just stick to my own fork, but until then I shall disagree with you.
No worries, I guess I prefer low-level functions.
Pardon my silly question, why we ever need to have a random() function for LoRa? Is there any specific case for this random() in LoRa applications?
"Generate a random byte, based on the Wideband RSSI measurement."
byte b = LoRa.random();
Thanks a lot.
Pardon my silly question, why we ever need to have a random() function for LoRa? Is there any specific case for this random() in LoRa applications?
"Generate a random byte, based on the Wideband RSSI measurement." byte b = LoRa.random();Thanks a lot.
It's not that LoRa needs it, it's that it allows one to have a way of generating more-or-less truly random values since those values are generated from all the random noise the radio picks up. The Arduino random() isn't truly random.
This is to say that it's just a useful addition one can use, if they wish to, but they don't need to use it nor does the library itself need it.