idf.build error about lepton HOT 11 CLOSED

Hello. Sorry you're having problems. Unfortunately I still build with make so don't have any experience with idf.build. It looks like the build system couldn't find the files which is strange. Are you sure the Espressif SDK has been properly installed and your environment variables are also correctly configured? I am building with v4.0.1 of the SDK and haven't tested with other versions. You can load the existing binary files until you resolve this compilation issue.

from lepton.

I've made changes on my fork to build using Cmake and the latest stable idf (4.4)
If there is interest i could do a PR

from lepton.

Yeah, that sounds interesting. Would be good to get off of 4.0.2. Things I'm worried about are having to retest everything and performance. Can you give me a quick idea of what had to change? (I saw your other issue regarding cJSON. Not sure what happened there but it looks like cJSON should be part of every IDF release).

from lepton.

From my memory:
I changed all the CmakeList.txt files to include all the dependent files. Seems to be needed to cmake correctly

Changed one line to switch the heap_caps_malloc region to MALLOC_CAP_SPIRAM for the json image text buffer. The IDF spi code checks if the buffer passed is in DMA region, if not the code allocates a buffer in DMA region and memcopies the result to the passed buffer. I only compiled and tested briefly with the IOS app.

sys_image_rsp_buffer.bufferP = heap_caps_malloc(JSON_MAX_IMAGE_TEXT_LEN, MALLOC_CAP_SPIRAM);

Made a small change in the i2c code. Something about the clock source. One parameter added.

I was originally only trying to build it so for a PR would just start from scratch and apply enough changes with nothing extraneous.

Yes you are right about cJson. As I am bulding with cmake the components being used in the IDF have to be explicitly listed. I'll make that change and that should be it.

from lepton.

Thanks for the info. Why did you have to change the malloc for the sys_image_rsp_buffer? Did the system run out of memory (malloc fail)?

As you figured out, that buffer needs to be in DMA accessible memory because that buffer is passed to the SPI Slave peripheral when the camera is used in the new Hardware Serial mode that the FW 2.X supports (allows connecting the camera directly to another micro instead of using Wifi and used by the tCam project). It seems to me that the same out-of-memory issue might occur if the SPI driver has to allocate the same size buffer. The copy may also impact performance since it will occur in series with data being available and notification to the external micro that an image is available.

I say make the PR when you can and I'll test it here. I just can't promise it'll be done immediately. But I do appreciate you making the effort and digging into, and understanding, someone else's code!

from lepton.

Yes, the malloc failed. Doesn't appear to be enough space in dma accessible memory. I didn't realize that the buffer in question is used for sending using esp slave SPI device mode. As you said that buffer must be in DMA memory. The available largest free block of DMA memory to malloc appears to be about 33792 bytes (from what i remember as I was testing). I believe that the code is trying to malloc 1024*53 or 54272 bytes. So short a bit.

I'll just get it to build with the idf.py (cmake) build system but it won't work with a slave peripheral and dma mode,

As you said interesting looking at someone else's code and trying to understand it and what hardware is involved. Thanks for the responses.

from lepton.

Just did a brief test with the attempt to allocate the DMA accessible memory for the spi buffer. Added a log for the free memory

I (1753) sys: Buffer Allocation
E (1753) sys: malloc shared json image text response buffer failed
E (1753) sys: DMA largest free block: 33792
E (1763) main: tCam Mini memory allocate failed

from lepton.

from lepton.

OK got the memory needed. Moved one of the json buffers to spiram/psram. Seems that the memory allocator puts MALLOC_CAP_8BIT into internal ram instead of using the external ram first. Even though it is 8bit addressable.
What sort of frame rate are you seeing with the desktop app over wifi? No idea if this change has affected anything.

I'll now remove all my debug prints and try to get a PR together.

from lepton.

Well this is a bit embarrassing. I took a peek at json_image_text (that I am guessing you moved up to PSRAM) and realized it was no longer being used (a hold-over from the 1.x code I didn't clean up). So I think there isn't an internal memory space issue after all. Sorry about that...(and thanks).

The 2.X FW should be able to get the full ~8.7 FPS the lepton is capable of. Wifi variability can affect this a bit but you should be able to see the desktop app reporting around that FPS while streaming at the fastest rate.

from lepton.

All good. Thanks again. I'm seeing around 6fps but as you said wifi variability can affect this. I'll build a stock image without my various changes and compare. And looking at code like yours is how i learn stuff. or attempt to.

from lepton.