host code with GIT about copter-gcs

[GoogleCodeExporter]

It is certainly possible, and I'll look into it.

I don't like the idea of many branches being out there very much, as that 
causes its own headaches.

What sort of changes are you wanting to make? There have been very few change 
requests etc (hence no updates lately), so i'm curious if i'm overlooking 
things?

Original comment by [email protected] on 27 Oct 2011 at 1:54

[GoogleCodeExporter]

Hi,
I'm more interested in being able to work off line, specifically GIT allows 
multiple computers to be synced then multiple repositories to then be synced 
back to the main line if valuable work is done.
Also GIT gives us full traceability on any modifications or code sources with 
checksumming, GIT reduces the headaches with multiple branches, that said I 
would be looking to possibly kill the BT link and take the Zbee directly into 
the HW

Original comment by [email protected] on 27 Oct 2011 at 8:58

[GoogleCodeExporter]

I've moved to GIT, not sure if its all correct. Have a look and give it a shot.

When looking at the XBee directly, most of that work is done, but out of the 
box Android does not support USB-Serial in host mode. I'll add that branch of 
code too.

Original comment by [email protected] on 6 Nov 2011 at 10:32

[GoogleCodeExporter]

Hi,
Yep it is cloning nicely......

There are a couple of ways to get to the serial port, specifically I was 
looking at a particular make of tablet that has the ports physically 
implemented inside.
Other ways usually require the USB drivers to specifically recognize the Serial 
ports, a good example would be the FTDI drivers already built into the kernel 
code.
But my tablet has already been hacked to support both internal BT and RS232

Original comment by hardcoreforensics on 7 Nov 2011 at 3:08

[GoogleCodeExporter]

Which tablet are you looking at?

When I looked at it early summer, the FTDI drivers were not a standard item in 
the kernel (and I had no tablet to test on myself(. I would like to keep the 
(main) app compatible with unhacked distributions, but if a particular tablet 
can do serial, a second download would be useful.

Original comment by [email protected] on 9 Nov 2011 at 11:58

• Changed state: Done

[GoogleCodeExporter]

Actually I have access to 'the' manufacturer. The main brand is APad.
The tablet is based around the Imx515 and the android OS
This particular CPU has  several integral RS232 ports along with integral USB, 

The way to keep the main APP common, would just be to allow redirection vial a 
plugin communication class.
it would also mean that 3rd parties could have their own java com class,  
RS232, TCP/IP, Bluetooth,SMS, etc.

It would just require that the  communications were standardized to a single 
class via an API

Original comment by hardcoreforensics on 10 Nov 2011 at 1:35

[GoogleCodeExporter]

Cool. 

The app already has the standarized interface, (bluetoothmodule.java , 
extending ICommunicationModule.). Perhaps you mean a second comm class?

The problem is that the USB classes in the android API were not available 
before 2.3 (from memory, somewhere around version 10?). The problem then was 
releasing an APK that referred to i.e., USB classes that don't exist. 

At any rate, that was where I left it at the time. If you can contribute a USB 
class that can be distributed, that would be great.

Original comment by [email protected] on 10 Nov 2011 at 2:04

[GoogleCodeExporter]

Yep ..... 
In the past when I have used java I have also had to write a 'wedge' in C, to 
gain access from java.
I really dislike it because it makes  certain forms of  communication rather 
difficult since it requires callbacks from the USB side, it is also a filthy 
hack which I would rather not have associated with my name.
Really Java is a bitch of an unfinished language which is unlikely to see any 
improvement under Oracle.

Original comment by hardcoreforensics on 10 Nov 2011 at 5:56