 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Richard Arroyo
Joined: 04 Apr 2006
Posts: 22
Location: Sebastopol, CA
|
|
 Posted: Mon Feb 19, 2007 1:50 pm |
 |
|
Hello Folks,
Well, I thought I would give 4.025 a try to check
the progress. Besides the funny behavior of the GUI it appears
there's an issue with pointers using inline asm.
V 3.249 increments the address by one which is correct.
Test Code:
| Code: |
#include <18f452.h>
#device adc=10
#fuses EC_IO,NOWDT,NOPROTECT,NOLVP,PUT,NOSTVREN
#use delay(clock=40000000)
#include <Math.h>
#include <stdlib.h>
#use fast_io(a)
#use fast_io(b)
#use fast_io(c)
#use fast_io(d)
#use fast_io(e)
void main(void){
Unsigned Int16 test16;
Bit_Set(test16,2);
Bit_Set(test16,10);
#Asm
BSF test16 , 2
BSF &test16+1 ,2
#EndAsm
}
|
Outputs:
| Code: |
.................... Bit_Set(test16,2);
0022: BSF 0B.2
.................... Bit_Set(test16,10);
0024: BSF 0C.2
....................
....................
....................
....................
....................
....................
.................... #Asm
.................... BSF test16 , 2
0026: BSF 0B.2
.................... BSF &test16+1 ,2
0028: BSF 0C.2
.................... #EndAsm
....................
|
Where as v4.025 shifts the address two places ahead:
| Code: |
.................... Bit_Set(test16,2);
0018: BSF 0B.2
.................... Bit_Set(test16,10);
001A: BSF 0C.2
....................
....................
....................
....................
....................
....................
.................... #Asm
.................... BSF test16 , 2
001C: BSF 0B.2
.................... BSF &test16+1 ,2
001E: BSF 0D.2 <<----------- This should be 0C.2
.................... #EndAsm
|
Is there something I'm missing here people?
I'm quite patient but if v4 is not clean
within a year I will use Microchip's C18
compiler exclusively. I've already used
it and haven't had any weird issues.
I will most definitely purchase The c30 as
I don't think there will be a CCS DsPic/24H
compiler anytime soon. I successfully
complied high speed DFT's and IIR filters
using the c30 compiler. The inline asm is not really inline asm.
I've learned real asm is best done using a .s file or ASM30.
_________________
RAA |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
Richard Arroyo
Joined: 04 Apr 2006
Posts: 22
Location: Sebastopol, CA
|
|
| Posted: Mon Feb 19, 2007 5:10 pm |
|
|
Hi PCM,
Thanks for the reply. So CSS made the change even though it would
break code made with 3.249. 
A union does the trick just fine.
| Code: |
#include <18f452.h>
#device adc=10
#fuses EC_IO,NOWDT,NOPROTECT,NOLVP,PUT,NOSTVREN
#use delay(clock=40000000)
#include <Math.h>
#include <stdlib.h>
#use fast_io(a)
#use fast_io(b)
#use fast_io(c)
#use fast_io(d)
#use fast_io(e)
Union BodgedInt16
{
Unsigned int16 a;
Unsigned int8 b;
};
void main(void){
Union BodgedInt16 test16;
Bit_Set(test16,2);
Bit_Set(test16,10);
#Asm
BSF test16.b , 2
BSF &test16.b+1 ,2
#EndAsm
}
|
Outputs:
| Code: |
....................
.................... Bit_Set(test16,2);
0018: BSF 0B.2
.................... Bit_Set(test16,10);
001A: BSF 0C.2
....................
....................
....................
....................
.................... #Asm
.................... BSF test16.b , 2
001C: BSF 0B.2
.................... BSF &test16.b+1 ,2
001E: BSF 0C.2
.................... #EndAsm
|
Well, at least it's easy to fix.
_________________
RAA |
|
|
micro2
Guest
|
| error inserting |
| Posted: Sun Mar 11, 2007 6:00 am |
|
|
hi to everybody
why am not able to insert the {} ?
when I click on the Alt button (for the sequence Alt 123) I go out from the edit mode.
Why?
Bye
compiler vers. 4.023 |
|
|
micro2
Guest
|
| error inserting |
| Posted: Sun Mar 11, 2007 6:05 am |
|
|
Ok resolved.
unchecked Dock Editor Window ceckbox.
Bye |
|
|
MikeW
Joined: 15 Sep 2003
Posts: 184
Location: Warrington UK
|
| CCS, stop concentrating on the IDE, and fix the compiler |
| Posted: Mon Mar 19, 2007 3:40 am |
|
|
This is just a rant about CCS.
The last several releases seem to be just updating the IDE.
I NEED the compiler to be fixed, not some minor interface update .
I desperately need the pointers to functions and constants etc to work.
In frustration, I last week purchased the Mikrolectronic C compiler, which does supprt those features that CCS have been promising for months.
This is not a " go buy the Mikrolrctronic compiler", its a "CCS get yer [spam] in gear"
Mike |
|
|
meepa123
Joined: 27 Feb 2007
Posts: 17
|
|
| Posted: Tue Mar 20, 2007 5:38 am |
|
|
Mine must be compiler issue too. I'm working with a 128x64 lcd but at certain modes it doesn't work. It is not a hardware issue, as the proteus 6.9 simulator gives the same response.
| Code: |
a=0;
b=0;
do
{
glcd_pixel(a,b,ON);
b++;
a++;
}while(b<=30);
glcd_update();
|
This ONLY plots the first point (0,0). The processor does not hang, as the plot appears at the lcd (proof that glcd_update(); was executed).
| Code: |
a=0;
b=0;
do
{
b++;
a++;
glcd_pixel(a,b,ON);
}while(b<=30);
glcd_update();
|
Okay, this one a joke. It is supposed that the function is the same, isn't it? This time, it plots a line from 1,1 to 30,30 a.k.a the code works properly.
I must add, that the lcd driver code is also supplied by CCS. The code is, in fact, simple (it took me a bit to understand it but it is very simple):
| Code: |
void glcd_pixel(int8 x, int8 y, int1 color)
{
int8* p;
int16 temp;
temp = y/8;
temp *= 64;
temp += x;
if(x > 63)
{
p = displayData.right + temp - 64;
}
else
{
p = displayData.left + temp;
}
if(color)
{
bit_set(*p, y%8);
}
else
{
bit_clear(*p, y%8);
}
}
|
Forgot to say, that this struct was defined at startup, an image of the lcd ram.
| Code: |
struct
{
int8 left[512];
int8 right[512];
} displayData;
|
So the thing is that this struct is not well filled... it may sound like a problem of mine... but could anybody explain me why does the code work and doesn't work, according to the position of the { a++;b++; } code?
thanks! |
|
|
meepa123
Joined: 27 Feb 2007
Posts: 17
|
|
| Posted: Tue Mar 20, 2007 10:03 am |
|
|
I must add this, in order for you to understand better the conflictive part of the program...
| Code: |
....................
....................
.................... do
.................... {
.................... b++;
0312: MOVLB 4
0314: INCF x06,F
.................... a++;
0316: INCF x05,F
.................... glcd_pixel(a,b,ON);
0318: MOVFF 405,408
031C: MOVFF 406,409
0320: MOVLW 01
0322: MOVWF x0A
0324: MOVLB 0
0326: GOTO 0218
....................
....................
.................... }while(b<=30);
032A: MOVLB 4
032C: MOVF x06,W
032E: SUBLW 1E
0330: BC 0314
|
| Code: |
....................
....................
.................... do
.................... {
....................
.................... glcd_pixel(a,b,ON);
0312: MOVFF 405,408
0316: MOVFF 406,409
031A: MOVLW 01
031C: MOVLB 4
031E: MOVWF x0A
0320: MOVLB 0
0322: GOTO 0218
.................... b++;
0326: MOVLB 4
0328: INCF x06,F
.................... a++;
032A: INCF x05,F
....................
.................... }while(b<=30);
032C: MOVF x06,W
032E: SUBLW 1E
0330: BTFSS FD8.0
0332: BRA 033A
0334: MOVLB 0
0336: GOTO 0312
|
The first one works, but the second not. I hope this can help. |
|
|
Ttelmah
Guest
|
|
| Posted: Tue Mar 20, 2007 3:53 pm |
|
|
What happens if you make the first code produce the same numbers as the second?:
| Code: |
a=1;
b=1;
do {
glcd_pixel(a,b,ON);
b++;
a++;
} while(b<=31);
glcd_update();
|
As posted, the first code produces numbers offset by one from the second example. It is worth proving that this difference is not the problem.
Best Wishes |
|
|
meepa123
Joined: 27 Feb 2007
Posts: 17
|
|
| Posted: Tue Mar 20, 2007 4:48 pm |
|
|
Thanks for your answer!
But recompiling the code at a different compiler (3.221 rather than my 4.023) has brightened the causes. Definitely, IT IS a bug.
I've tried both compilations in a stand-alone 18f458 chip in proteus 6.7 SP3. The 4.023 gives me the mentioned issue. The 3.221 version, instead, works fine.
I've sent both LST outputs to ccs people, to see if they can do something.
Another thing... do you have any problems debugging ccs V4 created files in proteus? I load the .COF file at proteus, but the debugging capabilities don't work. Instead, if I put a 3.221 compiled .COF file, it does work. Another bug? This one may be labcenter people's.
Thanks!
PD: I just looked at both LST outputs... and they are almost identical... anybody can explain that? thx |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Mar 21, 2007 10:40 am |
|
|
Both .lst files, make perfectly good sense. Have you thoroughly checked for erratas for your version of the chip (there are a _lot_ for these chips). The difference is almost certainly the use of the 'BC' instruction, which older compilers didn't use.
Best Wishes |
|
|
meepa123
Joined: 27 Feb 2007
Posts: 17
|
|
|
meepa123
Joined: 27 Feb 2007
Posts: 17
|
|
| Posted: Wed Mar 21, 2007 5:48 pm |
|
|
Hello people. Found the bug finally.
3221 code:
| Code: |
.................... temp = y/8;
0248: RRCF x09,W
024A: MOVWF x0D
024C: RRCF x0D,F
024E: RRCF x0D,F
0250: MOVLW 1F
0252: ANDWF x0D,F
|
4023 code:
| Code: |
.................... temp = y/8;
0224: RRCF x09,W
0226: MOVWF x0D
0228: RRCF x0D,F
022A: RRCF x0D,F
022C: MOVLW 1F
022E: ANDWF x0E,F
|
The difference is at 022E. I took the 4.023 hex file, and changed manually it's opcode, in order to convert 022E instruction in ANDWF x0D,F. Loaded the hex at the pic board and... voilá! The thing works. Another bug for the list, ccs![/code] |
|
|
XAVIER_CAT
Guest
|
| PROBLEMS WITH COF IN PROTEUS |
| Posted: Tue Mar 27, 2007 5:02 am |
|
|
| meepa123 wrote: | Thanks for your answer!
But recompiling the code at a different compiler (3.221 rather than my 4.023) has brightened the causes. Definitely, IT IS a bug.
I've tried both compilations in a stand-alone 18f458 chip in proteus 6.7 SP3. The 4.023 gives me the mentioned issue. The 3.221 version, instead, works fine.
I've sent both LST outputs to ccs people, to see if they can do something.
Another thing... do you have any problems debugging ccs V4 created files in proteus? I load the .COF file at proteus, but the debugging capabilities don't work. Instead, if I put a 3.221 compiled .COF file, it does work. Another bug? This one may be labcenter people's.
Thanks!
PD: I just looked at both LST outputs... and they are almost identical... anybody can explain that? thx |
Hi, I'm having too problems debugging in proteus 6.9 sp5. I use the .COF file provided by CSS, but it dont't debug well.
Does anybody have the solution?ç
Thanks |
|
|
Ttelmah
Guest
|
|
| Posted: Fri Mar 30, 2007 2:39 am |
|
|
As an 'update' on the state of the compiler, I have been playing with some parts of 4.030. Some things that were not working, are now operational. Addressmod, now seems to work OK. :-) Several bits that had bugs in the former releases do appear to work, with basic I2C, serial etc., all working. Pointers to constant strings have 'problems', but in part are working. The declarations don't work using 'const' as given in the manual, but limited functionality is there, using 'ROM'. This with all three different 'configuration' options (CCS3,4,ANSI). However there are are some serious 'screw ups', in quite basic operations at times...
| Code: |
//Limit range
if (dampval<0>1023) dampval=1023;
//Check not below minimum
if (dampval<lowval>120.0) value=120.0;
if (value<0.0) value=0.0;
}
|
Now, 'dampval', is a signed int16, sent across I2C from another chip, having a possible range of 0-1023. The first couple of lines clip any 'fliers', and ensure that the value cannot be outside this range. 'Lowval', is a signed int16, set to zero as the chip wakes up, and 'disp_div', is a float at 10.24. Latter these are set, so that a smaller part of the adc range, corresponds to 0-100%. However on boot, the maximum output possible, should be about 99.9%.
In 3.249, and several older releases, this works fine. In 4.030, it gives an output value of 120.0!. Now if you think about this, that is impossible, and implies that something radical is going wrong in the maths. It woks OK, if the division is moved onto a separate line, suggesting that the fault here is with a 'temporary' value used internally by the compiler...
Stepping through with MPLAB, has all the values as expected before the arithmetic.
It does mean, that anyone relying on the result of arithmetic, would be wise to be using another release, or 'double check' the sums do behave as expected.... 
Unfortunately, the compiler still does not do 'what it says on the tin'...
Best Wishes |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
