Need to run old 8051 firmware
in [Embedded]
|
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
From: -jg on 23 Apr 2010 19:36
On Apr 24, 11:08 am, An Schwob in the USA <schwo...(a)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 |