open source *ware ideas!

Category Archives: Arduino Mega ADK

Hi boyz and girlz (with the “worm” of embedded development inside! 🙂 ).

This time I would like to talk about a new topic (following an input from SirsLab of University of Siena), tied to the connection via USB between Android phones (or tablets) and Arduino.

The goal is to cerate a master-slave channel on the USB in order to control an Arduino from a Android app. A possible logo for this “experiment” could be the following:

Mhhh…Android hides behind an Arduino. What a strange idea (and what a strange logo—>produced by ML)! 😀

Ok, I say clearly that I don’t like to use an Android phone as Arduino controller, since in my honest opinion writing an Android app in order to use the USB in master mode is not so simple and immediate. I prefer to use a linux single board computer (such as Raspberry PI) to control Arduino, as you can see in my previous post(s): here and here.

But the argument is very exciting and …”I was born ready” (cit. Jack Burton of “Big trouble in Chinatown” movie)! 😉

This is the “hand-made schema” of the complete system at the end of this post (click to view the zoomed image):

In order to verify the USB host capability of the Arduino I connected a USB memory stick to the USB host port, then I downloaded the USB Host Shield 2.0 library and I inserted it in the libraries folder of Arduino IDE.

IMPORTANT ACTION: I opened the library file settings.h and I modified the following line (note that the default for the define is =0, meaning that you are using the USB host shield instead Arduino Mega ADK):

#define USE_UHS_MEGA_ADK 1

This step is fundamental (if using Arduino IDE 1.0.5) because otherwise all sketches using USB Host library will give the error “OSC DID NOT START” at runtime, since the function Usb.Init() will return a -1.

Once saved the modified file, I opened the library example script called USB_desc, and after the succesful compilation and download on the Arduino ADK, I opened the Arduino serial shell at 115200 bps.

This is the hard truth: not all Android devices can enable the “Accessory Mode”, the necessary capability to talk with “accessories” (in our case the Arduino Mega ADK) via the ADK protocol. In these cases only the ADB protocol could be used… but this is another story! 😉

Note that the Accessory Mode is a capability depending on the Android version installed on your phone. 😦

For example, my old Samsung Galaxy S (GT-I9000) has a too old Android version installed, so, in order to enable the Accessory Mode, I flashed on it the latest version of Cyanogen Mod.

And, at the same time, I had no problem using a Samsung Galaxy Tab 2 with his original firmware….since the Android version is newer and it supports Accessory Mode.

IMPORTANT ACTION: In order to enter automatically in Accessory Mode (if supported by the Android version), the mandatory step is to enable the “USB Debug mode” on the phone.

I opened and compiled the ArduinoBlinkLed sketch from the ADK examples provided in the USB Host Library.

I powered ON the Arduino and I opened the Arduino shell (…and the encourageant sentence “Android accessory started” appeared ;-)).

Then I connected the Android device to the Arduino host USB. After a moment, the screen of the device reported “Accessory Mode entered” and after this a message appeared on the device requesting to download from internet the Android app associated to the sketch.

Anyway, starting the downloaded/installed app, a great button appeared on the device screen. And the result of this big effort activity is a little poor, but at the same time it’s very nice: clicking the software button, the Arduino LED 13 (the onboard led) turns ON/OFF!!! Yeahhhhhhhh! 🙂

Conclusions

The code on the Arduino side is (as always) very very very simple. The code on the Andoid side (the app), in order to manage the ADK protocol, in my opinion can be very difficult to be implemented, because it contains some strange instruction and construct.

In which mode I discovered it? Well… studying and compiling in the Android IDE an application similar to the “closed source” one used for my experiment. I found it in the ADK examples from Google Code or around Internet (it is called SkeletonApp) : you can download it from this link. Obviously you should compile this code in the Android IDE Eclipse in order to produce the app (i.e. the .apk file to install on your Android device).

Note that you could modify the ArduinoBlinkLed script in order to download/install from internet your own app modifying the following code:

This is the post of the “real dark side” of porting external hardware control from Arduino to Intel Galileo. And, it’s just an example, a little sketch of the real work.

