On Tuesday, February 17, 2015 at 6:29:45 PM UTC-5, [email protected] wrote: > > > I've considered the Debian Linux image as shipped. Programming in C or > C++ is not a problem, and it looks as if it works well at accessing the I2C > devices. However, I've tried TI's Code Composer Studio, and find that the > examples don't compile properly because the paths are not valid in windows > 8.1 (apparently, lots of "file not found, fatal error", for the includes. > With multiple platforms and processors, CCS is not that friendly. Nor is > using Android on CCS. Not sure what graphics tools are available for > making a GUI program. >
While everyone has their own method of development, I have had very good luck with developing C/C++ under a Linux VM on my desktop and natively on the BBB itself. I'll get a code framework up and running on my Linux VM and then move the codebase over to the BBB to fine-tune it and add in the hardware interfacing bits as needed. Some folks prefer to use a complete cross-compile environment on the desktop and then push the final binaries/libraries over to the BBB. > Android Image. I have the circuitco image, which boots, but does not > connect to the laptop over USB. I can (probably) work thorugh the JNI > aspect if I need that to get to the I2C drivers working, but haven't yet. > Since Java has a built in GUI creator (drag and drop, I'm familiar with > Lazarus Pascal, Delphi, and Visual studio, although I don't like visual > studio at all), that solves the GUI problems. Using Android studio, latest > version. > That is the 4.2.2 JellyBean image, correct? The newer 4.4.4 KitKat image has ADB over USB support in it by default. For hardware interfacing, I develop the C interfacing code natively under Linux on the BBB to test communication with the hardware. Once it looks good, I move that code over to a platform with the NDK and build it as shared library for JNI use with an app. Include the built library into your app and use JNI to make the native calls. Keep in mind that you still need to properly mux the pins (via dynamic device tree overlays or static modifications to the base kernel device tree), and the hardware that you are talking to (usually via files in the /dev filesystem) must be accessible from your app. Android locks down those permissions, so to make a device available at the app level without changing the Android HAL requires relaxing the device's permissions so that pretty much anyone can access it. However, under android, even setting Developer options/usb debugging does > not even produce an undefined device on the direct USB cable connection to > the PC (windows 8.1). Trying to edit the android usb configuration .ini > file (instructions at TI's android development platform) produces a file > that windows says has been tampered with, and refuses to install. The > basic driver file (before modification) installs just fine. > BBBAndroid reports the BBB as a Google Nexus S (18D1:4E23). If you don't have an ADB driver for this device already, it is included in the Universal ADB Driver: http://www.koushikdutta.com/post/universal-adb-driver SO: Questions abound: > 1) which application framework would be best to do what I need to do. No > problem doing Java if needed, no problem with C, C++ if needed... > Check into Qt under Linux or Android. > 2) Is there a specific problem with windows 8.1 and debugging (and > changing .ini files) that I don't know the solution to (hopefully.... yes) > No ADB support in that 4.2.2 image. Switch to the 4.4.4 KitKat image (API 19). > 3) which platform is best at hardware access. I need to be able to > read/write I2C with binary strings to be able to communicate to the > hardware and boards. Those are already designed, so the protocol won't > change, and I2C specifies only the first one or two bytes anyway. > I think Linux is the easiest for developing this sort of thing. > 4) I've read tons of web pages, and right now, I'd like to avoid Linux if > possible, but if necessary, then I guess I need to. Right now I'm trying > to make it all work under windows 8.1 just to keep the development on the > same system. > I think you should develop your hardware-interfacing bits under Linux and then decide which platform (Linux or Android) works best for your needs. Andrew -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
