Sure I'll try thank you for your time.
Cheers!
Valentine
Yeah, was considering Teensy but a that point I'm genuinely gravitating towards my own H7 based PCB with external dram, and using the internal ram as fast indexing / share memory space for the two cores. I'm not very comfortable with Teensy as I don't have much experience there.
When I solve the problem I'll come back and report with pix. I'm pretty sure I could spin up a custom PCB with 200MHz dram over the weekend if I get the time.
Cheers,
Valentine
Yes I'm aware of this it's actually six memory regions with different properties. More like 5+1, but that's beside the point.
/* Memories definition */
MEMORY
{
RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 512K
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K /* Memory is divided. Actual start is 0x8000000 and actual length is 2048K */
DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 288K
RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 64K
ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
}
The ones I'm interested are D1 and D2, and I know I cannot allocate a solid block across, I was just not sure how Arduino treats the memory across the two cores.
As I mentioned I'm a total Arduino noob, so I'm doing lots of experimentation and digging now. Thank you all for helping.
Cheers,
Valentine
It's a real-time data structure which needs fast access. I need to achieve about 700MBit (about 90 MByte/s) read throughput.
It could very well be that my problem is not solvable with H7, but 700mbit/s on a 500mhz core with direct ram access should be doable. I think... If not, I'll have to look for an "outside the box" solution.
Cheers,
Valentine
Is external RAM really going to be faster than Internal Flash? Not that I can figure out actual flash performance from the datasheet 
(and it will depend on how you access it; apparently flash reads are 256bits at a time...)
Not sure. I don't have a choice as my data frame requires contiguous allocation. I could spread over D1 and D2 in two chunks, but that's something I have to discover and unfortunately Arduino doesn't give you the ready and convenient mechanism to do this. If I have to go low level I might as well abandon the Arduino idea and stick to Cube, the effort is a wash.
I believe you are probably thinking storing on mcu flash, reading internal flash vs external dram. I'm not sure but I would venture a guess dram is always faster than flash. Reading in chunks is not a problem, in fact, it's a benefit, as I need to dump rather large chunks of memory at a time.
Cheers,
Valentine
Yes. It looks like there is 2M of contiguous internal flash on the Giga. Flash technology is inherently slower than DRAM, but you (usually) lose quite a bit of speed by having to go off-chip, and/or through a DRAM controller. (Of course you wouldn't want to use off-chip QSPI (like on an RP2040 or ESP32), but the STM flash on this chip is internal (AFAIK))
I assume that the built-in 8MB SDRAM on the GIGA is not sufficient?
Arduino GIGA R1 Cheat Sheet | Arduino Documentation
That is simply SDRAM.malloc the size of your flash array and memcpy it up there.
Would it be faster than accessing it from internal flash? No idea. My guess is in neither case will the access be as fast as if you could use Tightly Coupled Memory (DTCM).
Note: my knowledge of some of the internals of the STM32 processor used here is not as strong as it is on the IMXRT processors used in the Teensy 4.x boards, where spend the majority of my time.
In particular I do not know much about if and how the STM32 boards caching system. It looks like the board has a 16KB instruction cache as well as a 16kb data cache.
On the Teensy boards, If your memory access is not to/from TCM memory, there is a data cache that can be configured for each of the different sections, if/how the caching should be done. Depending on your usage patterns, a lot of reads may come out of cache and in other cases not...
If it were me, I would try to setup some simple test case that hopefully is as close as possible to your actual usage pattern and try out the different memory regions and see how well they work.
Thank you for the feedback.
I tried displaying 800/600/60 on the giga screen and was greatly disappointed. I believe you tried something similar, I reproduced your test cases and also wrote many of my own. The read/write speed and bandwidth were not even close to what's required.
My current calculations point that using a VGA hsync/vsync/30/565 color setup with an external VGA display may be workable provided I get sufficiently fast memory write/read with the required bandwidth (640/480/30/2 bytes in an R5G6B5 color space which is about 18mbyte/s). The giga lcd screen and the educational arduino graphics libraries (I tried all three with varying degrees of disappointment) aren't even close to a realistic scenario to be used for even low resolution low frame rate video which is a pithy. The arduino giga display setup has two strikes against: low speed graphics libraries and insufficient memory to hold even a low res low color space frame buffer.
As you mentioned the external memory on giga may be sufficient to hold a frame buffer (8 mb sram is plenty) however sram is anyncronous and I'm not sure I can achieve the timing required for a tight loop to both refresh the frame buffer and then push out the lines to the vga screen. To be determined.
I need to achieve minimum of VGA/60/565 setup, as 30 fps is not sufficient. The 30 fps is just a proof of concept. The pot of gold is 800/600/60/24 stream. That's 86 mbyte/s write/read bandwidth. And I'm not even talking about the time it takes to process the stream, this is just to display a static buffer atm, which is what I'm doing right now. If I cannot achieve this with H7 dual core and external ram, I'll have to look elsewhere, perhaps teensy, though I'd rather not, I've got almost no experience with NXP.
I'll definitely come back and report.
I'd be curious as what is your take on this.
Cheers,
Valentine
PS Perhaps double buffering in sram might be another option, tbd.
As you mentioned, I was curious about the GIGA and have tried using some of the different cameras that are sold by Arduino and Arducam for it. And it was curious that none of their examples read anything larger than QVGA (320x240) to display on the screen. And some of our attempts, did not work overly well.
As I have mentioned before, I am simply doing it for the fun of it.
So I spend most of my play time working with the Teensy boards. Currently I am playing with
some Custom Teensy boards, that were made by some other Teensy forum members.
Lots of stuff talking about some of these boards up on the forum thread:
(1) Call to arms | Teensy + SDRAM = true | Page 47 | Teensy Forum (pjrc.com)
A couple of us have created a camera library similar to what Arducam did for the GIGA. More details up on the thread:
(1) New Camera Library for Teensy Micromod/4.1 | Teensy Forum (pjrc.com)
We have also been playing with building versions of some of our display libraries to work using parallel output. So far on this with the ILI948x displays and the RA8876.
RA8876 Parallel Display Library Testing | Teensy Forum (pjrc.com)
ILI948x_t41_p - a parallel display driver for Teensy 4.1 | Teensy Forum (pjrc.com)
Sorry I know the above does not answer any of your main questions, except to show that there are some up on the Teensy forums working on similar things.
I know with the Teensy and would guess with the STM32, there are several different approaches to solve some of the different thing. Plus lots of variables to try out,
Examples:
SDRAM with Teensy - How fast can you reasonably run these at. In one or more threads, there has been a lot of testing on changing a capacitor values impact on fast you can run these chips. Some of our cameras work fine at the default speed, some don't, and for example end up with a yellow tint to the images.
Camera input - There are two primary subsystems we use on the processor for this, depending on which IO pins we have available:
CSI (CMOS Sensor Interface) - is setup directly for this.
FlexIO (Flexible IO) - which is a subsystem (3 instances of it), each with 8 shifters, 8 timers, ... which you can define for example to use shifters to output or Input for N pins at a time using one or more of the built in timers... This can be setup to use DMA...
The CSI stuff is great for normal camera input. With a few of our cameras it can be
challenging to do some things, like the OV2640/OV5640 have the ability to output
JPEG data, which CSI was not setup to be able to deduce when the image frame has been
completed..
Parallel Display output: - For this we are again mainly using FlexIO.
All of the stuff I have played with are using displays with their own controllers.
For raw VGA output, the processor does have the eLCDIF interface for doing all of
the timings and the like.
As well as a PixelPipeline(PXP) which is setup to do some different transformations of pixel data.
I believe the STM32 probably has some similar sub-systems, but I have personally spent a lot of time with it. I mainly purchased it to try out the dual processors and was curious about MBED. I probably will at some point spend some more time playing with it.
But I rather spend time playing with the Teensy boards. While it is nice at times to have some of the features of a system such as MBED, like threads and the like, I also found it to be a pain. And 600mhz processor does help!
Sorry I know not much here to help...
Good luck.
Kurt
Real time video is a hard problem. If you want to do this you may want to use stm's dcmi built in interface which allows you to do all that. This is a very mature ground, covered extensively by openmv
as well as
and
Unless you use dcmi not much could be done by generic code. But then you run into issues such as not all sensors and/or stm mcu lines support dcmi, etc.
Displaying the video however seems harder. I'll respond later in more details.
Cheers,
Valentine
was just poking around on openMV and noticed it supports Arduino GIGA:
openmv/src/omv/boards/ARDUINO_GIGA at master · openmv/openmv (github.com)
EDIT: Guess it might install the same way as it does on the Vision
Well even better here is the giga firmware for the OpenMv
Flashing firmware to Arduino Giga R1 not working - Arduino Boards - OpenMV Forums
even better looks like arduino added a tutorial on it:
Display Camera Feed on GIGA Display Shield with OpenMV | Arduino Documentation
Thank you. This is very helpful.
I've seen those, and they (openmv) have the same issue I got:
framerate of about 15~ FPS
The folks over at openmv are very experienced professionals and if they can't hit more than 15 fps on the ov7675 sensor (0.3mp), that's a little discouraging.
I need to hit 60 fps on an svga sensor (0.5mp), and will keep digging into this.
Meanwhile I'll keep the ball rolling perhaps there is a way to achieve this?
Cheers,
Valentine