¿La librería usb_cdc.h ocupa el 56% de mi memoria RAM?

[BrunoF]

Buenas...

Estoy usando el PIC 18F4550 con CCS 4.049 e hice un programa sencillo en el que sólo incluyo la librería usb_cdc(#include "usb_cdc.h") y, al compilarlo, ¡me dice que tengo el 56% de mi tan apreciada RAM ocupada!.
Entonces, ¿es correcto este valor o le estoy errando en algo?¿Estaré agregando cosas innecesariamente? ¿Tanta memoria devora usar este módulo?

Gracias.

[RedPic]

Si, Bruno. Es un devorador de memoria. De RAM y de ROM. He estado haciendo un proyecto que tiraba de la USART así que he montado el CDC para monitorizar y ... durante el trabajo estaba en torno al 60% de ambas ,RAM y ROM, y cuando quité toda la parafernalia del CDC el Firmware operativo no pasaba del 7%. 

[BrunoF]

Pues entonces es realmente lamentable. Que me use más de 1.1K RAM y 3.6 K Words es una pena. Gracias por confirmar lo peor Diego.  

[RedPic]

Si, y enlazo con otro tema que también me preocupa y que creo que es similar a este. Me refiero a la conexión TCP/IP, que como sabes yo soluciono con un EM232 y que conectado a la USART de mi PIC no me quita ni un gramo de RAM o de ROM, pero parece que si usamos el ENC28J60 tambien usamos RAM y ROM del PIC para el famoso Stack TCP/IP.

¿Sabéis si es muy grande y ocupa mucho? ¿Es devorador?

[LABmouse]

Sip amigo REDPIC, usar el ENC28J60 ocupa casi lo mismo que implementarlo directamente con un PIC18F97J60.

Creo que como algo didáctico va bien pero para cosas comerciales no hay nada como el EM202 para el ETHERNET y el FT232R para el USB.

SALUDOS AMIGOS!

[BrunoF]

Pos ya me lo habías mencionado al FT232R Ernesto y la verdad que cada vez me resulta más factible. Su costo no es tan elevado, y me va a ahorrar más de un dolor de cabeza.

No he mirado si los Buffers del USB exísten físicamente y reservados en el PIC, o se utiliza memoria RAM GPR para ello. Por lo que la librería ocupa, debo suponer que Microchip implementa los módulos pero no los buffers de memoria para ellos. Cosa que es de lo más ilógica(pero obviamente más viable comercialmente por lo visto). Ganamos una extremidad pero nos quita el 50% del tronco...   

Voy a indagar sobre el asunto.

Gracias por la data del TCP/IP también.

Saludos.

[jfh900]

En realidad para mi es un planteamiento equivocado. Cuando montas un EM202 estas montado 2 micros (el tuyo más el del EM202). Por qué no realizar esta arquitectura con dos pic. Un micro con la aplicación que se comunica con un módulo que se encarga de la transmisión que incluye el ENC28J60 y otro micro o un único micro PIC18F97J60 que se encargue de la transmisión.

Un saludo

[RedPic]

Precisamente por esa misma razón de que monto dos micros, el del EM202 ya esta preparado, completo, instalado y funcionando, con utilidades, con soporte técnico, con servicio de actualizaciones y con un plantel de ingenieros en taiwan solo pensando en cómo sacarle mas provecho. Y yo me dedico profesionalmente a mi firmware para hacer lo que yo tengo que hacer, que no es implementar un stack tcp (aunque como aficionado si es algo que me encantaría hacer) 

[jfh900]

Totalmente de acuerdo con el planteamiento.

Un saludo

[LABmouse]

Tambien estoy del mismo lado.. 

[PalitroqueZ]

...
Creo que como algo didáctico va bien pero para cosas comerciales no hay nada como el EM202 para el ETHERNET y el FT232R para el USB.

SALUDOS AMIGOS!

habría que hacer otra comparación: ver si la velocidad de transmisión es favorable en la relación codigo programacion vs ft232r

ojo que no la conozco.