• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 103 subscribers
  • Views 456 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Slowing down uPP transfer rate

BAS
Expert 2370 points
Other Parts Discussed in Thread: OMAP-L138, ADS901

Hi,

I am using OMAP-L138 EVM which uses uPP to transfer data from ADS901. uPP transfer rate is so fast i.e. it takes only 17 CPU cycle to transfer X amount of data which doesn't let me process the data in real-time because processing takes longer than transfering it from uPP. I tried transfering different amount of data but it takes same amount of time i.e. 17 CPU cycle. I am wondering how can I slow down the uPP transfer rate according to my requirement ?

Thank for your help.

  • 0
    Expert 2370 points

    Any help on this ?

  • 0 in reply to BAS
    Prodigy 90 points

    Hey BAS,

      Not sure I follow your question, but if you want to "slow down" UPP transfers,  you can modify the UPPICR register (refer to Section 33.3.5 in SPRUH77A.pdf), specifcially bit 8 in this register.

      Hope this helps. Are you using Linux for your O/S on the OMAP?

  • 0 in reply to Allan_Jones
    Expert 2370 points

    Allan,

    uPP I/O speeds up to 75 MHz with 8-16 bit data width per channel. I don't know the current speed of uPP in my system. As i mentioned earlier, it takes only 17 CPU cycle to transfer 1024 data point. I want to know how can I decrease the speed so that it takes more than 17 CPU cycle.

    The specific bit you mentioned in UPICR register can be used to divide down the clock if channel A is used in TRANSMIT mode where as I am using channel A in RECEIVE mode.

    I am using windows 7 for OMAP-L138.

    Any help ?

    Thanks.

  • 0 in reply to BAS
    Expert 1550 points

    BAS ,

    a) Just reminding in case you missed . When the channel is configured in receive mode the CLOCK in not under control of UPP device .

         It is decided by PERIPHERAL DEVICE CLOCK. So in RECEIVE mode you have to slow the peripheral device which will in turn the UPP channel working 

         in receive mode .

    b) Can you please let us know if you are using the default sample code available form TI or any thing else. 

        THIS IS BECAUSE I HAVE COMPLETED BUILDING THE DRIVER IN LINUX FOR THE SAME PERIPHERAL ,

        BUT NOW I AM SUPPOSED TO WORK FROM DSP SIDE .....on which i have never worked.

        So if you can please tell me from where you are using the sample  and how to compile it !!!!!!!!

    Thanks

    Ashish Mishra

    [BANGLORE/INDIA]

  • 0 in reply to Ashish Kumar Mishra
    Expert 2370 points

    Ashish Mishra,

    a. Do you know how can I change Peripheral Device Clock to control the UPP clock ?

    b. I am using BSL based UPP example code which can be found on Logic PD webpage.

    Thanks.

  • 0 in reply to BAS
    Expert 1550 points

    Hi BAS, 

     As per my experience you cant control the clock of peripheral connected to UPP

     In case we are missing any point i would like to share my expr. 

    1. I am having UPP connected to FPGA [XILINX]

    2. Channel A is configured in TRANSMIT mode and Channel B in receive mode 

    3. The clock frequency [Output clock]  of channel A is what i am controlling .

        In case of channel A transmitting , UPP acts like MASTER and FPGA acts like SLAVE.Slave will synchronize with master[UPP] clock. 

    4. For channel B in RECEIVE mode , the clock of channel B is not under my control.It is Controlled by FPGA.

        Hence in RECEPTION mode FPGA acts like MASTER and UPP acts like SLAVE

    5. Also in either case SLAVE will get 1/4th [Single Data Rate] or 1/8th [Double Data Rate] of MASTER clock

       

        Hence it the MASTER who have to control his clocking frequency. 

    Hope it helps .Also if you think my understanding is wrong or i am missing , FEEL FREE TO CORRECT ME .................. 

        

    Ashish Mishra

    [BAnglore/India]