Prev: linking error in libgcc.a
Next: Simulator/debugger for 80C320
From: Stefan Brröring on 19 Apr 2010 10:39
Look here:

http://www.littlediode.com/components/80C537_Integrated_Circuit.html?NO_COOKIE_WARNING=2&ti=ca697e2b03146363b5a9601ab6592a49&xid=60b420f64a0bf7ac68d8779fdb2b8008
From: Tim Wescott on 19 Apr 2010 10:44
Smith 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?

I'm with the rest of the folks here:

(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
www.wescottdesign.com
From: Smith on 19 Apr 2010 10:43
I need about 100-200 parts.

"Stefan Brr�ring" <stefan___(a)broering.de> wrote in message
news:4bcc68c8$0$3291$8e6e7893(a)newsreader.ewetel.de...
> Do you need one 80537, a few, or lots of MCUs?


From: Smith on 19 Apr 2010 10:44
I found a company in UK that auto convert 8051 assembly code to C (and then
hand optimize a few things).

www.microapl.co.u


"D Yuniskis" <not.going.to.be(a)seen.com> wrote in message
news:hqhpi9$f65$1(a)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 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.
>
> http://www.opencores.com/project,8051
>
> 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.
>
>> Any one here had any luck with this kind of problem?
>
> "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
> *compiler*, my throughput goes up dramatically!)


From: D Yuniskis on 19 Apr 2010 10:57
Smith wrote:
> I found a company in UK that auto convert 8051 assembly code to C (and then
> hand optimize a few things).
>
> www.microapl.co.u

Note that you don't have to "go to C". You can just
leave the code in ASM and tweek the I/Os as needed.

The only advantage to an FPGA approach is if you can
purchase it packaged and bonded out to *exactly* the
same pinout.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: linking error in libgcc.a
Next: Simulator/debugger for 80C320