View previous topic :: View next topic |
Author |
Message |
biomed12
Joined: 05 Feb 2016 Posts: 33
|
18f4620 PLL Configuration |
Posted: Sun Aug 21, 2016 4:33 pm |
|
|
Hello,
I want to run 18f4620 at 40Mhz. Is this configuration enough for it and does compiler detect automatically configuration? When i was studying with 18f4550 i was adding some fuses like
#fuses hspll,pll5 //etc...
http://i.hizliresim.com/WbnGzP.png
note: I read 18f4550's datasheet. |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1934 Location: Norman, OK
|
|
Posted: Sun Aug 21, 2016 5:00 pm |
|
|
If you look in the device header (h) file you will find those fuses won't work.
Using a 10MHZ xtal, this fuse configuration worked for another user:
Code: | #fuses H4, NOWDT, NOBROWNOUT, NOPUT, NOLVP, NOMCLR
#USE delay(crystal=10Mhz, clock=40Mhz)
|
BTW, I found this in about 3 minutes using the forum search...try it sometime. _________________ Google and Forum Search are some of your best tools!!!! |
|
|
biomed12
Joined: 05 Feb 2016 Posts: 33
|
|
Posted: Sun Aug 21, 2016 5:29 pm |
|
|
dyeatman wrote: | If you look in the device header (h) file you will find those fuses won't work.
Using a 10MHZ xtal, this fuse configuration worked for another user:
Code: | #fuses H4, NOWDT, NOBROWNOUT, NOPUT, NOLVP, NOMCLR
#USE delay(crystal=10Mhz, clock=40Mhz)
|
BTW, I found this in about 3 minutes using the forum search...try it sometime. |
Thanks. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19551
|
|
Posted: Mon Aug 22, 2016 1:27 am |
|
|
Also the obvious comment:
Quote: |
note: I read 18f4550's datasheet.
|
Why?.
You have a 18f4620. It is this chip's data sheet you need to read. The 4550, in common with most of the USB PIC's has much more complex clock settings to generate the USB clocks. Data from this chip is no use at all for the 4620.... |
|
|
biomed12
Joined: 05 Feb 2016 Posts: 33
|
|
Posted: Mon Aug 22, 2016 1:50 am |
|
|
Ttelmah wrote: | Also the obvious comment:
Quote: |
note: I read 18f4550's datasheet.
|
Why?.
You have a 18f4620. It is this chip's data sheet you need to read. The 4550, in common with most of the USB PIC's has much more complex clock settings to generate the USB clocks. Data from this chip is no use at all for the 4620.... |
Haha sorry Ttelmah. Just a wrong writing. It is 18f4620... If you study so much, you can do some simple mistakes like this.
Thanks for caution. |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Mon Aug 22, 2016 7:48 am |
|
|
I'd like to add that in my experience,
the entire 18Fxx5x family of parts :
have little available program memory (when USB is enabled )
problematic - in either case
are buggy - errata wise
provably worthless - in new designs
and just all around waste of time & space in any project.
Better to use hardware mediated USB like the FTDI family
and let the pic do what it does best. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9246 Location: Greensville,Ontario
|
|
Posted: Mon Aug 22, 2016 8:54 am |
|
|
yup, asmboy, hit the nail on the head especially about the USB section ! When you factor in the hardware for USB (connector, resistors, caps), LEDs, as well as PCB layout.. it's a LOT cheaper to just buy a $2 TTL<>USB module !
BIG benefit...they work out of the box AND save a LOT of PIC memory !
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19551
|
|
Posted: Mon Aug 22, 2016 1:46 pm |
|
|
I think the amount of memory is much overstated.
I have a project here at the moment. Has BlueTooth, USB MSD, SD card, I2C to a number of other boards, GSM/GPRS. Merrily fits in a 47J53. Still under 50% ROM. RAM is getting slightly tight, but when you are moving 512byte sectors, both to the file-system on the SD, and to the USB, while also handling serial from the cellphone & the BlueTooth, and data logging to a server via the cellphone (also sending alert SMS messages), quite a bit of RAM is going to be used. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9246 Location: Greensville,Ontario
|
|
Posted: Mon Aug 22, 2016 4:31 pm |
|
|
hmm, I remember when the 4550 came out and pretty sure the CCS drivers for USB took about 1/3 of ROM. Now I never 'trimmed' down the driver, instead stood back, looked at the cost/benefits of using a ready made TTL<>USB module vs a PIC with USB peripheral PLUS additional hardware and felt the $2 was money well spent as it also freed up a LOT of code space.
Perhaps the CCS drivers are 'trimmed' now ?
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19551
|
|
Posted: Tue Aug 23, 2016 12:18 am |
|
|
Yes. This was documented some time after the drivers launched. They now offer an option to optimise for ROM or RAM use, and are 'slimmer' for both. Still a large slice compared to simple things like serial, but much less than they were at the start. I remember posting about this several years ago here.
The simple drivers like CDC, can be got working effectively 'instantly', so it is a question of whether you are happy to accept perhaps a couple of thousand words ROM use, and just needing a connector (and the constraints on board layout for this), versus the external module.
Now conversely USB host is a pain. I'm not surprised CCS haven't implemented a driver for this. The MicroChip versions I have tried all have problems, and use a huge amount of ROM.
So choices are:
1) For slave. External module - say $2.50 in one off. Only a few hundred bytes of ROM needed, for basic control code and serial. Fastest way to start.
2) For slave. Use the internal USB peripheral. Connector perhaps $0.50. Couple of Kwords of ROM used. Puts responsibility on you to layout the tracks properly. Will need USB sense resistors. 4 pins lost on the PIC (two for USB data lines, Vusb, and one for connection sense). Also forces particular clock selections. With layout done properly, can be running in the same time as 1).
3) For host. Use external module. Same price comments. A little harder to get working - depends on what you want to talk to. Simple devices like a flash drive have good support, and are easy.
4) For host. Use internal peripheral. Can increase the clock selection complexity (some of the later USB PIC's allow operation off the internal clock as a slave, using synchronising to the USB bus itself - this can't be done on a master). Code is massive. At least 2* the slave code for even the simplest device. Code is also unreliable - look at the number of revisions the MicroChip code has been through - every one has problems with some devices....
You 'takes your choice'. |
|
|
|