Using Visual C/C++ to do 8051 development - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Using Visual C/C++ to do 8051 development

Quoted text here. Click to load it

    Many good points but one overriding negative, the map is not the terrain.
 No emulator and no simulator can ever precisely reproduce the hardware
response characteristics.  This is why I, and many others, develop on the
exact hardware being produced.

-- Regards, Albert
----------------------------------------------------------------------
AM Research, Inc.                  The Embedded Systems Experts
http://www.amresearch.com 916.780.7623
----------------------------------------------------------------------


Re: Using Visual C/C++ to do 8051 development
Quoted text here. Click to load it

I used to believe that. Then I went to work on IC design. It turns out
that simulators are MORE accurate than hardware. Why ? Heisenberg, as
in "the uncertainty principle".

Another proof is simple. Many companies simulate against the actual
verilog or VHDL used to create the chip(s) in use.



Re: Using Visual C/C++ to do 8051 development
---------snip----------
Quoted text here. Click to load it

    No doubt simulators work fine in the lab but in the field or in real
world equipment I'd have to respectfully disagree.
 
Quoted text here. Click to load it

    Is a map of a map proof?
 
-- Regards, Albert
----------------------------------------------------------------------
AM Research, Inc.                  The Embedded Systems Experts
http://www.amresearch.com 916.780.7623
----------------------------------------------------------------------


Re: Using Visual C/C++ to do 8051 development
Quoted text here. Click to load it

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.

Regards
   Chris




/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Using Visual C/C++ to do 8051 development

Quoted text here. Click to load it

    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.


-- Regards, Albert
----------------------------------------------------------------------
AM Research, Inc.                  The Embedded Systems Experts
http://www.amresearch.com 916.780.7623
----------------------------------------------------------------------


Re: Using Visual C/C++ to do 8051 development
Quoted text here. Click to load it


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    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

8051 Bank Switching Applications
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


Re: 8051 Bank Switching Applications
Quoted text here. Click to load it

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)



Re: 8051 Bank Switching Applications

Quoted text here. Click to load it

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

 or applications with a lot of
Quoted text here. Click to load it

That one I expected.

Ian


Re: 8051 Bank Switching Applications
Quoted text here. Click to load it

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)










Re: 8051 Bank Switching Applications

Quoted text here. Click to load it

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.

Quoted text here. Click to load it


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


Re: 8051 Bank Switching Applications
Quoted text here. Click to load it
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]

Quoted text here. Click to load it


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)




Re: 8051 Bank Switching Applications
Quoted text here. Click to load it

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    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: 8051 Bank Switching Applications
says...
Quoted text here. Click to load it
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

Re: 8051 Bank Switching Applications

Quoted text here. Click to load it

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

Re: 8051 Bank Switching Applications
snipped-for-privacy@ruffrecordsDOTworldonline.co.uk says...
Quoted text here. Click to load it
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

Re: 8051 Bank Switching Applications
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.

Re: 8051 Bank Switching Applications

Quoted text here. Click to load it

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


Re: 8051 Bank Switching Applications

Quoted text here. Click to load it

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

Re: 8051 Bank Switching Applications
Quoted text here. Click to load it

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       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Site Timeline