Using Visual C/C++ to do 8051 development

In article <40265fc5_3@mk-nntp-1.news.uk.worldonline.com>, Ian Bell
<ian@ruffrecordsDOTworldonline.co.uk> writes
>Chris Hills wrote:
>
>> In article <402645c0_3@mk-nntp-1.news.uk.worldonline.com>, Ian Bell
>> <ian@ruffrecordsDOTworldonline.co.uk> writes
>>>I am curious to know what are the applications that use an 8051 but manage
>>>to exceed its 64K byte code limit and require bank switching.
>> 
>> There are many.
>> 
>> Datalogers and monitors
>> TV and video control systems
>> Security systems
>> F1 cars
>> control systems
>> printers and photocopiers
>> 
>> I have seen back switching in many of these. This is often where a
>> system has grown over the years.
>
>I still find it hard to believe these would need more than 64K of *code* or
>do many fall into the lots of text or graphics data type of application?
>Ian

No, despite the Keil compiler being VERY efficient, there are many 8051
programs that use more than 64K 

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills wrote:

> In article <40265fc5_3@mk-nntp-1.news.uk.worldonline.com>, Ian Bell
> <ian@ruffrecordsDOTworldonline.co.uk> writes
>>Chris Hills wrote:
>>
>>> In article <402645c0_3@mk-nntp-1.news.uk.worldonline.com>, Ian Bell
>>> <ian@ruffrecordsDOTworldonline.co.uk> writes
>>>>I am curious to know what are the applications that use an 8051 but
>>>>manage to exceed its 64K byte code limit and require bank switching.
>>> 
>>> There are many.
>>> 
>>> Datalogers and monitors
>>> TV and video control systems
>>> Security systems
>>> F1 cars
>>> control systems
>>> printers and photocopiers
>>> 
>>> I have seen back switching in many of these. This is often where a
>>> system has grown over the years.
>>
>>I still find it hard to believe these would need more than 64K of *code*
>>or do many fall into the lots of text or graphics data type of
>>application? Ian
> 
> No, despite the Keil compiler being VERY efficient, there are many 8051
> programs that use more than 64K


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

Ian Bell wrote:
> Chris Hills wrote:
> 
> 
>>In article <40265fc5_3@mk-nntp-1.news.uk.worldonline.com>, Ian Bell
>><ian@ruffrecordsDOTworldonline.co.uk> writes
>>
>>>Chris Hills wrote:
>>>
>>>
>>>>In article <402645c0_3@mk-nntp-1.news.uk.worldonline.com>, Ian Bell
>>>><ian@ruffrecordsDOTworldonline.co.uk> writes
>>>>
>>>>>I am curious to know what are the applications that use an 8051 but
>>>>>manage to exceed its 64K byte code limit and require bank switching.
>>>>
>>>>There are many.
>>>>
>>>>Datalogers and monitors
>>>>TV and video control systems
>>>>Security systems
>>>>F1 cars
>>>>control systems
>>>>printers and photocopiers
>>>>
>>>>I have seen back switching in many of these. This is often where a
>>>>system has grown over the years.
>>>
>>>I still find it hard to believe these would need more than 64K of *code*
>>>or do many fall into the lots of text or graphics data type of
>>>application? Ian
>>
>>No, despite the Keil compiler being VERY efficient, there are many 8051
>>programs that use more than 64K
> 
> 
> 
> 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

http://www.st.com/stonline/products/families/memories/psm/upsd3300.htm

-jg

"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)

"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)

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

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

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

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