[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Discuss-gnuradio] UHD problem
From: |
Per Zetterberg |
Subject: |
RE: [Discuss-gnuradio] UHD problem |
Date: |
Fri, 16 Jul 2010 10:50:56 +0000 |
I changed the code in "usrp2_iface_impl::ctrl_send_and_recv" slighly, see
below. It seems to solve the problem for my current application New and
removed lines are marked with "PZ".
BR/
Per
usrp2_ctrl_data_t ctrl_send_and_recv(const usrp2_ctrl_data_t &out_data){
boost::mutex::scoped_lock lock(_ctrl_mutex);
unsigned int number_of_tries=0; // PZ
//fill in the seq number and send
usrp2_ctrl_data_t out_copy = out_data;
out_copy.proto_ver = htonl(USRP2_PROTO_VERSION);
out_copy.seq = htonl(++_ctrl_seq_num);
_ctrl_transport->send(boost::asio::buffer(&out_copy,
sizeof(usrp2_ctrl_data_t)));
//loop until we get the packet or timeout
boost::uint8_t usrp2_ctrl_data_in_mem[USRP2_UDP_BYTES]; //allocate max
bytes for recv
usrp2_ctrl_data_t *ctrl_data_in = reinterpret_cast<usrp2_ctrl_data_t
*>(usrp2_ctrl_data_in_mem);
while(true){
size_t len =
_ctrl_transport->recv(boost::asio::buffer(usrp2_ctrl_data_in_mem));
if(len >= sizeof(boost::uint32_t) and
ntohl(ctrl_data_in->proto_ver) != USRP2_PROTO_VERSION){
throw std::runtime_error(str(
boost::format("Expected protocol version %d, but got %d\n"
"The firmware build does not match the host code build."
) % int(USRP2_PROTO_VERSION) %
ntohl(ctrl_data_in->proto_ver)
));
}
if (len >= sizeof(usrp2_ctrl_data_t) and ntohl(ctrl_data_in->seq)
== _ctrl_seq_num){
return *ctrl_data_in;
}
//if (len == 0) break; //timeout PZ
if (len == 0 ) { // PZ
if (number_of_tries==50) // PZ
break; //PZ
else // PZ
number_of_tries++; // PZ
}; // PZ
//didnt get seq or bad packet, continue looking...
}
throw std::runtime_error("usrp2 no control response");
}
________________________________________
From: address@hidden address@hidden on behalf of Josh Blum address@hidden
Sent: Thursday, July 15, 2010 9:40 PM
To: address@hidden
Subject: Re: [Discuss-gnuradio] UHD problem
You have done nothing wrong. This is a result of the transmit SM in the
FPGA using ethernet pause frames to flow control the transmit. The pause
frame is blocking the transaction from the issue stream command, and
causing the timeout error (no response).
Sending a large packet (greater than the fpga buffering) several seconds
in the future will cause the FPGA to issue these pause frames and it
will last for several seconds (until the transmit packets are processed).
Understanding that, it may be possible for you to work around this by
making the sends in the future sooner (within 100 ms). Or issue the
stream command before any sending occurs. In the long run, we are
working on a host based flow control to avoid using the pause frames.
Hope that helps,
-Josh
On 07/15/2010 12:16 PM, Per Zetterberg wrote:
> Hi Josh and List,
>
> I am trying to send two frames and then receive a frame. The two transmit
> frames are transmitted several seconds in advance using d_dev->send. They
> arrive nicely at the receiver as they should. However, then I try to receive
> a frame using "d_sdev->issue_stream_cmd(stream_cmd)" followed by
> d_dev->recv. However, the command "d_sdev->issue_stream_cmd" gives the error
> "usrp2 no control response".
>
> Could it be that when I do the command d_sdev->issue_stream_cmd the USPR2 is
> busy waiting to transmit the two transmit frames ?
>
> BR/
> Per
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio