1 external RAM shared between 2 separate FSMCs

[dmakhrov9]

Posted on October 16, 2012 at 17:14

Hi all,

I'd like to make 2 STM32F407 share 1 external RAM as a common memory. Chip #1 would store some data in RAM for chip #2, then stop all accesses and signal to #2 that there is some data for him. Chip #2 would do its job, store result in the same external RAM, abandon it and signal to #1 that it is done.

I see it is not easy to just ''Hi-Z'' FSMC pins, since they would retain their modes as inputs or (even worse) outputs even if FSMC is deinitialized.

Is there any possibility for external RAM sharing then?

regards

Dmitri

P.S. I'd like to avoid too big hardware overhead

[Tesla DeLorean]

Posted on October 16, 2012 at 17:53

http://www.idt.com/products/memory-logic/multi-port-memories/asynchronous-dual-port-rams

http://www.cypress.com/?id=82

You could do it with regular SRAM parts if you added buffers (74244 74245 equivalents). You either manage the pins in hardware, or software.

[emalund]

Posted on October 16, 2012 at 18:19

The best laid schemes of mice and men .....

I have seen more shared regular (not dual-port) RAM cases with problems that without.

You will open a true can of worms if yo try this with a regular RAM

Use a dual port RAM with sentinel (Cypress have some) and you will be home free

Erik

[Tesla DeLorean]

Posted on October 16, 2012 at 18:59

I have seen more shared regular (not dual-port) RAM cases with problems that without.

 

Yeah, more horse power, and memory bandwidth would be the less tortuous path.

[frankmeyer9]

Posted on October 17, 2012 at 08:11

The LPC43xx devices from NXP have a asymmetric dual core, which could possibly do the job for you. Not sure how they share RAM.

I would keep in mind - real multiprocessing could be a hassle. That starts already with debugging ...

[dmakhrov9]

Posted on October 17, 2012 at 14:04

Thank you all,

indeed, my intention is to double the computing power. Multiparameter function minimization takes too long even with FPU.

Still, the biggest problem is with read out protection level .

[frankmeyer9]

Posted on October 17, 2012 at 14:58

indeed, my intention is to double the computing power.

 

Maybe a Cortex A or similiar would serve you better.

The ''M'' profile is more optimized toward control application - with a good mix of peripherals, and Flash/RAM to fit for most applications. Performance is not the major

concern.

Multiparameter function minimization takes too long even with FPU.

 

That sounds more like ''abstract'' calculations, wich require a fast CPU/RAM with no special hardware (peripherals).

[dmakhrov9]

Posted on October 17, 2012 at 15:50

Indeed, Cortex A (beagleboard is your friend) could do this much faster.

I chose Cortex-M4F because

1. the firmware is locked in the internal flash

2. working examples for hi-speed USB host without Linux overhead (I added USB3320 as ULPI)

3. LQFP packages vs. fine pitch BGA for prototyping

6 STM32F405 in LQFP64 at 168 MHz could do the job as good as 1 Beaglebone at 1GHz.

[frankmeyer9]

Posted on October 17, 2012 at 16:04

Indeed, Cortex A (beagleboard is your friend) could do this much faster.

 

Well, there are other Cortex A types in between - the OMAP devices are way up.

Only RAM size could be an issue on the STM32F4, or other M4 devices.

Once you need more than the 96k, you have to go external with 16-bit lanes.

[dmakhrov9]

Posted on October 19, 2012 at 08:52

The more I think about this, the more multiprocessor solution seem a mess to me.

[frankmeyer9]

Posted on October 19, 2012 at 13:17

Surely you can write bare-metal code even for a Cortex A15, but somewhere it begins to hurt in complexity, time and costs ...

A multiprocessor solution will probably hurt in this regard, too. It is often underestimated by developers and project leaders who have no actual experience with this.

You can evaluate some higher-performance CPU. So far, I only found the NXP3200 as an approximate match. Or, you could reduce your project in complexity and performance requirements.