New SimulIDE MCU simulator:

I was working in a C++ port of simavr as a parallel project.
During this time, the idea of a base infrastucture for all MCu simulations came to my mind, so that simavr port became a generic MCU simulator.
In the last few months i have implemented the basic infrastructure and I/O POrts.
And now with the new simulator core it is using simulide event loop instead of it's own.
Indeed... simulide event loop was taken from this MCU simulator.

The problem now is that each MCU simulator in simulide implements the same things, sometimes simulide itself also implements it's own version.
So there is a lot of redundant code in diferent styles and even languages, and several layers to make everything work together...

The idea is having:
- Generic MCU simulator basic infrastructure.
- Generic perifericals (I/O Ports, Timers, ADC, communications, etc).
- Unified event loop (simulide simulator event loop).

And for each device type:
- One "Core": instruction decoder, cpu stuff, etc.
- "Periferical configurators" on top of those generic perifericals.

Then each concrete MCU is described in an xml file.
There is an xml parser that creates all the parts and put it together.
This means that concrete MCUs models are not hardcoded, and it is possible to add any MCU model using the parts available by just adding a new xml file.
It would be possible to add MCUs that don't even exist...

This xml files look something like this:

Code:

<mcu name="atmega328" core="AVR" data="2304" prog="16384" progword="2" eeprom="1024"
           inst_cycle="1">

   <registers start="32" end="255" sreg="SREG">
       <register name="PINB"   addr="3"   bits="0-7"/>
       <register name="DDRB"   addr="4"   bits="0-7"/>
       <register name="PORTB"  addr="5"   bits="0-7"/>
       <register name="PINC"   addr="6"   bits="0-6"/>
       ... More registers here
       <register name="TIFR0"  addr="21"  bits="TOV0,OCF0A,OCF0B"/>
       <register name="TIFR1"  addr="22"  bits="TOV1,OCF1A,OCF1B,0,0,ICIE1"/>
       <register name="TIFR2"  addr="23"  bits="TOV2,OCF2A,OCF2B"/>
       <register name="PCIFR"  addr="27"  bits="PCIF0,PCIF1,PCIF2"/>
       <register name="EIFR"   addr="28"  bits="INTF0,INTF1"/>
       <register name="EIMSK"  addr="29"  bits="INT0,INT1"/>
       <register name="GPIOR0" addr="30"  bits=""/>
       <register name="EECR"   addr="31"  bits="EERE,EEPE,EEMPE,EERIE,EEPM0,EEPM1"/>
       <register name="EEDR"   addr="32"  bits=""/>
       ... More registers here
   </registers>
   
   <port name="PORTB" pins="8" outreg="PORTB" inreg="PINB" dirreg="DDRB">
       <interrupt name="PCINT0" type="EXTINT" enable="PCIE0" flag="PCIF0" mask="PCMSK0"/>
   </port>
   ... More ports here

   <timer name="TIMER0" counter="TCNT0" disable="PRTIM0">
       <prescaler select="CS00,CS01,CS02" values="0,1,8,64,256,1024,EXT_F,EXT_R" extclock="PORTD4"/>
       <interrupt name="TIMER0_OVF" type="OVERFLOW" enable="TOIE0" flag="TOV0"/>
   </timer>
   ... More perifericals here
</mcu>

At the same time I got a offer to help with 8051 simulation.
And this is a perfect candidate to take advantage of this system: there are lots of MCUs based on the 8051 core and it is not extremely complex.
Once the "core" and a few periferical are done it would be easy to add many 8085 based MCUs.

So I got the suggested 8051 open source simulator, almost copy/pasted the instruction decoder, created the xml file and created a package.
And after solving a few issues i got a "blink led" working.

Here atmega328 and MCS-51(kindoff) working together.
Note that atmega328 is also running in the new MCU simulator (not simavr).

Can I test (and contribute) 0.5.15? Is there a official repository?

Hi.

Can I test (and contribute) 0.5.15? Is there a official repository?

It would be great.

There is no official repository, but i can send you source code.

Here is the official repository: https://launchpad.net/simulide

Picsimlab uses simavr, picsim, qemu-stm32, gpsim and uCsim for simulate uCs, for example.

uCsim is a part of SDCC, "It supports MCS51 family, AVR core, Z80, HC08, ST7, STM8, TLCS90, XA51 and Paduk. It can run on Linux, Windows, OSX, BSD, and other systems.", it can interact with sdcdb and has serial stuff.

I suggest try to using uCsim like in Picsimlab

P. S.:
It seems like picsimlab uses its own version of uCsim.
There is a sim/ucsim folder in sdcc sources, for 8051 picsimlab realize standalone program witch do something like that:

s51_alone.cc

Code:

#include <stdio.h>

#include "s51_lib.h"

int main()
{
  unsigned char val[4];

  s51_init("/home/gamboa/microcontroladores/8051/in_out.ihx");
  while(1)
  {
      s51_set_port(0,1);
      s51_set_port(1,2);
  s51_set_port(2,3);
      s51_set_port(3,4);

  s51_step();

      val[0]=s51_get_port(0);
      val[1]=s51_get_port(1);
      val[2]=s51_get_port(2);
      val[3]=s51_get_port(3);

      printf("0x%02X 0x%02X 0x%02X 0x%02X\n",val[0],val[1],val[2],val[3]);
  }
}

Brrr, printf in while(1) .

That's a good reference, thank you.

8051 support in simulide is already very advanced in 0.5.15-RC4:
Core, Ports, Timers, Usart and Interrupts are already implemented.
Not all modes are finished, but it should work for the most frequent uses.
ROM and external RAM still not implemented.
Not tested in deep.

I will upload the sources in a few hours.
8051 is at the end of Component list in "New Mcu" section.
If you try it, let me know how "usable" it is.

Is it planned to support Z80, Padauk, STM8? They are can easliy be ported from uCsim and I want to try it, but I am very newbie in C++ .

Also I see that you have done a great job on 8051!...
I already play with 8051 in examples projects (blinking led, horaaay ) and try to start some code from the internet.

By the way, my 0.5.15 build often crashes with segfaults (not only on MCU projects), and professor from my university talked about same behavior in some university computers with Ubuntu and 0.14.15-SR5. I think this is a problem with libraries.

By the way, my 0.5.15 build often crashes with segfaults (not only on MCU projects), and professor from my university talked about same behavior in some university computers with Ubuntu and 0.14.15-SR5. I think this is a problem with libraries.

I opened a new discussion about this issue:
https://simulide.forumotion.com/t75-simulide-crashes-in-some-linux-systems#241