6

How can I easily start off professional development with the BeagleBoard XM?

  1. Which OS should I work with? .. my choices include:

    • Ubuntu
    • Android
    • MeeGo
    • WinCE
    • QNX
    • Angstrom (preinstalled)
    • Symbian
    • Gentoo

  2. How do I install an OS onto the board?

  3. Which IDE do I use?

  4. How do I debug or run my code on the target?

I bought a brand new Beagleboard XM to interface to a camera module, capture video and do some image processing. The camera uses an 8-bit parallel port interface to transfer images.

What do you recommend?

tyblu
  • 8,167
  • 6
  • 40
  • 70
Kevin Boyd
  • 1,971
  • 4
  • 23
  • 28

3 Answers3

2

I would start with Angstrom Linux, and then move to Ubuntu if you have to. I doubt that you will need to switch just to make the camera work.

I believe the OS for the Beagleboard XM is stored on the SD card, so if you decide you do need to switch to something else, you might get a second SD card, so you can leave the original OS intact. Depending on the OS, you can probably find a prebuilt SD card image that will allow the Beagleboard to boot.

For an IDE, I would recommend starting with a text editor that works over SSH. You might start with Nano, unless you've used Vim or Emacs before.

I'm not sure about debugging C++ on the Beagleboard, but you can start compiling in Angstrom with g++. You'll be able to execute code from the commandline.

pingswept
  • 12,581
  • 4
  • 46
  • 64
  • if you can ssh, then you can use gdb for debugging code, or possibly foward the gdb traffic and use a graphical debugger on your computer – Earlz Dec 27 '10 at 00:55
  • I'm sorry but I'm new to this kind of development. Just to clarify would I be doing all my development on the BeagleBoard itself or would I need a PC + Beagleboard setup. I have a windows OS on the PC but I would mind setting up Linux if that's going to make development any easier. – Kevin Boyd Dec 28 '10 at 06:59
  • Sorry, I should have been more clear. The usual method is to use an SSH terminal on a local PC (could be Windows with Cygwin or Mingw, but Linux is a better fit). You SSH to the board and then run the editor on the board. You could also do the coding on your PC and copy the binaries over, but this means setting up an ARM compiler ("cross-compiling") on your PC, which can be a bit tricky. – pingswept Dec 28 '10 at 15:53
  • Just to add: Earlz and Johan are correct to recommend gdb and JTAG. It's kind of hard to set up, and the hardware can be expensive, but it's great once you get it going. I wouldn't think it was necessary to get started. – pingswept Dec 28 '10 at 15:54
  • I don't think you need a JTAG unless you intend to debug the kernel and/or drivers. For standard apps, using gdbserver in the board accessed by a gdb-compatible IDE in a PC is far easier. – fceconel Dec 29 '10 at 22:46
2

OS

It really depends on what you would like to do?

You have three options that is Linux kernel based:

  • Angstrom is a classic GNU/Linux distribution created for this type of devices.
  • MeeGo is the cool Nokia/Intel Qt based platform that will be used a lot in infotainments systems in cars (and in some Nokia phones).
  • Android the google phone OS, mostly Java

And some Desktop Linux distributions:

  • Ubuntu
  • Gentoo

And then some other OS:

  • Symbian that is a 99% phone OS (I would not recommend it)
  • QNX I think is has some real time stuff that could be fun to play with
  • WinCE And you have the classic looked down Windows platform.

And I would actually start to play with the stuff in this order

  1. Angstrom, since it seems to be easiest on the Beagleboard
  2. MeeGo since Qt is a really nice lib to work with
  3. Android since it is good to know
  4. QNX

But for the rest of this question I will only focus on the Linux based options.

Install OS

It depends, but most of them uses the SD card.

But in debug mode you can use a combination that loads the kernel over tftp and the the runs the root filesystem over nfs

IDE and debug

To play the kernel you need the command line, a good editor like vim/emacs. To debug the kernel you need a debugger to run over the jtag.

But for application development you could use the classical way (with a good editor and a lot of makefiles). Or maybe something like eclipse.

Application debugging is usually done with gdb.

On the linux based you could use a normal text editor or maybe Eclipse.

Johan
  • 2,385
  • 2
  • 25
  • 27
  • I would have to buy a usb or parallel port tool for debugging over jtag, right? What would you recommend for that? – Kevin Boyd Dec 28 '10 at 06:49
  • @Kevin: Í tried to use a affordable OpenOCD based jtag, but today that project has problem with internal caches on the Cortex A8 chip that the BeagleBoard is using.... However I know that the Expensive jtags from Lauterbach do work to debug the kernel. (They are good but expensive)... – Johan Dec 28 '10 at 06:57
  • Thanks! Any idea how to get hold of cam drivers, if I have to interface to a cam module? – Kevin Boyd Dec 28 '10 at 10:29
  • @Kevin: No idea, but it can't hurt to ask the maker of the cam? And have a look a video 4 linux, http://en.wikipedia.org/wiki/Video4Linux – Johan Dec 28 '10 at 15:11
