Questions about E100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

as far as I understand, the E100 is a complete standalone system. I’m
just a bit irritated by the descriptions “Console (USB)” and USB
on-the-go. I assume, console USB is a serial console via some getty to
ttyUSBx? How am I supposed to use it? Adaptor USB->Mini-USB and a
USB-Serial adaptor?
What is USB on-the-go?

How about the software? Is the box x86 compatible or do I have to wait
for Ettus to create some kind of software image if there is an update of
gnuradio?

And finally - how about the performance? Does the box run X? Is it
powerful enough to run grc-created WX-stuff?


(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk25sVsACgkQbQKZlCdPOMPjyACghOeAdNBONvp1t9BuUKSUDdjR
kCEAoLBw4B3e5HEuhvk/ue/9kX8yoGgD
=qWm+
-----END PGP SIGNATURE-----

On 28/04/2011 2:26 PM, Stefan Gofferje wrote:

What is USB on-the-go?
USB on-the-go (OTG) is a USB standard that allows a USB port to adopt
either “host” or “device”
personality, depending on application. It’s fairly common on
embedded-system platforms to
supply this.

It’s also very common for such embedded systems to provide a virtual
serial-port via USB, by virtue of
“looking” exactly like a USB serial port. Such devices work with
existing Linux serial-port
software, and as you observe will “manifest” as /dev/ttyUSBx or
sometimes, /dev/ttyACMx.

How about the software? Is the box x86 compatible or do I have to wait
for Ettus to create some kind of software image if there is an update of
gnuradio?
The E100 is based on an TI OMAP platform. Phil Ballister could fill in
the details, but it ships with
a Linux image pre-installed, and you can do either a cross-build or
native build of Gnu Radio yourself,
and most E100 users do so. It’s completely end-user configurable,
programmable, as you would expect
any Linux platform to be. But it’s not X86.

And finally - how about the performance? Does the box run X? Is it
powerful enough to run grc-created WX-stuff?

It’s not a desktop-class platform by any stretch of the imagination.

If you’re interested modifying the base image beyond what’s provided
you’ll need to get familiar with OpenEmbedded. It’s essentially a
complete embedded framework for cross compilation, filesystem
generation, and whatever embedded coolness you’re interested in. The
E100 has a Gumstix Overo board which contains a TI OMAP3530 which
contains an Armv7 GPP and a C64x+ Texas instrument fixed point DSP …
basically no x86. you would need to get familiar with how to use
OpenEmbedded to target the gumstix overo which is fairly well supported.

I know Philip is providing images which also allow you to download
installation packages using opkg so people won’t have to mess with
OpenEmbedded … I’ll leave further commenting to Philip.

al fayez

Hi,

On Apr 28, 2011, at 10:40 PM, Marcus D. Leech wrote:

And finally - how about the performance? Does the box run X? Is it
powerful enough to run grc-created WX-stuff?

It’s not a desktop-class platform by any stretch of the imagination.

The Overo platforms can run X11.

Here is a link to a getting started guide

http://www.gumstix.org/get-started/getting-started-guide.html

Here is a link on how to build a standard image for the Overo using the
OpenEmbedded system. Mind you, this is not the GNU Radio specific one,
I don’t have the E100, but I’ve worked on the Overo and OMAP35xx
platform for 3 years now.

What you can do is to merge the GNU Radio recipe, with something that
you can pick and choose from the X11 recipe in the standard open
embedded distribution.

http://www.gumstix.org/software-development/open-embedded/61-using-the-open-embedded-build-system.html

Once you clone the overo-oe repository, under
overo-oe/org.openembedded.dev/recipes/images folder, you can find an
x11-image.bb recipe.

To build a root file system image, type the following command:

cd overo-oe
bitbake x11-image

This will create a tar file in the tmp/…something…/deploy folder

I should warn you, the learning curve for learning OE is steep, and you
can look at the Old Nabble lists for Gumstix Users on many common
problems encountered and solutions posted for this platform.

I think I took a whole year just to figure out the whole build system.
You also need a fast quad-core i7 system to build the images using
OpenEmbedded. A core 2 duo system with 4GB RAM can take 20 hours for an
omap3-console-image. A quad-core i7 with 4GB RAM will do it in around
2.5 hours. I use Ubuntu 10.04 running on a Virtual Machine on top of Mac
OS X, for all this work.

Elvis D.

Just to avoid the impending flood of “oh god I need a core i7 just to
run an E100” posts, we do ship the E100 with a default image based on
Angstrom Linux which has full X support. Eventually the Gnuradio QT GUI
sinks will also run on the E100; this support is experimental right now
but when it’s stable we’ll release an image supporting it out of the
box. We aren’t planning on supporting wxgui on E100.

For many uses, users will never have to deal with OE, bitbake, or
compiling their own images. That’s what Phil is for. =)

–n

There have been a lot of good answers already. Thanks guys!

If you are having trouble figuring out what a USRP-E100 is, look at the
gumstix website. The E100 is basically a Gumstix Overo expansion board
with an FPGA and codec to interface to a USRP daughterboard.

On 04/28/2011 02:26 PM, Stefan Gofferje wrote:

What is USB on-the-go?
These terms come from the Gumstix/mobile computing world. The USB
console is a usb to serial convertor. Rather than have you provide the
usb to serial dongle, the convertor is in the E100 so you can connect
directly to the E100 with a USB 1 to mini B cable.

How about the software? Is the box x86 compatible or do I have to wait
for Ettus to create some kind of software image if there is an update of
gnuradio?

The processor is a TI OMAP3, which is basically an ARM Cortex A8 machine
(armv7a+NEON instruction set). Yes, lots of confusing numbers and names
in the ARM processor space.

And finally - how about the performance? Does the box run X? Is it
powerful enough to run grc-created WX-stuff?

It runs gnuradio-companion and qt. It is not a desktop class machine,
but it is a gateway to small standalone SDR system and mobile SDR
solutions.

I’ve started a document on doing your own image builds based on the OE
release branch here:

http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/Install_OpenEmbedded

The kernels from Gumstix won’t work (no driver) and their u-boot has a
clash with the gpmc config. (I’m working on resolving this) Their MLO is
fine.

Long term, we should be able to draw on the work of the larger
Yoctoproject to make embedded development easier.

Philip

On Thu, May 5, 2011 at 5:42 PM, Scott Johnston
[email protected] wrote:

Hi,

Has anybody out there done any development on the DSP? What tools are
available to program it? I have used TI’s code composer in the past to
program DSPs, is there something comparable to that included with E100, or
is it easy to get it? What I would like to be able to do is obtain common C
libraries and compile C code to run on the DSP.

With a TI account, you can grab the free tools here:

https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm

Brian

Hi,

Has anybody out there done any development on the DSP? What tools are
available to program it? I have used TI’s code composer in the past to
program DSPs, is there something comparable to that included with E100,
or is it easy to get it? What I would like to be able to do is obtain
common C libraries and compile C code to run on the DSP.

Thanks

Scott

Philip B. wrote:

These terms come from the Gumstix/mobile computing world. The USB
The processor is a TI OMAP3, which is basically an ARM Cortex A8 machine

Long term, we should be able to draw on the work of the larger

Version: GnuPG v2.0.16 (GNU/Linux)
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Scott Johnston
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA 02420-9108
(781) 981-8196
[email protected]

I’ve done a fair amount of work with using the C64x+ DSP in and out of
GNU Radio using the TI tools, you download my code and some custom
gnuradio blocks for the omap processor based on the C64x+ DSP. I’ve
tested this code on a Beagleboard but it should work for the E100.

https://github.com/alfayez/gr-dsp

I recommend using the Linux tools for development and to use Code
Composer for debugging … I include a brief description of the tools
you need to install to use the DSP my preference is to use DSPLink
versus Codec Engine for GPP/DSP communication because it’s simpler to
program. Good luck and feel free to send more detailed questions over
the listserv once you start the work.

al fayez

On Thu, May 5, 2011 at 6:07 PM, Brian P. [email protected]
wrote:

With a TI account, you can grab the free tools here:

https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm

Also, another good resource for all TI processors seems to be:

