Conectar PIC18F4550 con Tablet Android como Host.

Estoy tratando de conectar un pic18F4550 a una tablet para lograr el tipico encender/Apagar un led.

el pic esta grabado como HID. al conectarlo la tablet me lo detecta y puedo hacer la conexion del software pero no logro enviar o recibir datos.

para no hacer el cuento tan largo ¿alguien a logrado hacer una conexion asi?

si alguien tiene experiencia en esto agradeceria que me comentara como se hace en terminos generales.
 
Última edición:
A ver si no me equivoco. pero por lo que lei (rapidamente) es para que un PIC de alta Gama sea utilizado como Host y el dispositivo android sea el Cliente, yo lo que busco es que sea al revés el 18f4550 o 18f2550 como Cliente y la tablet como Host.
 
Última edición:
Mi estimado papirrin, yo en realidad no logre mucho, pues soy muy malo en el asunto de Java y android, sin embargo logre prender/ apagar leds y leer el estado de un par de switchs (ambos en el pic) desde esta aplicación que ademas es open source y se llama USB HID TERMINAL

Aquí la liga del Open Source


Seguramente tu estarás mas ducho que yo en el asunto de programar en android, y a manera de chisme, por que yo no lo tengo comprobado en persona; con esta aplicación que cuenta con el código fuente, se puede usar como base para hacer lo que se quiera, tómalo como tal (chisme) aunque quien me paso el dato es una persona seria, sin embargo lo que si te aseguro es que en el teléfono que utilice en su momento con android 2.3 si me funciono perfectamente la aplicación así como estaba (parece que a evolucionado la versión) y suponiendo que teniendo todos los programas fuentes, si puedas utilizarla como plataforma.

Saludos y suerte...yo francamente me perdí en la textura del ambiente android (JAVA) y termine desesperado...quizás un porro de hierba verde me falto...mas bien nunca he tomado un curso de Java.
 
Si habia visto esa aplicacion aunque el codigo fuente no.

estuve revizandolo y ahi esta mi duda principalmente, has de cuenta que yo grabo el pic con PICBASICPRO con el HID Wizzard. pero al revizarlo maneja una Transferencia INT que no se que sea XD, y esa aplicacion USB HID Terminal utiliza una Transferencia BULK y eh ahi donde estoy atorado.

por cierto yo lo estoy intentando con B4A Android (basic for android) que esta mucho mas facil que JAVA, aunque lo que hace es una precompilacion a JAVA.
 
Última edición:
El HID Wizzard, nunca lo utilice , pero lo que si te aseguro es que si tu prototipo lo reconoce android, linux, mac y windows como un HID Device, pues ya tienes todo correcto por el lado del hardware/software del pic. ---Ya esta en modo BULK---

Y solo te resta dialogar con el dispositivo vía el kernel, framework o capa de software correspondiente en el HOST (android en este caso), quiero suponer que ya tienes resuelto manejar tu PIC desde windows, via viusual basic, visual C, etc. Al menos yo así lo hice y ya bien entendido el asunto de los Buffers de intercambio que existen entre las dos capas (Host/cliente) ya tuve la seguridad de poder manipular estos con la aplicación de android.

Sin embargo tratando de ayudar a despejar las dudas, dependiendo del VID&PID que se asigna y su vinculo obligado con el "report description" que es donde se especifican los buffers de entrada/salida, el nombre de la interface, etc, etc, en realidad es ahí la diferencia entre las posibles de la clase BULK (entre esas la INT que comentas) y esta información es la que logra la enumeración HID correspondiente en el Host que manejara a la interface. Por el momento no recuerdo donde, pero en este foro tenemos desmenuzado este tema, si lo encuentro lo comparto....

Te dejo saludos.
 
Última edición:
Bueno pues logre enviar datos del PIC al Androide,no estoy muy contento pero al menos se que se puede :D

Lo que no entiendo ya sea en JAVA o B4A, como es que se pasa del UsbRequest.Buffer al USBRequest.Queue :confused:

Aqui el video de la prueba:
 
No tengo idea de nada. Pero según interpreto de
http://www.basic4ppc.com/android/documentation.html
y de
http://www.basic4ppc.com/android/help/usb.html#usbrequest

usbrequest es una clase que representa un paquete USB.
usbrequest.buffer es el buffer/array/datos que se van a enviar por usb.
usbrequest.queue es una función que coloca el paquete en la cola/queue de envío (pensar que hay otras aplicaciones que pueden querer acceder al mismo dispositivo USB, de ahí la necesidad de una cola, para serializar el acceso al dispositivo).
Esa función pone al paquete en la cola/queue y vuelve de inmediato, sin esperar a que el paquete efectivamente se envíe.
Una vez que el paquete se envía se generará el evento UsbDeviceConnection_NewData

request.queue(data, dataLength) lo que va a hacer es poner en cola de envío el buffer data

request es un objeto derivado de una clase, no es una variable, ni una función, sino un colección de variables y funciones.
 
Si es justo como dices, el unico detalle es que si se recibe un dato deberia pasar del buffer a la cola o queue pero no se pasa me falta hacer algo y cuando lo leo si lo leo cuando se desborda el evento newdata.
 
Entonces la cuestión es como recibir datos. Pero al recibir datos no hay queue, solo al enviar.
A ver esto:
http://www.basic4ppc.com/android/forum/threads/android-usb-host-tutorial-adbtest.11289/
http://www.basic4ppc.com/android/forum/threads/usb.26122/

En esos ejemplos usan el evento newdata para manejar los datos recibidos:

PHP:
Sub Connection_NewData (Request As UsbRequest, InDirection As Boolean)
   If Connection.IsInitialized = False Then Return 'Might happen after we close the connection
   If InDirection = False Then 
      ReleaseRequest(Request, OutRequests) 'no veo documentación de ReleaseRequest, omitir?
      connection.ContinueListening
      Return 'don't handle OUT requests <- si la interrupción es porque se completo un envío no hago nada
    End If

'Aquí ya sabemos que se trata de un paquete IN, que el pic nos está enviando datos.
  Label1.Text = request.buffer(0)
  Label2.Text = request.buffer(1)
  '... usar el resto de los datos recien llegados..

  ReleaseRequest(Request, OutRequests) 'otra vez esto, no veo documentación, quizás se puede omitir
  connection.ContinueListening
End Sub
El tema de los ReleaseRequest supongo que tiene que ver con que uno puede crear/destruir distintos request, y el release lo que hace es borrar un request que ya se uso para liberar memoria.

En el video veo que en la rutina del evento newData, luego de recibir el paquete estas enviando el paquete otra vez al pic llamando a request.queue(..)
¿Eso queres que funcione asi? (cada vez que me llega un paquete del pic enviarselo de vuelta tal y como vino).

Va a ser más fácil si pegas el código aca, porque leerlo del video es poco practico.

/////////////////////////
Edición

https://developer.android.com/reference/android/hardware/usb/UsbRequest.html
Veo que la clase usbrequest en el manual de Android tiene un método close, pero no está documentado en la clase usbrequest de b4a, será por eso el ReleaseRequest?
 
Última edición:
Bien :)!!! (y)

En realidad el buffer se usa para las 2 cosas, para entrada y para salida. Solo que para salida es necesario poner los datos en el queue/cola de salida (llamando a request.queue), y para entrada solo nos enteramos cuando los datos ya estan puestos en el buffer request.buffer.

Ese retardo inicial no se si es normal. ¿La enumeración del dispositivo en tu programa Android se hace al pulsar el botón Connect cierto?. Si se hace en la rutina del botón enviar puede deberse a eso (tarda un tiempo en enumerar, cargar drivers, etc).
También puede ser el programa del pic, ¿quizás hay algún retardo entre que se completa la enumeración y se pasa a ejecutar el while(1)?.
Otra cosa puede ser que el propio sistema android si no detecta actividad durante algún tiempo ponga al dispositivo en modo sleep para ahorrar batería, y que ese retardo sea el tiempo en volver a despertar. En el PIC se podría verificar si esto pasa preguntando por el estado de la conexión y si alguna vez entra a suspensión.
Acá hay un bug de Android con dispositivos HID que al ponerse en standby envía la orden suspend a los dispositivos usb, pero al despertar no envia el resume para volver a despertarlos:
https://code.google.com/p/android/issues/detail?id=62305
 
Otra cosa puede ser que el propio sistema android si no detecta actividad durante algún tiempo ponga al dispositivo en modo sleep para ahorrar batería, y que ese retardo sea el tiempo en volver a despertar.

lo estuve observando y si, creo que si es eso lo que dices despues de unos segundos como que lo pone en sleep, porque si le doy seguido hace la comunicacion inmediata, si lo dejo un rato sin presionar es cuando hay un retardo.

pero bueno en realidad por ahora no le tengo ninguna aplicacion asi que no es importante, solo era por saber si se podia conectar el pic con androide y que tan dificil era, y pues es mas o menos facil y definitivamente si se pùede XD.

Gracias de nuevo.
 
Hola!, se que es un poco antiguo el tema, pero quería saber si ahi algún código fuente por ahi >.<, acabo de lograr conectar el micro con una tablet pero me gustaría manipular datos :confused::confused::confused:, espero me puedan ayudar, Saludos Cordiales!!!!
 
Listo pues ya funciona de SAlida y entrada:
el buffer si es para la entrada y el queue para la salida


Hola papirrin... Estoy tratando de hacer lo mismo.. tendrás el ejemplo de enviar y recibir en el pic y el android un byte con B4A? Si no tw molesta te lo super agradecería. Muchas gracias. Mi correo es

Como NO cumplo las políticas del Foro, me editaron el mensaje.
 
Última edición por un moderador:
Atrás
Arriba