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.
What is your application? I keep hearing of 8051 projects with so much code that they need banking but I have no idea what they might be. Can you enlighten me? Just curious.
snipped-for-privacy@laars.com (Ed) wrote in news: snipped-for-privacy@posting.google.com:
I've used VC6.0 (no C++ of course) to debug complex algs. when I don't have a good emulator or JTAG debugger available. I've also created test harnesses in VC6 and plopped 8051-destined statemachines and functions into the test harness. I've done all this in ISO C in as much as I could by using #defines to remove issues with Keil C51 extenstions such as data, idata, xdata etc. Of course using fixed bit types with a win32 and 8051 header file is a requirement. That is, typedef'ing unsigned char as a U8, signed char as S8, etc.
I heard a while back that someone built a bunch of macros to _assemble_ 8051 code. I followed a dead link.
I think you understand that a cross compiler is needed to compile to the 8051 family. So as others mentioned, debugging code and a familiar editor is all Vc++ will give you.
"Ed" schreef in bericht news: snipped-for-privacy@posting.google.com...
I did that once for a 8051 serial terminal with graphic LCD. The first step was a header that redefines Keil keywords, such as redefining SFR into an unsigned char and redefining interrupt into whitespace.
The 'windows' version of the software had some extra files, doing the blitting of the LCD bitmap to the screen every 0.1 second or so, and used a serial port com thread, which did not much else than loading the received character into the SFR and calling the 8051 interrupt function. Likewise, characters from the PC's keyboard or translated mouseclicks on the screen where sent to the '8051' function that used to called from the multiplexed 8051 keyboard scan. The windows software also scanned the non existing ports for key presses, but never saw a key pressed of course. And a few conditional compiles sections were needed, to handle some more obscure things such as the beeper, which was then handled by sending a wav-file through the multimedia api. The final result looked pretty much the same as the real thing, and it was quite useful. Quite reliable too, in most cases after some heavy changes and making it all work on the PC, the 8051 code would run also, after the first rebuild using the Keil compiler.
--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)
This is a backwards step. Using a Microsoft compiler will SLOW things down.
1 It can not compile 8051 code. If does not understand the Keil or 8051 extensions.
2 Because of 1 the code will be larger and less efficient
3 Given 1 and 2 you will have to spend time porting the code from MS to Keil C51 and have more room for errors.
4 The Keil simulator is accurate. The MS simulator pointless for debugging a C51 program.
5 The MS compiler does not understand banking.
Why would you want to use the wrong tools?
What is the application?
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
2 MINUTES? That doesn't even give me enough time to get another cup of coffee. When it takes 25 minutes to do a complete build, then you can start looking for speedups.
I agree Gene, this guy is spoiled. A full rebuild on my project takes about 18 minutes then another 7 to burn the image into flash to test. It sure makes you think hard about your changes.
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.
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.
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.
"Chris Hills" schreef in bericht news:+ snipped-for-privacy@phaedsys.demon.co.uk...
I
there
the
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)
No, it's just not that useful in ISC compliant mode. Everyone knows that and everyone enables the Keil extensions.
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.