"Bob Stephens" <stephensyomamadigital@earthlink.net> schreef in bericht news:e03r4zo6d9z5.qvtjuwzedvpn$.dlg@40tude.net...> On Fri, 6 Feb 2004 22:57:55 +0100, Frank Bemelman wrote: > > > 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.Emulator for the UART, left the write part out for brevity. As you can see it's a sort of a mix of 8051 stuff and windows API. I cleaned it up a bit, in a rush, as there was more stuff in, such as to mimic leds on the PC application window, and some error handling. The communication thread: DWORD CommThread(DWORD dwParam) { while(TRUE) { read_serial() // reads *and* processes data from PC's serial port if((P4_4==1) && S0BUF) { Stufftosend[0]=1; Stufftosend[1]=S0BUF; write_serial(); TI = 1; SerialComInterrupt(); // call the 8051 interrupt handler } } return 0; } And this read the PC's serial port and transfers the character to the 8051 interrupt code: int read_serial(void) { DWORD dwREAD1; DWORD dwErrors; COMSTAT comStat; BOOL bResult; DWORD dwcharsREAD1; DWORD idx; if (hComm == INVALID_HANDLE_VALUE) return FALSE; // port not available bResult = ReadFile(hComm, (LPVOID)&ComRecBuf[0], COMINBUFSIZE, &dwREAD1, NULL); if(!bResult) { ClearCommError(hComm, &dwErrors, &comStat); //PrintfToBuf(SELDEBUG, "RS232 read-error, code=%lx\r\n", dwErrors); } else { if(dwREAD1>0) { // raise dtr line // EscapeCommFunction( hComm, SETDTR); if(port==TERMINALCOM) // data from terminal { dwcharsREAD1 = dwREAD1; ComRecBuf[dwREAD1]=0; idx = 0; // OkMsgBox("Timer", "string>%s<", &ComRecBuf[0]); idx = 0; while(dwcharsREAD1) { RI = 1; S0BUF = ComRecBuf[idx]; SerialComInterrupt(); dwcharsREAD1--; idx++; } } // set dtr line back //EscapeCommFunction( hComm, CLRDTR); } } return(dwREAD1); } -- Thanks, Frank. (remove 'x' and 'invalid' when replying by email)
Using Visual C/C++ to do 8051 development
Started by ●February 5, 2004
Reply by ●February 6, 20042004-02-06
Reply by ●February 6, 20042004-02-06
In article <Xns9487B056A5AABCopyrightMarkOdell@130.133.1.4>, Mark A. Odell <nospam@embeddedfw.com> writes>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. >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 /\/\/\/\/\ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●February 6, 20042004-02-06
"Chris Hills" <chris@phaedsys.org> schreef in bericht news:q1V1yNAnlCJAFAEg@phaedsys.demon.co.uk...> > The thing that is worrying is that a lot of these "embedded Engineers" > seem to run to MS Dev studio to solve problems.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)
Reply by ●February 7, 20042004-02-07
"Bob Stephens" <stephensyomamadigital@earthlink.net> wrote in message news:e03r4zo6d9z5.qvtjuwzedvpn$.dlg@40tude.net...> On Fri, 6 Feb 2004 22:57:55 +0100, Frank Bemelman wrote:> 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. > > BobThere are a lot of advantages to simulating new hardware on the PC, or other workstation platform. First and foremost, you can develop the software before the hardware shows up. Second, the PC is a better and faster platform, although since most compilers cross from the PC anyways, that is pretty much a moot point. Third, developing against emulated modules takes a lot of the timing, miswires and other hardware trivial out of the picture, so that you can get software correct functionally before trying to get it to work with the target hardware. Forth, it gives everyone a development system at zero cost per station, since all they need is the PC and the software. Fifth, it makes automatic regression testing easier, since all of the ins and outs of the program can be automatically verified, and thats an advantage that exists even after hardware is correct and shipping. Sixth, it simplifies debugging in general, since the environment is virtual and predictable. For example, many real world hardware interaction bugs tend to be intermittent. A simulator can tightly control the run and produce the same run every time. Seventh, simulators that closely resemble the hardware tend to find hardware design issues that nobody thought of, in time to get the hardware put right before a lot of money is spent on manufacturing boards and ICs. Eigth, many hardware simulators provide hooks so that real code can be run against them. For example, verilog simulators can be arranged to link to C programs to form a test bench of the final system. Simulating the hardware and software together like that is how you get hardware that is correct on the first build.
Reply by ●February 7, 20042004-02-07
In article <2o_Ub.187742$Rc4.1473181@attbi_s54>, Scott Moore <samiam@moorecad.com> writes>"Bob Stephens" <stephensyomamadigital@earthlink.net> wrote in message >news:e03r4 >zo6d9z5.qvtjuwzedvpn$.dlg@40tude.net... >> On Fri, 6 Feb 2004 22:57:55 +0100, Frank Bemelman wrote: > >> 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 > >There are a lot of advantages to simulating new hardware on the PC, or other >workstation platform. First and foremost, you can develop the software before >the hardware shows up. Second, the PC is a better and faster platform, although >since most compilers cross from the PC anyways, that is pretty much a moot >point. Third, developing against emulated modules takes a lot of the timing, >miswires and other hardware trivial out of the picture, so that you can get >software correct functionally before trying to get it to work with the >target hardware. Forth, it gives everyone a development system at zero cost >per station, since all they need is the PC and the software. Fifth, it makes >automatic regression testing easier, since all of the ins and outs of the >program can be automatically verified, and thats an advantage that exists >even after hardware is correct and shipping. Sixth, it simplifies debugging >in general, since the environment is virtual and predictable. For example, >many real world hardware interaction bugs tend to be intermittent. A simulator >can tightly control the run and produce the same run every time. Seventh, >simulators that closely resemble the hardware tend to find hardware design >issues that nobody thought of, in time to get the hardware put right before >a lot of money is spent on manufacturing boards and ICs. Eigth, many hardware >simulators provide hooks so that real code can be run against them. For >example, >verilog simulators can be arranged to link to C programs to form a test >bench of the final system. Simulating the hardware and software together >like that is how you get hardware that is correct on the first build.I agree with all of this. So use the Keil 8051 simulator. IT is a very good sim that is very accurate and it handles most of the peripherals of most of the 51 family. Why change from a full implementation of the target language and a good sim to a non-standard version of C that is not correct for the architecture and a less accurate or complete sim? BTW compare the results of MS-C and Keil C using Plum-Hall and Paranoia and see what I mean. However if you have a decent ICE for the part it is no contest. Use the Keil C51 and the ICE. This is the only way to pick up an intermittent bug. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●February 7, 20042004-02-07
On Sat, 07 Feb 2004 05:07:10 +0000, Scott Moore wrote:> ---------snip----------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 ----------------------------------------------------------------------
Reply by ●February 8, 20042004-02-08
"Albert Lee Mitchell" <albmit@albert.amresearch.com> wrote in message news:pan.2004.02.07.22.57.55.342352@albert.amresearch.com...> On Sat, 07 Feb 2004 05:07:10 +0000, Scott Moore wrote: > > > ---------snip---------- > > 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.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.
Reply by ●February 8, 20042004-02-08
In article <pan.2004.02.07.22.57.55.342352@albert.amresearch.com>, Albert Lee Mitchell <albmit@albert.amresearch.com> writes>On Sat, 07 Feb 2004 05:07:10 +0000, Scott Moore wrote: > >> ---------snip---------- > > 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.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 /\/\/\/\/\ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●February 8, 20042004-02-08
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. -- Regards, Albert ---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts http://www.amresearch.com 916.780.7623 ----------------------------------------------------------------------
Reply by ●February 8, 20042004-02-08
On Sun, 08 Feb 2004 07:30:08 +0000, Scott Moore wrote: ---------snip---------->> 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. > > 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".No doubt simulators work fine in the lab but in the field or in real world equipment I'd have to respectfully disagree.> Another proof is simple. Many companies simulate against the actual > verilog or VHDL used to create the chip(s) in use.Is a map of a map proof? -- Regards, Albert ---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts http://www.amresearch.com 916.780.7623 ----------------------------------------------------------------------
