"GOSUB DoUSBIn" con EasyHID

[Marioguillote]

Hola amigos !

Estoy tratando de lograr una comunicación PIC-PC / PC-PIC con un 18F2550, a través de las facilidades que brinda EasyHID.

A través de la instrucción GOSUB DoUSBOut logro comunicarme desde el PIC hasta el ordenador y el programa hecho en VB6 responde sin problemas a las "órdenes" del PIC.

Mi problema se origina al tratar de enviarle datos ó información al PIC
Imaginen un programa en el PIC que maneje un contador  0 a X,  y que un botón en la aplicación VB6 esté encargada de resetear ó reiniciar la cuenta.

Dentro del lazo de la cuenta incluyo la instrucción GOSUB DoUSBIn esperando que el PIC "observe y controle" si hay algún dato ingresado por USB, y que si lo encuentra, actúe en consecuencia.
En el caso de que no haya dato ingresado desde la PC, mi idea era que volvía y continuaba con el resto del programa, ya que las instrucciones son bien pocas y sencillas :

Código: [Seleccionar]

' ************************************************************
' * receive data from the USB bus                            *
' ************************************************************
DoUSBIn:
   USBIN 1, USBBuffer, USBBufferSizeRX, DoUSBIn
   RETURN

Es decir, el programa entra en la etiqueta DoUSBIn, toma el dato del buffer y sigue su camino de regreso, a través del RETURN

Pero esto no ocurre !!!!!     
Cuando llega a la línea USBIN 1, USBBuffer, USBBufferSizeRX, DoUSBIn, el programa muere allí esperando el ingreso de algún dato.
Si no le enviamos dato alguno (el que sea) queda estancado el programa allí y no continúa con la rutina de trabajo.

Una de las pruebas que hice y funcionó OK, es la de colocar un Timer en la aplicación de VB6 y cada 1ms envío a través del buffer el número 0 (mis controles deseados los hago trabajar con otros números)
De ésta forma cada vez que el programa pasa por la etiqueta DoUSBIn encontrará "algo" y permitirá que el programa siga corriendo.

Es ésto normal ?
No debiera trabajar como cualquier caso de GOSB >>> instrucciones ... >>> RETURN
Existen opciones para que el programa no caiga en ése agujero sin salida ?

Si fuese una aplicación, dependiente sólo del PC, no habría problemas ya que el PIC esperaría sólo las ordenes del PC y las ejecutaría sin problemas, pero es el caso en que la comunicación debiera ser en ambos sentidos y en cualquier momento y no puedo lograr resolverlo.

Espero se haya entendido mi duda.
Tengo muchas más, pero al menos me gustaría arrancar con ésta.

Saludos a todos y el agradecimiento a quienes me puedan ayudar.
Mario

[aitopes]

Hola Mario!

Mirando un poco tu problema (yo no uso ni ese BASIC ni he intentado hacer nada USB), veo que en este hilo de miarroba Giovanni Lafebre  usa un "GOSUB DoUSBIn" y por lo visto el programa vuelve a la linea siguiente....

Quizas si Gio lee este hilo pueda darte algún dato más.

Tambien en su página habla de ello:

Código: [Seleccionar]

DEFINE OSC 48         

USBBufferSizeMax   con 8  ' maximum buffer size
USBBufferSizeTX    con 8  ' input
USBBufferSizeRX    con 8  ' output

' the USB buffer...
USBBuffer        Var Byte[USBBufferSizeMax]
USBBufferCount   Var Byte
dato             var byte

' ************************************************************
' * main program loop - remember, you must keep the USB      *
' * connection alive with a call to USBService every couple  *
' * of milliseconds or so...                                 *
' ************************************************************

PORTB = 0
TRISB = 0

usbinit ' initialise USB...
ProgramStart:
    gosub DoUSBIn
    PORTB = USBBuffer[7]
    goto ProgramStart

' ************************************************************
' * receive data from the USB bus                            *
' ************************************************************
DoUSBIn:
   USBBufferCount = USBBufferSizeRX              ' RX buffer size
   USBService                                    ' keep connection alive
   USBIn 1, USBBuffer, USBBufferCount, DoUSBIn   ' read data, if available
   return
"Lo que hago es recibir un byte enviado desde el PC y lo asigno al PUERTO B que es en donde esta conectado el driver que comanda los motores..."


Espero te sirva de algo mientras llegan las respuestas de los que saben

Saludos! 

[LordLafebre]

Hola:

Mario leí tu privado, mil disculpas por no reponder antes, y en efecto como tu mencionas,

USBIN 1, USBBuffer, USBBufferSizeRX, DoUSBIn

funciona como el serin, espera hasta que haya algún dato, pero como lo has corregido con el timer desde VB no creo que tengas problemas.

[Marioguillote]

Hola Ariel !

Gracias por responder !

Estuve allí en su página y ví su vehículo del ejemplo que mencionás; y lo tuve en cuenta al momento de comprender la comunicación USB.

Sucede que dicho vehículo, mientras no reciba instrucciones a través del USB queda detenido, muerto en el lugar, esperando datos. Esperando alguna instrucción que le indique qué hacer.
Por eso no es problema que el programa del PIC quede detenido allí, porque precisamente éso es lo que se busca en dicho ejemplo : que quede a la espera de instrucciones y no otra cosa.

En mi caso, quisiera que no solo esté atento a cualquier instrucción que pueda venir desde el PC, sino que también continúe él, autónomamente con su trabajo que le pude haber asignado mediante el programa que le pude haber cargado.

Por mencionar algún ejemplo con el mismo vehículo; que cada 2 segundos envíe al PC la temperatura y la humedad del medio donde se halle y al mismo tiempo almacene ésos datos en una 24C08 para luego de la "expedición", visualizar todo en un gráfico Excel Chart.
Que encienda luces si detecta que se encuentra en un medio oscuro.
Que pueda sensar a qué distancia se encuentra del obstáculo más cercano con un sensor de ultrasonidos que "barra" un sector de 180º a su frente y nos devuelva qué distancia detecta y en qué dirección.
... que se yo .... miles de posibles tareas que se me ocurren que podemos asignarle al PIC que vá sobre el vehículo.

Entonces lo que busco es éso. Que no se quede holgazaneando esperando órdenes de acción, sino que siga trabajando autónomamente y recogiendo datos útiles para sí y para la interfaz gráfica, mientras que quien lo meneje decida hacia donde lo vá a movilizar.

Debe haber alguna forma de que no se "caiga" indefinidamente allí y la estoy buscando.

Saludos Ariel !  
Gracias por tu buena predisposición.

Mario

Justo pulsé para postear y apareció tu mensaje Gio ...

Sí ...., lo hago funcionar gracias al timer desde el VB, pero estoy tratando de buscar otra forma; ya que hice un ejemplo gráfico de una barra de progreso (modificando una que encontré en la web) pero los resultados son espantosos en lo que a gráficos y a respuesta del sistema se refiere.
Por eso era mi consulta : Si existe otro modo de sacar al PIC de ése estado de espera para que el mismo siga trabajando, sin apelar al Timer en la aplicación VB.

La otra pregunta que te había hecho por privado y por aquí por el foro, era acerca de cómo el programa interno del PIC puede darse cuenta si se desconectó del bus.
Saber cuál es la flag de cuál registro para limpiar su estado. He dado vueltas por todo el datasheet del 18F2550 y no lo he sabido encontrar a eso.

Será cuestión de seguir estudiando !

Gracias por la ayuda que puedan brindar.

Saludos again.
Mario