Skip to first unread message
Parichay Barpanda
Feb 16, 2018, 2:09:02 PM2/16/18
to BeagleBoard GSoC
Hello. My question is for Hunyue Yau and Kumar Abhishek. Kumar Abhisek your Hackday Project Page on beaglelogic gives a lot of information so does your article. A big shout-out to your successful beaglelogic standalone board. I came across this link which is apparently a proposal for gsoc 2017 for the same idea. I am assuming this proposal failed because the GitHub repo doesn't exist. So here is a list of things that has kept me wondering:
1) Why did the last year's proposal fail? Can I get insights on some important issues in implementing a 'synchronous beaglelogic'?
2) What was the reason behind making beaglelogic asynchronous over synchronous when it was designed in the first place?
3) Can you give me some idea where to start from in order to contribute to this idea? And what part of the code and hardware needs to modified/replaced? Can this be implemented in the existing Beaglelogic standalone?
1) Why did the last year's proposal fail? Can I get insights on some important issues in implementing a 'synchronous beaglelogic'?
2) What was the reason behind making beaglelogic asynchronous over synchronous when it was designed in the first place?
3) Can you give me some idea where to start from in order to contribute to this idea? And what part of the code and hardware needs to modified/replaced? Can this be implemented in the existing Beaglelogic standalone?
Hunyue Yau
Feb 20, 2018, 6:19:37 PM2/20/18
to beaglebo...@googlegroups.com, Parichay Barpanda
Hi,
In general, proposals can fail for many reasons.
As implemented, BeagleLogic will sample at whatever rate it (the PRU) is setup
for. This has no relationship to the signal being observed, i.e. asynchronous.
So to get good picture of what is going on, the sample needs to be much faster
(sampling theory, etc.) then the signal.
Another way to look at the signal is to synchronously. There is a defined input
clock and the signal is looked at during a perdefined point in the clock.
(i.e. either or both edges with a time offset).
The idea is to create a synchronous sampling mode
On Friday, February 16, 2018 11:09:02 Parichay Barpanda wrote:
> Hello. My question is for Hunyue Yau and Kumar Abhishek. Kumar Abhisek your
> Hackday Project Page
> <https://hackaday.io/project/25745-beaglelogic-standalone> on beaglelogic
> e-prus-part-1/449>. A big shout-out to your successful beaglelogic
Hunyue Yau
http://www.hy-research.com/
In general, proposals can fail for many reasons.
As implemented, BeagleLogic will sample at whatever rate it (the PRU) is setup
for. This has no relationship to the signal being observed, i.e. asynchronous.
So to get good picture of what is going on, the sample needs to be much faster
(sampling theory, etc.) then the signal.
Another way to look at the signal is to synchronously. There is a defined input
clock and the signal is looked at during a perdefined point in the clock.
(i.e. either or both edges with a time offset).
The idea is to create a synchronous sampling mode
On Friday, February 16, 2018 11:09:02 Parichay Barpanda wrote:
> Hello. My question is for Hunyue Yau and Kumar Abhishek. Kumar Abhisek your
> Hackday Project Page
> gives a lot of information so does your article
> <http://theembeddedkitchen.net/beaglelogic-building-a-logic-analyzer-with-th
> e-prus-part-1/449>. A big shout-out to your successful beaglelogic
> standalone board. I came across this link
> <https://elinux.org/BeagleBoard/GSoC/SynchronousDataCollectionPRU> which is
> apparently a proposal for gsoc 2017 for the same idea. I am assuming this
> proposal failed because the GitHub repo doesn't exist. So here is a list of
> things that has kept me wondering:
>
> 1) Why did the last year's proposal fail? Can I get insights on some
> important issues in implementing a 'synchronous beaglelogic'?
>
> 2) What was the reason behind making beaglelogic asynchronous over
> synchronous when it was designed in the first place?
>
> 3) Can you give me some idea where to start from in order to contribute to
> this idea? And what part of the code and hardware needs to
> modified/replaced? Can this be implemented in the existing Beaglelogic
> standalone?
--
> proposal failed because the GitHub repo doesn't exist. So here is a list of
> things that has kept me wondering:
>
> 1) Why did the last year's proposal fail? Can I get insights on some
> important issues in implementing a 'synchronous beaglelogic'?
>
> 2) What was the reason behind making beaglelogic asynchronous over
> synchronous when it was designed in the first place?
>
> 3) Can you give me some idea where to start from in order to contribute to
> this idea? And what part of the code and hardware needs to
> modified/replaced? Can this be implemented in the existing Beaglelogic
> standalone?
Hunyue Yau
http://www.hy-research.com/
Reply all
Reply to author
Forward
0 new messages