Related
Hi, I'm a student of IT. My final project is on remote monitoring of patients. One of the features is the detection of falls and I have to use two types of accelerometers (Witilt and WiiMote).
Market applications that use the Wiimote does not work in our i9000.
And my question is: Is it possible with the standard ROM to perform a program that connects to the Wiimote?
If so could someone guide me a little about how to start, or put some link where I can see the starting point for this part of my project?
If it is not possible, would appreciate an explanation of why this happens.
Thanks in advance
Nobody can help me? =)
Can't you just use the accelerometer and orientation sensors built into the phone? If you have to use the external hardware in conjunction with the phone I would say use an Arduino, which has a lot of Wiimote and Wiichuck interface code available, with a Bluetooth module to talk to the phone; look at the Amarino project for interface code.
Alternatively the wiimote IME developer had the problem with the SGS and HTC because they were using a native library as most phones didn't have Bluetooth HID support, and the Bluetooth native library didn't behave the same way on all phones. Because the SGS with Froyo has Bluetooth HID support you may be able to interface with the Wiimote at a higher level and avoid the native libraries, if you take care of its quirky pairing behavior, but you will have to do more work with the Wiimote low-level protocol, which is quite well documented.
I managed to snag an Android Accessory Development Kit from Google IO.
After wrangling all the necessary code bits together I got the demo code running on the Arduino board and my Nexus One.
The first picture you can see the phone reading the sensors of the demo shield, button states, the temperature, a light sensor and the joystick position.
In the second picture the phone is controlling the led colors and has one relay turned on.
In the last picture you can see that the phone detects the board being plugged in, Android knows there is no app installed for the board and it cannot be found in market.
The Nexus One is running a rooted 2.3.4 ROM from this thread
P.S. Mod's can we get a forum section for Android Accessory Development?
Now for Pics.
Now that is bad a**!!! I was waiting for something like this!!
Hey, I've been attempting to hack in the support into CM7 (nightly, 2.3.4) on my EVO without much success. I've rebuilt the kernel with the necessary flag enabled and ripped the JAR/XML files from the Nexus S update.
I've monitored logcat and seen that it does find the framework JAR (the application wouldn't install otherwise since it's a needed feature) and a dmesg scan shows that the kernel driver is being initialized.
What's happening now is I plug in the ADK and the output from the Arduino board spams that it couldn't get a protocol version from the phone. The phone slows down to a crawl as its probably being spammed with requests from the ADK for a protocol version and doesn't know what to do.
I'm at a loss here as to what I could possibly be missing. If you have any insight through your own endeavors it would be much appreciated.
Great stuff! I was also at Google I/O and picked up an ADK. Can you post the apk file of your app? I'd love to try it out.
And if you're feeling generous...the code?
badass. good ****
Well done mate...
Have tried it out with arduino UNO?...
uh uh, why i wasn't at the Google I/O
Google is doing really good s**t nowadays. I suppose that Arduino will guest in my house in some time as I am fascinated
I am Actually using the ADK with my Nexus One on an Arduino UNO and an USB-Host Shield from Sparkfun, it works equal but only take a fraction to buy it
My first project is an interface for my Audi, at the moment i only use it to start the Motor, but in future i want to try to build a CAN-BUS interface...
Sure here is the compiled ADK.
-Nik
bharathp666 said:
Well done mate...
Have tried it out with arduino UNO?...
Click to expand...
Click to collapse
The Arduino UNO doesn't have native USB Host support onboard like the megas.
You will need a USB Host shield and will have to modify the Arduino code.
SoyoBro said:
Great stuff! I was also at Google I/O and picked up an ADK. Can you post the apk file of your app? I'd love to try it out.
And if you're feeling generous...the code?
Click to expand...
Click to collapse
You can find all the ADK instructions and code here.
Note: When you select your build target you must choose
Target Name - Vendor - Platform - API Level
"Google APIs" - "Google Inc." - "2.3.3" - "10"
Otherwise you will get errors trying to build on the new libs. The instructions on the ADK page wern't very clear about this. Took me awhile to figure that one out.
You will need to update your Android SDK if you don't see those options.
-Nik
As for the point of using an arduino uno, Oleg is providing an newer version of his USB lib, it now works with his shield and the ADK.
My car is almost starting with the ADK, i am only missing a few relays and stuff to get it completed but i posted a proof of concept on youtube. Text an explanation is all german, sorry for that
http://www.youtube.com/watch?v=FlvpMwSxgMg
if there are any questions Ill be here for you
Great stuff. I am really looking forward to this.
But what I don't get is which hard- and software is required:
- is 2.3.4 sufficient?
Answer: YES
- do other devices (running 2.3.4) than the Nexus 1/S work?
Answer: Pending
- will an Arduino Duemilanove board work?
Answer: NO
Thanks for your help, guys
Besides those questions I have one more:
- assuming I have a board that is connected to a power supply. will i be able to charge an Android device when connecting the board to the handset via USB?
Answer: depends on the boards and its power consumption/outlet. Basically, it should
Nikropht said:
P.S. Mod's can we get a forum section for Android Accessory Development?
Click to expand...
Click to collapse
+1 for a dedicated section.
I reckon it's gonna take off as soon as more USB host boards become available
My Arduino Duemilanove works perfectly
Hello XDA developers,
As you know, Atmel maXTouch touchscreen controllers are used in a large percentage of Android phones and tablets out there.
I wanted to let you know that the latest patches for the official Atmel maXTouch Linux driver are available on GitHub. This will allow you to get the latest up to date changes before they make it into the mainline kernel.
On GitHub, search for user "atmel-maxtouch"
Happy hacking
Best regards,
Sherif
Product Marketing Manager - Atmel
thank u for ur valuable information, well can u pls post what are the latest changes and updates. that will help the devs much more.
Hi showlyshah,
The latest updates include the following:
- Support for Atmel's mXT224E, mXT768E, and mXT540E chipsets
- Support for both protocol A and protocol B reporting
- Support for kernel 3.0 in addition to kernel 2.6.35
More details are available on GitHub in the release notes.
Regards,
Sherif
Is https://github.com/atmel-maxtouch the correct URL?
Unfortunately, if it is, the drivers in this repository are structured completely differently from the ones included in many vendor source drops, and unfortunately this causes great negative impact on their usefulness.
See, for example:
https://github.com/Entropy512/linux_kernel_sgh-i777/tree/master/drivers/input/touchscreen - This includes the mxt224 drivers as implemented by Samsung on their device (Galaxy S II)
https://github.com/atmel-maxtouch/linux/tree/master/drivers/input/touchscreen - mxt224_u1.c is completely missing, indicating that the driver here is incomplete or structured very differently from the one used by Samsung, making it very difficult to use. Also, the few files there that do pertain to Atmel MXT such as atmel_mxt_ts.c in there appear identical to the mainline Linux repo.
Entropy512 said:
Is https://github.com/atmel-maxtouch the correct URL?
Unfortunately, if it is, the drivers in this repository are structured completely differently from the ones included in many vendor source drops, and unfortunately this causes great negative impact on their usefulness.
Click to expand...
Click to collapse
But it's not Atmel who are to blame. Atmel are doing a great job working directly with upstream so that all the users of mainline linux can benefit. I have been using the drivers from the vanilla kernel for quite a while on both my tegra tablet (with chromium kernel) and galaxy s2, and they work just fine, supporting multitouch in xorg in ubuntu.
The problem is OEMs who do crap like hardcoding/hacking drivers instead of using platform data, use machine-specific hacks, custom interfaces and a lot of copy-paste. That's the essence of modern consumer electronics business - no one cares for quality, only about releasing early.
Entropy512 said:
Unfortunately, if it is, the drivers in this repository are structured completely differently from the ones included in many vendor source drops, and unfortunately this causes great negative impact on their usefulness.
See, for example:
linux_kernel_sgh-i777/tree/master/drivers/input/touchscreen - This includes the mxt224 drivers as implemented by Samsung on their device (Galaxy S II)
atmel-maxtouch/linux/tree/master/drivers/input/touchscreen - mxt224_u1.c is completely missing, indicating that the driver here is incomplete or structured very differently from the one used by Samsung, making it very difficult to use. Also, the few files there that do pertain to Atmel MXT such as atmel_mxt_ts.c in there appear identical to the mainline Linux repo.
Click to expand...
Click to collapse
I think you're looking at the unchanged mainline branch: the driver releases are as tags.
The advantage of these drivers is that they are generic for all chips in the maxtouch series. mxt224_u1.c is just a renamed atmel_mxt_ts.c, it contains lots of mxt224 specific configuration and it's unlikely that it will go upstream.
You will also find some user-space tools for extracting config files in a format the kernel driver can load, on the same github account.
Missed the tags, thanks for the additional info!
I'll look into maybe playing with this when ICS time rolls around. It's getting late in the game to do a major driver rework on the Gingerbread kernel I maintain.
sherifhanna said:
Hi showlyshah,
The latest updates include the following:
- Support for Atmel's mXT224E, mXT768E, and mXT540E chipsets
- Support for both protocol A and protocol B reporting
- Support for kernel 3.0 in addition to kernel 2.6.35
More details are available on GitHub in the release notes.
Regards,
Sherif
Click to expand...
Click to collapse
Hi Sherif,
I found the project in Github, but am not able to find the the release notes. Does this driver support the Atmel mXT336S at this time?
Thank you
Hi omaha64,
Support for mXT336S is in progress.
Regards,
Sherif
Question,
I am trying to back-port the 2.6.35.7 driver to 2.6.32. I have mostly succeeded, but probe() fails because of missing platform_data. Digging through the driver code, I found the platform data structure in include/linux/i2c/atmel_mxt_ts.h:
Code:
struct mxt_platform_data {
unsigned long irqflags;
u8(*read_chg) (void);
};
So I assume that in my board file (where my i2c_board_info arrays live) I would want to create a static instance of the above struct and store a pointer to it in the .platform_data member of the i2c_board_info struct, right? But what is the preferred initialization, and what is read_chg supposed to actually do? What's the consequences of just setting it to NULL? (I know it won't crash because the driver checks it before calling it)
Need atmel mxt224 driver for Windows embedded compact 7
sherifhanna said:
Hello XDA developers,
As you know, Atmel maXTouch touchscreen controllers are used in a large percentage of Android phones and tablets out there.
I wanted to let you know that the latest patches for the official Atmel maXTouch Linux driver are available on GitHub. This will allow you to get the latest up to date changes before they make it into the mainline kernel.
On GitHub, search for user "atmel-maxtouch"
Happy hacking
Best regards,
Sherif
Product Marketing Manager - Atmel
Click to expand...
Click to collapse
Hi,
Can you please send me the multi touch driver for ATMEL MXT224(Stream interface PDD layer) for Windows Embedded compact 7.
Thanks in Advance,
Rag
Android Driver Initialization
Hi,
I would like to use MaxTouch mxt224 on a TI am335x-evm board running Android ICS, I'm looking for documentation on how to initialize mxt224 driver from board's configuration file. Can someone help me?
Thanks.
ceskobassman said:
Hi,
I would like to use MaxTouch mxt224 on a TI am335x-evm board running Android ICS, I'm looking for documentation on how to initialize mxt224 driver from board's configuration file. Can someone help me?
Thanks.
Click to expand...
Click to collapse
.
I don't know if there's such documentation to tell you how to initialize. At least a sample exists; look here:
arch/arm/mach-exynos4/mach-nuri.c
The values in "mxt_init_vals" come from Atmel's mxt224 datasheets/manual, so you'll have to find those. I would be surprised if you could not find these by Googling. When I was trying to get the mxt224 to work on an Omap4 board, I had to hack up the driver a little to handle the reset going to the IC, and to handle the /READY line from the IC to the host. Also, for ICS, you will need to have an IDC file in your root file system. Just Google for "Android Input Device Configuration File" (I'm new here and cannot post links yet).
Without that IDC file, Android considers the touch device to be a pointing device (like a mouse).
Good luck
Atmel Mxt768e Driver details
Hi Sherif & All,
Can you please share the atmel MaxTouch mxt768e driver link, I would also request you to share the driver which has the implementation for fIrmware upgrade.
Thanks,
Balaji S
Is there some place I can learn to understand and modify these? I've never done driver development before. Before I waste any time with this, can someone confirm if the input lag in most devices is because of filtering in the driver or because of the Atmel hardware?
KurianOfBorg said:
Is there some place I can learn to understand and modify these? I've never done driver development before. Before I waste any time with this, can someone confirm if the input lag in most devices is because of filtering in the driver or because of the Atmel hardware?
Click to expand...
Click to collapse
I don't think you'll be able to find a single place that describes the driver. Luckily, these drivers are small, the mxt224 is just a single C file. I've looked at the mxt224/mxt336, so the following info is specific to those. Some high level info for you to get started:
* The driver allows the exchange of "objects" between the touch IC and the host processor. To understand what the objects are, you'll need to find the datasheets/manual for the chip you're using. Just try Googling for it. Objects from the host to the IC are typically configuration data, and objects from the IC are probably touch data
* In the case of the mxt224/336, the driver needs the I2C driver
* The driver has a structure that needs to be setup from your board file (example arch/arm/mach-omap2/board-???.c). This structure has some configuration data needed by the driver
* Typically, there's a reset line that has to be pulled high on the board. May need pinmuxing to set the functionality of the pin correctly.
* The IC will also have a /CHG line that will go low when it has data to send to host. You will need to set up pinmuxing for this pin as well.
* The driver has an interrupt routine handling the /CHG line. When a touch/drag happens, objects will be sent to the driver to process. The driver formats the data and forward that up to the user space via the input subsystem.
* If you're doing this for Android, you'll need an .idc file in your root file system. Info: {link removed because I'm new. Just google Android IDC }
* The driver will look for a config file in /system/vendor/firmware, upon starting up
I can't comment too much on the lag you're talking about because I don't know the nature of the lag you're seeing. But I can tell you that the Atmel touch IC needs a "tuning" process where the internal parameters have to be adjusted to operate properly.
If you find more info on this subject, please post it here.
omaha64 said:
I can't comment too much on the lag you're talking about because I don't know the nature of the lag you're seeing. But I can tell you that the Atmel touch IC needs a "tuning" process where the internal parameters have to be adjusted to operate properly.
If you find more info on this subject, please post it here.
Click to expand...
Click to collapse
The "lag" is because the touchscreen does not recognise fast taps. You must press and hold your finger on the screen for several milliseconds before it actually recognises a touch. If it was purely a latency, then even a fast tap would be recognised after a delay. In this case, only a continuous press of a minimum duration is recognised. This makes the screen unresponsive and useless for games that need taps.
Is this something that can be resolved in the driver? I have a feeling this is coded in the firmware blob that gets uploaded to the touchscreen on initialisation.
KurianOfBorg said:
The "lag" is because the touchscreen does not recognise fast taps. You must press and hold your finger on the screen for several milliseconds before it actually recognises a touch. If it was purely a latency, then even a fast tap would be recognised after a delay. In this case, only a continuous press of a minimum duration is recognised. This makes the screen unresponsive and useless for games that need taps.
Is this something that can be resolved in the driver? I have a feeling this is coded in the firmware blob that gets uploaded to the touchscreen on initialisation.
Click to expand...
Click to collapse
I believe that if the issue you're describing is due to the IC's noise rejection algorithm, then you may be able to alter that in the driver. There are params in the chip such as number of valid ADC samples for the touch to be recognized as a true touch, that you can play with. But I don't know if you can change these parameters on the fly, or has to be done at start up. I haven't played with these params. See if you can grab hold of a "Protocol Guide" for the touch controller that you're working with. That shows all the params that you can change. In fact, you may be able to alter some of these params without having to touch the driver; search for mxt_app in github. I've used mxt_app to load configuration and change T9 object before, but that's the extent of my use of it.
Thanks for your help. Time to start reading. Some of the mach-* initialisation params can be changed at runtime such as the Vitalij value.
What is the real world best case input latency of these controllers? Can the Galaxy S2's touchscreen actually be made as good as the iPhone 5 or are the iPhone controllers simply superior?
Description:
AndroidLib is a .NET assembly written in C# (C-Sharp) that easily handles communication between a connected Android device and your program. Currently, there is a large amount of automated controls, eliminating thousands of lines of code the programmer has to write themselves. The class AndroidController is a semi-wrapper of the ADB (Android Debug Bridge) binary. The other class you will be working with the most is the Device class. This class contains useful information about the device (for example: software/hardware info, memory info, battery stats, mount points for partitions, root status, busybox information, and much more), as well as exposes many instance methods to control your phone such as Rebooting, Mounting Filesystems, Push/Pull/Install Files, and much more to come. AndroidLib contains all of the Android binaries necessary to work properly. AndroidLib also assumes that the phone's USB drivers are already installed correctly on the target machine, or that your program will take care of it on it's own.
This is perfect for any developer who would like to create, for example, an auto-rooter or any other application that needs to connect with Android devices through a .NET application. AndroidLib provides all the methods needed to communicate with the Android device. This will cut back on the code you have to come up with and write yourself by a HUGE amount!
What it does:
Provides easy-to-use code for communicating with Android devices in .NET
Provides easy access to information about the connected Android devices
Has a large list (and growing...!) of methods that control connected Android devices
Please credit the work here by me in your own projects; not only to give thanks to me and the many hours I am putting in to this project, but so others know where to find it if they need to!
Usage:
Add a reference to AndroidLib.dll in your .NET project and begin using this great API. Please refer to the "Getting Started.txt" guide and full documentation included in the zip.
Requirements:
.NET 3.5 or Higher
Changelog (Only most recent version displayed, full Changelog in download)
Version 1.5.1.0 | 01.21.13
Fixed Device.InstallApk() bug
Download Latest Release
GitHub
Online Documentation
Sample Solutions Using AndroidLib:
C# (C Sharp)
Visual Basic (VB)
AndroidLib Featured Projects by XDA Users:
RegawMOD Evo 4G LTE Rooter - XDA
RegawMOD CDMA Hero Rooter - XDA
RegawMOD Rebooter - XDA
Droid Manager by DeepUnknown - XDA - Google
Android SMS - XDA - Home Page
Quick ADB Pusher by Goatshocker - XDA
reserved just in case
It's very useful, thank you very much, im planning to code a Filemanager like qtadb, because qtadb is sucking too often
In the process of completely redesigning the library (due to coding stupidity), basically from the base class up. I should have a beta1 out by this weekend for testing. All that are interested in beta testing this library for their Android .NET projects, post here and I'll add you to the list of testers!
It would be great!
Can you add something like adb forward? So we can connect to an android service without using ADB, that as we all know sucks!
Mrc527 said:
It would be great!
Can you add something like adb forward? So we can connect to an android service without using ADB, that as we all know sucks!
Click to expand...
Click to collapse
Yeah, I'll throw in a method to create a port forward. What I have now uses the bridge, which is included in the assembly, but handles all of it silently and very well. I should have a build out soon (most likely this weekend). As long as you don't dispose the AndroidController object, that port forward will be good, so you can use your own Socket code
regaw_leinad said:
Yeah, I'll throw in a method to create a port forward. What I have now uses the bridge, which is included in the assembly, but handles all of it silently and very well. I should have a build out soon (most likely this weekend). As long as you don't dispose the AndroidController object, that port forward will be good, so you can use your own Socket code
Click to expand...
Click to collapse
Great work! really, great idea!
You can change the .NET to 3.5? I too code in .NET, and I try to keep the .NEt version as low as possible!
SimranSingh said:
You can change the .NET to 3.5? I too code in .NET, and I try to keep the .NEt version as low as possible!
Click to expand...
Click to collapse
Yeah, I actually did that a few days ago, forgot to update the OP.
Where is it possible to download?
Mrc527 said:
Where is it possible to download?
Click to expand...
Click to collapse
I'm just writing the documentation for this. I'm pretty sure I'll have it done today.
Yeah! Just a joke. When finished I'm sure will be a success!
Inviato dal mio Galaxy Nexus usando Tapatalk
Making some last minute changes to the Device class, then I'm going to finish the documentation and release it. Just keeping you updated.
Ok everyone, the new documentation is up (Online) (Offline). For the beginning of this product, I would like developers to pm me, or reply here in the thread if they would like to try the library out for their project, and I'll send it to them. It's still under development, and there will be updates coming out regularly. Shoot me a pm or post here and I'll send you a link right away.
regaw_leinad said:
Ok everyone, the new documentation is up (Online) (Offline). For the beginning of this product, I would like developers to pm me, or reply here in the thread if they would like to try the library out for their project, and I'll send it to them. It's still under development, and there will be updates coming out regularly. Shoot me a pm or post here and I'll send you a link right away.
Click to expand...
Click to collapse
Meeeeeeeeeeeeeeeeeeeeee!!
Hi,
I'm C# developer and i would like to try your lib, can you send it please?
Thanks in advance, and great work.
Hey guys, check the first post to download the library. It is in a zip which includes the dll, "Getting Started.txt" and the documentation. Please read the getting started guide before diving into it! And please give me feedback on it. That would be much appreciated in order for me to deliver a better product.
Dan
Great work!
It works without any problem to me!
Next update will have these features internally implemented:
Package Manager (inside the phone's shell)
Ability to install/uninstall apks
Ability to freeze/unfreeze apks
Ability to backup/restore apks
A class that will handle signing of update zips
More internal information about connected device (cpu, environment, etc)
Possible wrapper of AAPT
That seems like a good amount for the next update. Please post anything you wish to share about the library after using it for these few days.
Hi everybody.
I coded an Android app that ended such modest that it is compatible with the API level 1. (Some additional features are deployed if a higher api is available, e.g. uses the Material Theme if present, addresses some deprecated functions otherwise, etc... memory and screen resolution are also handled if they are low.)
My question: is it a good idea to really set minSdkVersion=1 ? (The only device that was deployed with this api that I know of is the HTC Dream...)
I won't be able to test such a low api on a real device. Should I do this anyway? Are there any snares I am missing?
Paul2017 said:
Hi everybody. I coded an Android app that ended such modest that it is compatible with the API level 1. (Some additional features are deployed if a higher api is available, e.g. uses the Material Theme if present, addresses some deprecated functions otherwise, etc... memory and screen resolution are also handled if they are low.). My question: is it a good idea to really set minSdkVersion=1 ? (The only device that was deployed with this api that I know of is the HTC Dream...). I won't be able to test such a low api on a real device. Should I do this anyway? Are there any snares I am missing?
Click to expand...
Click to collapse
In short...
The min sdk version Is the earliest release of the Android SDK that your application can run on. Usually this is because of a problem with the earlier APIs, lacking functionality, or some other behavioral issue.
The following link reflects all the details regarding the sdk versions for Android.
https://developer.android.com/guide/topics/manifest/uses-sdk-element.html
Good Luck!
~~~~~~~~~~~~~~~
I DO NOT PROVIDE SUPPORT VIA PM UNLESS ASKED/REQUESTED BY MYSELF.
PLEASE KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE