Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

I have a problem using Proteus

Status
Not open for further replies.
B

bomba

Full Member level 2
Joined
Sep 9, 2003
Messages
134
Helped
1
Reputation
2
Reaction score
0
Trophy points
1,296
Activity points
1,193
isis proteus

I'm using proteus to test my ccs program, I transfer the HEX file to proteus 6.3 sp1 (win XP), and when I run it step by step it work well just do the program exactly, but when I use F12 to run, it not do the same that the program.
For example I need to blink tow leds, the first led in the program line don't blink.

Any advice!!!!
Thanks
 

You may gather more help to your questions here if you are more specific in order to replicate your problems. For instance, can you upload here your program and/or your proteus proj drawings.
In general, I didn't find difference in proteus with step-by-step debugging and full running, provided that some bug exists either in your app or proteus.
 

See topic: Proteus and a 27256 EPROM

**broken link removed**
 

I'm learning to use CCS and Proteus, and maybe I'm doing something wrong....
I upload the example that I told before.....

CCS 3.181
MPLAB 6.4
Proteus 6.3 SP1
WINDOWS XP

Thanks a lot 8)
 

Hi Bomba,

Your bug happend to me when you connects the LEDs driect to the porta

You must connect them through a limiting current resistor on value 220OHM example

And the problem will be fixed

Bye
 

Well, interesting behaviour, though unrelated from resistor value.

Though cannot fully explain myself, you may have relevant results is you modify code such that:

Code: 
   delay_ms (100);
   OUTPUT_A(0x0c); // Leds switched on in a single shot.
 //  output_high (Led0);
 //  output_high (Led1);
   delay_ms (100);
   OUTPUT_A(0x00);
 //  output_low (Led0);
 //  output_low (Led1);
or:

Code: 
   delay_ms (100);
   output_high (Led0);
   delay_ms (1); // allow for small delay 	
   output_high (Led1);
   delay_ms (100);
   output_low (Led0);
   delay_ms (1);
   output_low (Led1);

May I wrong, but looks like proteus is responding to a single output event whereas two outputs are enabled in very quick sequence using output_high/output_low.

It may depends also from how CCS translates in assembly. I didn't ever seen using IAR.

However, as this board looks recently teeming with Labcenter guys :wink: , maybe this is right time to tell about problem, if any.
 

The problem seems related to internal clock of PIC model.

Try to set Processor Clock Frequency up to 7MHz.
Obviosly change your #use delay(clock=20000000) into the relevant frequency. Your code will works without any modification need.
 

Thanks James!!!! 8)

What means IAR?
 

I used OUTPUT_A(0x00) instead of OUTPU_LOW, and it work well. This intruction generate more compact assembler.

Thanks james
 

IAR is another good (but expensive) compiler for PIC and many targets as well. ( https://www.iar.com ). If you are registered user of proteus you must been supplied with a CD and a KickStart version (code limited) of IAR for PIC12/16/17.

I agree. OUTPUT_A(0x00) will be translated efficiently then output_low in CCS, but I didn't get fully the meaning of strange proteus feature related to frequency.
 

Hi bomba,

Your upload file work good when i connect the leds through resistor without any modification in the code!

Thanks james too for his notice.

Bye
 

Hi sphinx

In the ckt uploaded I connected the led through a resistor. But maybe I don't understand the meaning of "leds through resistor". See them and is there are a difference upload the schema.

Thanks a lot and in advance
 

Hi Bomba,


I didn't see your ckt becuase i havn't Proteus V6.3 (i only have V6.2 SP5)
I redraw the circuit from your c code.
I uploaded the DSN file.
Your orginal c code don't need any change.

Bye
 

SphinX,

As I said (and confirm) the problem will depend from frequency !

I got your sample and I simulated again in 6.2 SP5 (I've both).

In your sample you make use of 5MHz as a processor clock, and this is the only reason why it works. Please change it to 20MHz (as bomba's drawing does) and you will see your sample will not work anymore.
You will see D1 only flash on/off (not D2) and this is unrelated from R1/R2 values.

Do you have same results.
Please report.
 

do you known if there are more pic library available by 3º parts???

Thanks

I don't have notices about the problem comented above
 

There's a russian guy who has created a "PIC like" used in Russia. You may find (and download it) at **broken link removed** . I never tested it.

bomba, I didn't hear too about this problem before. I'm just looking now like you. The PIC model should works up 20MHz. Perhaps what we're going to see is a proteus's bug.
 

Hi james,

You WON :D
When i changed to 20Mhz, it didn't work :oops:
I didn't notice the processor clock value.

SphinX
 

Hi SphinX,

It's all right, no winners no loosers. :)

The problem here is (as you said), no modifications would required to bomba's code in normal conditions, because his code is nice.
My mods just trick over proteus behaviour, and this is bad.

I did discover another behaviour which would confirmate my theory. Set "TimeStep per Frame" value ( it's in System menu, Set Animation option...) from 50ms to 10ms. The yours and bomba's circuit will work both still with 20MHz clock freq, even though time "slows down".

Very interesting. Maybe this is a proteus's limitation.
 

I'll have a look at this but from the sounds of it I think that, as James said, the issue results from the simulation architecture.

Animation within Proteus VSM operates on the basis of performing a certain amount of simulation and then updating the screen. This is as opposed to updating the animated components every time something changes within the circuit which would be *highly* inefficient in many cases.
Typically the frame rate is defaulted to 20Hz so one frame is equivalent to 50ms. The amount of simulation time advanced per frame is determined by the Animation Timestep, as set from the System Menu within ISIS.

When you run a digital simulation the engine can be processing millions of events per second. Depending on what else your code does/delay loops etc. the IO lines may simply be toggling the LED faster than the refresh rate of the simulation. If you have the CPU power available you can fiddle with the animation timestep to correct this.
Modelling the clock internally, replacing analogue resistors with pullups etc. should help reduce CPU load.

I'll have a play and confirm the above (or eat my hat) later this morning.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top