Using UART0 and UART1 with DSPBIOS for DM6437

rafael,

rafael becerra said:

,.. and the characters I see in the serial port console ( in my pc) are incomplete.

Can you describe more about what you see on the console output? That may answer a lot of questions.

rafael becerra said:

I even tried including the whole sample code in my proyect and running it exactly as the example, still,  the same problem. In the example I see the "interrupt" mode is configured.. however I don't see within the example's DSPBIOS configuration any hardware interrupt or event within ECM, configured to be used with the UART0.. so, how is it that works ?

There are a variety of ways to configure interrupts. The ECM is not required, so perhaps the interrupt is configured directly as an HWI rather than using a combiner in the example?

I will recommend doings your merging of projects the other way around. Start with the example project that works for your UARTs, and add you application project to that. This will mean entering the DSP/BIOS configurations as needed. You may be able to do a lot of that using text editing of the .tcf file, but be careful that you are not overwriting parts that were already defined and used for the example project.

The UART User's Guide is the best place to look for information on how to use the EDMA3 with the UART peripheral. It describes the interaction in terms of when DMA events are generated.

You may want to search the forum (red Search box) for others who have tried to use EDMA3 with UARTs. And you might also find some help on the TI Wiki Pages. I have not searched either ahead of you, but I hope you will find something helpful. I have discussed this with others in the past and I do not recall a perfectly clean way to use the EDMA3 for servicing a UART.

You can "easily" setup a DMA channel for servicing the transmit side, since you know how much data you want to send and there are no decisions to be made at that point. But for the receive side, it would seem best to have a DMA channel setup to handle the FIFO-filled condition and then have the DSP get interrupted either after the FIFO has been read or just periodically to test if any data is in the receive buffer to be examined. If you have a fixed receive data count, then the DMA can be more suited for receive. But even just getting the data in every once in a while will be helpful to the DSP's load.

Regards,
RandyP

Please reply back with more details about your application, or if you have solved the problem, reply back with your success story, too.

Hello, thank you very much for the tips and advices.

I got UART to work in interrupt mode, I was forgetting for a moment that UART driver has to run within a TASK ( as it has a semaphore included in the driver). I assume that it's true since it worked when I did that change. Also, I had to use the  uart_bios_drv.lib  driver from the dvsk DEBUG folder, because the RELEASE folder didn't seem to work properly eventhough I rebuilt the library project.

I implemented the UART in the following way:

-  I have a task that writes a buffer to UART using GIO_write
- I have another task that reads a buffer from UART using GIO_read
- both tasks have the same priority

Defining a tx buffer of 256 bytes, When writing a long message to UART ( say all 256 bytes) write task status becomes blocked as it completes the message in several executions.. (small parts of the message are sent and task is executed several times, I know this because I see terminal window filling up with my message characters in several task executions, while doing this the task status remains in blocked),    it is finally unblocked when the 256 bytes are sent , using GPIO_write to an UART object.

Here's the code for my TX task:

void ALV_UartTx(void)
{
  // execute forever
  for ( ; ;)
 {
     if (TxStr[0] != NULL)        // verify if there is something to send
       {
         // Input buffer
            txbuf.addr = TxStr;
         // Time out value
          txbuf.timeout = SYS_FOREVER;
         // Length of data
         txlen = SIZEOF_UART_STRING_TX;
          txstatus = GIO_write(hUart_OUT, &txbuf, &txlen);

          // Error status detection
         if(!((txstatus == IOM_COMPLETED)||(txstatus == IOM_PENDING)))
                      {
                       printf("UART ERROR: 0: Error from GIO_write for UART TxStr\n");
                        }
            // there was no error, data was sent so mark tx buffer as clean
             else
             {
                 TxStr[0] = NULL;
              }
    }
   // if there is nothing to send, just pass control to another task
   else
   {
    TSK_yield();
    }
}

Is this the normal behavior?  I know the UART driver uses a built-in semaphore which is involved into this.  But as soon as the code flow reaches the "GPIO_write" is the task supposed to be blocked until GPIO_write is done writing all bytes to UART ?

shouldn't the task just pass the buffer to a lower level layer (which would be the one responsible to put all bytes to UART) and continue executing instead of blocking itself until all bytes are sent ?

am I implementing UART driver the right way ?

Rafael,

The hardware and BIOS issues were things I could help you with, but clarifications on the drivers will need to come from the BIOS forum. If you would, please re-post this latest post on the BIOS forum under the Embedded Software group. You might additinonally include a link back to here, if you think It could be helpful.

Regards,
RandyP