• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 278 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.

Connecting AM1808 with CCD sensor

aric
Prodigy 60 points
Other Parts Discussed in Thread: AM1808

Hi all,

we're working on a programmable board to interface an ARM9 with a CCD sensor in a Linux environment. We have the following requirements;

- We need to generate 9 signals with low jitter to drive the CCD phases, with frequencies of at least 15 MHz

- We need to read data from an 8 or 16bit ADC in sync with the previous signals with a data rate of at least 1.5 Msamples/sec

I would like to understand if this could be feasible with the AM1808 and which peripherals could do the job. In particular, my idea was to use the PRU because of its flexibility. My questions are:

- Can I toggle the PRU output register at the above speed (15MHz) to generate the 9 control signals and which jitter should I expect?

- Can I move the requested amount of data by reading from the PRU input register and writing to external DDR memory?

Assuming that the output control signals can be generated but the data rate towards the external memory is too high for the PRU, could I use the uPP interface with the PRU driving the uPP control signals?

Thanks a lot,

Andrea

  • 0
    TI__Expert 8890 points

    Andrea,

    The uPP peripheral is definitely capable of operating in this frequency range in either 8- or 16-bit mode, but I don't believe the PRU and uPP have been tested in combination like you propose.  It's more common to use an FPGA to interface with uPP and generate the required control signals.  I will need to check with a PRU expert to see whether this combined use case is feasible.

  • 0 in reply to Joe Coombs
    Prodigy 60 points

    Hi Joe,

    thanks for your quick reply. Do you think that the PRU alone can't handle the 1.5 Msamples/sec bandwidth, so that we need to use the uPP? If I understand well, there should be 100 PRU instructions/sample for reading a register and write it to the external memory.

    Regards,

    Andrea

  • 0 in reply to aric
    TI__Genius 17355 points

    Andrea,

    The two PRU cores inside the PRU subsystem will run at one-half of the core rate of the ARM, so they will typically be running at 150 MHz or higher, so you are right that ideally they should have at least 100 cycles per sample.  But when using the GPO pins into the PRU, there is no synchronization among the pins, so these inputs are not really suited to creating a high-speed parallel bus.  You could some kind of oversampling techniques or something of that nature, but I would encourage you to use the PRU in conjunction with other hardware peripherals that are specifically designed for parallel interfacing. 

    The control signals you describe could very well be implemented within the PRU, but that could be dependent on the state machines and input conditions that determince how those control signals transition and change over time.

    Just some things to think about.

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Prodigy 60 points

    Hi Daniel,

    thanks for the info. I'm open to use the uPP for interfacing the ADC, if this is the best option. Regarding the control signals, the transitions doesn't depend on any condition, in fact they need to be as jitter free as possible to ensure best performances: do you have any info about jitter performances? Moreover, the signals need to be synchronous: I was supposing that writing the whole 32 bit register in a single instruction was enough to have an high degree of synchronization among the signals: am I wrong? Which degree of synchronization can be obtained?

    Thanks a lot,

    Andrea

  • 0 in reply to aric
    TI__Genius 17355 points

    The PRU code will be deterministic, except with regards to memory accesses. Therefore I wouldn't expect jitter (as I understand the term) unless you are performing memory accesses. But the point I mentioned about input pins being synchronized, also applies to output pins, so there may be skew among the various output signals.  That skew has not been characterized, to the best of my knowledge.

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Prodigy 60 points

    Hi Daniel,

    the skew among the output pins is really bad news: anyway, could you confirm that, as the bits are all written at once with a single instruction, the maximum possible skew corresponds to a PRU cycle, that is a little less of 5 ns for the AM1808 at 456MHz?

    What if I use the second channel of the uPP to write the signals? I mean the following:

    - generate a clock for both uPP channels using the PRU (should be almost jitter free)

    - write a segment of 16bit data in memory representing the temporal behavior of the signals I need to generate. For example the following pattern, when read sequentially with a fixed clock,  will produce a rectangular wave of period "1" on pin 0 of the bus and a rectangular wave of period "2" on pin 1:

    addr x+0: 0000000000000011

    addr x+1: 0000000000000010

    addr x+2: 0000000000000001

    addr x+3: 0000000000000000

    addr x+4: 0000000000000011

    addr x+5: 0000000000000010

    ...
    this way I can generate up to 16 signals with arbitrary shape
    - use the uPP dma to output the data on one channel (the signals) and to read on the other one (the data)
    The questions are:
    - could this produce better results than generating the signals with the PRU (less or no skew)?
    - which memory should I use to avoid the dma to run out of data due to bus contention with other masters (15MHz frequency)?
    - maybe the raster lcd controller could be a better solution to generate the signals using memory patterns as depicted above?
    Thans a lot for your help.
    Andrea

  • 0 in reply to aric
    TI__Genius 17355 points

    aric said:
    the skew among the output pins is really bad news: anyway, could you confirm that, as the bits are all written at once with a single instruction, the maximum possible skew corresponds to a PRU cycle, that is a little less of 5 ns for the AM1808 at 456MHz?

    I would suppose that it is, but I can't confirm that. The possible skew among signal outputs is due to propagation delays between the PRU subsystem and the pin buffers, but again those various delays among all the possible output pins has not been characterized.

    aric said:
    - generate a clock for both uPP channels using the PRU (should be almost jitter free)

    This should be no problem (depending on the frequencies you want to generate).

    The remaining questions I'll leave to others who know more about the uPP peripheral.

    Regards, Daniel