Unless you have an FPGA implementation of /exactly/ the 537, it probably won't work. Remember that this MCU also contains very many special function registers that most probably are used by the software, but not covered by the available, more "generic", IP cores.
Several thousand lines of 8051 assembly, however, don't appear too much to port. If you have the sources (as it sounds), you can probably find the SFR-relevant code sections rather easily and port the application (still in assembly language) to your new implementation on any current
8051 - or an IP-core in an FPGA.
Unless you have an FPGA in your new design anyway, I would however suggest to look for a new flash-based 8051 MCU. It will probably be less porting expense. Have a closer look /why/ the 537 was choosen for this application - was it the number of ports, or any special peripheral hardware function? Get a modern chip that fits these requirements best.
"Without any changes to the code" is not possible IMHO.
There are lots and lots of MCS-51 microcontrollers still on the market. Silicon Labs, Atmel, and Infineon among many others. I'd look there first, before committing to instantiating an FPGA core.
Note that you still have a lot of road ahead of you, should you go down this path. Recall that you will also need to design the various "integrated I/Os" in that '51 variant. And, *hope* there are no subtle timing exploits used in the code.
"Several thousand rows (?)" of assembly language isn't a particularly big design. *If* you have the sources
*and* the schematics *and* knowledge of the application domain, this would probably be easier to reimplement from scratch.
If you *don't* have the sources, but *do* have the other two items, you can mechanically reconstruct them and back-annotate as appropriate (to add semantic value).
If you have only knowledge of the application domain, then you have to deduce the hardware requirements as you are back-annotating. Your knowledge of what the device is likely *trying* to do gives you the foundation for these deductions.
This last case is the most challenging though it is still do-able. When I bid reverse-engineering jobs like this, I figure on generating commented source code at a rate of about 2-4KB/week. So, a 16K image is only a month or two from start to finish. (If the image was created by a
(a) Why try to rewrite this in C? Why not port this to a new 8051 using the existing code as a base? If the code is well written and commented then the only parts that will have to be changed will be the parts that talk to hardware, although depending on the code and the application this may take some head-scratching.
(b) You're probably far better off to make this work with some new spin of an 8051, with the peripherals that you need to get the job done.
(c) I could easily see trying to exactly replicate an old application, complete with snazzy peripherals and maybe timing loops, to be a never-ending hassle. You know the old saw about the last 10% of the work taking 90% of the time? I think this would be a way to design a project where the last 1% of the work takes 99% of the time. If I'm wrong, it'd only be because you'd see the last 0.1% of the work taking
99.9% of the time.
Software is cool because it's easy to change, so you can use it to help your product dodge around changing marketing requirements and hardware issues. Chaining your whole project to a large chunk of dead code is just asking for a nightmare.
--
Tim Wescott
Control system and signal processing consulting
I'd try tweaking firmware first. Looks like this one is not standard 8051 deriviative. Has 32bit math MDU and 8 DPTR registers.
First thing I'd do is see if these odd features are being used. If not, it would be easy to port to another 8051 derivative. If so, porting challenge could range from a minor hassle to impossible. Then C port might be way to go.
I'd get a good firmware engineer to evaluate code before moving forward.
Perhaps a brief explanation of why might have been useful. Need to make some more old units, need to upgrade for a newer product?
One application I did many years ago was all hand-coded 6800 machine code. About 4k of it. This was input to the system by the switch and step method. So in an actual assembler, this should not be too much of a hassle even if the code is 2 or 3 times that size.
Others have indicated that the parts are available from at least one stockist. Unless you need special certification of the parts that would seem to be the way to go to make more of an old product.
On the other hand, if this is an update of the product-line then it would be much wiser to bite the bullet and select a more recent part offering that gives you the facilities you need. Then set to and understand the assembly code listing so that you can re-work the system and improve it as you go.
--
********************************************************************
Paul E. Bennett...............
But that may be the cheaper option. Yes, I have done it before.
You can't do it. Simple as that. There are some 50+ 8051 cores. All different. From the standard 12 to 1 cycle systems.
On top of that they had different peripherals. So once you get your core, tune it to be the same as the one Siemens used you then have to get all the peripherals and get them to be have exactly as Siemens did. Then bolt them together.
The faster and cheaper option by far is to reverse engineer the code.
Why do you need to run this firmware? If you need to do 100-200 units to do the same thing go and get a cheap modern core with the same peripheral set. And start again.
This will be faster, more reliable and cheaper.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
First, I'd try and source the real silicon. An FPGA will lack the peripherals, and lacks the Analog options, so a precise clone will be _very_ difficult.
Failing getting the silicon, there are other, newer, parts with similar resources, including newer Infineon parts.
Do you have the ASM source ? How much code space, and is a move to on-chip code ok ?
The 8031/8051 architecture or compatible MCUs are still being used. When I was at KODAK it was used in a couple of different parts of a minilab system for controlling and synchronizing motors. I recently interviewed with a avionics company that uses it for digital displays in the cockpit of the plane (it is easy to get certfied for the FAA).
It does depend on programming /style/ more than on programming /language/.
If the device-related code (peripherals, special functions) is spread over all sources, with inline access/instructions and not commented, it's *much* work regardless of language.
If the code is well structured and commented, with modules dedicated to clearly defined tasks, it's not really a problem - also regardless of language.
For a high level language I would agree but we are discussing "several thousand rows of assembly language".
For most 8051 code the C will be the same for the core and it is only the peripherals that are different. Most of the other stuff like memory allocation and SFR's etc will be handled by the compiler. A recompile with a different 8051 target selected will solve many of the problems. With Assembler you can't do that.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.