This is a spinoff from a thread regarding Interfacing the MCU with an Android Smartphone. Hopefully it will help those interested in programming in the Android environment using Java. Here is a sample screenshot and pic of a tempsensor/blink_led adaptation...

It's possible to write all the Android programs and resources (icons/images/string etc) in a text editor and compile them on the command line, but if you are just starting out, the Eclipse IDE program is a huge help. You can get all the downloads and instructions from Google's Android Download Site. You'll need a Java Development Kit and Runtime Environment to go along with it (links are on the same page and are bundled together), and it might be safer to use Java 6 until they get the security flaws ironed out with Java 7. I've installed it on Windows and Ubuntu and it worked fine (however I couldn't get the emulator to work in Ubuntu).

Once you have things set-up, it would be beneficial to go through the My First App exercise to get familiar with things. The developer site is packed with tons of info since Google wants people to write as many apps as possible as easy as possible.

Of particular interest to this subject is the Connectivity section. The first item on the page deals with Bluetooth and if you follow the guide down to a section called "Managing a Connection" you will find a link to a "Bluetooth Chat" sample project. This can be brought into Eclipse and compiled without any code adjustment as long as all the files are in the correct folders. I only needed to modify the main source code file and the resource files to create a custom app, including the NK icon!

PCBolt,

Can your Bluetooth devices connect in an "ad-hoc"/"connectionless" manner?

Normally, for Bluetooth, it is essentially a Master/slave type arrangement. The Master, your Android Device, and the slave has been "recognized" by each other. Normally the Master can "recognize" more devices than the slave can. (I am probably using the "wrong terms" as far as Bluetooth is concerned but I think that makes sense anyway?)

So using the Bluetooth adapters that you are using would it be possible for these transceivers to recognize each other? So that you could communicate multiple AVR's to multiple other AVR's whenever they are near each other? (For instance multiple AVR robots that wonder around and when they wonder near each other recognize each other's Bluetooth signal and can chat for awhile...)

What fun, custom apps on my phone! I'll get started on it tomorrow and thanks for sharing with us Pcbolt.

Jim -

That is a very good question. From what I've been able to find, once the module is set to Master mode, theoretically it will automatically pair with a Slave that shares it's passkey value if it is within range. There would be a problem if 3 "robots" were wandering around since at least 2 would have to share the same configuration (2 slaves/1 master or 2 masters/1 slave) and I don't think 2 masters can talk to one another and 2 slaves cannot for certain. However, the MCU can change the configuration "on-the-fly" through AT commands so that could make for some interesting programming (i.e change from master to slave at will or even change passkeys). I have yet to experiment with this but it sounds like a worthy challenge. If you'd like to explore further, the actual chip is the BC417 and there are a bunch of datasheets out there.

You're right about the Smartphone configuration, except it falls back to terms like server/client instead of master/slave. It sets up the equivalent of a server socket and listens for incoming connections. Once it has a connection, it ends the server socket connection and sets up a dedicated socket for read/writes. Before any of that happens, the pairing process has already been taken care of.

Noter -

It is fun.

The more I research I did, the more I realized how powerful those devices really are. What's really amazing is that you can use other apps to do your dirty work for you, so you don't have to program your own browser, map viewer, phone dialer, voice controller, query bluetooth connections, etc. Pretty cool stuff.

I have to admit though, I've kind of gotten used to "flipping every bit" in C, so Java with it's relatively high level of abstraction takes a little getting used to again. (I'm just a hobbyist so maybe it's easier if you do programming for a living.)

I can tell from your post you're enthusiastic about getting started and believe me it well worth the effort involved. I have a lot more research/testing to do but I'm still thinking in terms of incorporating the embedded MCU's into the process.

Looking forward to seeing how far you can "move the football"...

Made some progress today. I have the Bluetooth Chat demo compiled and installed on my phone but every time I run it, it crashes after a few seconds with no hint of the problem. Just a dialog box that says "Unfortunately, Bluetooth Chat has stopped".

Noter -

Wow that was fast. I didn't have a problem the first time I compiled and loaded the program but I certainly did when I started modifying it. Got the "Stopped..." message a number of times and got frustrated by the lack of indicators as to failure. Then I noticed the source code had a bunch of lines of debug code inserted and found the "Logcat" window in Eclipse. There is a tab between the main code window and the bottom window that activates the function (or under WINDOW>SHOW VIEW/LOGCAT from the top menu) . It will show most of the stages in the life cycle (ON CREATE/ON RESUME/ON START etc). Even better is it will spit out a stack trace on errors and you may be able to home in on the culprit. You need to have the phone hooked up to PC via the USB cable to access the messages.

Got past the crashing problem but it is slow going to talk to the adapter on the nerdkit. Finally realized the phone is the client and the adapter on the nerdkit is the server so I expect better progress now. Will probably be a while before I have anything to show.

And thanks for the tip on LOGCAT. Once I figured out how to view it on linux I could see the messages. No doubt it will be very useful going forward.

Whew! Android definitely has the steepest learning curve I've been up against in quite a while. I'm still coding on the bluetooth demo and it will probably be another week before I have a somewhat complete working version. I also have decided to remove all the text command interface in cmddemo.c and replace it with a JSON stream for communicating with the android app and that adds at least a few more days to the task. Below is a screen shot of the program. It has a config tab for selecting and connecting to a bluetooth device, a simple text log of the JSON data for debugging, and a control screen for interacting with the avr. Heck, it took days just to get the tabs formatted and working but it's all getting easier now.

Very nice!

In my rush to get a working app, I violated many of the User Interface guidelines. Looks like you're on the right track. I think you'll find all the time spent formatting and learning where everything goes (strings, xml, layouts etc.) will be well worth it. The icon tabs look really slick. Curious why you went with JSON for communication. I'm guessing it has something to do with the built in parser/stream classes. I just used text but had to use custom start/end of message tags to separate messages, but I guess when you think about it, that's what JSON is doing to some degree.

My main consideration in favor of JSON is that it's a lightweight protocol and will require less resource on the AVR. Built in lib's on Android are a plus and I've found an open source lib for the AVR too so implementation should be relatively painless. Ha - famous last words!

Now I've got this idea that the screen widgets should be specified/built from the AVR via JSON which will make the android app a general purpose tool for any project. Anything that can do JSON could have a custom interface on an android phone or tablet. Also probably need expand beyond bluetooth and add the network and usb for the greatest flexibility and usage. The more I think about it the more I realize this project is really just beginning.

I think I understand, and if I do it is a very interesting idea. If an AVR program on a chip needs a button, it just creates one. If it needs a text view (instead of an LCD screen) it just creates that too.

I was thinking of making an Anroid interface for a RTC chip. By your method I'd just ask your Android app for a time/date picker. Question is how to get the user data back to the AVR program...some custom, pre-written code would have to be written specifically for that project. Maybe use "intents"? Again...very interesting.

Yep, that's the idea. At least as far as I have thought it through. I haven't looked at the android date/time formatting but I think it's just a filter on a regular editText widget so it won't be any harder to implement than any other widget.

As for the programming, the widgets have to be created in java on demand when the appropriate JSON transaction comes in. Then android events have to be captured and formatted into another JSON transaction and sent back to the AVR. All that will be done in the intent that manages the AVR tab. So far there are 5 intents - the main tabhost, each individual tab, and the bluetooth service.

I've got the java code that creates common widgets working so now I'm ready to strip cmdDemo to add the JSON code and start sending transactions back and forth as I work on event capture and processing in the app. The editText box has taken the most work because setEms() doesn't work right so to get around it I had to measure the width of the letter 'M' rendered then multiply by the string length and set the box width in pixels. Stuff like that always takes a bunch more time than planned.

The more I thought about it, the more I realized the date/time pickers really have only one function anyway (to return time/date picked) so there would be no reason to write custom code for each project. Same with buttons, just event recorders.

The really cool part of the idea is having a "Nerdkit App" or "AVR App" that does just about every user interaction needed instead of a single app for each project. I'm sure the folks over at "Hack-A-Day" would be impressed enough to feature it on their site.

Can't wait to see the next stage.

I'm still working on this and getting closer to having a demo. Got sidetracked into the NDK for a week and that's another ton of stuff. That's the thing about windows programming no matter the platform there's always a lot to learn. Below is my app screen so far. What is there is working and even though it doesn't look like much there is a lot going on behind the pixels. Next I'll add radio buttons under the LED Color title to pick color for a new RGB LED and then make a little uTube video to show it in action. Probably have it early next week.

Looking really good so far. I'm definitely interested in seeing the video and some of the AVR code.

I stayed away from the NDK after reading the warning about not using if you only wanted to program in another language. I'm not very comfortable with Java (seems convoluted for some reason) and would rather use C or C++, but decided to stick with the recommendation.

Again, I think your app would be a huge hit with the AVR Freaks and Hack-A-Day crowd. Great stuff!

Had some interruptions but haven't given up, still trudging along. Working on the video and learning all about Kdenlive on linux. Fortunately I don't really have to worry about meeting a schedule so no more predictions. :-)

Noter, did you end up getting the app done?