On Fri, 20 Feb 2015 05:52:41 -0800 (PST), you wrote: >On Thursday, February 19, 2015 at 5:02:45 PM UTC-5, Harvey White wrote: > > >> 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. > > >Android uses OpenGL ES for its rendering, but the binary blob driver for >the SGX GPU core on the BBB isn't supported under the 3.8 kernel. This >means all of the rendering to textures and then scaling the textures is >done in software. The larger the screen resolution that you use, the more >sluggish the system will act. The TILCDC driver in the kernel will >initialize the framebuffer resolution at the highest resolution supported >by your display. Your HDMI/DVI display will report an EDID block to the >kernel driver via your HDMI cable, and the EDID block contains a list of >all modes the display supports. If your display doesn't report EDID >information or your cable/converter blocks the EDID block, the resolution >will default to 1024x768. You can edit the uEnv.txt file in the boot >partition of the microSD card to add a "video=" kernel command line option >to limit the size of the resolution. For example, "video=720x480@16" will >limit you to 720x480, which will give you performance that is far more >snappy than the performance at the higher 720/1080 resolutions.
OK, got that. The eventual target display I will have is either 640x480 or 800x600. If I can get the cape working for the VGA (which I have), then I'll invest the 30 dollars to get the 800x600 display (or perhaps two or three...), then make an adaptor that goes from cape to display, and that will handle that. Will wait for additional hardware support as time goes on from the kernel. > >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). >> > >Sorry about that. I meant use Qt as the widget framework under Linux or >just use Android (as in, the Android API framework and GUI). You would not >use Qt under Android. Yep, no problem. Just wondering if there was some sort of advantage, and there isn't. > >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... > > >I use a GCC toolchain natively on the BBB itself, Android SDK via Eclipse >on the desktop, and the Android NDK for the native bits. So this says that you bypass CCS completely. Not a bad idea, all things considered (at this point). The BBB is powerful enough to use as a development environment. That also says that you either change OS on the BBB a lot, or have more than one, or just boot from the SD card for android (or vice versa). >For hardware >interfacing, I write a small C program under Linux on the BBB to actually >perform ioctl() calls, flip bits in mmap()'s registers, etc. Basically, >all of the stuff that must happen on the actual hardware. Familiar with that, tried to write simulators for processors once, got the instruction set working fine, started to have complexity problems with handling the I/O variations. I generally design the hardware first, then build the software, then redesign the hardware, build it, and then debug. The hardware I use can be somewhat complex (FPGAs and graphics subsystems), and does not lend itself to simulation. >Once that works >well, I make a clean interface to those functions and build it as a library >on the BBB under Linux and make sure everything is OK. That code is then >moved over to my Windows system and built using the NDK. It is usually >little more than a file or two, so the Android.mk for it is trivial to set >up. I add the NDK-generated library into my project inside of Eclipse and >then add in the appropriate JNI calls to access the native code. OK, got that procedure, it is similar to what I was thinking would be needed, but I'll need to consider all the little details as I do it. No problem, this gives me a direction to go to. > >For straight Linux development, it is GCC on the BBB and GCC in a Linux VM >on my desktop. I do much of the development on my desktop and then move >the code to the BBB to shake out the x86/ARM 32/64 bit assumptions and get >it working well on the BBB. Then, I move it back to the desktop and see >what I broke. Do this a few times and you are in good shape. #ifdef's >will assist you in isolating the platform specific stuff so that you can >have code that will build and run on both platforms. I try to stick with >the integer datatypes specified in <stdint.h> to explicitly specify data >type sizes. Good idea on the standard integer types. I'm very familiar with reconfiguring projects using #ifdef, so that's not a problem at all. Not likely to do straight linux development right now, since I'm going to focus on getting the applications up and running first. Thanks again, Harvey -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
