On Thu, 19 Feb 2015 09:28:55 -0800 (PST), you wrote: >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. >
The latter method is the one that I normally use in embedded programming, The hardware is complicated enough that using a simulator is unpleasant at best. I generally have the hardware before the software and just hang equipment off the hardware if it needs it. > >> 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. I noticed that 4.2.2 doesn't even make the windows USB enumerator beep... the 4.4.4 image I've tried, but several things seem not to work, i.e. android comes up and says (remembering here: core services not running and wallpaper not running). The mouse pointer seems to be quite lagged, but I'm sending the HDMI output directly onto a monitor right now. >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. That was an option. I tried going back to code composer (5 or 6 doesn't matter) and found that the example programs/projects seem not to be complete (need additional modules) and the paths are wrong. Right now, I'm fighting CCS to get it to recognize the debugger on the BBB. Tried eclipse, but cross compiling is not all that well documented. I suspect that (since all the "just go do this" kind of instructions are written for linux, then that may be what I have to use. Apparently nobody does android development on a windows platform the way that you do with embedded processing. XMEGA/AVR development is simple by comparison. Write code, download to hardware, run code. >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. OK, got the basic concept. I'd picked a multiplex scheme to run the LCD display, and hopefully the right pins on the cape to make it all work. I'll have to see what I can do to relax the restrictions once I get that far. Thanks for that information. > >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 I think I used that, and I'm not sure that it worked. but I'll keep trying on that one. > >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. Apparently with android studio, I don't need QT, since the drag and drop GUI is built in, one of the attractive features of android (also that I can run the application on a number of other things I have). > > >> 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). I eventually came to just that conclusion.... > > >> 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. I'll look into that again. > > >> 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. > Right now, Android is more attractive for the overall system, but linux seems to be needed to do the hardware stuff unless I can make use of something like "i2C tools" (trying to remember the name). Then I need to use JNI to get the java to recognize it. Thanks, good advice and I'll go back and see what I can do. May just end up using that Linux laptop I converted over, likely to be the best way of doing things. What compiler setup do you use for the Linux development? It seems that Android Studio is the hands down best choice for the development of the java code... Harvey >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.