http://processors.wiki.ti.com/index.php/Main_Page

Brian

On Fri, May 6, 2011 at 16:29, Philip B. [email protected]
wrote:

You can build an image with dsp support by following the notes at:

http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/Install_OpenEmbedded

I’ll post a copy of the image next week.

To run the demos, you’ll need to modify the kernel boot args to create a
memory hole. This is (barely) documented on the interwebs. Next time I
update u-boot, I’ll include an extra variable to make it easier to create
the memory hole.

On a related question - have anyone tried SysLink on Gumstix/E100?

I’m just getting into this staff and trying to understand what tools
are the best to use for DSP on OMAP/DaVinci/Integra.


Regards,
Alexander C…

On 05/06/2011 04:51 PM, Alexander C. wrote:

On a related question - have anyone tried SysLink on Gumstix/E100?

I’m just getting into this staff and trying to understand what tools
are the best to use for DSP on OMAP/DaVinci/Integra.

Good question :slight_smile:

More information on syslink is here:

http://processors.wiki.ti.com/index.php/Category:SysLink

I see a recipe to make syslink in OE, but it pulls from a git repo. I’ll
ask what sort of state it is in.

Philip

On 05/05/2011 05:42 PM, Scott Johnston wrote:

Hi,

Has anybody out there done any development on the DSP? What tools are
available to program it? I have used TI’s code composer in the past to
program DSPs, is there something comparable to that included with E100,
or is it easy to get it? What I would like to be able to do is obtain
common C libraries and compile C code to run on the DSP.

You can build an image with dsp support by following the notes at:

http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/Install_OpenEmbedded

I’ll post a copy of the image next week.

To run the demos, you’ll need to modify the kernel boot args to create a
memory hole. This is (barely) documented on the interwebs. Next time I
update u-boot, I’ll include an extra variable to make it easier to
create the memory hole.

Philip

On 05/06/2011 05:07 PM, Philip B. wrote:

common C libraries and compile C code to run on the DSP.
update u-boot, I’ll include an extra variable to make it easier to

More information on syslink is here:

http://processors.wiki.ti.com/index.php/Category:SysLink

I see a recipe to make syslink in OE, but it pulls from a git repo. I’ll
ask what sort of state it is in.

Apparently there is no official syslink for OMAP3 at the moment. This
may change in the future. Sounds like you should focus on dsplink for
now.

Philip

On Sat, May 7, 2011 at 02:03, Philip B. [email protected]
wrote:

Has anybody out there done any development on the DSP? What tools are

I’m just getting into this staff and trying to understand what tools
ask what sort of state it is in.

Apparently there is no official syslink for OMAP3 at the moment. This may
change in the future. Sounds like you should focus on dsplink for now.

Weird. Why do they mention OMAP3530 as an example of Syslink target
here?
http://processors.wiki.ti.com/index.php/Category:SysLink
and mention some OMAP3530 executables here?
http://processors.wiki.ti.com/index.php/SysLink_UserGuide


Regards,
Alexander C…

For now I’d say there are two main approaches that can be taken for DSP
development on the omap/davinci … at least to the best of my
knowledge. There is the DSPLink approach and the Codec Engine approach.
DSPLink provides the barebones mechanisms to enable inter-processor
communication, setup, and data exchange. I’ve steered away from Codec
Engine because it seems more complicated and because from what I gather
it’s targeted more for situations where you might purchase a codec and
only have access to the binary and you would need a mechanism to select
and run between multiple codecs that might be available and for that
Codec Engine would provide a framework to handle this situation.

If you’re taking the DSPLink approach then the following are the set of
tools you would need:

1- TI Code Generation Tools (CGT) C6000
the DSP Compiler
2- TI DSPLink
to handle inter processor communication
3- TI Codec Engine
even if you’re not using it you have install it because of
dependency
4- TI DSP/BIOS
DSP RTOS
5- TI Local Power Manager (LPM)
The OMAP processor has a bug where you have to reset the DSP if you
plan on loading different executables and the LPM modules provides an
executable to do just that

You would need to setup the Makefiles for DSPLink before using it to
point it to your kernel directory, compile tools, … etc

al

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs