Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: DMA Operation???

Re: DMA Operation???

From: George Styles <george_at_ripnet.co.uk>
Date: Tue, 22 Oct 2002 15:15:53 +0100

OK,

as an experiment, I wrote code (hooked into the demo menu for
convienence...) which set a flag to indicate that another stream was being
injected (to prevent the DMATick from re-enabling the DMA):

...
bool injecting;

static void dma_tick(void)
{
    if(playing && (!paused) && (!injecting))
    {
...

 and stopped the DMA like so in my test code:

...

void wait_for_demand()
{
 while ( (PBDR & 0x4000)==0)
 {
  yield();
 }
}

void write_mpeg_data(char c)
{
 char *pc;
 pc = 0x5FFFEC3; // serial data
 *pc = c;
}

bool test_inject(void)
{
    int i;
    char *ptr;
    ptr = mp3buf;

    injecting = true;
    stop_dma();
    mpeg_injectframes(0, 1000);
    for (i=0; i<128000; i++)
    {
        wait_for_demand();
 write_mpeg_data(*ptr);
 ptr++;
    }

     injecting = false;
    start_dma();
    return false;
}

...

What I expected to happen would be that the DMA would be stopped, then I
manually (ie, non-dma) pumped 128000 bytes to the serial port from the start
of the big buffer (waiting for demand to be high), and then I re-enabled the
DMA.
I expect to hear a couple of cracks/pops as the frame was rudely stopped,
and silence until the start of another frame in the 128000 bytes, then some
music from the start of the buffer (earlier in the song). Instead, I heard
nothing.

Is it OK to write data straight to the serial port? or does the DMA logic
see different addresses to the processor?

can neone spot what went wrong?

cheers
g


----- Original Message -----
From: "George Styles (RipnetUK)" <george_at_ripnet.co.uk>
To: "George Styles" <george_at_ripnet.co.uk>
Sent: Tuesday, October 22, 2002 12:19 PM
Subject: Fw: DMA Operation???


>
> ----- Original Message -----
> From: "Linus Nielsen Feltzing" <linus_at_haxx.se>
> To: <rockbox_at_cool.haxx.se>
> Sent: Saturday, October 19, 2002 8:12 AM
> Subject: Re: DMA Operation???
>
>
> > On Fri, 18 Oct 2002 14:44:19 +0100, George Styles wrote:
> > > Can i ask one more thing please? is the DMA clever enough to not
> > > send data through faster than the MAS can use it? i assume the MAS
> > > can say 'enough for now' and the DMA pauses until the MAS says it
> > > is ready for more data (or does so via the UART by setting RTR to
> > > no!)?
> >
> > There is a signal from the MAS called the DEMAND signal. It goes high
> > when the MAS wants data. We poll that signal at 1ms intervals. When
> > we see a high signal, we enable the Tx Empty interrupt on the serial
> > port, which in turn triggers one DMA transfer. The byte is sent via
> > the serial port (at approx 1mbit/s), and an interrupt is triggered
> > when the byte is sent, and the DMA transfers the next byte, and so
> > on. We get an interrupt when the DEMAND pin goes low again, where we
> > disable the Tx interrupt.
> >
> > > How about this? when we want a beep, we
> > >
> > > 1. stop the current DMA (assumes that DMA is active all the time
> > > either transfering data to serial0 or waiting for serial0 to become
> > > ready),
> > >
> > > 2. Read the address it got up to
> >
> > We can read that on the fly. We can do like this:
> >
> > 1. Read the current DMA address.
> > 2. Search for the next frame boundary from there
> > 3. Adjust the DMA buffer length accordingly
> > 4. We get a DMA interrupt when it has transferred the remainder of
> > the frame
> > 5. We reprogram the DMA to play the beep
> > 6. We continue with the normal stream
> >
> > To make this really good, we may want to skip as many frames as the
> > beep took, to keep the play time constant.
> >
> > The operation above gets complicated for several reasons:
> >
> > 1) The next frame boundary may not be in the current DMA buffer
> > 2) The buffer may wrap
> > 3) The music may be paused
> > 4) The DMA address is used to detect the track boundaries
> >
> > /Linus
> >
> > --
> > Linus Nielsen Feltzing, linus_at_haxx.se on 2002-10-19
> >
> >
> >
>
>
Received on 2002-10-22

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy