CCS strange behaviour with Proteus

[wh_hsn]

Hi all,
 
I had a strange problem with CCS+Proteus!!
 
To demo the problem I'm using this code for an 8 LED knight-rider:
 
 

Code:

#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!!!
 
 
Anyone with an explanation?
 
Thanks

[vsmvdd]

first
 
i dont know why you post this here ?? :eek:
what do you expect people here to do about it for you??? :confused:
 
you need to talk to labcenter and point out there bug :p
 
proteus is full of bugs :rolleyes:
 
try this
 
 
init all ports as digital on pic877
 
{any micro they make models for ive tried}
 
now just use a
 
for(;
{
}
 
what i refer to as a static init
 
 
{
and this is usefull to scan the ports pins to aid in security
then reinit to run state mode a handy thing when developing secure micros
over and above the code security
{ie if you pull the chip out it wont ever run till its put back in circuit etc etc and if you remove and boot it it remembers this and disables its self for ever }
}
 
 
 
becouse it sits and does nothing
 
but you would expect that all pins of the micro should just be low
 
this is the case with mplab / picsimulator ide / virtual breadboard
and infact any other simulator i tried
 
even electronics workbench worked :cool:
 
and all pins are pulled low as you would expect
as does the real chip
and this is the correct behaviour
 
but not proteus oh no and in there infinite wisdom
they told me i was wrong !!!! and " i didnt know what i was talking about"
 
so i pointed out that the real chip also does this correctly
 
now they dont answer my mail and banned me from there user site
despite the fact i spent my hard erned wedge buying there app and my valuble time developing such models as com / sldvdd and many other dlls and over 1500 libs and parts
 
so what is the point in moaning about it here?
 
just use mplab or better buy a copy of picsimuator ide {about 30 euros or so}
 
it works perfectly and its a cheep one off fee for unlimited updates {please dont crack this app  and  support the guy  he is just one  guy  !!! dont use cracked version please}
 
its a little tedious at first to use but its a pleasure once you learn its interface
but it does work perfectly and performs all the tests i used with it
 
and the guy who writes it lives in a war ravaged country
that is just starting to get on its feet
 
personaly i would rather give him the cash !!!
 
 
your just pointing out what many people already realised from v5 till now
 
only after they splash there cash out every year and get stung up the ass
and abused by this english company
 
 
eventualy some big company will sue them or take them over
 
what i am really trying to say is there programming staff are arrigent selfritious cretins
 
no wonder people crack there software !!!
 
becouse there lack of ears for listening to there paying customers
is
 
1} frustrating
2} inept
3} cheeky
4} greedy like holding a steak infront of your nose then you find it has a bug crawl out of it
5} stupid !
 
they are too busy adding payloads to its engines to stop hacks
when really there marketing is all wrong
to the point that there company is becoming discredible in the right circles
 
so it wont be long now ..... till they go under or get bought out
 
what payloads really means is PAY LOADS !!!
 
to get a half baked app full of bugs flaws and holes
i have found over 50 bugs  reported them all and 39 are still there !!!
 five years, 75 service paks, and £400 of my quids  later !
 
when a simple test fails its really annoying
and i sympathise with youand others  fully
 
especialy when a $40 app does exactly what you need in the first place
 
 
so dont moan about it here
 
complain to them
 
they arent referred to in circles  as 'laviacenter' for nothing you know !
 
 
in fairness it did pass the flash an led test hehe
 
 
 
 
 
just for info to add a little fun into life.... ^^^^
 
right now at the moment i am deciding if i should sue them myself
for theft of intelectual properties
ALL my parts libs and models carry an ident secret marking
vsmlibs very small and hidden

i have found my labels in there standard librarys

proving they reused my copyrighted parts models and designs
and sell them as there own

[vsmvdd]

a few tips  when working with ccs

 
dont load the hex file
instead load the .cof  file  
this will allow you to step debug it  while watching the registers
you can find exactly where the flaw is
 
