Reply by -jg April 23, 20102010-04-23
On Apr 24, 11:08=A0am, An Schwob in the USA <schwo...@aol.com> wrote:

> So, as pointed out, the lowest cost and by far fastest option is to > find a broker. > Hint: you can use the 80C517 as well because it is drop in compatible. > The EA pin will always be connected for start from external memory > when using a 80C537, so the 80C517 behaves EXACTLY like a 80C537 as > long as the EA pin is not connected to the start from internal ROM > option.
Yes, the 80C517/80C517A may give him enough parts, to not need much Sw effort at all... -jg
Reply by An Schwob in the USA April 23, 20102010-04-23
On Apr 19, 6:53=A0am, "Smith" <sm...@donotwantmail.com> wrote:
> Hello all > > I need to run an old firmware for a Siemens SAB 80C537 microcontroller un=
it
> (MCU). The MCU is now obsolete (it's from the late 1980s). > > The firmware is compiled from several thousand rows of assembly language.=
It
> would take a long time to understand the code and re-program it in C. > > So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware > code without any changes to the code. > > Any one here had any luck with this kind of problem?
My 2 cents. 1. The 537 comes in a 84-pin package, so finding a "modern" part with that much I/O is going to be a challenge, this was a top of the line 51-device in the late 80s 2. It has a MUL/DIV unit to accelerate 32/16 DIV and / or 16x16 MUL, much faster than a library. The only other device I know with the same MUL/DIV unit is the C509, unfortunately that one comes in a 100 pin package and is afaik a true superset of the 80C537. So, as pointed out, the lowest cost and by far fastest option is to find a broker. Hint: you can use the 80C517 as well because it is drop in compatible. The EA pin will always be connected for start from external memory when using a 80C537, so the 80C517 behaves EXACTLY like a 80C537 as long as the EA pin is not connected to the start from internal ROM option. Hope this helps, An Schwob Once upon a time I was an FAE supporting the 80C5x7, I know (knew?) these devices really well ;-) If it comes down to it to re-engineer or port to a different device and you need professional help, write me an e-mail to microcontroller addgmaildotcom
Reply by Dave Nadler April 22, 20102010-04-22
On Apr 19, 10:44=A0am, "Smith" <sm...@donotwantmail.com> wrote:
> I found a company in UK that auto convert 8051 assembly code to C (and th=
en
> hand optimize a few things). > > www.microapl.co.u > > "D Yuniskis" <not.going.to...@seen.com> wrote in message > > news:hqhpi9$f65$1@speranza.aioe.org... > > > Smith wrote: > >> I need to run an old firmware for a Siemens SAB 80C537 microcontroller > >> unit (MCU). The MCU is now obsolete (it's from the late 1980s). > > >> The firmware is compiled from several thousand rows of assembly langua=
ge.
> >> It would take a long time to understand the code and re-program it in =
C.
> > >> So I'm thinking of using an 8051 IP-core for a FPGA and run the firmwa=
re
> >> code without any changes to the code. > > >http://www.opencores.com/project,8051 > > > Note that you still have a lot of road ahead of you, should > > you go down this path. =A0Recall 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. > > >> Any one here had any luck with this kind of problem? > > > "Several thousand rows (?)" of assembly language isn't a > > particularly big design. =A0*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. =A0Your 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. =A0When I bid reverse-engineering jobs like this, > > I figure on generating commented source code at a rate of > > about 2-4KB/week. =A0So, a 16K image is only a month or two > > from start to finish. =A0(If the image was created by a > > *compiler*, my throughput goes up dramatically!)
I used this firm to port some IBM assembler to C. Their tools actually worked well, except for the self-modifying code, which tripped them up ;-) Make sure its a fixed-price contract... The correct URL is: http://www.microapl.com/asm2c/index.html Hope that helps ! Best Regards, Dave
Reply by George Neuner April 22, 20102010-04-22
On Tue, 20 Apr 2010 18:14:05 -0700 (PDT), Derek Simmons
<dereks314@gmail.com> wrote:

