-
Notifications
You must be signed in to change notification settings - Fork 6
local variable reference before assignment in rfm69.py #5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Can you provide more information? Can you post the code that you are running? What error messages do you receive? The full traceback would be helpful. Looking at the code, it does look like it should be changed to return None. I'll do some testing. I'm surprised I have not seen this error so it would be helpful to see what code you are running so I can try to reproduce it. edited to add: It is clear that read_fifo "can" try to return packet without it being initialized if it is called when the FIFO is empty, but the code "should" never call read_fifo if the fifo is empty. I'd like to understand haw that is happening in your case. Are you calling read_fifo directly from your code or using the receive function? |
Although I cannot reproduce your issue, I think it does make sense to make sure "packet" is always defined.
I'll do a bit more testing and then submit a PR to implement this change. As I noted, it is not clear to me how read_fifo can be getting called when the FIFO is empty. read_fifo should only be called if there is something in the FIFO. It would be good if you can try adding the |
Here is the Traceback before making any changes to software:
Those received bytes are all correct. The dataframe is as it should be. That integer printed just before the traceback is a gc.free_mem() value. I was looking at the memory situation. All ok there. At the present, I've added the packet = None line to the rfm69.py file and restarted the code. I'll let it run a while and see what happens. Some speculation. I suspect the packet = None will fix the crash. But, I'm not yet sure that we have an assurance that the python can keep up with the burst I'm sending. I'm still accepting that my long term solution might be to replace the remote nodes with Circuitpython nodes. But, I'm still curious about this project we're on. I'll post more if something comes to mind. Meanwhile, I'm going to leave this setup running for several hours. Here's my "gateway" node code that is just listening to the messages from one remote node.
|
FYI So, far there are a few extraneous packets every so often. My software ACK works. And no code crash after adding the packet=None line to the library file. I'll post more if I learn more snippets:
|
It sounds like you are making great progress in getting your project working. I'm happy to see someone is actually able to take advantage of some of the new features of the RFM library (disabling the RadioHead header in your case). It is nice to see the ACK working. As I noted, I expect it will be OK for the received packets. It may be harder to implement for transmitted packets. You will still likely see some packet loss/corruption but hopefully a tolerable amount. Good luck with it. I will go ahead an submit a PR later today to add the |
read_fifo in rfm69.py tries to return packet when it is possibly not assigned
The text was updated successfully, but these errors were encountered: