I have a device that uses Serial Port and work with MS Windows. I would like to replace it with android with mobility. So I dont need to bring the bulky notebook for the simple work. Since the software is windows based, I cannot install it in android. Remote Desktop is an alternative to access my home computer for the software functionarity. The missing link is the serial connection of the device. In desktop version of RDP, many app allow redirection of both parallel and serial port. Yet I did not see any RDP app implementaion. Are there any known solution or where to start my own compilation?
The serial port on android device is provided by prolific pl2303 and is proven to work with android already.
Thanks.
Related
For over a year now I own a htc prophet.
Ever Since i've been on the lookout for a technique to use activesync over tcpip (wifi). It's been years since microsoft took that feature from us. all over the net i can hear the cries of people not understanding why it is missing.
There are virtual com port replicators, mappers, loggers and what not available for windows mobile.
there is just one thing missing!!!
A virtual com/serial port redirector for the ppc which redirects traffic to a server on the x86 machine over tcpip that creates a com port on the windows box for active sync to use. as both the ppc and the x68 active sync components support com connections.
ppc (wm5)->virtual com port client->tcpip(wifi)->virtual com port server(on x86 windows)->activesync 4.x
(of course bidirectional)
such software is readily available for windows to enable many computers to share a com device.
i have found libraries that would facilitate making such a product and i'm sure thousands would appreciate it (and happily hand over some amounts of money).
why is there no such thing? has ms been sending cease and desist letters to protect their exchange server business?
am i blind? was i just thinking too quick?
i might one day do it myself - unfortunately i can't stand visual studio and did never like learning ms-apis. I never needed it before and was happy with that.
hello everyone,
Can anyone make an application which sends ASCII code via bluetooth to a PC or a bluetooth module??
I really need it for my mechatronics project.
Thanks before
Does it have to be Bluetooth? You might be able to cobble something together over USB with the USB host driver.
I'd like wireless communication for the system since cable is kinda out of date...
But when time is running out... I guess USB will be OK. But for now, since I still have plenty of time, I'd go with wireless.
You could use the chroot method and install Ubuntu on your Nexus One. I don't know if it exposes the phone's Bluetooth interface, but it might be worth looking at since you could code up anything you want in any language if that were the case.
ermmm... it's kinda advance...
any URL to the guide maybe???
is there no ordinary apps or so?
Basic serial over bluetooth is done using the RFCOMM profile, details on how to write an app can be found here:
http://developer.android.com/guide/topics/wireless/bluetooth.html
I'd guess you open a socket to the destination machine, just like normal network programming, just over bluetooth rather than tcp. Here is a stackoverflow article on the subject
http://stackoverflow.com/questions/...-sdp-connection-to-a-rs232-adapter-in-android
....
I'll try my best to understad it
complete noob on java programing here T^T
Hi Folks.
With both a Zune HD and WP7 devices not supported via USB conenction to a Surface RT, I was thinking there had to be a way to tweak/re-write the ZuneHD / Zune driver files to allow them to be installed on the Surface RT...The ZuneHD is an ARM based device running Windows Embedded - and RT is an evolution of Windows CE you might say.
If so, the earlier regedit hack to allow the WP7 (or ZuneHD) to connect as a USB mass storage device would hopefully be possible, without the full ARM recompile of the Zune software (a near impossible task).
It's ridiculous that pre WP8 devices cannot even be connected via USB to facilitate file transfers "non-cloud" way.....
I tried manually updating drivers on the Surface RT with my ZuneHD connected - pointing at the Zune 4.7 drivers, and it confirmed that they were not ARM compatible.
Cheers,
Sheeds.
...
"tweak/re-write" an x86 kernel-mode driver into an ARM kernel mode driver for installation on a platform that doesn't (currently) permit unsigned drivers at all? You act like you have some idea what an instruction set architecture is, but you say this. If I ran this entire message through a translator to Finnish and then ROT-13'd it, you'd probably have a better chance of understanding the post than of managing to get the existing x86 Zune driver working on RT without a full re-write plus an additional hack to bypass driver signing. The Zune driver isn't exactly open-source... binary emulation *might* work at some point, but it's not practical for a kernel-mode driver (signature checks or not).
There is not, and never was, a hack to allow Zune-like devices to connect using UMS. The hack you're referring to merely un-hid the MTPZ (Media Transfer Protocol, Zune) devices from Windows Explorer. MTP(Z or not) and UMS are not at all the same thing, although they can sometimes be used for some of the same purposes.
We'd have a much better chance of getting Zune to run on RT, actually. That's "just" a matter of emulating an x64 machine for it to run on and passing its system calls through to the real OS and back again. Won't do any good for this use case without the driver, of course.
What does it matter that RT and CE run on the same ISA? The driver that we need is x86/x64 only.
There is basically nothing in common between CE and NT, aside from the fact that they're both portable operating systems from Microsoft and both implement some large portion of the Win32 API. Claiming that "RT is an evolution of Windows CE" is laughably wrong. They probably have less in common than Windows 95 (9x kernel, partially based on Win16 code) and Windows 8 (NT kernel, completely different project that contains no portions of DOS/Win16 except the re-implementation of the shell in NTVDM) - at least Win8 can run (many) Win95 apps. CE is at least as different from each of those as they are from eachother.
At this point, I'd guess that the most practical way to connect Zune on Windows RT would be the following:
a) Use a full x86-machine emulator (Bochs or QEMU, for example).
b) Use one that does JIT and/or dynamic recompilation, so the performance isn't abysmal (not sure what qualifies here...)
c) Install XP on it (no point targeting something newer).
d) Install Zune on the emulated XP.
e) Forward the tablet's USB port to the emulated machine's USB port (not sure if anybody has the ability to do this... currently, we can't even get networking in the emulated machine).
Good luck with that! I actually mean that quite seriously, I have a WP7 device myself and it annoys me that my Surface and it can't communicate except over Bluetooth (and I had to hack the phone to get that much).
GoodDayToDie said:
...
"tweak/re-write" an x86 kernel-mode driver into an ARM kernel mode driver for installation on a platform that doesn't (currently) permit unsigned drivers at all?QUOTE]
LOL - Thanks for the informative reply Luckily I have no delusions of grandeur over the fact that I am A) not a Developer and B) can't code past "hello world"
I was coming from the angle of the old registry hack for WP7 which allowed your phone to work as a USB mass storage file by a simple change via regedit to one of the registry strings associated to the Zune Driver....Certainly ignorant of the finer (and even the coarser) detail of your reply...so thanks for the explanation.
I added a MS Answers post asking why Microsoft cannot provide USB device connection for legacy WP7 and ZuneHD units with Windows RT. Be interesting to see what they or their MVP's reply to this, if at all.
Cheers.
Click to expand...
Click to collapse
Yeah.. asking MS to support the devices is definitely the best approach. We might manage to make a user-mode connection to them using some third-party software talking directly to the USB port on sufficiently hacked RT devices, but that's about the best we'll get.
Also, I really with people would stop calling it a "USB Mass Storage" hack. I've posted to that effect in the relevant forums that I can find, too. This is not now, never was, and (short of custom ROMs or special bootloader modes) never will be a UMS interface to Zune-like devices. The device literally doesn't support it. Please don't confuse Media Transfer Protocol for USB Mass Storage. They are *not* the same. For example, those nicely named music files you see when using the "UMS" hack for WP7/Zune? *THEY DO NOT EXIST* anywhere on the device's filesystem. True, there are files containing the same binary data, but they have names like "2D.mp3" and are stored in a filesystem structure designed to make referencing them in a database faster. MTP exposes a hierarchical storage system (which may, coincidentally, mirror the filesystem although it does not do so on Zune-like devices), but it does *NOT* expose the filesystem/storage (which is what UMS does).
I'm using TeamViewer QuickSupport on my two Samsung devices, but it seems to need a device-specific add-in to work on other devices.
The device in question is a CubieTruck as in http://tinyurl.com/mjzejs4.
Actually the TeamViewer product almost works. Connects to the device, gives stats about the device, allows file transfers... but when it comes time to connect to the desktop it mis-interprets the device's "OK" to "Refused".
Does anybody know of another product that allows a Windows session to connect to an Android desktop?
Seems like there are plenty of products that go the other way... but Windows ==> Android?
Hi xda dev team !
I would like to write an android app which sends serial data (over USB as bridge) to a hobby
circuit. The app should work on my Motorola Defy+ (android 2.3.6) and look like
a text editor (with some exceptions) - the window content should be sent to my circuit.
The problem is that the only programming language I know is C and my Linux knowledge
is minimal, almost zero ! FTDI offers some "java drivers" on their site for USB to serial converter
chipsets, but those work only on android 3.1 and above (USB host capability on android device).
An alternative would be the use chipsets like FT 311/312 which act as usb hosts
and comunicate over AOA (Android Open Accessory) Protocols with android devices.
How do i know which AOA protocol version my phone has (i want to make my app upwards compatible
so it can be used by as much android devices as possible)? Also, which IDE should i use
taking into account that i'm a beginner in this matter ? Can somebody give me some tips
where to start from ?
thanks!