CCM isn't used by default. You can add it to the linker script and
initialize the stack there but its important to realize that the internel
peripherals cannot use it, so if you have a function
write_sd_card() {
char some_buf[512];
send_data(some_buf, 512)
...
}
And the send_data function uses DMA to send the data out, the DMA will
complain about the fact that memory isn't accessible.
You can also just make a pointer to it uint8_t *ccm_memory = (uint8_t
*)(0x10000000); and play around with it.
--Chuck
On Fri, Jan 31, 2014 at 3:48 PM, Jeff Mitchell <[email protected]> wrote:
> Is CCM used by default with launchpad gcc?
>
> I had assumed stack and unknowns are in there..
>
> If we define it in linker can we go nuts in there?
>
> That would make an excellent compositing buffer .. Do a lot of work in
> there during dma then blit during vblank ..
>
> Jeffphone
> --
> Have you played Atari today?
>
> On Jan 31, 2014, at 11:59 AM, Chuck McManis <[email protected]>
> wrote:
>
> You start running into contention for the AHB bus. This is exactly where
> I'm stuck between an FPGA and a hard place :-)
>
> Basically as you start running code, the fetches from RAM can interfere
> with the DMA. There are a few things you can do, One there is a memory
> space (CCM 64K) which isn't on any of the RAM busses. I found putting my
> stack there for processes helped. But you can't DMA to/from that memory.
> Really just the CPU can talk to it. There are chunks of memory that have
> special access to the DMA which facilite higher performance on the '407
> there is some 22K or so reserved for the Ethernet peripheral which
> mitigates this same sort of problem.
>
> --Chuck
>
>
> On Fri, Jan 31, 2014 at 8:42 AM, skeezix <[email protected]> wrote:
>
>>
>> I wonder if anyone has some ideas here, or can clear up some of my
>> observations.
>>
>> Project here is a VGA display driven from STM32F4, currently on
>> the F429 disco board to make life a little easier. Its running great,
>> image is crisp and sharp, no blurr or jiggle going on (thanks to using DMA
>> and a timer to regulate the output timing.)
>>
>> Essentially the code is all interupt driven:
>>
>> - timer (TIM2) to drive hsync/vsync/line
>> - during a line, it may opt to turn up DMA to spit out pixel data
>> - DMA has another timer (TIM8) to drive pixelclock
>>
>> Running at 168MHz (or 120Mhz, doesn't matter, just changes
>> reoslution/refresh with same timing setup, luckily!), using libopencm3 rcc
>> function.
>>
>> The main loop is basicly:
>> while(1){ nop }
>>
>> Everything is fine.
>>
>> The problem is.. chanigng the main loop to _do something_ can futz
>> up the image on the display.
>>
>> - using memcpy to 'blit' a chunk of image from one buffer to
>> another totally blows up the display; if I brute force a for-loop instead,
>> its okay. Using the Launchpad gcc toolchain, not sure if thats newlib or
>> what, but whatever memcpy is doing is ugly :) (maybe it uses DMA or
>> something..)
>>
>> - if I just brute force stuff, such as a for-loop to copy a
>> picture onto display .. if I do 'too much', it'll blow up the image.
>>
>> I only do update during 'vblank' area anyway, but if I do 'too
>> much' and exceed vblank, its the problem.
>>
>> The question is .. shouldn't you be nearly to do anythign you want
>> 'brute force' in the main loop, without impacting the timers/ISR's?
>>
>> - there is one volatile, the vblank flag; main loop can have:
>>
>> if ( vblank) {
>> vblank = 0;
>> ...
>> So that shouldn't really limit anything.
>>
>> I would think having "nop" looping forever is nearly the same as a
>> for-loop doing a brute force image copy in offscreen buffers. The timers
>> driving the sync/line rendering should always take precedence.
>>
>> Anyone have any ideas?
>>
>> FWIW, here is a picture of the display, pretty nice and sharp:
>>
>> https://www.dropbox.com/s/y8b5htd0r3ed1kg/Photo%20Jan%2030%2C%2012%2006%2031%20AM.jpg
>>
>> The main loop code is this in its entirety:
>>
>> while ( 1 ) {
>>
>> if ( vblank ) { // volatile
>> vblank = 0;
>>
>> fb_lame_demo_animate ( offscreen ); // move square
>> fb_clone ( offscreen, framebuffer ); // blit offscreen to
>> onscreen
>>
>> }
>>
>> __asm__("nop");
>>
>> } // while forever
>>
>> The entire rest of application is in the VGA ISR.
>>
>> Is it just fact of life, with single core mcu, that busy work can
>> take awhile for the context to switch during to ISR, and thats killing me?
>>
>> It shouldn't take half the cpu's cycles up doing the display, so I
>> woudl think I'd have some ability to do non-VGA stuff in there without
>> blowing up the image :/
>>
>> jeff
>>
>> --
>> If everyone would put barbecue sauce on their food, there would be no war.
>>
>>
>> ------------------------------------------------------------------------------
>> WatchGuard Dimension instantly turns raw network data into actionable
>> security intelligence. It gives you real-time visual feedback on key
>> security issues and trends. Skip the complicated setup - simply import
>> a virtual appliance and go from zero to informed in seconds.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>> _______________________________________________
>> libopencm3-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
>>
>
>
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
libopencm3-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
