CCS strange behaviour with Proteus

Discussion on both general simulation and Proteus VSM microcontroller simulation.
Post Reply
wh_hsn
Unlicenced User
Posts: 2
Joined: Tue 2006-03-14 8:47

CCS strange behaviour with Proteus

Post by wh_hsn »

I had a strange problem with CCS+Proteus!!

To demo the problem I'm using this code for an 8 LED knight-rider:

Code: Select all

#include "led_blnk.h"
#use fast_io(B)
 
// commenting & uncommenting this line shows 2 methods to do knight-rider
// using to slightly different methods
//#define _M1_
 
 
#ifdef _M1_
// this method doesn't work on Proteus but work ok with MPLAB & real hardware!!
#byte  PORTB  = 6
void main()
{
 int1 d=0;
 PORTB =1;
 SET_TRIS_B( 0 );
 for( ;; )
 {
   DELAY_MS(100);
   if(d) PORTB >>=1;
   else PORTB <<=1;
  if(PORTB &0b10000001) d=~d;
 }
}

#ELSE
// this method works on Proteus and with MPLAB & real hardware!!
void main()
{
 int1 d=0;
 int8 b=1;
 SET_TRIS_B( 0 );
 for( ;; )
 {
  output_b(b);
   DELAY_MS(100);
   if(d) b >>=1;
   else b <<=1;
   if(b &0b10000001) d=~d;
 }
}
#ENDIF
I'm including everything in the following ZIP file.

Proteus wrongly excute the if(d) statement in the 1st method although it's ok!!!


the hex are identical :

1) the good one:

Code:

Code: Select all

0000 00199 .................... if(d) b >>=1; 
0024 1C0F 00200 BTFSS 0F.0
0025 2829 00201 GOTO 029
0026 1003 00202 BCF 03.0
0027 0C90 00203 RRF 10,F
0000 00204 .................... else b <<=1; 
0028 282B 00205 GOTO 02B
0029 1003 00206 BCF 03.0
002A 0D90 00207 RLF 10,F
2)and the bad one:

Code: Select all

0000 00177 .................... if(d) PORTB >>=1; 
0022 1C0F 00178 BTFSS 0F.0
0023 2827 00179 GOTO 027
0024 1003 00180 BCF 03.0
0025 0C86 00181 RRF 06,F
0000 00182 .................... else PORTB <<=1; 
0026 2829 00183 GOTO 029
0027 1003 00184 BCF 03.0
0028 0D86 00185 RLF 06,F
Attachments
CCS.zip
(28.13 KiB) Downloaded 67 times
Ettore
Labcenter Staff
Posts: 2932
Joined: Fri 2006-03-03 11:56
Location: Milan
Contact:

Post by Ettore »

This depends from read-modify-write logic of PIC micros and by d/a interface logic levels. You can solve the problem in two ways:
1. use resistors in series with leds.
2. edit the leds bar and change the Forward Voltage to 2.6V.
Kind regards,
Ettore Arena - Labcenter Electronics.
wh_hsn
Unlicenced User
Posts: 2
Joined: Tue 2006-03-14 8:47

Work arround!!

Post by wh_hsn »

Hi,

I've tried both but didn't solve the odd behaviour!

I got a feed back from another user -
just edit the LED bar forward voltage to 4.8v (not 5V of course).
and made the LEDs working

thanks
Ettore
Labcenter Staff
Posts: 2932
Joined: Fri 2006-03-03 11:56
Location: Milan
Contact:

Post by Ettore »

I'm sorry for you, but both work fine to me ! You must have something else that does not work :)

4.8V makes not sense (though it works, obviously, is unreasonable high forward voltage for a led). The led forward voltage is suffice to be greater than VUD voltage (and in fact 4.8V is greater!) but at more resonable real value.

Again, with analog (not digital!) 100 ohms resistor all is working fine.. and I used your circuit not the mine.

This problem will be solved without any need to change led voltage, though.
Kind regards,
Ettore Arena - Labcenter Electronics.
Post Reply