…Are you ready? Before starting this dangerous “trip” I want you send a first warning: unfortunately the x86 (the architecture of Intel Quark, the CPU inside the Intel Galileo) is very different from the architecture of the AVR (the Arduino MCU). So, registers, memory spaces etc. are completely different (Monty Python docet!).

My (insane, very insane 🙂 ) idea was to port some “lower level” code from Arduino Mega to Intel Galileo, in order to verify on my skin the real hardware differences between the two platforms and also in order to compare the “hardware level” performances.

What a cool find! 😉 I love the shifting dysplays in the chinese stuff stores! 😀

So… I googled for already working driver on Arduino for these devices. I found some very interesting solution. The first one library is here, and it is very powerful and fast in my little opinion.

I tried on the Arduino Mega all the library demo sketches and I verified the correct work for my two displays. Looking inside the code I saw that all the library is based on AVR registers programming (using in every instruction all the possible bit-field functions, bit masks, bitwise operators and so on…).

Weahhhh…ok, I know this is the correct mode to write a driver, and it’s true that I wanted to go to a “lower level”…. but not so low! 😀

Indeed, once ported the code inside the Intel Galileo IDE, a so high number of “undefined references” gave me the real proof that NOT ALL the AVR architecture has been ported by the Intel team in the Galileo development environment…. so we have two natural choices: the first one is to rewrite all the library using the Quark registers instead the AVR registers (but we are inside a Linux environment, it’s no so simple to manipulate the low level hardware without interact with the Linux kernel) or, the second choice is try to write a library at an higher level, using only the basic functionalities (so using the native APIs) of Arduino.

I preferred the second oprion (…you suspected it, I know! :-)), so I started looking for a little simpler (and without too many functionalities) library working directly on Arduino GPIOs, in order to simplify the porting phases (and possibly without losing my love in microelectronics 😉 )

I found the code and the circuit reported on Arduino Playground (I love this site…because it’s a made in Italy product. You know, we don’t have only corruption, not-so-effordable persons & politicants… and soccer 😉 )….and -oh, oh- it was exactly what I was looking for. 😀

I took all the code and, after I removed the parts (code and hardware) related to the real time clock (because actually I don’t have a RTC!), I compiled the code in the Arduino IDE and I flashed it on my Arduino Mega. I obtained a “fixed hours and day” red and green clock on my two led displays. The draw of the displays is very fast (approx. immediate).

Ok, I ported the same code in the Galileo IDE and I obtained some compilation errors, tied to the hardware differences between Arduino and Galileo. This is the pinout for display I used:

Mainly Galileo IDE doesn’t have the <avr/pgmspace.h>… it’s natural since it’s a x86 CPU…but it is also a problem, because the great majority of third party lins use this file and its definitions (especially to declare some variable directly in the program flash, since Arduino doesn’t have so much RAM).

But since Galileo has a lot of RAM, it isn’t necessary to save data in the flash program space.

So, following the defines reported in avr/pgmspace.h , I changed in the file font1.h definitions:

PGM_P CHL[] PROGMEM= [...]

in a simple

char* CHL[] = [...] .

After this, I removed the #include <avr/pgmspace.h> in the main .ino file, and in the same file (function set_buffer()) I changed the line :

memcpy_P(buffer[j], (PGM_P)pgm_read_word(&(CHL[j+pos])), 8);

in

memcpy(buffer[j], (const char *)(&(CHL[j+pos])), 8);

Once resolved the errors, I compiled and flashed the code on Galileo.

I obtained a strange behavior: instead of the clock some strange character appeared on the two displays, with a very very (very! 😦 ) slow draw rate.

Ok, I think the strange characters are tied on a non perfect alignment on the memory in the x86 respect to the AVR or to different sizes of some data type, especially due to the above memcpy porting (but I didn’t investigated so much because I was worried by the displays slow draw rate). So, I changed the initial code in order to write a text on display pixel by pixel (note that this is the same approach of the original code), starting from drawing a single pixel in a certain (x,y) coordinate.

