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

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

Translate This Thread From English to

Threaded View
Re: 8051 Bank Switching Applications

Quoted text here. Click to load it


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

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

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



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






Re: 8051 Bank Switching Applications

Quoted text here. Click to load it

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

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




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



Re: 8051 Bank Switching Applications

Quoted text here. Click to load it

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

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

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

Re: 8051 Bank Switching Applications

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Using Visual C/C++ to do 8051 development


Quoted text here. Click to load it

No, it's just not that useful in ISC compliant mode. Everyone knows that
and everyone enables the Keil extensions.

Quoted text here. Click to load it

Chris, you are absolutely correct. However, I've successfully debugged
corner cases on things like ring buffer management,
pointer-to-pointer-to-array code, etc. by pasting the function from my
Keil C51 project into a MSVC6 .c file. I think this is what the OP is
after.

--
- Mark ->
--

Re: Using Visual C/C++ to do 8051 development
Quoted text here. Click to load it
Yes but.....  The OP said it was a banked 8051 application. I can't see
how a non standard MS VC compiler and windows debugger is going to help
in this case. It could introduce more errors than it solves and you then
have to port everything back to the 51 compiler again possibly
introducing more errrors.   All the "solutions" have been by cobbleing
together wrapper fuinctions that behave "almost" the same as the 51
does. Whey re-invent a poor wheel when there is a good one you can use.

(note the same problem will occur if you are using IAR, Tasking etc)

The thing that is worrying is that a lot of these "embedded Engineers"
seem to run to MS Dev studio to solve problems.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ 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

Why is that worrying? Under *certain* circumstances it may be
very useful indeed.

In my case, porting a grahical 8051 LCD terminal to windows
allowed the guy who makes documents, to have hardcopies (bitmaps)
of the emulated LCD screen and insert them into the manuals.
The net result being a very crisp looking manual. There were
some other benefits too, but perhaps too esoteric to explain.

There may be many more circumstances where it can be a
useful practice, even if I can't think of any.

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




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

Fine, what is not standard about VC ? NO, not what they have extended,
what standard C language construct does VC not accept ? Thats all
that matters.




Re: Using Visual C/C++ to do 8051 development
I am using such DESKTOP/EMBEDDED technique for a long time. It's
extremely powerful method of design, you can trace practically
everything what's happening inside your program by creating log files
on PC and then examine them using any graphics package (gnu_plot). The
only complexity is to simulate interrupts but more or less it's easy
in DOS mode, ports are simply replaced with BYTE variables.

Nordic regards,
Yuri

Site Timeline