Hello, in an ironic twist, the Philips 89C51RD2 we use for the control panels on Philips CT scanners has been discontinued due to Philips selling it's semi-conductor operations last year. So I was wondering if anyone had a good substitute they had tried ???
Thanks, Don
we occasionally have these threads that are in the wrong category (251 for a 51 here) is there a way to make the main header change?
Erik
one difference, probably the one that hit you is the 6/12 clock switching is not iodentical. The 'C' has a fuse, the 'V' has a SFR.
are you running 6 or 12?
I also believe the default is the opposite.
HOWEVER, to the best of my recollection (I left these for SILabs [needed the speed]} the bits needed for the 'V' are 'don't care' in the 'C'
Has anybody actually used a P89CV51 part. I just got the 1st sample today. It did not drop in and work. Flash magic went thru the motions but the part does not run my application. Instead it appears to send garbage out the serial port and it resets over and over. The only clue i have is that Flashmagic does not report or program the 6/12 clk bit correctly, not sure which. It always reports a 12 clk setting after programming even with the prog clocks box is checked. So i suspect flashmagic is not quite right.
Thanks Bob, I missed the "CV" in your reply on Aug 20. The NXP web-site is such a POS I couldn't find the part number unless I already knew what it was :-)
Please read the note above it is a CV51 not a V or an LV or a C51 ... it is a CV51.
We were equally dismayed when NXP dropped the 89C51RD2. This is their replacement. It is FULLY compatible as far as we have seen.
Hello again, the 89V51RD2 appears to be absolutely NOT fully SW compatible with the 89C51RD2.
Besides any HW differences, anyone using In-Application-Programming (IAP) or has their own downloader for In-System-Programming (ISP), there are differences that can only be resolved by changing and recompiling both the 8051 IAP code & the external ISP downloader code. This would seem to really throw a wrench into the works for anyone without SW support.
In our 8051 application we have an option to change some settings which must be remembered between resets. We store them in an ascending list in unused flash, starting at 0xC000 by enabling the boot-rom code & calling the flash byte program function. They changed the register & bit to enable the boot-rom code from AUXR1.5 (enboot) to FCF.0 (BSEL) They also changed the address of the IAP entry address from 0xFF00 to 0x1F00.
We also have our own ISP downloader in an external device which will have to change since the Specify Oscillator Frequency function is no longer supported. If you have an external downloader which waits for the returned "." as an acknowledge to that command, it will wait forever, since the SOF is ignored.
I'd really like to know why these changes were made since they don't really appear to enhance the functionality of the device any. In addition, there may be other changes that I'm not yet aware of.
Technical Note TN06007 - V51RX2 Migration
www.semiconductors.philips.com/.../TN06007_V51RX2_Migration.pdf
Quoting the NXP website:
"Designed to be drop-in software-compatible replacements for the popular NXP microcontroller P89C51RD2, making it easy to upgrade designs with additional memory, an SPI interface, and faster erase times. Backward-compatible ISP and IAP functions also increase design flexibility."
Thanks Joe & Maaz, I'll check that forum & the ED2 part.
Good Substitute of AT89C51RD2 is AT89C51ED2, which have an additional 2KB EEPROM and no other difference. Same programming procedure through FLIP and it is also easily available. I think no price difference too. Regards
The P89V51 is a good replacement but not fully drop-in replacement.
Both are 80c51 core but there a slight differences.
There is a comparison in the http://www.8052.com forum pages that you can search or ask a question.
Joe
After upgrading to Linux (and its peripherals), I've found the MMU in particular especially valuable in some of my other 8051 projects. It really helps find those places where I didn't use the OVERLAY directive correctly, especially with a couple of hooks into RTX51 Tiny to swap protection on locals for the current call tree. I don't know how I got along without it before.
I also save lots of money on those expensive cross-development tools (sorry, Keil) by just running bash directly on my target and using gcc. I stripped a couple of features I never use out of the bash source so it's only about 500KB now. Gcc itself can be a little big if I compile anything larger than the 4KB Keil eval examples, but I had an extra serial port so I just added a driver to swap out to my USB flash drive. And of course once we've got GCC running, then it becomes pretty painless to switch to C++. One of my colleagues has a cool idea on a way to use template metaprogramming to get our LEDs to blink at compile time.
Yes, you can. why not? Juat a matter of getting C51 with more Memory, timers, and additional required perpherals........
Thanks for the tip on 8052.com, had never heard of it before. I didn't find the thread you were telling me about, but will keep looking. I did get a real hoot out of the FAQ wondering "Can I run Linux on an 8052?"
Thanks Erik & Bob, I'll make sure they are planning on using the correct replacement part.
Don
NXP offers a 89CV51RD2 that is ROHS and fully compatible with the 89C51RD2
View all questions in Keil forum