Skip to content
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

get_state drops text on the STM32 #2357

Open
kwagyeman opened this issue Aug 5, 2024 · 6 comments · May be fixed by #2493
Open

get_state drops text on the STM32 #2357

kwagyeman opened this issue Aug 5, 2024 · 6 comments · May be fixed by #2493
Labels
investigate Needs further investigation to reproduce the issue.

Comments

@kwagyeman
Copy link
Member

kwagyeman commented Aug 5, 2024

I noticed that a lot of lines of text are missing on the STM32 with get_state.

Pretty easy to replicate with master:

import sensor, image, time

sensor.reset()
sensor.set_pixformat(sensor.RGB565)
sensor.set_framesize(sensor.QVGA)
sensor.skip_frames(time = 2000)

clock = time.clock()

while(True):
    clock.tick()
    img = sensor.snapshot()
    print("hello world")
    print(clock.fps())

Gives:

hello world
23.3051
hello world
23.301
hello world
23.2975
hello world
23.2945
hello world
23.3236

Traceback (most recent call last):
  File "<stdin>", line 16, in <module>
OpenMV v4.5.8-43.g0ad4d34a.dirty; MicroPython v1.22-omv.r17.434.g8f6a976de; OPENMV4P-STM32H743
Type "help()" for more information.
>>> 

With the old polling. With get_state() I get:

23.3029
hello world
23.301
hello world
23.2992
hello world
23.3161
Tracebll last):
  File "<stdin>",e>
MPYMV v4.5.8-43.g0ad4d34a.dirty-omv.r17.434.g8f6a976de; OPEpe "help()" for more informal

The same on a tiny USB board produces:

46.7706
hello world
46.70913
hello world
46.74797
hello world
46.69261
hello world
46.72897

Traceback (most recent call last):
  File "<stdin>", line 14, in <module>
OpenMV v4.5.8-43.g0ad4d34a.dirty; MicroPython v1.22-omv.r17.434.g8f6a976de; OpenMV IMXRT1060-MIMXRT1062DVJ6A
Type "help()" for more information.

Need to look into how to fix. The change related to breaking on interrupts being disabled shouldn't affect this as interrupts are on.

@kwagyeman kwagyeman added the investigate Needs further investigation to reproduce the issue. label Aug 5, 2024
@iabdalkader
Copy link
Member

It's not a bug, it drops text on all cams. The TX buffer eventually overflows now that text is not polled separately. I can send more text in the same packet, up to 512 if the IDE can handle variable length string.

@kwagyeman
Copy link
Member Author

The text isn't destroyed with GetState using TinyUSB or not using GetState with the STM32. Seems like it's just related to the STM32 using GetState. Even with a polling rate of 1KHz very small strings are eaten. Something is off.

@iabdalkader
Copy link
Member

iabdalkader commented Aug 5, 2024

The STM32 clears CDC buffers on soft-reboot, for some reason which I forgot. Also the TX buffer on some boards is bigger than the ST TX buffer.

@iabdalkader
Copy link
Member

I fixed this, however text can still be chopped off if you print a lot of text and if the poll rate is slow. As I've mentioned above I can extend GET_STATE to use the remained of the max packet size for text (close to 512 bytes per packet) if the IDE can handle variable sized, null-terminated strings.

@kwagyeman
Copy link
Member Author

No, the IDE will be confused by that. The return size must be what was requested in the USB command. However, I can make the packet size I ask for larger if I know the board's capabilities. Maybe add a flag to the flags mask that says I can request 512 bytes versus 64 for the get_state packet?

The first one I ask for will be 64 bytes, but, then, I can ask for 512 bytes afterwards on caching that capability.

@iabdalkader
Copy link
Member

You should be able to figure out the endpoint size easily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
investigate Needs further investigation to reproduce the issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants