• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 97 subscribers
  • Views 1270 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

File Transfer with 3MBs UART with DMA ...

Marco Destro
Intellectual 590 points

Other Parts Discussed in Thread: AM3352

Hello to all

Using a AM3352 processor on a custom board. I need transfer files between two boards .

At the moment, i can use the UART1/UART4 to transfer files. Normally these files 17KB, sometimes up to to 1GB. (I can not use the SPI ports because it's already occupied.). The TRM shows that the serial can go up to 3MBs. (So ​​the transfer time would be acceptable) For now I have only used the protocols lrzsz minicom.

I find it a little strange that for large file transfers, there is a CPU usage by almost 90%.
I think it's due to the fact that the FIFO of the UART is not using DMA. In fact in the source file

KERNEL_TREE/mach-omap2/serial.c the option for the dma is set to false
 
static struct omap_uart_port_info omap_serial_default_info [] __ initdata = {
{
             dma_enabled = false,

I modified the source files, changing the option to "true", without making any changes to the device tree, and then I recompiled the kernel.

I saw this post http://e2e.ti.com/support/arm/sitara_arm/f/791/t/298523.aspx

But I have not seen the same mistakes. I have not seen kernel panics. I made a simple test program in C (read () and write () function adn termios.h), but I'm not sure that it works differently since I have not made the change.

How can I test if the change I made was implemented correctly?

a connection via USB could be better?
 
Any help is highly appreciated
 
Marco

 

  • 0
    TI__Expert 5960 points

    Hello Marco,

    The support for DMA has been missing for some time now in this driver. It supported DMA at one time, then support and testing ceased even though there still remain some DMA support structures.  This commit seems to me to be the best explanation of why: 

    https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/tty/serial/omap-serial.c?id=0ba5f66836c9253c67c469fb4016f94ea

    Since the Fifo is set to 1 byte, it wouldn't make sense to use the DMA anymore. For small transfers, there is more overhead when using the DMA.  I'm not sure when DMA support stopped for this driver, possibly is was even before this commit.

  • 0 in reply to Jeff L
    TI__Expert 5960 points

    Marco,

    I also happen to be looking some different baud rates for Uart.  I created application layer test which is using the lowest level read and write to /dev/ttyO0 between two AM335x EVMs.  With a standard 3 foot RS232 null-modem cable, I can transfer data at 1152000 with no errors.  When I run that test and transfer 2MB of data, I see around 3% CPU utilization for the duration of the test.

  • 0 in reply to Jeff L
    Intellectual 590 points

    Hello Jeff

    Thank you very much for your valuable support :)

    I admit I did not understand very well the reason of DMA support missing. 
    But I guess it plausible, as there are other devices dedicated to the efficient transfer of large amounts of data.

    for the second post, could you please show me the software you've written? it's 'likely to be written in a more efficient way than that my.


    Thanks again


    Marco

  • 0 in reply to Marco Destro
    TI__Expert 5960 points

    Hi Marco,

    I will attach the code here, but please keep in mind this is only low level test code.  It does not do any error handling of any type, so it will not be reliable.  The lrzsz code you were using has error handling, but I'm just not sure what is so taxing on the CPU.  With this code, I was just trying to show that is not the omap-serial driver that is eating up the available CPU cycles.

    There are 3 fixed arguments:

    1. device node
    2. r or w (read or write)
    3. baud rate

    EX:

    ./serial_test /dev/ttyO0 r 115200 

    7875.serial_test.c

  • 0 in reply to Jeff L
    Intellectual 590 points

    Hello Jeff

    You do not know how grateful I am

    I will keep in mind what you said. My goal is just to understand how it is possible that a high consumption of CPU. If necessary, make the appropriate changes.

    Again, thanks a lot Jeff :) +100 pts

    Best regards

    Marco

  • 0 in reply to Marco Destro
    TI__Expert 5960 points

    Hi Marco,

    Thanks for the positive feedback.  To analyze what is using up the CPU, you may want to try Oprofile. It can be useful to help determine which process and functions are using most CPU clocks.

    See this link for a good starting spot for Oprofile:

    http://processors.wiki.ti.com/index.php/Oprofile_User's_Guide