USB en CCS: Detectando y gestionando la interrupción

[gu1llermo]

Guao!!!  ya no te prende la luz amarilla, eso significa que tenemos más espacio para declarar más variables para nosotros como programadores?? y perdona mi ignorancia.

Saludos.

[Modulay]

Eso mismo.
El problema no es que la memoria no estuviera libre en tiempo de ejecución,que si lo está.El problema es que llega un momento en que para el compilador no lo está y no te deja seguir creando variables

[Modulay]

De todas formas habrá que ojear los ficheros auxiliares a ver qué uso le da el compilador a ese array.
Algo hará con él,digo yo.

[gu1llermo]

Ah! ok, gracias por responder.

[PalitroqueZ]

Modulay, ¡¡ya casi lo tienes!! 

el caso que te dije con lo de programas genericos, lo vi en el archivo mmc_spi.c hay muchas funciones que consumen mucho espacio, y como todos sabran, la idea es optimizar el código lo mejor posible.


con tu permiso voy a imprimir todo lo que has explicado generosamente. 

[Modulay]

Tiene usted mi bendición

[PalitroqueZ]

Estuve leyendo la datasheet y otros documentos que imprimí en su tiempo. (por cierto tengo que leerlo varias veces para enterdelo mejor) a

a ver si comprendo, entonces quiere decir que ese ¿porcentaje de ram que muestra el ccs es virtual? porque puede darse el caso que yo en una condición ejecute procesos en el pic y otra condición use exclusivamente el usb.

de ser así la ram-usb solo sería usada en la última condición, aunque el ccs me la muestra estadisticamente como "apartada"

sabemos que UOWN se activa para indicarle al pic que se va acceder a la ram-usb, la pregunta a resolver es: ¿podemos determinar que segmento de la memoria utilizará la SIE para así no perjudicar las otras areas ram? todo ello con el objetivo de no machacar la ram usada tal como mencionas modulay

seguiré investigando...

[PalitroqueZ]

después de salcochar la lectura del capitulo en la datasheet respecto a la ram-usb llego a la conclusión que el problema es que 2KB de ram es muy poca memoria para los 18f4550, a la final solo tendras 1KB de ram para ti, la única forma es que uses los otros 1KB en una condición en que no estes usando el usb.

De lo contrario, es como dejar un objeto en una habitación compartida, no sabes si lo encuentras la próxima vez que pases por ahí 

pd: uff me pasé de offtopic, debería comentarlo en el hilo que hizo Bruno hace un tiempo.

[Modulay]

Vaya,no me dí cuenta de que había nuevas respuestas.

CCS reserva memoria para los búferes con la directiva #reserve y aparte declara un array que ocupa dichos búferes.Esto resulta redundante y, en tiempo de compilación, lo que hace es ocupar 2 veces la misma zona de memoria (aunque suene raro) sin ser "consciente" de ello,por lo que el indicador de RAM usada aumenta igualmente.

La solución que yo le veo a esto y que tras probarla parece ir bien es la de eliminar la declaración del array mencionado más arriba,ya que la memoria se sigue reservando de igual forma (en la justa medida que impongan los endpoints que uses) y no hay peligro de que tus variables se metan dentro de la zona de búferes...eso si,desconozco si se le llega a dar uso a ese array en alguna de las librerías...a mí por el momento me ha compilado y ejecutado bien.

Como dije antes,para saber que segmentos de la usb-ram van a ser accedidos por la SIE hay que ver qué endpoints se tienen activos,qué tamaño de paquete maneja cada uno y qué modo Ping-Pong se está usando...sabiendo estas tres cosas se puede deducir qué zonas de memoria pueden ser accedidas por la SIE,y consultando el bit UOWN que corresponda se podrá saber si en un instante dado un búffer está tomado por ella.

Realmente los 2kB están ahí (quitando desde 0x400 a 0x4FF,que se reserva para los descriptores de buffer y que seguramente también estén mal gestionados y gasten esa página de ram tontamente) y puedes usarlos,simplemente hay que eliminar el dichoso array.

[Cryn]

Hola Modulay, muy buen trabajo el que haz hecho.
Tengo algunas dudas, espero que puedas ayudarme, o quizá algún otro forero

Miren les cuento que hice hace ya bastante tiempo hice la comunicación USB, pero utilizando el usb_kbhit() y pues esa vez me ha ido muy bien, ahora pretendo hacer un proyecto en el cual incluya tb la comunicación USB, pero esta vez debo gestionarlo por interrupción, pues el uC tb estará realizando otras operaciones.

He leído todos los post, y tengo algunas preguntas, ojalá puedan responderme

En el código, también tengo que incluir todas las librerias que se incluyen en la forma sin interrupcion? o solo copiar los código que están en los primeros posts del hilo?

Para inicializar el USB, y esperar la numeración, se hace lo mismo que en el método de no interrupción?

Talvez utilice un buffer de 128bytes como mínimo de IN y OUT, no hará falta que sea pinpong, cual es el máximo valor de buffer que puedo utilizar? y que pasa si solo necesito 1byte?

Modula, quizá sea muy atrevido de mi parte, pero si es puedes, nos colocas todo el codigo que hiciste apra poder ver las librerias qeu se incluyen, los pasos a seguir para habilitar el usb por interrupcion y todo ello.

Muchas gracias por la ayuda
un saludo.

[Modulay]

En el código, también tengo que incluir todas las librerias que se incluyen en la forma sin interrupcion? o solo copiar los código que están en los primeros posts del hilo?

Las rutinas que te debes traer a tu fichero principal (si lo haces de la forma que yo sugerí) y el resto de rutinas que se usan para la inicialización del usb hacen uso de otras rutinas contenidas en las librerías, por lo que las invocaciones a éstas no pueden faltar.

Para inicializar el USB, y esperar la numeración, se hace lo mismo que en el método de no interrupción?

Sí

Talvez utilice un buffer de 128bytes como mínimo de IN y OUT, no hará falta que sea pinpong, cual es el máximo valor de buffer que puedo utilizar? y que pasa si solo necesito 1byte?

Que yo sepa, el tamaño máximo para transferencias bulk es 64 bytes.

Modula, quizá sea muy atrevido de mi parte, pero si es puedes, nos colocas todo el codigo que hiciste apra poder ver las librerias qeu se incluyen, los pasos a seguir para habilitar el usb por interrupcion y todo ello.

No es necesario, Cryn.
Las librerías usadas son las mismas.
La interrupción usb es habilitada con la llamada a usb_tasks() si no recuerdo mal. Aún sin ser consciente de ello, la interrupción usb ya se produce y se atiende aunque hagas polling con la función kbhit(), sólo que no tienes control sobre ella.

[Cryn]

gracias por la respuesta Modulay.

Me quedó una duda más, si mal no recuerdo si hago USB como en uno de los primeros hilo sobre usb (J1M, creo que lo desarrollo muy bien) incluyendo todas las librerias y ejecutando las funciones necesarias el espacio de ROM (FLASH) que se usaba era de más o menos 50% del total, y ahora viendo tu codigo no ha ocupado ni el 20%, quizá sea por el micro que usaste, es mucha la diferencia de FLASH entre el 4550 y el micro que usaste?

dejame ver si he entendido bien, esto qeu desarrollaste utiliza interrupcion en USB, verdad? y al parecer ocupa menos FLASH? o es que me confundí?

un saludo

[Modulay]

El micro que usé es distinto,sí.
Concretamente,es el 18F66J50.De ahí que las cuentas no te cuadren.
El consumo de memoria de programa no varía por enfocar el uso del usb gestionando tú mismo la interrupción...lo que sí puedes optimizar de forma considerable es el gasto de RAM, ya que ccs, por defecto, la administra de forma pésima cuando se habilita el usb (aunque eso tiene más que ver con la gestión de los búferes que con la interrupción en sí).
Ese tema también se trató en este hilo.

[Cryn]

vale, si en efecto consume algo más de RAM, ya me fije en mi trabajo que hice hace tiempo.

Tengo unas nuevas duda, disculpa la insistencia y molestia.

Las rutinas que te debes traer a tu fichero principal (si lo haces de la forma que yo sugerí) y el resto de rutinas que se usan para la inicialización del usb hacen uso de otras rutinas contenidas en las librerías, por lo que las invocaciones a éstas no pueden faltar.

cuando dices traer te refieres a copiarlas o a moverlas, yo supongo que debe ser moverlas, o no?

si no me equivoco J1M modificó una parte de las librerias, esto afectará? pues estos usando lo que alguna vez J1M nos dejó, o uso netamente lo que nos da CCS?

Todavía no me queda claro lo de los endpoints, si podrías decirme porfavor que enpoints usaba J1M y si estos se deben especificar en el programa de la PC al momento de enviar y recibir datos? como te mencione creo que solamente usaré un buffer de Salida y otro de entrada, pero en la PC no me queda claro.

Agradezco tu ayuda y tu tiempo Modulay, un saludo

[Modulay]

No puedes tener en tu código dos rutinas con el mismo nombre.Por lo que deberás moverlas,no copiarlas.

Que yo recuerde, las modificaciones que hizo J1M consistían únicamente en los descriptores de dispositivo. Dependiendo del tipo de dispositivo que vayas a implementar (CDC,MSD,AUDIO,HID,etc..) y de otras cuestiones como el tema de endpoints, dichos descriptores deben tener una estructura y contenido concretos.

Del lado del host, no recuerdo el modo de gestionar los endpoints, pero por lógica, también se deberían poder gestionar de forma independiente, es decir, recibir y/o enviar cada vez por un endpoint concreto.

Esto de los endpoints, mirándolo del lado del pic, imagínalos como si se tratara de usarts. Cada endpoint es una usart...con sus registros de control (descriptores de buffer), sus registros de dato (buffers),etc...la diferencia radicaría en que todos los endpoints lanzan una misma rutina de interrupción, y de la forma que yo implementé el tema, el endpoint responsable de la interrupción estará indicado por el parámetro "en" de la rutina "datos_endpoint(en)", por lo que sabrás a donde tienes que ir a buscar los datos que te han llegado cuando dicha interrupción se produzca.
Si sólo vas a usar un endpoint, pues dicho parámetro te es supérfluo.