Thanks! I can work with optimizing this. We haven’t merged anything in that would have slowed this down on purpose.
Anyway, it will be a while for all these bugs are fixed. I have a lot on my plate and paying customers get priority. However, I will add a bug tracker.
Thanks. Can you give me a very rough eta? I need to plan next steps, thanks.
Maybe at the end of the month or next month. I must focus on 4-5 high-priority things before I can work on general bug fixes like the performance enhancement you want.
I care about customers who want support, so, given your efforts to fix this, I will get it done. But, gotta focus on ensuring I get potential accounts over the line.
This is actually very relevant. Just to be clear, the firmware still crashes even with DMA disabled, correct ? This would make more sense to me because I don’t think it’s a DMA/SPI issue.
Also this fw tag just doesn’t look right, not sure what’s going on but Micropython should have 1.23.0 in it not 1.22
With frame_buffers set higher than 3, I.e. 5,6,10 yes.
I just loaded the No DMA firmware I was sent here. To be clear before no dma build I always had crashes. (4.5.8) after acquiring frames to sdram.
I’m on vacation right now and will be back in a couple of days, I can test this some more. In the meantime if you could try to reproduce this 6 framebuffer crash with no SPI that would be very helpful.
Yeah I know but still that firmware doesn’t look right. I think it’s built using the old micropython branch.
Disabling the DMA could just be masking the issue.
I can reproduce it.
Not sure if useful for you cause it crashes without error most of the time or if there is an error it doesn’t make sense. (I.e. can’t get statistics on int)
Maybe most reasonable that I test with the correct micropython version merged whenever you can make available.
We have priority to start shipping product by end of next month and need to freeze all by this month.
P.s. I think we are a paying customer if boxes of global shutter sensors makes us qualify as one . A good reason we want to stay current is to be able to access the new global shutters you announced for our product upgrade.
Not asking for a performance enhancement.
Asking to reverse breaking change. Performance was fine before. (Since 3 years)
Yes it’s very useful. Please use the latest dev firmware if you could, or latest stable release. Don’t use any firmware attached in this thread as they don’t look good.
I was going to try to help you regardless of whether you’re a paying customer or not, but I can’t do that right now as I don’t have my laptop, cameras and debugger with me.
I will refrain from writing till you confirm you are back from vacation. Enjoy and let me know when you are back so we can wrap this up.
No please feel free to post any updates, and if you could please post a script to reproduce the framebuffer issue using the latest dev firmware as discussed. This might be the best lead we have so far.
Latest Dev Release (as of today)
OpenMV ae43945; MicroPython 8f6a976d; OPENMV4P-STM32H743
Running the last script I shared.
Expected around 372 fps
Result:
200.0
200.0
200.0
200.0
200.0
200.0
200.0
200.0
200.0
200.0
200.0
196.721
196.97
197.183
197.368
197.531
197.674
197.802
197.917
198.02
198.113
198.198
198.276
198.347
198.413
198.473
198.529
198.582
198.63
198.675
198.718
198.758
198.795
198.83
198.864
198.895
198.925
198.953
197.97
198.02
198.068
198.113
198.157
198.198
198.238
197.425
197.479
197.531
197.581
197.628
197.674
197.719
197.026
197.08
197.133
197.183
197.232
197.279
197.324
…
down to 194 ish where it stabilizes
Performance aside just for now, if you change the number of buffers to 6 does it crash ?
Very interesting. Setting to 6 doesn’t crash. I added a few lines of my post processing code and crashes both with 3 and 6 when getting the statistics. Not immediately but after about 516 frames in the for loop- at least until there it prints “Playing Frame”
# This work is licensed under the MIT license.
# Copyright (c) 2013-2023 OpenMV LLC. All rights reserved.
# https://github.com/openmv/openmv/blob/master/LICENSE
#
# Image Memory Stream I/O Example
#
# This example shows how to use the ImageIO stream to record frames in memory and play them back.
# Note: While this should work on any board, the board should have an SDRAM to be of any use.
import sensor
import image
import time
# Number of frames to pre-allocate and record
N_FRAMES = 950
sensor.reset()
sensor.set_pixformat(sensor.GRAYSCALE)
sensor.set_framesize(sensor.HQQQVGA) #resolution
sensor.set_windowing([3,13,57,24])
sensor.set_auto_exposure(False, exposure_us = 2700)
sensor.set_framebuffers(3)
sensor.skip_frames(100)
clock = time.clock()
# Write to memory stream
stream = image.ImageIO((57, 24, sensor.GRAYSCALE), N_FRAMES)
for i in range(0, N_FRAMES):
clock.tick()
stream.write(sensor.snapshot())
print(clock.fps())
while True:
# Rewind stream and play back
stream.seek(0)
for i in range(0, N_FRAMES):
print("Playing Frame" , i)
img = stream.read(copy_to_fb=False, pause=False)
median1 = img.get_statistics(roi=[36,0,21,4]).median()
median2 = img.get_statistics(roi=[2,0,4,5]).median()
stdev1 = img.get_statistics(roi=[35,0,9,18]).stdev()
stdev2 = img.get_statistics(roi=[30,0,27,14]).stdev()
# Do machine vision algorithms on the image here.
This narrows it down considerably. I’ll debug it as soon as I get back. Thanks!
@Joe100A I ran the script for about 10 minutes and it just keeps replaying the stream but doesn’t crash. Can you try to record a stream, save to file, and see if that causes a crash, if so please attach it here.
It is crashing for me the first sweep through the initial images in between 500 and 700th frame like clockwork. Are you using the same build I reproted above? Do you have a global shutter sensor attached? Can the IDE version have some influence?
I am using the latest development release and the global shutter sensor. I don’t think the IDE has anything to do with it, but it’s 4.2.3 anyway. I think the stream data itself might cause it to crash faster or more predictably.