Sign in
Search adsp
Subscribe to adsp
adsp by Keywords
AD1819 | AD7332 | ADSP-2106 | ADSP-21060 | ADSP-21065L | ADSP-2116 | ADSP-21160M | ADSP-2181 | ADSP-218x | ADSP-219 | ADSP-2199 | ADSP219 | BF531 | BF532 | BF533 | BF535 | Blackfin | FFT | JTAG | LDF | SDRAM | SHARC | SPORT | UART | VDSP++ | VisualDSP
Discussion Groups
Discussion Groups | Analog Devices DSPs | Need to read the data comming on PF pins(Steve)
Technical discussions related to Analog Devices DSPs (including Blackfin, TigerSHARC, SHARC and ADSP-21xx DSPs).
Need to read the data comming on PF pins(Steve) - ajax...@yahoo.co.in - May 3 6:53:00 2005
Hello last time i posted an thread of how to send the data thru an PF pin.
Well i have done it ,now i know how to transmit data using the PF pins.
Now My problem is how to Read the data coming on an perticular PF pin.
since i need to read the coming data c\Bit by bit .
Can any one Suggest to capture it.
I know how to make an pF pin To be an INput pin.
But when the external device sends the data to the PF pin of the DSP ,how to synchronize it to recevie.
I am using the BF532.PF12 is been configured as INPUT one.Is their any interrupt need to be used for this purpose or just simply reading the pin can i get the data.i am not able to have any idea of how is it to be done.
Steve willwating for ur valuable guidence.
regards
Ajay Narayan
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: Need to read the data comming on PF pins(Steve) - Mike Rosing - May 3 9:34:00 2005
On Tue, 3 May 2005 ajax_narayan@ajax... wrote:
> Hello last time i posted an thread of how to send the data thru an PF pin.
> Well i have done it ,now i know how to transmit data using the PF pins.
>
> Now My problem is how to Read the data coming on an perticular PF pin.
> since i need to read the coming data c\Bit by bit .
>
> Can any one Suggest to capture it.
> I know how to make an pF pin To be an INput pin.
> But when the external device sends the data to the PF pin of the DSP ,how to synchronize it to recevie.
>
> I am using the BF532.PF12 is been configured as INPUT one.Is their any interrupt need to be used for this purpose or just simply reading the pin can i get the data.i am not able to have any idea of how is it to be done.
>
> Steve willwating for ur valuable guidence.
Look at I2C or SPI. You need a clock pin and a data pin for those. You
can also look at RS232 and have an internal baud generator (no clock but
both sides need the same timing).
If you want to invent your own method, you can do that too. for example,
use one pin to mean "new data available" and another pin to mean "data".
When "data available" changes, read the data bit, then wait for the next
change. That gives you 2 bits per clock, you don't need to worry about
syncronizing and it's really easy to do.
Patience, persistence, truth,
Dr. mike
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
> Well i have done it ,now i know how to transmit data using the PF pins.
>
> Now My problem is how to Read the data coming on an perticular PF pin.
> since i need to read the coming data c\Bit by bit .
>
> Can any one Suggest to capture it.
> I know how to make an pF pin To be an INput pin.
> But when the external device sends the data to the PF pin of the DSP ,how to synchronize it to recevie.
>
> I am using the BF532.PF12 is been configured as INPUT one.Is their any interrupt need to be used for this purpose or just simply reading the pin can i get the data.i am not able to have any idea of how is it to be done.
>
> Steve willwating for ur valuable guidence.
Look at I2C or SPI. You need a clock pin and a data pin for those. You
can also look at RS232 and have an internal baud generator (no clock but
both sides need the same timing).
If you want to invent your own method, you can do that too. for example,
use one pin to mean "new data available" and another pin to mean "data".
When "data available" changes, read the data bit, then wait for the next
change. That gives you 2 bits per clock, you don't need to worry about
syncronizing and it's really easy to do.
Patience, persistence, truth,
Dr. mike
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: Need to read the data comming on PF pins(Steve) - Steve Holle - May 3 10:29:00 2005
This is not going to be as easy as transmit. The way a UART works is
to sample the incoming bits at 16 times the baud rate to determine
where the edges are. This will almost certainly need to be done in a
timer interrupt running at 16xbaud. Determining where the edges are
is no easy matter either, as you must maintain a history to
compensate for two asynchronous clocks.
What I would recommend is either to use a synchronous interface, with
a clock, receive, and transmit lines to communicate with whatever you
need to talk to or find a synchronous to async converter as an
asynchronous receiver is not trivial. Otherwise, you will need to
build an asynchronous receiver. If you put your transmitter back in
a timer interrupt running at 16 times the baud rate you output the
current bit for 16 samples before shifting to the next bit and sample
your input line each time looking for an edge. It's a little more
complicated than that but you really do need to get your software
UART running in an interrupt, or a thread, or something that let's
you run the rest of your code while waiting.
Any one else have any ideas? Is my suggestion overly complex?
At 04:53 AM 5/3/2005, ajax_narayan@ajax... wrote:
>Hello last time i posted an thread of how to send the data thru an PF pin.
>Well i have done it ,now i know how to transmit data using the PF pins.
>
>Now My problem is how to Read the data coming on an perticular PF pin.
>since i need to read the coming data c\Bit by bit .
>
>Can any one Suggest to capture it.
>I know how to make an pF pin To be an INput pin.
>But when the external device sends the data to the PF pin of the DSP
>,how to synchronize it to recevie.
>
>I am using the BF532.PF12 is been configured as INPUT one.Is their
>any interrupt need to be used for this purpose or just simply
>reading the pin can i get the data.i am not able to have any idea
>of how is it to be done.
>
>Steve willwating for ur valuable guidence.
>
>regards
>Ajay Narayan >
Steve Holle
Link Communications, Inc.
1035 Cerise Rd.
Billings, MT 59101
sholle@shol...
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
to sample the incoming bits at 16 times the baud rate to determine
where the edges are. This will almost certainly need to be done in a
timer interrupt running at 16xbaud. Determining where the edges are
is no easy matter either, as you must maintain a history to
compensate for two asynchronous clocks.
What I would recommend is either to use a synchronous interface, with
a clock, receive, and transmit lines to communicate with whatever you
need to talk to or find a synchronous to async converter as an
asynchronous receiver is not trivial. Otherwise, you will need to
build an asynchronous receiver. If you put your transmitter back in
a timer interrupt running at 16 times the baud rate you output the
current bit for 16 samples before shifting to the next bit and sample
your input line each time looking for an edge. It's a little more
complicated than that but you really do need to get your software
UART running in an interrupt, or a thread, or something that let's
you run the rest of your code while waiting.
Any one else have any ideas? Is my suggestion overly complex?
At 04:53 AM 5/3/2005, ajax_narayan@ajax... wrote:
>Hello last time i posted an thread of how to send the data thru an PF pin.
>Well i have done it ,now i know how to transmit data using the PF pins.
>
>Now My problem is how to Read the data coming on an perticular PF pin.
>since i need to read the coming data c\Bit by bit .
>
>Can any one Suggest to capture it.
>I know how to make an pF pin To be an INput pin.
>But when the external device sends the data to the PF pin of the DSP
>,how to synchronize it to recevie.
>
>I am using the BF532.PF12 is been configured as INPUT one.Is their
>any interrupt need to be used for this purpose or just simply
>reading the pin can i get the data.i am not able to have any idea
>of how is it to be done.
>
>Steve willwating for ur valuable guidence.
>
>regards
>Ajay Narayan >
Steve Holle
Link Communications, Inc.
1035 Cerise Rd.
Billings, MT 59101
sholle@shol...
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: Need to read the data comming on PF pins(Steve) - Mike Rosing - May 3 12:58:00 2005
On Tue, 3 May 2005, Steve Holle wrote:
> This is not going to be as easy as transmit. The way a UART works is
> to sample the incoming bits at 16 times the baud rate to determine
> where the edges are. This will almost certainly need to be done in a
> timer interrupt running at 16xbaud. Determining where the edges are
> is no easy matter either, as you must maintain a history to
> compensate for two asynchronous clocks.
>
> What I would recommend is either to use a synchronous interface, with
> a clock, receive, and transmit lines to communicate with whatever you
> need to talk to or find a synchronous to async converter as an
> asynchronous receiver is not trivial. Otherwise, you will need to
> build an asynchronous receiver. If you put your transmitter back in
> a timer interrupt running at 16 times the baud rate you output the
> current bit for 16 samples before shifting to the next bit and sample
> your input line each time looking for an edge. It's a little more
> complicated than that but you really do need to get your software
> UART running in an interrupt, or a thread, or something that let's
> you run the rest of your code while waiting.
>
> Any one else have any ideas? Is my suggestion overly complex?
the reason for complexity is robustness. I think this is a great idea,
and he should start simple and build up to it. Simple gets the basic
idea across, but the real world throws stuff at you to make it not work.
Making it robust is real engineering, so I think this should be his
ultimate goal.
Patience, persistence, truth,
Dr. mike
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
> This is not going to be as easy as transmit. The way a UART works is
> to sample the incoming bits at 16 times the baud rate to determine
> where the edges are. This will almost certainly need to be done in a
> timer interrupt running at 16xbaud. Determining where the edges are
> is no easy matter either, as you must maintain a history to
> compensate for two asynchronous clocks.
>
> What I would recommend is either to use a synchronous interface, with
> a clock, receive, and transmit lines to communicate with whatever you
> need to talk to or find a synchronous to async converter as an
> asynchronous receiver is not trivial. Otherwise, you will need to
> build an asynchronous receiver. If you put your transmitter back in
> a timer interrupt running at 16 times the baud rate you output the
> current bit for 16 samples before shifting to the next bit and sample
> your input line each time looking for an edge. It's a little more
> complicated than that but you really do need to get your software
> UART running in an interrupt, or a thread, or something that let's
> you run the rest of your code while waiting.
>
> Any one else have any ideas? Is my suggestion overly complex?
the reason for complexity is robustness. I think this is a great idea,
and he should start simple and build up to it. Simple gets the basic
idea across, but the real world throws stuff at you to make it not work.
Making it robust is real engineering, so I think this should be his
ultimate goal.
Patience, persistence, truth,
Dr. mike
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: Need to read the data comming on PF pins(Steve) - Steve Holle - May 3 15:12:00 2005
That's true. You could just try sampling the recieve pin at the same
time you transmit, shift it into position and see what you get. One
way to thest this would be to loop your tx pin to your rx pin and
read and shift until you get the same back as you sent.
At 10:58 AM 5/3/2005, Mike Rosing wrote:
>On Tue, 3 May 2005, Steve Holle wrote:
>
> > This is not going to be as easy as transmit. The way a UART works is
> > to sample the incoming bits at 16 times the baud rate to determine
> > where the edges are. This will almost certainly need to be done in a
> > timer interrupt running at 16xbaud. Determining where the edges are
> > is no easy matter either, as you must maintain a history to
> > compensate for two asynchronous clocks.
> >
> > What I would recommend is either to use a synchronous interface, with
> > a clock, receive, and transmit lines to communicate with whatever you
> > need to talk to or find a synchronous to async converter as an
> > asynchronous receiver is not trivial. Otherwise, you will need to
> > build an asynchronous receiver. If you put your transmitter back in
> > a timer interrupt running at 16 times the baud rate you output the
> > current bit for 16 samples before shifting to the next bit and sample
> > your input line each time looking for an edge. It's a little more
> > complicated than that but you really do need to get your software
> > UART running in an interrupt, or a thread, or something that let's
> > you run the rest of your code while waiting.
> >
> > Any one else have any ideas? Is my suggestion overly complex?
>
>the reason for complexity is robustness. I think this is a great idea,
>and he should start simple and build up to it. Simple gets the basic
>idea across, but the real world throws stuff at you to make it not work.
>Making it robust is real engineering, so I think this should be his
>ultimate goal.
>
>Patience, persistence, truth,
>Dr. mike
Steve Holle
Link Communications, Inc.
1035 Cerise Rd.
Billings, MT 59101
sholle@shol...
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
time you transmit, shift it into position and see what you get. One
way to thest this would be to loop your tx pin to your rx pin and
read and shift until you get the same back as you sent.
At 10:58 AM 5/3/2005, Mike Rosing wrote:
>On Tue, 3 May 2005, Steve Holle wrote:
>
> > This is not going to be as easy as transmit. The way a UART works is
> > to sample the incoming bits at 16 times the baud rate to determine
> > where the edges are. This will almost certainly need to be done in a
> > timer interrupt running at 16xbaud. Determining where the edges are
> > is no easy matter either, as you must maintain a history to
> > compensate for two asynchronous clocks.
> >
> > What I would recommend is either to use a synchronous interface, with
> > a clock, receive, and transmit lines to communicate with whatever you
> > need to talk to or find a synchronous to async converter as an
> > asynchronous receiver is not trivial. Otherwise, you will need to
> > build an asynchronous receiver. If you put your transmitter back in
> > a timer interrupt running at 16 times the baud rate you output the
> > current bit for 16 samples before shifting to the next bit and sample
> > your input line each time looking for an edge. It's a little more
> > complicated than that but you really do need to get your software
> > UART running in an interrupt, or a thread, or something that let's
> > you run the rest of your code while waiting.
> >
> > Any one else have any ideas? Is my suggestion overly complex?
>
>the reason for complexity is robustness. I think this is a great idea,
>and he should start simple and build up to it. Simple gets the basic
>idea across, but the real world throws stuff at you to make it not work.
>Making it robust is real engineering, so I think this should be his
>ultimate goal.
>
>Patience, persistence, truth,
>Dr. mike
Steve Holle
Link Communications, Inc.
1035 Cerise Rd.
Billings, MT 59101
sholle@shol...
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )