Using Visual C/C++ to do 8051 development

In article <pan.2004.02.08.12.59.11.558572@albert.amresearch.com>,
Albert Lee Mitchell <albmit@albert.amresearch.com> writes
>On Sun, 08 Feb 2004 10:53:58 +0000, Chris Hills wrote:
>
>> -----------snip--------------
>> With 8051's most good ICEs use EXACTLY the same silicon as the target.
>> There is also often no way to test conclusively without one.  At least
>> this is what I am told by people developing very high integrity and
>> safety critical devices.
>
>       Please name a few, I'm unaware of one that doesn't have drivers and
>receivers nor can I imagine a quasi-bidirectional I/O port pulling up a
>18" tether at 25 MIPS without a driver.


Most 31/32 types use the actual part as a bond out is not required. Also
for all hooks parts the same silicon that is actually on the target.
Further to this one satellite manufacturer I know personally is using an
ICE and they measured ALL the interfaces and timings with and without an
ICE to see what effect the ICE had before they stated work.

Their actual figures proved that the ICE had a smaller effect than
changes in production and batch of the silicon. They use the simulator
for the VHDL as a *SIMULATION*  but all that testing is validated by
using an ICE on the finished board.

Their comment was: "When you need to test reality a simulation is just
not good enough."

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

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.

Ian

"Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> schreef in bericht
news:402645c0_3@mk-nntp-1.news.uk.worldonline.com...
> 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.

Software that supports many different machines, that all use
the same controller board, or applications with a lot of
text/graphics for the user interface, or....


-- 
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)

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. 

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

Regards
   Chris


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

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

Frank Bemelman wrote:

> "Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> schreef in bericht
> news:402645c0_3@mk-nntp-1.news.uk.worldonline.com...
>> 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.
> 
> Software that supports many different machines, that all use
> the same controller board,

Can you amplify that.  I am not quite sure what you mean.

 or applications with a lot of
> text/graphics for the user interface, or....
> 

That one I expected.

Ian

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

Ian

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

"Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> schreef in bericht
news:40265e6d_3@mk-nntp-1.news.uk.worldonline.com...
> Frank Bemelman wrote:
>
> > "Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> schreef in bericht
> > news:402645c0_3@mk-nntp-1.news.uk.worldonline.com...
> >> 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.
> >
> > Software that supports many different machines, that all use
> > the same controller board,
>
> Can you amplify that.  I am not quite sure what you mean.

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.

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.


-- 
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)

Frank Bemelman wrote:

> "Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> schreef in bericht
> news:40265e6d_3@mk-nntp-1.news.uk.worldonline.com...
>> Frank Bemelman wrote:
>>
>> > "Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> schreef in bericht
>> > news:402645c0_3@mk-nntp-1.news.uk.worldonline.com...
>> >> 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.
>> >
>> > Software that supports many different machines, that all use
>> > the same controller board,
>>
>> Can you amplify that.  I am not quite sure what you mean.
> 
> 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
developed the software for a *very* early digital cordless telephone - a
sort of pre-pre-cursor to the old Rabbit phone system that was deployed for
a short period at Little Chef outlets and airport lounges.  In short the
basestation software I wrote had to handle up to 9 handsets actively
calling, up to 15 more in a queue waiting to make a call, manage fruadulent
calls, handle incoming calls, calculate billing information and transmit
this down a serial port.  All this in real time on an 1802 running at 1MHz. 
I wrote it in assembler in three months and it fitted into 8K bytes.

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


Ian