Open chrisrothwell1 opened 1 month ago
Hi Chris,
Thanks heaps for spending some time in the weeds of this library!
The notes and improvements will definitely help drive some great improvements.
In the meantime, if you have a moment and want to open a pull request or put these changes on your own fork of the Repo I can make a link to credit your improvements in the README on the repo.
This is not a request, but I'm providing an update with improvements. I have attached a new camera.py file in a ZIP file. I've been working on a project using a Pico W and the Arducam 5MP using Micropython and needed a way to take pictures and upload them. This project does work, but it's very slow. The saveJPG() function could be optimized a bit, I did make some changes and included a new function (old version commented out). There are several issues that make this slow. First, its not using burst mode. Second, the SPI reads are one byte at a time, but it needs to read two bytes and throw one away, then there is the overhead of calling into the SPI driver to initiate the next read. Third, the file write is being done one byte at a time. Someone had worked on getting burst mode working, but the two functions are incomplete. I commented them out and provided my own function, save_JPG_burst(), which does read and write the JPG file. Using the burst mode avoids the need to read two bytes for each byte and throw one away. Instead you can read a chunk of data up to 255 bytes in one SPI call. I also used the SPI readinto functionality, that lets the SPI driver handle the process of filling the buffer, I suspect this is quite a bit more efficient. Finally, the data is written to the file system in 255 byte chunks, much more efficient. With the camera set to 640x480 resolution using the old saveJPG() function, it took about 3.5 seconds to read the file from the camera and save it to the file system. With save_JPG_burst(), it took about 165 ms, that's a 20x increase in speed! I'll warn that there is a corner case for finding the the end of the JPG file (0xff, 0xd9) where the 0xff could be the last byte of the previous chunk and the 0xd9 is in the first byte of the next chunk. I have implemented a check for this, but haven't tested it and I haven't seen the case naturally occur yet.
camera.zip