On 3/27/2012 9:37 PM, Jon Elson wrote: > Kent A. Reed wrote: >> Oops, I hit send too soon. >> >> Final question--- >> >> Are you compiling code natively on the BeagleBoard or cross-compiling on >> a desktop machine? If cross-compiling, what tool chain are you using? >> > Right now, I'm doing all development and testing on PCs. But, for a > deployed > application using the Beagle, I did the development ON the Beagle, and it > works fine. It may be marginally slower than an average PC, but not bad at > all! This app has a couple page C program that creates a TCP server and > then controls a signal multiplexer board using some GPIO pins. I think > compiling and linking this code takes a couple seconds, tops.
When I was working with the more limited resources of the Insignia Infocast, I had to cross compile to keep from going crazy. I tried and eventually got several different approaches to work, including building my toolchain from scratch, using CodeSorcery, using Scratchbox2, and using OpenEmbedded/BitBake. (Thank the gods for virtual hosts. I could create each environment without fear of polluting the others. I know it's possible to create more than one on one system, I just don't trust myself to be careful and not do something stupid.) I managed to get each to work on a test problem but none of them ever felt like the "one true" way. I'm always looking to see what others do. I agree with you that the BeagleBoards are beefy enough for lots of development work. I just like the extra elbow room in a PC-based Linux environment. > I would think for this new app, I can just copy most of the files over from > the PC (xxx.glade, xxx.py, xxx.c, etc.) and then just insert the OMAP > GPIO-specific code before compiling there. This kernel is probably a > bit dated now, but since I have made this GPIO mapping stuff work, I > am loath to replace it without a good reason. Once the app is compiled, > it becomes a single-purpose board used in a private network, so I'm > not real concerned with having everything up to date. I wouldn't get my knickers in a knot over the kernel version if the software is currently talking to the OMAP hardware. It's hard enough to discern what new features come with each kernel release, even harder to figure out what's been done for alternative architectures like ARM. Let someone else be the front runner. Case in point, when I commented on the ArchLinuxARM forum about my problem with the uSD card and noted that the problem went away with other distributions, I was entreated to work on the ArchLinux kernel drivers(!). I pointed out I was only an application hacker not a masochist and switched to a working distribution. > <...> > > Jon > Regarding your earlier response about Tk/Tcl > Constructing complex GUIs in Tk/Tcl is a > horrible > exercise, and each GUI page often runs to thousands of lines of Tcl > code, with all > sorts of annoying problems. "Amen!" That's why I left it to my guy who reveled in tweaking those thousands of lines of code. I haven't written a GUI based on Glade but my read of the tutorial mentioned by Dave tells me that's the way to go. Regards, Kent ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