Ok, using this code the text is shown in the correct way on Intel Galileo (….to be investigated the strange drawing with the original code! 😉 ), but using Galileo the draw process took approx. 20 seconds (versus the Arduino result, which is minor than 1 second!!!) and with some different delay times between one pixel draw and the subsequent.

This is the final result (sorry for the up-down text, but I have very short wires between Galileo and the display…;-) ). In the background of the photo you can see two beautiful italian progressive rock cds by Maurizio di Tollo and by La Maschera di Cera (both my good friends), which have been the inspiration for my porting work. 🙂

Any ideas for this behavior (the slow drawing process)? I have one…but I don’t know if it is the correct idea.

As you know, Intel Galileo runs the Arduino sketches as Linux user processes (so, all kernel calls, interrupts, threads etc. have a higher priority than a user process and so they can interrupt the execution of the Arduino skecth), whereas in Arduino no operating system is used (the sketch is a well-known “bare metal” code), so a real time behavior is a “true real time” behavior, and the sketch runs at the highest speed without interruptions.

So… what can I say? Intel Galileo is a really fast machine (compared to Arduino Mega or UNO) but in my little opinion it has some little “real time” problem when using the Arduino IOs (also I know my code is not optimized at all!!! 😉 ). And you? What do you think? 😉

As promised in my last post, this time we start to talk about the porting procedures (and issues) from Arduino UNO/Mega ADK to Intel Galileo.

One can think the porting is painless (since Intel Galileo is born from a “collaboration” between Intel and Arduino guys), but unfortunately the truth is different. My experience tell me that’s the naked reality behind the embedded world…but this is a sad

Ok, the first thing you will notice porting a sketch from Arduino IDE to Galileo IDE is that NOT ALL Arduino libraries have been ported correctly in the Galileo environment (do you remember my old post? The String class is one of these examples…), so you could encounter a great number of “undeclared” variable or function errors. Someone told me that also TFT library doesn’t work correctly in Galileo….I’m a little sad…. 😦

But today we talk about some “working” library, in order to gain some succesful result before the “real battles”! 😉

For example, the I2C library seems to work in the same way in Arduino environment and in the Galileo environment. The I2C is a serial communication protocol used to connect Arduino (and in general all processors) with external devices.

An exampre of therse devices are EEPROMs of 24cXX series. I used these EEPROMs for maaaaaaany years, because simply they use the I2C protocol, so they are serial (=slower, I know it)….but they use few wires to be commanded. And it isn’t a little thing when using Arduino UNO! 🙂

…The parallel EEPROMs such as 28cXX are much faster but they use too much electrical links (and Arduino UNO doesn’t have so many GPIOs!).

Then I designed a little circuit (with Fritzing) in order to use one 24c64 (64kbytes) EEPROM and one 24c256 (256 kbytes). This is the circuit (please…use Intel Galileo instead Arduino UNO, with a pin-to-pin correspondance, and all should be work correctly! 😉 ):

Then I wrote a very simple “dummy” sketch in order to execute some basic operation on the EEPROMs.

Well, once the code will be downloaded on the Galileo, open the IDE serial monitor and use the following commands in order to read/write the EEPROMs:

<1+Enter> will write a fixed pattern (somedata256[]) on the 24c256

<2+Enter> will write a pattern (somedata64[])on the 24c64

<0+Enter> will erase both EEPROMs

<3+Enter> will read content from the 24c256 and write it on the serial monitor

<4+Enter> will read content from the 24c64 and write it on the serial monitor

You can see the behavior of the code and the access times looking at the ON/OFF status of the two leds present in the circuit . I know this project is a toy-example…but it can be a good simple step to start using I2C interface (and Arduino I2C library) on Intel Galileo.

Ok. This time we joked dear guys ;-), because in the next episode… we will encounter the real “dark side” of the porting from Arduino to Galileo. Cross your fingers, drink a beer and ….relax!

…Bye bye!

Advertisements

This blog uses cookies in order to improve your navigation experience. Visiting the blog you accept their use. Click on Exit if you don't accept it.
INFORMATION (Italian)ESCI