EmbeddedRelated.com
Forums

Using Visual C/C++ to do 8051 development

Started by Ed February 5, 2004
I think it's best you stick to Keil, and probably optimize your code
if possible. I don't think there is much sence in trying to use Visual C++
for your application.

Mickey


"Ed" <efeten@laars.com> wrote in message news:cef06b19.0402050816.4fc61d41@posting.google.com...
> I am working on an 8051 project. The code size has grown very large. I > am currently using code banking which makes compiling and linking of the > code very time consuming. For example to do a re-build take about 2+ > minutes using the Keil Compiler. I know that some people have used > Visual C/C++ 6.0 to do 8051 development (these are systems where there > is almost no assembly except for the startup module supplied with the > compiler vendor) in order to speed things up. Do you have any experience > with this? Like maybe writing DLLs to simulate 8051 peripherals? Any > info would be appreciated.
To others in this thread, you assumed he wanted to use VC to compile to 8051. I beleive he wants to compile standard C in VC and simulate the target system to get the thing debugged, then recompile for his target. To ed, I suspect you are thinking in too complex terms. Just move your code to VC, and start compiling it. If you have a few assembly routines, just create a stub for them. Your first problem is going to be overcoming the incompatibilities between these two compilers. There will be some, perhaps a lot if you have used a lot of non-standard features of the Keil compiler. Now that just gets you a clean VC compile. Next, you want to simulate the system as best you can. You are going to need a routine, in C, that performs every hardware operation you want to do on your target. These routines are either going to do nothing, or print an indication for you, or whatever you can handle. For example, if you have an LCD display on the unit, then you can have the LCD display write routine output in a window on the PC instead. Typically on the projects I have done like this, we open up a window and fill it with a lot of status buttons and readouts to represent the target. For instance, if the unit has a button, you make a button object in the window, there is a indicator light, that gets a little light on/off graphic, etc. Luck.
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
In article <NIKUb.186474$5V2.915198@attbi_s53>, Scott Moore
<samiam@moorecad.com> writes
>"Ed" <efeten@laars.com> wrote in message news:cef06b19.0402050816.4fc61d41@posti >ng.google.com... >> I am working on an 8051 project. The code size has grown very large. I >> am currently using code banking which makes compiling and linking of the >> code very time consuming. For example to do a re-build take about 2+ >> minutes using the Keil Compiler. I know that some people have used >> Visual C/C++ 6.0 to do 8051 development (these are systems where there >> is almost no assembly except for the startup module supplied with the >> compiler vendor) in order to speed things up. Do you have any experience >> with this? Like maybe writing DLLs to simulate 8051 peripherals? Any >> info would be appreciated. > >To others in this thread, you assumed he wanted to use VC to compile >to 8051. I beleive he wants to compile standard C in VC and simulate >the target system to get the thing debugged, then recompile for his >target.
This is a waste of time. Standard C is not very efficient on the 8051 especially if he is banking already
>To ed, > >I suspect you are thinking in too complex terms. Just move your code >to VC, and start compiling it.
Then you are doomed to failure.
>the incompatibilities between these two compilers. There will be some, >perhaps a lot if you have used a lot of non-standard features of the Keil >compiler.
As Keil is used for 80% of the worlds 8051 C projects the Keil *IS* the standard. MS VC is hardly "Standard C"
>Now that just gets you a clean VC compile.
Which is on no use on a 51.... How do you do BData? work with SFR's etc? This project uses code banking. You can't do that in VC.
>Next, you want to simulate the system as best you can.
Use the Keil simulator.
> You are going to >need a routine, in C, that performs every hardware operation you want >to do on your target. These routines are either going to do nothing, or >print an indication for you,
Or use the peripherals in the simulator... why are you suggesting a solution that is hard work and less accurate?
>or whatever you can handle. For example, if >you have an LCD display on the unit, then you can have the LCD >display write routine output in a window on the PC instead.
These can also be don in the Keil sim.
>Typically on the projects I have done like this, we open up a window >and fill it with a lot of status buttons and readouts to represent the >target.
Just like in the Keil Sim but less accurate. Why go back many steps? /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
"Chris Hills" <chris@phaedsys.org> schreef in bericht
news:xLJOhkAGD+IAFAMR@phaedsys.demon.co.uk...
> In article <NIKUb.186474$5V2.915198@attbi_s53>, Scott Moore > <samiam@moorecad.com> writes > >"Ed" <efeten@laars.com> wrote in message
news:cef06b19.0402050816.4fc61d41@posti
> >ng.google.com... > >> I am working on an 8051 project. The code size has grown very large. I > >> am currently using code banking which makes compiling and linking of
the
> >> code very time consuming. For example to do a re-build take about 2+ > >> minutes using the Keil Compiler. I know that some people have used > >> Visual C/C++ 6.0 to do 8051 development (these are systems where there > >> is almost no assembly except for the startup module supplied with the > >> compiler vendor) in order to speed things up. Do you have any
experience
> >> with this? Like maybe writing DLLs to simulate 8051 peripherals? Any > >> info would be appreciated. > > > >To others in this thread, you assumed he wanted to use VC to compile > >to 8051. I beleive he wants to compile standard C in VC and simulate > >the target system to get the thing debugged, then recompile for his > >target. > > This is a waste of time. Standard C is not very efficient on the 8051 > especially if he is banking already
So Keil wrote a 8051 C compiler nobody wants/needs ? -- Thanks, Frank. (remove 'x' and 'invalid' when replying by email)
In article <4023e864$0$62689$cd19a363@news.wanadoo.nl>, Frank Bemelman
<fbemelx@euronet.invalid.nl> writes
>"Chris Hills" <chris@phaedsys.org> schreef in bericht >news:xLJOhkAGD+IAFAMR@phaedsys.demon.co.uk... >> In article <NIKUb.186474$5V2.915198@attbi_s53>, Scott Moore >> <samiam@moorecad.com> writes >> >"Ed" <efeten@laars.com> wrote in message >news:cef06b19.0402050816.4fc61d41@posti >> >ng.google.com... >> >> I am working on an 8051 project. The code size has grown very large. I >> >> am currently using code banking which makes compiling and linking of >the >> >> code very time consuming. For example to do a re-build take about 2+ >> >> minutes using the Keil Compiler. I know that some people have used >> >> Visual C/C++ 6.0 to do 8051 development (these are systems where there >> >> is almost no assembly except for the startup module supplied with the >> >> compiler vendor) in order to speed things up. Do you have any >experience >> >> with this? Like maybe writing DLLs to simulate 8051 peripherals? Any >> >> info would be appreciated. >> > >> >To others in this thread, you assumed he wanted to use VC to compile >> >to 8051. I beleive he wants to compile standard C in VC and simulate >> >the target system to get the thing debugged, then recompile for his >> >target. >> >> This is a waste of time. Standard C is not very efficient on the 8051 >> especially if he is banking already > >So Keil wrote a 8051 C compiler nobody wants/needs ? >
I think it has about 80% of the market. Please explain how you access and use XDATA, CODE, IDATA & BTATA in ISO- C. How do you use and access SFR's in ISO-C? How do you write interrupts functions in ISO-C? How do you do re-entrant functions in Keil C using only ISO-c? How do you do 8 bit emuns in ISO-C? How do you place variable as specific addresses in ISO C? The architecture requires various extensions. Besides you were not advocating the use of standard C anyway. Regards Chris /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
"Chris Hills" <chris@phaedsys.org> schreef in bericht
news:+1yteyAuJAJAFAnD@phaedsys.demon.co.uk...
> In article <4023e864$0$62689$cd19a363@news.wanadoo.nl>, Frank Bemelman > <fbemelx@euronet.invalid.nl> writes > >"Chris Hills" <chris@phaedsys.org> schreef in bericht > >news:xLJOhkAGD+IAFAMR@phaedsys.demon.co.uk... > >> In article <NIKUb.186474$5V2.915198@attbi_s53>, Scott Moore > >> <samiam@moorecad.com> writes > >> >"Ed" <efeten@laars.com> wrote in message > >news:cef06b19.0402050816.4fc61d41@posti > >> >ng.google.com... > >> >> I am working on an 8051 project. The code size has grown very large.
I
> >> >> am currently using code banking which makes compiling and linking of > >the > >> >> code very time consuming. For example to do a re-build take about 2+ > >> >> minutes using the Keil Compiler. I know that some people have used > >> >> Visual C/C++ 6.0 to do 8051 development (these are systems where
there
> >> >> is almost no assembly except for the startup module supplied with
the
> >> >> compiler vendor) in order to speed things up. Do you have any > >experience > >> >> with this? Like maybe writing DLLs to simulate 8051 peripherals? Any > >> >> info would be appreciated. > >> > > >> >To others in this thread, you assumed he wanted to use VC to compile > >> >to 8051. I beleive he wants to compile standard C in VC and simulate > >> >the target system to get the thing debugged, then recompile for his > >> >target. > >> > >> This is a waste of time. Standard C is not very efficient on the 8051 > >> especially if he is banking already > > > >So Keil wrote a 8051 C compiler nobody wants/needs ? > > > I think it has about 80% of the market. > > Please explain how you access and use XDATA, CODE, IDATA & BTATA in ISO- > C. > > How do you use and access SFR's in ISO-C? > > How do you write interrupts functions in ISO-C? > > How do you do re-entrant functions in Keil C using only ISO-c? > > How do you do 8 bit emuns in ISO-C? > > How do you place variable as specific addresses in ISO C? > > The architecture requires various extensions. > > Besides you were not advocating the use of standard C anyway. >
The idea was to use Visual C as a temporary platform to develop the application at hand. Which is in fact quite possible for some 8051 applications, using a header that redefines Keil keywords. I did it for one project, and it worked quite well. I would not claim that you can write all the software this way, and some of the works still needs to be done with the Keil, using the ICE on the real thing. I just wouldn't call it a 'waste of time' per se. One area where it works great is writing a user interface, for instance. -- Thanks, Frank. (remove 'x' and 'invalid' when replying by email)
Chris Hills <chris@phaedsys.org> wrote in
news:+1yteyAuJAJAFAnD@phaedsys.demon.co.uk: 

Frank Bemelman wrote:

>>So Keil wrote a 8051 C compiler nobody wants/needs ?
No, it's just not that useful in ISC compliant mode. Everyone knows that and everyone enables the Keil extensions.
> I think it has about 80% of the market. > > Please explain how you access and use XDATA, CODE, IDATA & BTATA in ISO- > C. > > How do you use and access SFR's in ISO-C? > > How do you write interrupts functions in ISO-C? > > How do you do re-entrant functions in Keil C using only ISO-c? > > How do you do 8 bit emuns in ISO-C? > > How do you place variable as specific addresses in ISO C? > > The architecture requires various extensions. > > Besides you were not advocating the use of standard C anyway.
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 -> --
On Fri, 6 Feb 2004 22:57:55 +0100, Frank Bemelman wrote:

> "Chris Hills" <chris@phaedsys.org> schreef in bericht > news:+1yteyAuJAJAFAnD@phaedsys.demon.co.uk... >> In article <4023e864$0$62689$cd19a363@news.wanadoo.nl>, Frank Bemelman >> <fbemelx@euronet.invalid.nl> writes >>>"Chris Hills" <chris@phaedsys.org> schreef in bericht >>>news:xLJOhkAGD+IAFAMR@phaedsys.demon.co.uk... >>>> In article <NIKUb.186474$5V2.915198@attbi_s53>, Scott Moore >>>> <samiam@moorecad.com> writes >>>> >"Ed" <efeten@laars.com> wrote in message >>>news:cef06b19.0402050816.4fc61d41@posti >>>> >ng.google.com... >>>> >> I am working on an 8051 project. The code size has grown very large. > I >>>> >> am currently using code banking which makes compiling and linking of >>>the >>>> >> code very time consuming. For example to do a re-build take about 2+ >>>> >> minutes using the Keil Compiler. I know that some people have used >>>> >> Visual C/C++ 6.0 to do 8051 development (these are systems where > there >>>> >> is almost no assembly except for the startup module supplied with > the >>>> >> compiler vendor) in order to speed things up. Do you have any >>>experience >>>> >> with this? Like maybe writing DLLs to simulate 8051 peripherals? Any >>>> >> info would be appreciated. >>>> > >>>> >To others in this thread, you assumed he wanted to use VC to compile >>>> >to 8051. I beleive he wants to compile standard C in VC and simulate >>>> >the target system to get the thing debugged, then recompile for his >>>> >target. >>>> >>>> This is a waste of time. Standard C is not very efficient on the 8051 >>>> especially if he is banking already >>> >>>So Keil wrote a 8051 C compiler nobody wants/needs ? >>> >> I think it has about 80% of the market. >> >> Please explain how you access and use XDATA, CODE, IDATA & BTATA in ISO- >> C. >> >> How do you use and access SFR's in ISO-C? >> >> How do you write interrupts functions in ISO-C? >> >> How do you do re-entrant functions in Keil C using only ISO-c? >> >> How do you do 8 bit emuns in ISO-C? >> >> How do you place variable as specific addresses in ISO C? >> >> The architecture requires various extensions. >> >> Besides you were not advocating the use of standard C anyway. >> > > The idea was to use Visual C as a temporary platform to develop > the application at hand. Which is in fact quite possible for > some 8051 applications, using a header that redefines Keil > keywords. > > I did it for one project, and it worked quite well. I would > not claim that you can write all the software this way, and > some of the works still needs to be done with the Keil, using > the ICE on the real thing. > > I just wouldn't call it a 'waste of time' per se. One area > where it works great is writing a user interface, for instance.
I don't get this at all. How is a Win32 user interface going to get you anywhere on an 8051? If you mean an RS232 to terminal interface or keypad and LCD or... it would take more time to write emulators for the UARTs, oscillators, SFR's etc than it would to write and debug natively. Bob
"Chris Hills" <chris@phaedsys.org> wrote in message news:xLJOhkAGD+IAFAMR@phaedsys.demon.co.uk...
> In article <NIKUb.186474$5V2.915198@attbi_s53>, Scott Moore > <samiam@moorecad.com> writes > >"Ed" <efeten@laars.com> wrote in message news:cef06b19.0402050816.4fc61d41@posti > >ng.google.com... > > MS VC is hardly "Standard C" >
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.