Using Visual C/C++ to do 8051 development

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

Reply to
Frank Bemelman
Loading thread data ...

In article , Mark A. Odell writes

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

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

"Chris Hills" schreef in bericht news: snipped-for-privacy@phaedsys.demon.co.uk...

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 to
Frank Bemelman

"Bob Stephens" wrote in message news:e03r4zo6d9z5.qvtjuwzedvpn$. snipped-for-privacy@40tude.net...

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.

Reply to
Scott Moore

In article , Scott Moore writes

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

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

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

formatting link
916.780.7623

----------------------------------------------------------------------

Reply to
Albert Lee Mitchell

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 to
Scott Moore

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

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

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

formatting link
916.780.7623

----------------------------------------------------------------------

Reply to
Albert Lee Mitchell

---------snip----------

No doubt simulators work fine in the lab but in the field or in real world equipment I'd have to respectfully disagree.

Is a map of a map proof?

-- Regards, Albert

---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts

formatting link
916.780.7623

----------------------------------------------------------------------

Reply to
Albert Lee Mitchell

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

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

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

Reply to
Ian Bell

"Ian Bell" schreef in bericht news:402645c0 snipped-for-privacy@mk-nntp-1.news.uk.worldonline.com...

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)
Reply to
Frank Bemelman

In article , Ian Bell writes

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

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

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

Reply to
R Adsett

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

or applications with a lot of

That one I expected.

Ian

Reply to
Ian Bell

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

Reply to
Ian Bell

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

Reply to
Ian Bell

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)
Reply to
Frank Bemelman

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.

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

Reply to
Ian Bell

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.