Beginning Operations on BBB, Android or Linux? Debugging and building Graphics applications

GoogleGroups
1

Note: the tags are a trifle misleading, but the best I can do.

I’ve got a BBB, Rev C. I’ve considerable experience in programming embedded C on an XMEGA under FreeRTOS, so programming is not necessarily a problem.

However, I’m going back and forth about how to start (and this includes the basic environment) for the BBB.

The ultimate application would be instrument monitoring screens for custom I2C instruments (oscilloscope and logic analyzers), displayed on an LCD display with a resistive touchscreen. The BBB has more RAM and can run programs out of RAM memory (does not have a Harvard architecture).

I’m using windows 8.1, not Linux, although I do have a laptop running Ubuntu 14 which I could use if needed.

I’ve considered bonescript and javascript, but at first glance, it may not be complex enough or capable enough to write drivers for I2C. I’m also not sure about the graphics aspect, since a logic analyzer would need considerable graphics support (as does a scope). The advantage of these seems to be that they are well supported.

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.

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.

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.

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…
  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)
  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.
  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.

These are a lot of questions, but I’m looking for a decent place (and direction) to start. And no, the TI “blink the LED” application does not work (won’t compile due to path problems, even with a default installation).

Thanks for any help.

Harvey

2

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: Koush

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.

  1. 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).

  1. 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.

  1. 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

3

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: Koush

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

4

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.

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.

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. 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. 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.

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.

5

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