Completely off topic, but ...

>I recently interviewed with a avionics company that uses [8031/8051] >for digital displays in the cockpit of the plane (it is easy to get >certfied for the FAA).
I've never heard FAA certification described as "easy". Maybe they rubber-stamp for established vendors and members of the "old boys" club. From what I've heard wandering air shows, they actively prevent small businesses from entering the market. I don't have personal experience with FAA device cert ... I haven't built my plane yet and my pilot license so far has provided quite enough contact with them to satisfy my masochistic streak. However, I have dealt professionally with the FDA, and if the FAA is in any way similar they really ought to be a PITA. George
Reply by Tilmann Reh April 21, 20102010-04-21
Chris H schrieb:

>>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".
Even with several ten thousands rows of assembler that needs not be a problem. BTDT. It's a matter of structure and documentation. (I am still doing many projects completely in assembler.)
> 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.
Even with C you need to access the SFRs (ports, peripherals) somehow. If these accesses are splattered across the whole sources, it doesn't matter if it's C or assembler. Memory allocation is normally uncritical, since that is easily portable between many similar derivatives. Of course, if you previously had a device with large XRAM (being used indeed) and try to port that to a smaller chip, you'll run into problems... But again, in this case C wouldn't help you either. Basically, the part that you can leave unchanged with C, is the same part that you can leave unchanged with assembler. Tilmann
Reply by Chris H April 21, 20102010-04-21
In message <hqmfbt$g77$1@news.eternal-september.org>, Tilmann Reh
<usenet2007nospam@autometer.de> writes
>Chris H schrieb: > >>>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). >>> >>>Don't write it off yet... >> >> There are some 500 variants based on over 40 different cores. Whilst it >> is relatively easy to move C it will be a real dog to moves assembler. > >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 /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by Tilmann Reh April 21, 20102010-04-21
Chris H schrieb:

>>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). >> >>Don't write it off yet... > > There are some 500 variants based on over 40 different cores. Whilst it > is relatively easy to move C it will be a real dog to moves assembler.
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. Tilmann
Reply by Chris H April 21, 20102010-04-21
In message <1771ba54-e12f-44ba-af73-1cebb0cb2182@11g2000yqr.googlegroups
.com>, Derek Simmons <dereks314@gmail.com> writes
>On Apr 19, 9:53&#4294967295;am, "Smith" <sm...@donotwantmail.com> wrote: >> Hello all >> >> I need to run an old firmware for a Siemens SAB 80C537 microcontroller unit >> (MCU). The MCU is now obsolete (it's from the late 1980s). >> >> The firmware is compiled from several thousand rows of assembly language. It >> would take a long time to understand the code and re-program it in C. >> >> So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware >> code without any changes to the code. >> >> Any one here had any luck with this kind of problem? > >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). > >Don't write it off yet...
There are some 500 variants based on over 40 different cores. Whilst it is relatively easy to move C it will be a real dog to moves assembler. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by Derek Simmons April 20, 20102010-04-20
On Apr 19, 9:53=A0am, "Smith" <sm...@donotwantmail.com> wrote:
> Hello all > > I need to run an old firmware for a Siemens SAB 80C537 microcontroller un=
it
> (MCU). The MCU is now obsolete (it's from the late 1980s). > > The firmware is compiled from several thousand rows of assembly language.=
It
> would take a long time to understand the code and re-program it in C. > > So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware > code without any changes to the code. > > Any one here had any luck with this kind of problem?
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). Don't write it off yet... Derek
Reply by -jg April 19, 20102010-04-19
On Apr 20, 1:53=A0am, "Smith" <sm...@donotwantmail.com> wrote:
> Hello all > > I need to run an old firmware for a Siemens SAB 80C537 microcontroller un=
it
> (MCU). The MCU is now obsolete (it's from the late 1980s). > > The firmware is compiled from several thousand rows of assembly language.=
It
> would take a long time to understand the code and re-program it in C. > > So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware > code without any changes to the code. > > Any one here had any luck with this kind of problem?
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 ? -jg