what i think is this  
 
TRIS ....  a headache
 
try not to use TRIS  it doesn't work well  
 
just define the port as individual pins as part of an array  then load the array

[wh_hsn]

As usual - helpful, very comprehensive reply!
Thanks VSMVDD!
 
I know that your strong words are not for my question but for laVcenter people :rolleyes:
 
What I wanted to know "why one code works & the other doesen't!!!???"
 

first
 
i dont know why you post this here ?? :eek:
what do you expect people here to do about it for you??? :confused:
 
you need to talk to labcenter and point out there bug :p
 
proteus is full of bugs :rolleyes:

I know that!
They never answered my questions before & there forum is out of order I think :confused:
 

try this
 
init all ports as digital on pic877

The demo bug was for pic84A
 
 
 

this is the case with mplab / picsimulator ide / virtual breadboard
and infact any other simulator i tried
 
even electronics workbench worked :cool:

You're right - I've tried them all - all work perfectly!
 
Although Proteus worked for me for many realy complecated designs!!
I don't use it much - I only use it in the design stage & fine-tuning stage.
 

just use mplab or better buy a copy of picsimuator ide {about 30 euros or so}
 
it works perfectly and its a cheep one off fee for unlimited updates {please dont crack this app and support the guy he is just one guy !!! dont use cracked version please}
 
its a little tedious at first to use but its a pleasure once you learn its interface
but it does work perfectly and performs all the tests i used with it
 
and the guy who writes it lives in a war ravaged country
that is just starting to get on its feet
 
personaly i would rather give him the cash !!!

I've a home-made development system plus a comercial one (EasePIC3 - great tool !) and MPLAB is my main simulator.
Virtual BreadBoard is a great tool - it's a pitty they stopped it
 

your just pointing out what many people already realised from v5 till now

I'm new to Proteus- I didn't know that - sorry!
 

when a simple test fails its really annoying
and i sympathise with youand others fully
 
especialy when a $40 app does exactly what you need in the first place

My role of thumb is never to trust software sims !!
When I see a bug - I try MPLAB then the real HW.
& MPLAB is free :rolleyes:
 

right now at the moment i am deciding if i should sue them myself
for theft of intelectual properties
ALL my parts libs and models carry an ident secret marking
vsmlibs very small and hidden
 
i have found my labels in there standard librarys
 
proving they reused my copyrighted parts models and designs
and sell them as there own

If I were you, I'll do!
 

dont load the hex file
instead load the .cof file

You are right - It's better but in the demo bug - if you try it - you'll see that Proteus treat the if statement differently - although they are exactly the same!!!!!!
 
if(d) b >>=1;
 
and
 
if(d) PORTB >>=1;
 
the test for 'd' is not simulated right!!!???!?!?!?!?!?!?!?!?
 
Thanks for your reply.

[vsmvdd]

it could be something to do with the way it parses the hex
when it encounters a PORT directive {TRIS} {in hex}
look at the hex for the two different situations
 
 
if we talk about it there programmers will gain insight
 
and i dont debug fat cats mistakes for free
 
already i said too much
 
and i will add that any MCU model that doesn't perform
such as a static init
is on other than a solid platform
 
at least they should have got the all digital working first !!!!
 
incidentaly it doesn't work with any language not just ccs or c
asm basic langage etc
 
so it will be in other parts than there loader.dll
 
more likely its becouse there model for pic isnt mixed mode
 
so there scope is limited by this
 
also judging by the structures they use in there dlls they dont have a clue
 
 
forinstance
 
iain one of there key staff
issued a dll DGATE.dll made up in visual studio a while back
 
 
the first thing i notice is the use of included library headers in the actual c class for the model
 
the first thing i learned at uni about c++ was only ever place the header .h as an
#include in the class
 
all libs #include statements belong in just the main header
 
or the scope is too narow and functions that should be there wont be
 
i attached there sources
 
take a look youll see what i mean
 
