Re: [beagleboard] Re: Could PRU read this signals?

2020-05-29 Thread PAk Ys 
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/sbaa205/sbaa205.pdf
https://www.xilinx.com/support/documentation/application_notes/xapp866.pdf

My idea is, if possible, to do just that with PRUs as a more powerful, 
lower cost, better integrated setup.


On Friday, May 29, 2020 at 9:13:20 PM UTC+2, Gerhard Hoffmann wrote:
>
> Hi, 
>
> I'm reading LTC2500-32 ADCs with the PRU. The LTC2500 delivers 32 Bits 
> every usecond 
>
> as a 320nsec burst with 100 MHz bit rate. I receive the burst with a 
> shift register in a 
>
> Xilinx CoolrunnerII CPLD and read the shift register bytewise with PRU2. 
>
> I think I could read 3 ADCs with the current timing (minimum requirement 
> for me), 
>
> maybe 4 with some optimization. The PRU writes the data into this 12 KW 
> shared ram, 
>
> organized as a ping-pong buffer. The ARM reads continuously half of the 
> buffer while 
>
> the other half is written by the PRU. That also solves the problem that 
> is is hard 
>
> to allocate REALLY big buffers in the virtual address space of Linux and 
> fixing 
>
> their location somewhere for the PRU, in addition to the unpredictable 
> duration 
>
> of a memory cycle when competing with the ARM for access. 
>
> I have currently paused that software development to first fix the 
> analog part. 
>
>
> Cheers, Gerhard 
>
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0bb2f408-61fa-4c19-9eff-42c6f5b0cc73%40googlegroups.com.

Re: [beagleboard] Re: Could PRU read this signals?

2020-05-29 Thread Gerhard Hoffmann 

Hi,

I'm reading LTC2500-32 ADCs with the PRU. The LTC2500 delivers 32 Bits 
every usecond


as a 320nsec burst with 100 MHz bit rate. I receive the burst with a 
shift register in a


Xilinx CoolrunnerII CPLD and read the shift register bytewise with PRU2.

I think I could read 3 ADCs with the current timing (minimum requirement 
for me),


maybe 4 with some optimization. The PRU writes the data into this 12 KW 
shared ram,


organized as a ping-pong buffer. The ARM reads continuously half of the 
buffer while


the other half is written by the PRU. That also solves the problem that 
is is hard


to allocate REALLY big buffers in the virtual address space of Linux and 
fixing


their location somewhere for the PRU, in addition to the unpredictable 
duration


of a memory cycle when competing with the ARM for access.

I have currently paused that software development to first fix the 
analog part.



Cheers, Gerhard



--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/98fcbd26-7ff4-a038-f4e4-b6a7a69b1352%40hoffmann-hochfrequenz.de.

[beagleboard] Re: Could PRU read this signals?

2020-05-29 Thread PAk Ys 
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 idea is to create a simpler, better device able to work with  the 
>> beaglebone (or the beaglewire), allowing users to create their own radar 
>> applications in a very fast way (including the UI).
>>
>
> You can use the second PRU to de-serialize the data, while the first PRU 
> is fetching them. Meanwhile the ARM CPU can provide the data transfer over 
> the network (or PRU IEP module?), or it can do simple evaluations like 
> pre-selection of relevant data sections, or GUI output ...
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b039ae70-d3a9-4581-9f70-8585a6792166%40googlegroups.com.

[beagleboard] RS485 serial communication on the Beaglebone AI

2020-05-29 Thread John Allwine 
Does anyone have any experience getting RS485 communication going over one 
of the UARTs on the Beaglebone AI? I'm finding very little info on it for 
the Beaglebone Black (none for the AI), and having a tough time figuring 
out how to apply what there is to the AI. I'm specifically trying to use 
UART3 on the Beaglebone AI and I'm not sure what to do.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/493240ef-925a-4b69-9a90-e3a689987185%40googlegroups.com.

