On Fri, Oct 03, 2008 at 11:10:36PM -0700, Matt E. wrote:
Jeff L. wrote:
Generated a new txrx.bin using EDK101 and put it on the SD
card. Works! I’m assuming that’s the correct app, based on
strings on the provided SD. BTW, is any of this documented
Yes, txrx is the correct app to use, and is the one which is on the SD
card which I ship out. No, we don’t really have this written anywhere.
I’ve been putting stuff on the USRP2 FAQ page on the wiki, but clearly
this is a lot which still needs to be documented.
txrx is the standard firmware at this point.
Where do printf’s go to?
They go to the serial port on the right side of the USRP2, between the
two daughterboards. You would have to connect a TTL-level serial port
to it, at 230,400 baud.
Using -Os vs. -O2 shaves off another 500 bytes if you ever
need the space. Takes txrx.bin from 26028 to 25484 bytes.
Good to know. We’ll need to see how the inner loop holds up.
At decim = 4 and/or interp = 4, it’s close to being the bottleneck.
I was thinking that -Os would probably be a good thing to try. Having
only 32K of RAM can be a bit constraining.
The function __udivdi3 is 1836 bytes long, and is only used
in print_uint64, which is used only in printf_fxpt_freq.
That might be something to get rid of.
Wow, 1836 bytes is a lot.
Right now __moddi3, __umoddi3, __divdi3 and __udivdi3 contain inlined
versions of __udivmoddi4. Un-inlining them should save about 5KB in
the worst case, 4KB typical. I’m working on it. (These routines
implement signed and unsigned 64-bit divides and mods. We use these
in dealing with our 64-fixed point frequency representation.)
Jeff, which RFX board are you using?