if this very basic oversight is blended thru there models and practiced by them
more likely this is there main problem thru there whole models .dlls
 
they never take the time to listen in there blatent omnipotent {they think they are god} fashon
 
 
here is how it should be done without posting my sources
 
 
.h file from sldvdd
 
////////////////////
// HEADER SET //
//////////////////////////////
#pragma once //
#include // required for some string functions pragmas
#include // required for advanced math's functions pragmas
#include // required for all Windowed applications, includes many spools & bobins in its self......
//////////////////////////////////
// API AND DEVELOPMENT HEADERS //
////////////////////////////////// placed after main includes so i can use the standard window metrix
#include "VSM.HPP" // needed to interface to proteus vsm engine
#include "VDM.HPP" // needed to interface to proteus vsm engine
 
 
 
.c model class
 
////////////////////
// HEADER SET //
//////////////////////////////
#include "SLDVDD.h" // main and only needed header file
 
 
.c message handler class
 
////////////////////
// HEADER SET //
//////////////////////////////
 
#include "SLDVDD.h" // main and only needed header file
 
 
 
the very basic entry level mistake they make is to trust in visual studio at all
 
then use digital mars {far better package}
 
BUT !!! then employ the same techniques as visual studio within digital mars
then just assume is the correct way to do it
 
its not !!! maybe the method they use is ok for some .exe files or executable dll's
 
but NOT for class based models frames
 
with heinsight  {and a masters degree} i can tell you this
 
that  really  all the  #include c++ library's
 
actualy belong in ONLY the API  its self
 
as its the actual main header
 
its like trying to teach a dog  that is badly trained  where to piss

[wh_hsn]

the if(d) statement always returns true in the PORTB method!
 
the hex are identical :
 
1) the good one:

Code:

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:

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

:confused: :confused: :confused: :confused:

[Faros]

I used not to trust simulators, but with proteus it differs, I am new to proteus, I have used it for several months, before I had used circuit maker 2000, not for PIC’s of course, but then switched to proteus.

I have produced several mass production mixed mode boards designees based on proteus, I have trusted first proteus results after carefully checking it. I didn’t even breadboard it; it worked fine in real live exactly as simulated. (With minor time lag by 2% due to capacitor quality and leakage)

If the program didn’t run on simulator but run in real circuit … no problem keep checking and tweaking tell it dose. The real problem if it runs on a simulator but it didn’t run in real. Here is the issue …

I did check your .DSN file; I have noticed that you connected the LED bar without current limiting resistors. The current measured 166mA when at LED’s ON state while F84A can source only 20mA … this condition loads PSPICE engine unrealistically and may cause unpredictable circuit behavior ( strange behavior ) even in real live especial when pulsating.

To avoid effort adding resistors you can just edit the LED bar forward voltage to 4.8v (not 5V of course).

I didn’t check your code … I don’t code in CCS ….. I have just tried to help. Beside I love proteus!!! Whoever I support vsmvdd in his opinions … he has more experience working with proteus … just my experience with proteus is less and different.

[vsmvdd]

main problem with this argument
 
as i pointed out that pic models are NOT mixed mode models
 
and looking at there code i see
they updated there model framework to mixed mode
 
so it wont matter how much current you sink from a pin
 
becouse the guts of the dll only work in a digital sence
 
so dont accomadate for too much current drawn from a pin
becouse the pins themselfs on the pics lib parts
are setup as i/o's and not passive
 
atleast you should expect that it would tell you this by v7
 
if i draw to much from a pic it blows up the gate and the pin stops working
 
so the model should disable the pin till you 'fix' the blown gate
 
simply adding this catch would cure this oversight in code
 
and is really easy to do !!!!
 
this way there is no need to measure the current or calculate it past the total current all gate on a register draw
 
any bad convergance is caused becouse there pins arent set properly
 
you can draw 1million amps from any pin on any digital model or mixed pin
 
and proteus wont complain should just use a little more energy
 
