Closed GoogleCodeExporter closed 8 years ago
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 Bart.Ver...@gmail.com
on 27 Oct 2011 at 1:54
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 practica...@gmail.com
on 27 Oct 2011 at 8:58
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 Orio...@gmail.com
on 6 Nov 2011 at 10:32
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
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 Bart.Ver...@gmail.com
on 9 Nov 2011 at 11:58
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
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 Bart.Ver...@gmail.com
on 10 Nov 2011 at 2:04
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
Original issue reported on code.google.com by
practica...@gmail.com
on 25 Oct 2011 at 8:28