monitor blocked in wait_read

[nexysm]

Hi all,

i wanted to use buck50 in order to record a simple digital communication of 19.2 kBaud. I call monitor with the following command: monitor rate=50k pb4-11=enabled printf="%2.5f" At the beginning it works fine, but at some point buck50.py get stuck at 3351: (readers, writers, exceptors) = select.select((usb_fd, sys.stdin), ( ), ( ), timeout ) Could it be that the buffers inside the blue pill are somehow full since there are a lot of samples since the communication lasts about 20 seconds?

[thanks4opensource]

The monitor command is intended as a live display of the digital/analog/serial inputs or for slow-speed data logging. 50kHz is pushing it. You should probably be using the logic (analyzer) command instead.

That said, neither the buck50 firmware nor the Python host application should hang. After the output stops can you recover by pressing the "ENTER" key or do you have to kill buck50.py and/or reboot the Blue Bill board? There's no explicit buffering in the monitor code (the trade-off is thatlogiccaptures at up to approx 6MHz but with a maximum number of buffered samples vs monitor being unlimited but much slower) so if there's a full lockup it could be a bug in the papoon_usb firmware library. I'm unfortunately caught up in a pure software open-source project at the moment and am not even set up to run buck50, but when I get back to hardware development I'll try to look into this. My recollection from the last time I experimented is that there's a distinct upper limit to the speeds achievable with monitor.

[nexysm]

Hi, thanks for the answer. Just to clarify. The code doesn't hang so that I need to do a restart or something like that. It simply doesn't go out of the select.select method I described above. If I hit ENTER it goes out of the loop just as it is intended in the code. The problem is, there are changes on the digital signal which last for at least 30s and after about 10s monitor simply doesn't output anything.

I tried with logic. Almost the same situation -> it says that 4824 is max number of logic samples. It somehow seems that as soon as the signal I am recording starts, 4824 samples are collected fast and after that nothing is recorded. I guess that recording 19.2 Kbit signal shouldn't be a problem.

[thanks4opensource]

Thanks for the clarification. I'll need to test further, but monitor should only miss reporting data changes if the data rate is too fast, not stop completely. You can also try playing with the rate=configuration parameter. That should fix the halting problem but will purposely miss data changes.

As per the documentation, my previous response, and your observations,logic definitely has a fixed buffer size. To clarify "samples are collected fast", they're collected each time any of the actively monitored lines changes state, not at a fixed 6+MHz rate. But yes, when the buffer is full (or the edges= or duration= parameters are hit), the sampling stops. These are tradeoffs given the STM32F103 hardware and how buck50 works within them: Either infinite sampling at a slow rate, or fast sampling with a limited number of samples.

[nexysm]

Thank you @thanks4opensource The trick was in defining the trigger. I am now able to record much more. However, I see some issues with logic. Should I start a new conversation?

[thanks4opensource]

Feel free to do so.