Printable View
Has anyone tried upgrading an existing 877a design to one with a 18f4620?
The 18f4620 appears to be pin compatible with the 877a, but does anyone know if my PBP code will port over directly?
I'm looking for the extra eeprom and code space the 18F has to offer.
Thanks for any advice
PBP code will port directly from an '877a to an 18F452, and the '452 is pin and register compatible with the 18F4620, so I believe it will work fine.
The '452 instantly doubled my code space so I'm good for now, but if I use that up, I plan to go to the '4620.
The upgrade works just fine. I've built an mp3 player that started out with a 16F877, then to an 18F452, and now it's running from an 18F4620.
The only problems I've encountered are a few bit positions in registers that got moved around a bit, so read your datasheets and make sure everything is accessed in the right spots.
Also, with the 18F4620, there seems to be problems with the SPI port. I can't get mine to work, so I use a software based SPI work around.
Other people will say that the newer PIC chips have problems with losing ram data, code execution problems at high speeds, locking up for no reason, etc.etc. I can say from extensive experience on a dozen or so completely different projects in various operating environments from battery powered living room types to underhood automobile data loggers to outdoor projects in the past 3 years, I haven't had any of these problems that others have had. Maybe it's because I've got plenty of bypass cap's around the PIC, maybe a steadier power supply, maybe because I read the fine print in the datasheets and take note on problems that have occurred in the past that others have learned from, I don't know.
In short, yes, the PBP code should port right over...as long as you keep track of your registers and various bit positions like I said earlier...
JDG
Hi, I am also going to migrate from 16F877A to 18F4620 in a near future. I have seen some lock-ups and resets on the 877A due to ESD (it is extremely dry here), I have ESD protection on all connectors but the spike still resets the PIC. Would you please share your successful bypassing with me and others.
How did you connect MCLR?
How many caps and what kind/size do you recommend using to bypass VDD to the pic?
All help is greatly appreciated!
/p
Thanks for the quick responses, I tried compiling my 877a program with the 18f4620 and it seems that I do have some register issues, but they should be easy enough to work around.
I didn't do anything wierd, just what's been known to work since whenever...
.1uf caps on both sides of the PIC, or wherever there is a power pin or ground...
the clock circuit, whether it be an oscillator chip or a crystal stays relatively isolated from everything else...
a good fat cap on the power supply output, even if it's a battery pack, along with a middle sized and a smaller one near the output before it even gets close to the PIC...
a few .1uf scattered here and there wherever I thought they might do some good around the circuit board, whether that be an actual PCB, a solderless breadboard, or a soldered perf-board matrix...the only drawback to all of those capacitors everywhere is that your initial load on the power supply is a bit big when initially turned on...
and lots of ground lines. Don't daisy chain grounds or power lines. That's a sure recipe for wierd stuff happening.
Again, nothing wierd here, just a bit of overkill I guess...
JDG
I do all the things that skimask describes and I've never had any ESD and lockup propblems either.
One additional thing I do is put a DS1233 reset generator chip on the MCLR pin. This assures a proper reset and restart if any spikes do occur. I've been doing it as standard operation procedure for years without problem.
Note: you will also need to insert two diodes, in an 'AND' fconfiguration, between the MCLR pin and the reset generator and MCLR line so that the bootload reset cycle won't invoke an unitended 350mS delay from the reset generator.
I can post a schematic if you would like to see what I'm referring to.
I would appreciate a schematic of what you are describing, with 2 diodes helping the bootload issue.
Schematic attached.
The double diode doesn't "help the bootloader". What it does is prevent the reset generator from interfering with the bootloader.
The reset generator helps prevent spurious PIC operation in the presence of "dirty" power, or start-up transient spikes. I once designed a PIC circuit that was powered by 110VAC. Everytime I switched on the power, the PIC would go "off in the weeds". This reset generator circuit solved the problem beautifully, and I've stuck with it ever since.
This particular reset generator imposes a 350mS delay upon power up and "other" power line disturbances, as well as debounces the reset switch. Note: there are other reset generators out there with shorter delays if 350mS is too long for your application.
When the bootloader "wiggles" the MCLR line, as part of it's normal start-up process, this would invoke a "fresh" (and undesirable) 350mS delay, from the reset generator, on the PIC reset pin if the double diode weren't there. Note: it doesn't have to be the BAT54 series diode, but it should be the Schottky type.
Newer PIC devices have brownout protection that may obviate this circuitry. I've just always used this circuit to solve a host of start-up and voltage transient problems.
Quote:
Originally Posted by skimask
hi skimask,
is it possible if you can share your mp3 project, im also planning to build one, i already have a VS1001 mp3 decoder.
thanks
Can you exactly define share?
As with soooo many things, do you want me to come over to your house to design and build it for you? Or would you like advice at various times when a difficult issue comes up that seems unresolveable?
If it's the first choice, as it has been practically every time I get an email on the subject, then forget about it...
If it's the 2nd choice, then I'd be happy to start a whole new thread on the subject. But, for a taste, go to www.srt.com/~jdgrotte and hit the mp3 player link on the left. I don't use a VS1001 in my design, but I've heard the earlier versions are a bit tempermental, so I guess I can't comment on that chip without all relavent facts. The STA013 isn't without it's own problems, specifically, you have 'bootload' some code to it to get it to function properly at higher bit rates.
And yes...I am being sarcastic...
and no...these comments are not a personal attack against 'ferds' but are a general statement about the lazyness of people overall...
'nuff said? Good...
JDG