No, despite the Keil compiler being VERY efficient, there are many 8051 programs that use more than 64K
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
Don't get me wrong, I don't doubt what you say is true, I am just trying to get a better understanding of why they should end up so large.
Ian
There are many reasons you can get > 64K. You are right that the apps may NOT have > 64K of actual *code*, but that's moot point if string constants reside in code space.
Typical things that can push the total memory map up are
- Multi langage support
- Multi model/variant support
- Inclusion of Test and config codes
So, one could get (say) a 144K application footprint, but a single customer may only use/see 30-40K of that.
The market segment is not tiny : for a device that targets >> 64K 80C51 applications specifically, see
-jg
see
Single chips, okay, but the old 8051 or 80552 perhaps can serve hundreds of IO's if you sacrifice a handful of address.
[snip]
The hardware was a board of 4 inch x 10 inch perhaps, RS485 for user terminal and one or two (intelligent) sensor arrays, and
30% of the board was occupied with just connectors for easy wiring of various sub parts. The configuration was done by answering a list of simple questions, in a service menu. Typically yes/no questions, and some open questions, such as a length of a conveyor belt etc. Stored in eeprom and written on a sticker inside the machine too. This application was ~60K - no need for bankswitching. Not much text, ~4K perhaps. 128K battery ram, with one bankselect, which was also storage for statistical data. 4 extra analog IO, and 24 digital inputs and 16 outputs.-- Thanks, Frank. (remove 'x' and 'invalid' when replying by email)
trying to
Yes, I had for instance a build-in 'oscilloscope' to help the more technical inclined operators adjusting a particular sensor. It took 4K of code, which is a lot if you only have 64K to play with. 99% of the customers never use it. All such things add up. The first version of the machine shipped used only 20K.
-- Thanks, Frank. (remove 'x' and 'invalid' when replying by email)
This raises another intersting point. With a code footprint of over 64K but customers only requiring 30 to 40K of it plus the ready availability of flash versions suggests building specific code for a customer in a smaller flash device.
Ian
but
That could be done, but may not be practical. Building special versions and keeping track of it, can take a lot of time. Even if you sell only ten systems per week, you would spend all your time keeping reasonable files on issued software. I hate the paperwork already ;) The advantage of one piece of software is tremendous. For instance if you fix a bug or add a feature, every newly released machine will profit from that.
-- Thanks, Frank. (remove 'x' and 'invalid' when replying by email)
smaller
I agree with Frank. You would have to repeat the testing phase for each customer, thus things could quickly become uneconomic. Do you fix bugs reported by customer A only in the A code version, or do you propagate the bug fix through all versions? I can see a configuration nightmare developing very quickly.
Tanya
This depends on how many variants you decide to have and the quantities you supply. For 10 a week I agree it is not worth it but for 1000 a week if you save just $1 by using a smaller part then you have to seriously consider splitting over 64K of code in to a few sub 64K major variants.
Ian
Not the answer to the question I meant to ask. There certainly are cases where you have more than 64K code or data. But, given that you have a system that used to fit within the 8051 address space w/o bank switching and now doesn't, is it really easier to add bank switching than to switch to a processor with a larger address space?
I can see that the answer might be different for different circumstances IE code or data explosion, amount of assembly, dependance on certain peripherals, but I'm curious as to the reasoning behind implementing bank switching rather than switching processors.
Robert
Hi, mostly the reason that htey don't want to change to another processor is that the expensive development setup they allready have would be "wasted". Much better to waste money by sticking with "what you know" and cripple your product at the same time.
I would explore other alternatives first. Don't forget the 8051 has a Harvard architecture so if you have lots of data for example there most of the 64K data space avaialable for it without the need to resort to bank switching.
Ian
Hi, yes, the Keil compiler is efficient (as efficient as my old PLM compiler). But the structure of code you build with it isn't. 8051 and C are not made for each other. The way you think is different. In C you think like working in a very stack-oriented processor, but the
8051 is very register based. That is why you get other programs and larger code.Pieter Hoeben
I don't think this is strictly true. An important part of the process for embedded programming is to, where appropriate, maintain awareness of platform-imposed requirements.
How a programmer thinks is under the control of the programmer, not the programming language.
-- Morris Dovey West Des Moines, Iowa USA C links at http://www.iedu.com/c Read my lips: The apple doesn't fall far from the tree.
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.