from other mixed models like the led so shouldnt affect the code
running in an array inside the pics digital branches
 
adding a load resistor wont help im sure... in a code sence
 
the two hex codes arent the same there is subtle differances
 
but i do agree that a load resistor is needed
 
but that it shouldnt care to the pic model
 
 
there is just no feedback of this kind from proteus
 
 
a good test of this and a way to catch errors
 
would be to set up the animation
to
 
50fps 15 frames per step single step size as the single ins cycle time
 
so for a 4mhz oscillator this should be 1us
 
doing this and running the code
doesn't help any further ??....
 
one simple way to fix it for good
 
is too use one current calculation
 
from all pins to ground
 
adding a ground pin defined in the mixed branches in there dll and measure total pic current per time step would cure the whole model
 
 
you see what i mean about telling them to much faros ?
EA its obvious
 
 
i found that if i had  auto insert notification {cd drive gets looked at every so often see's if you put a new disk in} causes glitch in other areas of windows
 
so disable it in the hardware manager

[wh_hsn]

Hi guys,
 
Thanks Faros, putting the forward voltage to 4.8 made the LEDs glow
 
Of course I use limiting resistors on the real HW but I know (as VSMVDD said) Proteus don't care for i/o current - & one coding method (using output_b) runs without problems!!
 
I posted a Q to the new Labcenter forum (changed & I had to re-register) & got this answer:
 
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.

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

 
single stepping change the behaviour too!
& as VSMVDD said - a CD insertion changes the behaviour too!!
getting email changes the behaviour too!!
..
..
..
and so on

[vsmvdd]

 
beleve it or not
 
 
if you add a second o/s to your system you can
disable all but onboard sound codec
disable lan {so isis and ares dosnt send data requests to servers ..hu hum...}
disable any other none essential hardware
like com2 port unless you use it
what i find is just to disable it in windows .. leave the hardware there
the machine will use different irq tables if you dont just disable it in software.
and the cd rom
{not needed for pure proteus systems i use a virtual cd for mounting images on the fly choose the cd from a drop down list and the cd automaticaly refreshes {nero}}
 
and disable any other things not essential or ever used
like the task bar icons for sound mixers video cards etc
 
win xp sp2 users running a second copy to set it up better
first you must disable the fancy rubbish that windows churns out ask for,
on its heeps stacks and registers all the dam time!
 
you can set up a single drive as multipartition with two bootable copies
using partition magic v8 {i used} this stops the stress and gives you lots more mips
 
 
navigate to the system -- system properties and disable system restore on all drives
other than the main c drive
{using partition magic it makes two c drives and hides completely the other partitions
you can also encrypt its passwords etc ...}
 
 
also never encrypt the o/s files or your own docs etc...
{windows offers to do this to accounts}
 
for a speedy machine or a decoder has to run on loads
 
this makes differances where you using the hard disk model is isis
 
but first turn the disk usage down to 0
 
then disable it or a bug in win xp is is it dosnt still use the space but other code runs if this isnt minimised and then diabled and this causes a very noticible glitch
 
also ... using ccs i find my hard disk attempts to park up on boot ?
do other suffer this ??
i think ive had the same problem with other apps
but if i remove ccs its fine
i didnt partition this disk on this machine !
 
so the partition table maybe to blame
when in the system properties
choose advanced performance set to adjust for best performance
then advanced and set for background services enabled for system
and programs for memory usage settings
change the virtual memory and for system controlled dont forgett o press the set
but if you add a second drive you can set a swap file on this also to cashe the system
and the first drive dont use it on the same ide cable or sata
and instead use it on the secondary ide
fit the cd rom on the primary as a master
set the boot for hard disk first
turn off windows update and disable
 
as many services as you can to get a lean me --proteus--machine--
 
finaly
 
i dont hate proteus
its just a pain in the ass
i also disable usb labcenter has'nt build models for it {but i have}
but via the serial port.... to a mode 1 master controller {you need 115k atleast...}
so ......