Pieter Hoeben wrote:

> 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.

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.

On Sun, 8 Feb 2004 20:15:19 +0000, Chris Hills <chris@phaedsys.org>
wrote:
>No, despite the Keil compiler being VERY efficient, there are many 8051
>programs that use more than 64K 

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
http://www.hoeben.com

R Adsett wrote:

> In article <40265f48_3@mk-nntp-1.news.uk.worldonline.com>,
> ian@ruffrecordsDOTworldonline.co.uk says...
>> R Adsett wrote:
>> 
>> > In article <rAh4j2BjNlJAFA2P@phaedsys.demon.co.uk>, chris@phaedsys.org
>> > says...
>> >> Personally I am with you on this one if it is over 64K and you can't
>> >> use one of the parts over 64K linear addressing (of which there are
>> >> quite a few now) you should move to a larger MCU The problem is that
>> >> there is an investment in the tools and the current system that does
>> >> not warrent porting to a new MCU
>> > Are there really very many places now where a systems with 64K
>> > addressing that needs more where it's actually easier and cheaper to
>> > introduce bank switching than it is to switch to a processor with a
>> > larger address range?
>> > 
>> > Robert
>> 
>> The only sort of thing I can think of where you would need perhaps more
>> than 64K *code* (not data like screen text/graphics) would be some very
>> complex algorithm or protocol (like ppp).
>> 
> 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

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

In article <40265f48_3@mk-nntp-1.news.uk.worldonline.com>, 
ian@ruffrecordsDOTworldonline.co.uk says...
> R Adsett wrote:
> 
> > In article <rAh4j2BjNlJAFA2P@phaedsys.demon.co.uk>, chris@phaedsys.org
> > says...
> >> Personally I am with you on this one if it is over 64K and you can't use
> >> one of the parts over 64K linear addressing (of which there are quite a
> >> few now) you should move to a larger MCU The problem is that there is an
> >> investment in the tools and the current system that does not warrent
> >> porting to a new MCU
> > Are there really very many places now where a systems with 64K addressing
> > that needs more where it's actually easier and cheaper to introduce bank
> > switching than it is to switch to a processor with a larger address
> > range?
> > 
> > Robert
> 
> The only sort of thing I can think of where you would need perhaps more than
> 64K *code* (not data like screen text/graphics) would be some very complex
> algorithm or protocol (like ppp). 
> 
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

tanya wrote:

> "Frank Bemelman" <fbemelx@euronet.invalid.nl> wrote in message
> news:4026d97f$0$89909$1b2cd167@news.wanadoo.nl...
>> "Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> schreef in bericht
>> news:4026d49f_2@mk-nntp-1.news.uk.worldonline.com...
>> > Frank Bemelman wrote:
>> >
>> > > "Jim Granville" <no.spam@designtools.co.nz> schreef in bericht
>> > > news:5VyVb.21782$ws.2862694@news02.tsnz.net...
>> > >> Ian Bell wrote:
>> > >> >
>> > >> > 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.
>> > >
>> > > 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.
>> > >
>> > >
>> >
>> > 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.
>>
>> 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.
>>
> 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

"Frank Bemelman" <fbemelx@euronet.invalid.nl> wrote in message
news:4026d97f$0$89909$1b2cd167@news.wanadoo.nl...
> "Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> schreef in bericht
> news:4026d49f_2@mk-nntp-1.news.uk.worldonline.com...
> > Frank Bemelman wrote:
> >
> > > "Jim Granville" <no.spam@designtools.co.nz> schreef in bericht
> > > news:5VyVb.21782$ws.2862694@news02.tsnz.net...
> > >> Ian Bell wrote:
> > >> >
> > >> > 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.
> > >
> > > 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.
> > >
> > >
> >
> > 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.
>
> 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.
>
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

"Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> schreef in bericht
news:4026d49f_2@mk-nntp-1.news.uk.worldonline.com...
> Frank Bemelman wrote:
>
> > "Jim Granville" <no.spam@designtools.co.nz> schreef in bericht
> > news:5VyVb.21782$ws.2862694@news02.tsnz.net...
> >> Ian Bell wrote:
> >> >
> >> > 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.
> >
> > 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.
> >
> >
>
> 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.

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)

Frank Bemelman wrote:

> "Jim Granville" <no.spam@designtools.co.nz> schreef in bericht
> news:5VyVb.21782$ws.2862694@news02.tsnz.net...
>> Ian Bell wrote:
>> >
>> > 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.
> 
> 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.
> 
> 

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

"Jim Granville" <no.spam@designtools.co.nz> schreef in bericht
news:5VyVb.21782$ws.2862694@news02.tsnz.net...
> Ian Bell wrote:
> >
> > 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.

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)

"Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> schreef in bericht
news:402689e7_3@mk-nntp-1.news.uk.worldonline.com...
> Frank Bemelman wrote:
>
> > For instance a vending machine for beverages. Does it have
> > the soup thing, the mocca, the expresso-option, the ATM link,
> > the money-changer, etc. It can be handy to have one single version
> > of software and a configuration menu that enables the fitted
> > options.
>
> That makes sense to me but, within the limitations of the peripherals
> available with a single chip mico like an 8051, I still find it hard to
see
> how these variants could need 64k code.  For example, a long time ago I

Single chips, okay, but the old 8051 or 80552 perhaps can serve
hundreds of IO's if you sacrifice a handful of address.

[snip]

> > I have written software for counting systems, but you could
> > have a belt feeder, a vibrating feeder, a long one or a short
> > one, one with 7-8-9-10-12 gutters, catch valves, infrared
> > counting curtain, capactive counting sensors, output conveyor,
> > output collectors, remote control, etc. I believe there were
> > over 400 possible combinations, and I didn't want to write
> > some 400 more or less identical programs, or 400 different
> > makefiles, not to mention the hassle it gives to ensure the
> > product gets shipped with the correct software. It required
> > a lot of thinking, where to put what, but I think that actually
> > helped setting up a good structure for the program. And it
> > really was a life-saver when more generic bells and whistles
> > were added.

> Very interesting.  What were the hardware impilcations of catering for all
> these variants?  How did you let the software 'know' what hardware it was
> connected to?  Was this all achieved from the peripherals of a single chip
> microcontroller?

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)