2

I tried Meego and Angstrom, and settled on Angstrom. It's far easier to make it work, and very stable. The Meego port for beagleboard, on the other hand, had many glitches. I didn't test the other OSes, but I'd say Angstrom seems to be the best choice for both community support and stability.

To install the OS is quite simple: you download an OS image to an SD card and make some changes in the bootloader to make it boot from the SD. There are some ready-made OS images at the Angstrom website, along with recipes to install it on the SD. Basically you'll create two partitions: a smaller FAT for the boot and kernel, and the other for the root filesystem containing everything else. Here's one site containing instructions for SD boot: http://www.xora.org.uk/2009/08/14/omap3-sd-booting/

You could also make it boot from the NAND flash, but I'd recommend to save this option for later when you're more comfortable with the device. Since the NAND is limited, you'll need to create a custom image using bitbake to make it fit, that's the kind of work you won't want to do right now.

About debugging, the best way is for you to buy an ethernet-to-usb interface + usb hub. Then you run gdbserver in your beagleboard and can use any gdb-compatible debugging IDE at your PC (I use Eclipse CDT).

For the camera interface, the easiest way would be to use the GPIO pins at the expansion connector; the drawback is that you may have a limited frame rate due to the bandwidth limitation, and also yo'll make the processor busy while transfering the image; on the other hand the GPIO is so flexible that you probably won't need any additional circuit to connect them - provided their voltage is compatible (the GPIO works at 1.8 V). There can be other ways if you want a higher frame rate and need the processor available for other parallel tasks, but I'd recommend to leave that for a second round of design.

fceconel
  • 2,659
  • 22
  • 19
  • I have the BeagleBoard XM, ver A3 and it doesn't have a Nand on it, so I would have to go with the SD card option. Regarding the camera interface any idea what is the bandwidth limitation. I would like to interface a 5MP camera and acquire full res @ 15fps. Also how do I locate the drivers for the cam, does Angstrom have built-in cam drivers? The cam module that I has an omnivision image sensor on it. – Kevin Boyd Dec 28 '10 at 06:53
  • 1
    Looks like someone just wrote a Linux driver: http://boundarydevices.com/blogs/omnivision-ov5642-camera-driver-for-linux That's good news, but it's very likely that it's not in the Beagleboard kernel yet. Looks like the XM is using 2.6.35 at present. – pingswept Dec 28 '10 at 15:57
  • @Kevin: well, I made some tests and the highest frequency I got for flipping a bit was about 4 MHz in a simple loop. If you put some logic then it goest to 1 MHz. That would mean that a QVGA frame would take 320x200/1M = 64ms. That'd give you a maximum frame rate of 15 fps, if you can use the processor time exclusively for it. – fceconel Dec 28 '10 at 16:16
  • @Kevin #2: I should mention also that the tests I did were in C, and when I examined the generated assembly code I saw that it could be made a lot more efficient if written directly in assembly (for that particular case). I didn't try it, though, but maybe there's some hope to have better results. – fceconel Dec 28 '10 at 16:18
  • Did you try on the BB or the BBXM?, you see that BBXM has a dedicated camera interface port so it should have good throughput, shouldn't it? Also another point to note is Leopard imaging makes camera modules for the BBXM and these modules are upto 5MP in res, they also must have built the drivers for these, so I guess they might have got it working but I'm not sure what frame rate they support. – Kevin Boyd Dec 29 '10 at 04:39
  • @Kevin, mine is BB Rev C3. Indeed, if you have a dedicated port you could get rid of those limitations. The only thing is to check if the OV5642 you're using has a compatible interface. I suggested that approach not as a final one, but as a first try to test the device. – fceconel Dec 29 '10 at 13:21
  • @fceconel: How can the BB's processor that runs at 1000Mhz give you a maximum bit flipping speed of 4Mhz? Isn't that ironic? Is it because of the OS? – Kevin Boyd Dec 29 '10 at 18:27
  • I don't think the OS is to blame very much; although the fact that it's multitasking and so there's some overhead involved, probably it's not really significant. I'd guess it's part the overhead in the generated code and part the maximum speed at which GPIO can operate. Also keep in mind that 1000 MHz (or, in my case, 600 MHz) is the processor internal clock only; That is made available inside the processor through a PLL that multiplies an external clock of 30 MHz. – fceconel Dec 29 '10 at 20:04
  • One thing I forgot to mention: I did the tests in user mode, so maybe the OS has indeed something to do with the performance penalty; a test in kernel mode would be helpful. I'm dealing with another task now, but I'll revisit these issues later. I'll post the results when I get them. – fceconel Dec 29 '10 at 22:43