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
you would find that it is replaced by the P89V51RD2.
Erik
Thanks Eric, our HW guys have lead me to believe it isn't as compatible as we hoped, I'll check it out more.
Don
there is a thread at 8052.com on the differences, I suggest you find it.
as far as HW goes, the main difference is that some 'hardware tricks' are not needed any more, but leaving them in does not hurt.
DO make sure that you are changing from RD2 not RD2H before starting to figure out which changes you need.
NXP offers a 89CV51RD2 that is ROHS and fully compatible with the 89C51RD2
Thanks Erik & Bob, I'll make sure they are planning on using the correct replacement part.
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?"
Yes, you can. why not? Juat a matter of getting C51 with more Memory, timers, and additional required perpherals........
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.
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
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
Thanks Joe & Maaz, I'll check that forum & the ED2 part.
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."
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
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.
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 :-)