Prev: Developin tool for Xilinx XC2018
Next: clock routing to generic IO pins?
From: Chris H on 21 Apr 2010 03:25
In message <1771ba54-e12f-44ba-af73-1cebb0cb2182(a)11g2000yqr.googlegroups
..com>, Derek Simmons <dereks314(a)gmail.com> writes
>On Apr 19, 9:53�am, "Smith" <sm...(a)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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



From: Tilmann Reh on 21 Apr 2010 05:09
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
From: Chris H on 21 Apr 2010 07:00
In message <hqmfbt$g77$1(a)news.eternal-september.org>, Tilmann Reh
<usenet2007nospam(a)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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



From: Tilmann Reh on 21 Apr 2010 12:29
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
From: An Schwob in the USA on 23 Apr 2010 19:08
On Apr 19, 6:53 am, "Smith" <sm...(a)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?

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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Developin tool for Xilinx XC2018
Next: clock routing to generic IO pins?