Excellent and many thanks! This will be enormously useful!
--
Have you played Atari today?
> On Jan 31, 2014, at 6:59 PM, Chuck McManis <[email protected]> wrote:
>
> 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
