JPEG mode #15
Comments
|
According to this code: https://github.com/iqyx/ov2640-stm32/blob/master/F4discovery/main.c |
|
Well its not completly clear from the code how often href rises and falls. Just that VSYNC goes high on the beginning of the frame and low at the end and that an active href marks valid data on the databus. |
|
This is more accurate. In the end only the dma and fb buffers needs to extended to a safety margin, and the transfer needs to be stoped at falling vsync. |
|
@igrr last one is the case. Can we get an example on how to work with an interrupt on vsync? |
|
Is there a known max length of data sent per HREF high period? Is there some guaranteed alignment, i.e. total size is dividable by 2 or by 4? Getting an interrupt is easy — check the gpio driver, it has some function to install interrupt handler. But i don't know how to tell the DMA FSM to flush all the data and end the transfer, especially if the FIFO contains an odd number of bytes. I'll try to clarify this. |
It's unfourtnatly not documented. Other implementations just streams in a big dma-buffer and flush it when vsync is going low.
Also not documented. :(( I will try to experiment a little bit arround. |
|
@igrr looking at the data and the osci, the data suggests that PCLK per HREF-HIGH stays at resolution width. So the dma-buffers could actually stay the same. The framebuffer should be set to maximum image size and trimed after capture. |
|
Hm.... doesn't seem to quite work out if i try it. |
|
Got myself an ov2640; will try to play with it on holidays. |
|
Thats great news. :) |
|
@Oitzu I had a few minutes today to check with the folks who had designed I2S peripheral, and there seems to be a way to get all the data out of I2S even when RXEOF interrupt doesn't fire. Will try using your OV2640 code. |
|
@igrr great to hear that you found some time. :) |
|
Yep, I have to find more time for this — apparently there are people who actually want to use JPEG sensors with the ESP32 for mass production, and we have to support them. Thanks for the code and the pointers. |
|
Well that is great to hear, for me. :P Any open information about the guys that want to mass produce? |
|
Well, based on your code i was able to get mjpeg streaming, a few frames per second :) And thanks for dropping a web server in there — it has really helped debugging! I need make this thing at least slightly faster and do some, will push my work-in-progress branch once I'm done for the day. edit: regarding your last question, no, there's no open info. |
|
Wow thats great, and is exactly what i wanted to accomplish, but stopped after not getting one complete frame. :) Note: If you want push in reference to my "quick and dirty"-branch mind that i rewrote history of the commit 2 days ago. I accidently dropped wlan credentials in it (that i already changed on my side). I should have implemented them in the sdkconfig at the first place. roll-eyes I'm thrilled to see how it is implemented. |
|
@igrr any news on this? :) |
|
The workaround for #20 has been found, and we can now get JPEG stream at 20MHz pixel clock. Need to think how to integrate this properly though, as clock rates <=10MHz and >10MHz require different DMA setups. |
|
Maybe a getter method implemented into the camera-specific files that calculates the expected pclk based on xclk/multipliers/dividers, resulting on different function calls on dma init? |
|
Pushed my work-in-progress branch. At the moment I have likely broken OV7725 (i.e. non-jpeg) support, will fix it a bit later. |
|
Great. 👍 Quite a lot changes. Need to play arround with it the next few days. |
|
Cloned it. Modified the pin configuration back. I updated inbefore my toolchain also. |
|
Can you please try with log level set to "verbose" in menuconfig? Also you may try using xtensa-esp32-elf-addr2line on the addresses in backtrace line to see where exactly it is crashing. |
|
|
Verbose output here: https://gist.github.com/Oitzu/e6c14089fadf4dc488a4c71b806d0c42 Strangly enough the backtrace differs? |
|
Getting an error during i2c check of camera: Cables are very short and testet. Sparkfun ESP32 THING + WaveShare OV2640 |
|
@H-LK : Second: Try a "cold boot". It happens that the ov2640 doesn't reset correctly on soft reboots.
|
|
@Oitzu works fine :) |
|
I had to reduce the clock down to 5MHz to get a not gibberish picture, but that works! :) I probably need to work on the hardware connection between camera and esp32 to get better/faster results. |
|
Yes, one thing with jpegs is that if you get a single byte wrong, the the rest of the picture will be garbage. I'm using the ESP-WROVER-KIT here, it works okay up to 20MHz. In the next chip we'll bump max i2s slave clock to 40MHz, to support those higher resolution modes. |
|
So the higher resolution modes are currently not implemented because that would be painfully slow? With "the next chip" you are speaking of the next revision of the esp32? |
|
Regarding higher resolutions (uxga?) — I just used the code from openmv, so I suppose it's just a matter of adding the right register configuration in ov2640.c. I have tested SVGA (800x600) which worked fine, but that's the highest resolution which I personally need. Regarding the next chip, I was referring to the single-core version of the esp32. The next silicon revision of dual-core esp32 doesn't have these changes. The new module based on the ESP32, which has 4MB pSRAM, also comes with ipex connector. PSRAM will come handy to store larger frame buffers as well. |
|
Will definitly try the higher resolution. In the meantime i pushed a few smaller enhancements. (No more fighting about the pin configuration) Didn't know that there is a single-core ESP32 in the queue. Is there anywhere detailed information about the differences between different versions and revisions? |
|
Was investigating the higher resolution and was baffled about the buffer allocation. |
|
I'm allocating (fb_size)/compression_ratio, where compression ratio is estimated based on jpeg quality parameter. That's not perfect, if you have any suggestion please let me know. Regarding junk — quite probably. I think the size is rounded up to the end of the line. |
At the moment, no. I was just curious from where this number is coming from. Possibly there is a method like: "header + (number_of_8x8_chunks * max_chunk_size / quality_factor) + footer (+junk)" but i'm not quite sure about the max chunk size and the quality factor. Maybe i just wait for the new ESP32 module and all my space restrictions will be gone. ;) |
|
@Oitzu i am trying https://github.com/Oitzu/esp32-cam-demo/tree/ov2640-jpeg-playground |
|
@radiumray could you give us the serial output? Maybe something in there gives a clue what is going wrong. |
|
There's also feature/ov2640 branch in this repo, which i need to merge one day. I think the only thing not finished there are non-JPEG modes (which are broken). |
|
@Oitzu i was useing OV7725, there is no serial output for jpeg-playground branch |
|
@radiumray not even "Enabling XCLK output" -> "Initializing SSCB" etc...? @igrr The jpeg-playground branch is basicly the same just added more configuration-options and fixes/adds direct jpeg display in browser. |
|
hi @Oitzu thanks a lots for your advise, (it is seem like not supported OV7725, Is not it?) Backtrace: 0x40008155:0x3ffb8760 0x40007d16:0x3ffb8780 0x40087320:0x3ffb87a0 0x40081c6c:0x3ffb87c0 0x4000beca:0x3ffb87e0 0x400dd41a:0x3ffb8800 0x400dbdf3:0x3ffb8830 0x400d0ba1:0x3ffb88c0 ================= CORE DUMP START ================= |
|
@radiumray yes the JPEG format is only available to the ov2640. |
|
@Oitzu a huge thanks |
|
hi @Oitzu i get OV2640 already, i still can't get image on my brower, my address is: the debug info below is something wrong about SCCB: D (974) tcpip_adapter: call api in lwip: ret=0x0, give sem I (1714) wifi: n:6 0, o:1 0, ap:255 255, sta:6 0, prof:1 D (2704) tcpip_adapter: call api in lwip: ret=0x0, give sem D (2714) tcpip_adapter: check: local, if=0 fn=0x40113420 D (2714) tcpip_adapter: dhcp client init ip/mask/gw to all-0 D (2844) event: SYSTEM_EVENT_STA_GOTIP, ip:192.168.199.146, mask:255.255.255.0, gw:192.168.199.1 I (2854) camera_demo: Camera demo ready |
|
Never seen this SCCB_Write errors. This gets you the fresh startup output without any software resets or whatever in between. |
|
@Oitzu hi my s_state->fb hex data Serial print is like that: |
|
The end of the jpeg is currently not junk-free but should work neither the less. |
|
@Oitzu @igrr Can you guys confirm you can't get proper JPEG image beyond 20MHz XCLK? I have bumped up the XCLK to 20MHz (confirmed with logic analyzer), and I start to have missing bytes (like JPEG header "JFIF" turns to "JFF"). btw, I can get like 8~10fps with MJPEG under 800x600 under 20MHz XCLK, I am using long wires though. |
|
Also, when I increased my core speed to 240MHz (default 160MHz), I can't see the images anymore. Frames seems still arrive, but corrupted, any idea why? |
|
@hopkinskong regarding the 20MHz XCLK: I couldn't reach 20MHz successful yet. |
|
@Oitzu Mine is messy too, I have 40CM long cables between the ESP32 and EVERY pins of my OV2640. With the logic analyzer, I can confirm that with >20MHz XCLK will in a result of >20MHz PCLK, which makes the I2S receiver missing some received bytes. |
|
Hi Everyone, Apologies for posting on a closed topic. I am trying to understand how the length of the JPG is assessed. From the above, I gather that once the data is captured from the ports onto a buffer, irrelevant bytes must be trimmed out. How does one know the length of relevant bytes ? Kindly share for the benefit of those trying to learn more about the OV2640 sensor and the ESP32 CAM Demo implementation. |
Forked from #11 to not go off-topic.
I will do this, as soon as i get the cam. (Feels like taking forever)
The text was updated successfully, but these errors were encountered: