 |
 |
| View previous topic :: View next topic |
| Author |
Message |
art
Joined: 21 May 2015
Posts: 181
|
| <usb_cdc.h> RAM & ROM usage |
 Posted: Sat Jan 02, 2016 4:39 am |
 |
|
Hai,
I would like to know is there is any other method rather to used library "#include <usb_cdc.h>". I found that when I add this library it will increase ram to 21% and rom 13% to my project. I'm using PIC18F4550 and my project is using virtual COM port by USB. Is there is any smaller library that i can used to replace it ? |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19542
|
|
| Posted: Sat Jan 02, 2016 5:00 am |
|
|
Not really. USB is _big_.
The driver is a lot smaller than it used to be, the driver now optimises lots of things, and is about 25% smaller than it was a while ago. 13% ROM is actually tiny when you consider what it has to do. The Microchip driver defaults to using slightly more...
However you can change the size depending on whether ROM or RAM is your problem "#define USB_OPT_FOR_ROM FALSE", set before you load the USB driver, will reduce the amount of _RAM_ used, but at the cost of extra ROM (This defaults to 'TRUE' to reduce ROM). However USB always uses quite a lump of RAM, since the hardware shares a significant buffer.
This is why some people here, will say "just use an external FTDI USB to serial chip/board". Suddenly only a few bytes used....
Alternatively switch to a chip like the 46J50, and you have twice as much ROM, and nearly twice as much RAM.... |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9244
Location: Greensville,Ontario
|
|
| Posted: Sat Jan 02, 2016 6:49 am |
|
|
I'm one of the guys that uses a USB<>TTL module. When I started using the 4550 I too saw the PIC mem resources being used up by USB. Back then the modules were $5( now $2 each, qty 1).
Yes, it costs a bit BUT consider hardware...
1) you need the USB connector($).
2) you have to connect it(4+ wires,best get them right !).
3) some passives(R,C,etc), more $
4) space/layout costs time ($$$).
As for software, here's where you really win !
ALL the USB code is in the module, so you 'gain' 1/3 of ROM and a lot of RAM for YOUR code not the USB drivers.
Overall using the module saves a LOT of R&D time and you only live so long ! You could easily spend a WEEK getting your project right,first thinking software(driver issues) only to discover D-,D+ is supposed to be D+,D-. Now if you'd used a module ,in 5 minutes your project would be running! Cost of a project includes 3 things, hardware,software and time and there's a 'balance' between them. I prefer to pay a bit more for stable,rugged hardware that allows software to be coded fast, getting product out the door !
Jay
I have maybe 20 of them in projects about the house, all have always worked, all made in China. Each comes with connector,2 LEDs( pwr, data),5to3V reg,'magic USB' chip and 5 pin interface. If your power use is low, you can run right off the USB of the PC,having both 5 and 3 means you can use a 3V PIC with 3V devices(GPS ?) without logic level conversion !
Space is NOT an issue with me, I prefer roomy enclosures,big PICs and 4by6 protoboards as I always need 'something' else for the PIC to connect to ! I also use 'huge' batteries when coin cells 'should' power the device. |
|
|
art
Joined: 21 May 2015
Posts: 181
|
|
| Posted: Sat Jan 02, 2016 8:05 am |
|
|
Hai Ttelmah,
Thank you very much for your explanation. I think the best decision is to use a usb module as you mention. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Jan 02, 2016 2:06 pm |
|
|
CCS has a feature called: #opt compress
It will reduce your program size about 15%. I have verified this, but I
have not examined the effects in detail. It only works with the 18F PICs,
or with enhanced PIC16 chips.
There have been some problems with it, as evidenced by this statement
on their versions page:
| Quote: | | 5.051 Fixed a bug when #opt compress is used on some programs |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19542
|
|
| Posted: Sat Jan 02, 2016 3:10 pm |
|
|
The existing ROM usage is only 13%. The saving on this is under 2% on the total size (the library still uses over 11%), and in the past it has always given me problems....
Gave up on this a few versions ago, but might be worth trying with the recent fix. 
I might try some experiments. |
|
|
art
Joined: 21 May 2015
Posts: 181
|
|
| Posted: Sat Jan 02, 2016 4:05 pm |
|
|
Hai,
I've tried to include "#define USB_OPT_FOR_ROM FALSE" in my code, but the result is same as without it (25% RAM, 18% ROM)
| Code: |
#include <18F4550.h>
#define USB_OPT_FOR_ROM FALSE
#fuses HSPLL,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN
#use delay(clock=48000000)
#use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7)
#include <string.h>
#include <input.c>
#include <stdio.h>
#include <stdlib.h>
#include <usb_cdc.h>
void main(void)
{
int8 binary_string[10];
char c;
usb_init_cs();
while(TRUE)
{
usb_task();
If(usb_cdc_kbhit())
{
c=usb_cdc_getc();
if (c=='\n') {putc('\r'); putc('\n');}
if (c=='\r') {putc('\r'); putc('\n');}
while(true)
{
printf(usb_cdc_putc,"Enter 8 binary number : \n");
get_string_usb(binary_string,9);
output_D((int8)strtoul(binary_string,0,2));
}
}
}
}
|
|
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Jan 02, 2016 4:51 pm |
|
|
We were talking about trying this (in bold):
But, only if you have compiler vs. 5.051 or later.
| Quote: | #include <18F4550.h>
#opt compress
#fuses HSPLL,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN
#use delay(clock=48000000)
#use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7)
#include <string.h>
#include <input.c>
#include <stdio.h>
#include <stdlib.h>
#include <usb_cdc.h> |
|
|
|
art
Joined: 21 May 2015
Posts: 181
|
|
| Posted: Sat Jan 02, 2016 5:08 pm |
|
|
Hai PCM,
My compiler ver 5.008.
I've tried using " #opt compress " , and the result still the same (25% RAM, 18% ROM) .
Can you explain to me, how to upgrade the compiler version ? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Jan 02, 2016 5:34 pm |
|
|
| Normally you have to pay money. |
|
|
art
Joined: 21 May 2015
Posts: 181
|
|
| Posted: Sat Jan 02, 2016 5:46 pm |
|
|
| Ok, if i used ver5.051 or later , do you know what is the final RAM and ROM usage. I hope that you can compile and get the result for me... Please... |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Jan 02, 2016 6:11 pm |
|
|
First I compiled your program from a couple posts earlier in this thread:
| Code: | CCS PCH C Compiler, Version 5.052, xxxxx 02-Jan-16 16:07
Filename: C:\Program Files\PICC\Projects\USB_Test\USB_Test.lst
ROM used: 5816 bytes (18%)
Largest free fragment is 26952
RAM used: 427 (21%) at main() level
509 (25%) worst case
Stack used: 0 locations
Stack size: 31
|
Then I added the line in bold below and re-compiled:
| Quote: |
#include <18F4550.h>
#opt compress
#define USB_OPT_FOR_ROM FALSE
#fuses HSPLL,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN
#use delay(clock=48000000)
#use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7)
#include <string.h>
#include <input.c>
#include <stdio.h>
#include <stdlib.h>
#include <usb_cdc.h> |
And I got the following results:
| Quote: | CCS PCH C Compiler, Version 5.052, xxxxx 02-Jan-16 16:08
Filename: C:\Program Files\PICC\Projects\USB_Test\USB_Test.lst
ROM used: 5346 bytes (16%)
Largest free fragment is 27422
RAM used: 427 (21%) at main() level
509 (25%) worst case
Stack used: 1 locations
Stack size: 31 |
So using #opt compress saves 470 bytes of flash memory.
But, I have not tested this program, so I don't know if it works after
using #opt compress. |
|
|
art
Joined: 21 May 2015
Posts: 181
|
|
| Posted: Sat Jan 02, 2016 6:27 pm |
|
|
Hai PCM,
Thank you very much for the confirmation. However it seems not so much different. Thanks again... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19542
|
|
| Posted: Sun Jan 03, 2016 1:53 am |
|
|
That agrees with what I found before. About 2% reduction in total use for this library.
Remember too that this will apply to your code as well. So code that was using perhaps 90% will only use 80% with this. Means it potentially could save the space of the entire USB library!....
The question is whether it does now work. I tried it a few versions ago, and at that time it looked hopeful, but introduced a couple of problems. What it was basically doing, was quite sensible. I'll try re-compiling that particular project, when I've finished what I'm currently doing, and see if it works. Probably be a couple of days. |
|
|
art
Joined: 21 May 2015
Posts: 181
|
|
| Posted: Sun Jan 03, 2016 5:38 am |
|
|
Hai Ttelmah,
I'm looking forward to know your result after recompiling this project.
Thank you |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
