8051 Emulator Download

[Badomero Schoulund]

Idid found quite a lot of questions discussing this. However, I wanted to break it bit more on a granular level so that I can know which areas I need to focus before i actually start writing the code.

An emulator executes binary code, and nothing else. The emulator doesn't include an editor (that's a development tool) nor an assembler (ditto). It's the assembler's responsibility to do the syntax check and translation, that way the emulator has only the relatively easy job of executing pre-validated, legal code.

You can use an array of up to (e.g.) 64K bytes as the emulator's working memory. You use variables in your program to emulate the registers. I'd use an unsigned char * to emulate the program counter, and ints for most other stuff...

The operation is pretty simple: Start the program counter at 0 (or a pre-determined boot location), and start a loop which fetches instructions via that pointer, and apply to registers and memory whatever operation is associated with the instruction. A simple implementation would center around a huge switch statement that includes all possible instruction codes.

As I said, your emulator shouldn't need to worry about illegal instructions, because the assembler shouldn't produce any. You could have your program (i.e. the main loop) halt if it hits an illegal operation.

Recently I put together an emulator for the AVR chip, which is also a small 8-bit microcontroller. The source is on GitHub as ghewgill/emulino. The most interesting file is cpu.c which contains the implementations for each CPU instruction. The key lines are in cpu_run() (omitting some details):

This loads a 16-bit word from the program memory pointed to by the PC register, then uses that as in index into an instruction jump table (which is a 64k array of function pointers - the actual table is generated by a script at compile time). This function will be one of the do_XXX() functions in that source file, and may do further instruction decoding before executing the actual instruction. For example, the do_ADD() function:

In addition, the MetaICE-XF supports Bank Switching overthe full range of the emulator's memory. The MetaICE-XFincludes a large time stamped trace buffer that can capture up to 64Kor 512K cycles of bus activity, depending on model. TheMetaICE-XF emulator system is a self-contained unit thatincludes the emulation electronics, the probe for the specific 8051derivative and a mating adapter to plug directly into the targetapplication's footprint - all in only 3.3 in. (8,5cm) x 3.0 in.(7,7cm) of space. Windows-based user interface delivers the highestdevelopment productivity. The context-sensitive hypertext andhyperlinked help system makes this interface easy to learn and easyto use. The MetaICE-XF includes a full symbolic and sourcelevel debugger for Assemblers and Compilers. The emulator fullysupports all of Keil's 8051 Assemblers and Compilers.

This is a simulator of the 8051/8052 microcontrollers. For sake of simplicity, I'm only referring to 8051, although the emulator can emulate either one. For more information about the 8-bit chip(s), please check out www.8052.com or look up the data sheets. Intel, being the originator of the architecture, naturally has information as well.

The 8051 is a pretty easy chip to play with, in both hardware and software. Hence, it's a good chip to use as an example when teaching about computer hardware. Unfortunately, the simulators in use in my school were a bit outdated, so I decided to write a new one.

The scope of the emulator is to help test and debug 8051 assembler programs. What is particularily left out is clock-cycle exact simulation of processor pins. (For instance, MUL is a 48-clock operation on the 8051. On which clock cycle does the CPU read the operands? Or write the result?). Such simulation might help in designing some hardware, but for most uses it is unneccessary and complicated.

The emulator is designed to have two separate modules, consisting of the emulator core and separate front-end. This enables the creation of different kinds of front-ends. For instance, this lets the user use the emulator core as a DLL in a C/C++ application which can simulate other kinds of hardware (such as leds, switches, displays, audio, or whatnot).

Simulation accuracy is valued over speed. Nevertheless, already at v.0.1 the emulator could run at over-realtime speeds on a P4/2.6GHz (running the emulator at over 12MHz). Based on profiler output, over half of the processing time is wasted on pipeline trashing when branching to the opcode functions. This could possibly be helped by JITing the code, but that is considered unneccessary at this point. Also, CPUs with shorter pipelines are not harmed by this behavior as badly.

Support for all sorts of 8051 memory combinations - 128 or 256B internal RAM, 0-64k of external RAM and 0-64k of ROM. External RAM and ROM may even point at the same memory, enabling self-modifying code.

SDCC comes with s51 but this is a CLI simulator. It may be useful in some cases. It also seems to be possible to invoke the simulator through ddd, the GNU GUI debugger frontend, which invokes sdcdb, which invokes s51. The docs say it may not be as smooth as expected.

Lookiing at other free simulators for Linux, mcu8051ide seems to emulate lots of 8051 variants, provide a fairly complete display, but unfortunately I can find no way to load just a hex or binary file, you have to develop using the compiler and assembler that it uses. I'm the kind of person who likes to use a text editor on a C file*. Since it's GPLed open source, I suppose one could add this capability.

Edsim51 is also quite complete, even simulates peripherals, and is written in Java, so cross-platform. But unfortunately again you have to develop using its IDE, I see no way to load a hex or binary file.

I am willing to consider jsim-51 which will run under my WIndows XP in a VM. It can even read both the .ihx and .map files generated by asxxxx, the assembler used by SDCC, to provide a labelled disassembly. However I can't find a way to display registers and memory continuously while simulating, one has to pause, then issue an update display command. Maybe I have to look harder. It's strange as the timers can be monitored continuously. One disadvantage is as it was written ages ago, it only caters for the 8031/8051, not any of the recent variants with more peripherals.

But one good thing about developing in C is that you are one level above assembly instructions and don't have to worry as much about the state of the registers and flags but think in terms of program variables. Subroutines also encourage compartmentalising functionality. But when it comes to low-level operations on ports, it's good to be able to watch.

* But I recognise the benefits of and do use the facilities of the Arduino IDE, especially the facts that it handles the variations in AVR CPUs behind the scenes, and brings together many tools, including such things as SPI programming, under its umbrella. One can always edit the .ino file outside of the IDE and then reload in the IDE.

I recently added s51 as a backend simulator in PICSimLab (a simulator with GUI). The s51 console remains operational for debugging and the simulator loads .hex files generated by the SDCC. It may be useful for your project.

I wish to know what emulator is . Is emulator used in CC2530ZNP kit? I see FET is used to debug and program? IS it the emulator . What role does emuator play . I googled about emulator to find about them. Info are vague . I wish to know a practical example since i might have used it without knowing that ist he emulator :P

This allows you to view and control the operation of your software in the target hardware. Note this this is what distinguishes an emulator from a Simulator - which is purely a software tool, running on a PC, workstation, or suchlike.

That was all very well in the days of socketed chips in DIL & similar packages (the example above is for a 44-pin PLCC 8051) but has long been impractical as chip packages have shrunk and/or grown in pin count.

However, this discussions sheds some ligt about the strange name 'FET' (Flash Emulation Tool) for the JTAG programmer. It "emulates an emulator" by attaching to a real MSP. No need to replace the MSP by an emulator (so likely 'flash' is not related to the MSP having flash memory, but to the fact that you can quickly attach it)

In the days of real In-Circuit Emulators, the low-cost alternative was an EPROM Emulator. This replaced the EPROM in the system (instead of the processor) - making it quicker & easier to reload code, and giving test access to the data & address busses.

lol. if by "configure" you mean rewrite the program, then one starts by reading the documentation for 8051 flashing algorithm. then create arduino code to implement this. arduino isp sketch is a starting point but im guessing only 5%-10% of that code can be reused.

If by configure, on the other hand, you mean to actually use the Arduino IDE as a development environment for 8051s, you can forget it. 8051 is a different architecture than AVR and Arduino only supports AVR.

MCU 8051 IDE is a free software integrated development environment for microcontrollers based on the 8051. MCU 8051 IDE has a built-in simulator not only for the MCU itself, but also LCD displays and simple LED outputs as well as button inputs. It supports two programming languages: C (using SDCC) and assembly and runs on both Windows and Unix-based operating systems, such as FreeBSD and Linux. The current version 1.4 supports many microcontrollers including:

WHICH Atmel 8051 microcontrollers? Some of them support an ISP protocol very similar to the AVRs, and should (theoretically) be programmable using something similar to the ArduinoISP sketch (but NOT without changes.) Other 8051s are only programmable in a parallel mode that requires connecting up about 24 pins...

3a8082e126