simulating using Proteus

[PA3040]

Dear All,

Please guide me how I display the source code, when I am simulating using Proteus

Thanks in advance

 

[alexan_e]

Which mcu /compiler do you have.

Depending on that there is a file apart from the hex file like coff, elf ..
Use that file instead of the hex file in the mcu of proteus

 

[anirudha.athavale]

You can not display a source code in the Proteus simulator software....
you will have to use MultiSIM software to write as well as read the source code.

You can only dump a code in to proteus simulator

 

[alexan_e]

You can not display a source code in the Proteus simulator software....
you will have to use MultiSIM software to write as well as read the source code.

You can only dump a code in to proteus simulator

No you are wrong , you can see the code and debug it using step or breakpoints

 

[PA3040]

Dear Alex,
Thanks for reply
I am using pic16f877a MCU and MPASM compiler and IDE is MPLAB

Thanks

 

[PA3040]

Dear All
Please see picture. I need to display red oval area , when I start to simulate
Please advice

 

[alexan_e]

Your IDE should create a coff file , it should be in the same path as the hex file so use the coff file instead of hex in the mcu properties of proteus.
Start the simulation by using the pause or step button in proteus, if you can't see the source window then select from the menu debug -> source code.
Then you can use step or place breakpoints etc.

 

[Li_ereunpisan]

No you are wrong , you can see the code and debug it using step or breakpoints

alex ... please explain step by step how to simulate it with source code...

 

[alexan_e]

The procedure is a s describe above, you can also see it

 

[Li_ereunpisan]

The procedure is a s describe above, you can also see it

the link is only described for PIC, what if for the series asm51 use AT89CXX?

 

[alexan_e]

I haven't used anything but AVR and ARM but the process is the same , you compile the code and you use the file that contains the debug info (instead of hex), then you can see the code in proteus.

I only know that
in MPLAB the file is COFF (or cof)
in AVrstudio/winavr ELF
in codevision COF
in keil uvision (ARM) AXF

 

[Tahmid]

When you build the program, the compiler generates a hex file that you generally use to simulate in Proteus. Your compiler can generate another output file such as COFF or ELF or COF or AXF as told above by alexan_e. This needs to be loaded in Proteus instead of the hex file if you must display the source code and debug it during simulation. Some times, the compiler does not automatically generate this and you must make sure that a certain option is selected in the options of the compiler to generate this file along with HEX. I'm not absolutely sure, but I think in MPLAB, along with the HEX file, the COFF file is also generated by default. In the compilers by mikroElektronika however, you must enable the "Generate COFF file" from Tools>Options>Output Settings.

You must tell us which compiler and IDE you are using for us to be able to advise you further.

Hope this helps.
Tahmid.

 

[gaurav_sharma132]

I Have one confusion in regarding Proteus ISIS simulation. As I'm generating the pulse of period 10ms using pulse generator. Then I'm measuring the pulse width of it i.e 5ms and displaying it on LCD using ATmega328P. Pulse width verified on Proteus oscilloscope.

But LCD displaying pulse width of approx 6ms. Why this extra 1ms is added to it. Is it not as accurate or I have to do some settings ?

 

[alexan_e]

What I can say is that you'll have exactly the same result in the real hardware , I guess there is some delay in your code which adds this 1ms.

Is this 1ms always constant , for example with 40ms you get 41ms or with 100ms 101ms?

Have you tries to chance the core speed to see if this changes?
It is caused by the code then it will change with the core speed.

 

[gaurav_sharma132]

No, I checked it again it is not constant. Actually what I'm doing is trying to simulate built-in function in Arduino 1.0 and checking out the results. There is one funcion: https://arduino.cc/en/Reference/PulseIn

So here are what I observed

100Hz -- 5ms(expected) -- 6.2ms(getting)
50Hz -- 10ms -- 12.4ms
25Hz -- 20ms -- 24.8ms
12Hz -- 41.5ms -- 51.7ms

You must be observing the pattern.. offset getting double. May be I'm missing something but I'm not able to figure it out.



Regards
Gaurav