That is really interesting Gerhard!!
Let me ask you, why did you decide to use a CPLD instead any other device?
Actually this signal configuration is very common in ADC+Serdes devices
(ADCs with DDR bit clock), in example you can take a look at these
application notes:
http://www.ti.com/lit/an
Thank you TJF, that was exactly my idea from the beggining with that exact
architecture.
If you think is feasible, then I will go for it.
Best regards
On Friday, May 29, 2020 at 2:39:27 PM UTC+2, TJF wrote:
>
> Am Freitag, 29. Mai 2020 11:35:56 UTC+2 schrieb PAk Ys:
>>
>> My i
Thank you Andrew. I am a radar engineer for more than 15 years myself.
We have designs more interesting than the AWR series of TI, which is quite
interesting for some applications but no so much on others. The costs are a
little bit higher than those $30, specially if you have to develop your PCB
ou could
> potentially even generate UDP packets in the PL, if all you want to do is
> move the data someplace else. The infamous FPGA learning curve is quite
> real, but not insurmountable. There are lots of tutorials available, both
> from the vendors and from other sources.
>
&
Thank you TJF for that detailed answer and thank you too Andrew for your
insights.
We are trying to extract radar data from one radar board. The goal is not
have it working at 50MHz (which is the system max rate), but have the
possibility if needed. Probably we will work at 10 to 20MHz, and the
tag, 26. Mai 2020 17:04:50 UTC+2 schrieb PAk Ys:
>>
>> Our signal will be in the tens of MHz (from 5Mhz to 50MHz max), depending
>> on configuration.
>>
>> The polling method is what I expected, however the manual (spruh73q)
>> states there are three meth
passed to the 2nd PRU which can either put them in ARM DDR memory,
> send out, etc. If you get the voltages on the PRU input pins correct and
> the data rate is within what the PRU can handle, then this can be done.
>
>
>
> *From:* beagl...@googlegroups.com > *On Behalf Of
Hello.
I am quite new to PRU, sorry in advance if I make any mistake or incorrect
asumption.
I would need to read a LVDS signal which is a 4 data channels + CLK and
Framesync, that looks like this:
As you can see, the signals change in every edge (both falling and rising
edges).
Of c
Hello.
I am quite new to PRU, sorry in advance if I make any mistake or incorrect
asumption.
I would need to read a LVDS signal which is a 4 data channels + CLK and
Framesync, that looks like this:
As you can see, the signals change in every edge (both falling and rising
edges).
Of c