[beagleboard] Re: Could PRU read this signals?

2020-05-29 Thread TJF 
Am Freitag, 29. Mai 2020 11:35:56 UTC+2 schrieb PAk Ys:
>
> My idea is to create a simpler, better device able to work with  the 
> beaglebone (or the beaglewire), allowing users to create their own radar 
> applications in a very fast way (including the UI).
>

You can use the second PRU to de-serialize the data, while the first PRU is 
fetching them. Meanwhile the ARM CPU can provide the data transfer over the 
network (or PRU IEP module?), or it can do simple evaluations like 
pre-selection of relevant data sections, or GUI output ...

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8724af50-adc1-481c-8bad-09769a085f5b%40googlegroups.com.

[beagleboard] Re: PocketBeagle is sometimes running very hot with only minimal CPU activity

2020-05-29 Thread Oleg Golevych 
Its OK when PB turns on.

пятница, 29 мая 2020 г., 14:08:54 UTC+3 пользователь Brett Maurer написал:
>
> Thank you for the reply. The drawing is very helpful. 
>
> I noticed that P1.03 EN blinks high, then low, then high again after a 
> couple seconds. I assume that this is not a problem for the power switch. 
> I'll be checking this further after I get my hands on the component.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/26932b72-5f9a-4bce-a0f3-7b32bbe71920%40googlegroups.com.

[beagleboard] Re: PocketBeagle is sometimes running very hot with only minimal CPU activity

2020-05-29 Thread Brett Maurer 
Thank you for the reply. The drawing is very helpful. 

I noticed that P1.03 EN blinks high, then low, then high again after a 
couple seconds. I assume that this is not a problem for the power switch. 
I'll be checking this further after I get my hands on the component.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c94ddd14-a95e-4402-92d8-e8290df0fff2%40googlegroups.com.

[beagleboard] Re: PocketBeagle is sometimes running very hot with only minimal CPU activity

2020-05-29 Thread Oleg Golevych 


[image: IMG1.jpg]
To avoid damaging PB use this scheme.

четверг, 28 мая 2020 г., 14:10:31 UTC+3 пользователь Brett Maurer написал:
>
> I'm using the PocketBeagle in one of my projects and have noticed 5 times 
> out of maybe 100 that the CPU runs very hot, enough to burn my fingers. 
> Running the TOP command, I see nothing using more that 1% CPU usage. When I 
> cycle the power, the temperature returns to normal. I'm concerned that it 
> might be dangerously hot. 
>
> Does anyone know what is going on?
>
> - Using Debian build: bone-debian-9.9-iot-armhf-2019-08-03-4gb.img
> - Connected to USB 3G modem but little else.
> - Running simple bonescript that is confirmed to take only 0.3% CPU
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f06a534b-dac2-4608-9f3d-9a011ea3d65c%40googlegroups.com.

[beagleboard] Re: Could PRU read this signals?

2020-05-29 Thread PAk Ys 
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 
antenna.







My idea is to create a simpler, better device able to work with  the 
beaglebone (or the beaglewire), allowing users to create their own radar 
applications in a very fast way (including the UI).






On Friday, May 29, 2020 at 1:22:40 AM UTC+2, Andrew P. Lentvorski wrote:
>
> You can certainly persist, but I'm going to point out the existence of 
> chips like the AWR1843--"Single-chip 76-GHz to 81-GHz automotive radar 
> sensor integrating DSP, MCU and radar accelerator":
> https://www.ti.com/product/AWR1843
>
> This is about $30, and does all the RF-y things while sending your ADC 
> data straight to a DSP and Cortex R4F with extra Radar-y things to 
> accelerate analysis.  This allows you to focus on analyzing the results 
> instead of the guts of "implementing a radar".
>
> Anyways, good luck.  Sounds like an interesting project.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ec989263-c422-47e6-9689-26c670ec86cc%40googlegroups.com.