 |
 |
| View previous topic :: View next topic |
| Author |
Message |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
 Posted: Fri Feb 09, 2007 1:12 pm |
 |
|
I noticed CCS just came out with a new version:
| Quote: | | 4.024 The IDE now includes an option to use classic menus instead of the new ribbons |
I don't use the IDE version but for everybody who was upset about
the ribbon menus, maybe this new version will help. |
|
 |
Ttelmah
Guest
|
|
| Posted: Fri Feb 09, 2007 3:57 pm |
|
|
The newest versions of V4, at last seem to have addressmod working!. Tried a couple of tests, and it seems to operate both for read and write.
Best Wishes |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Feb 09, 2007 4:08 pm |
|
|
Have you been able to get 'rom' pointers to work ? I tried testing it
for a few minutes and couldn't get it to work. I just got blank strings
displayed. It doesn't look like the proper ASM code is generated.
Then I tried to get the 'PASS_STRINGS=IN_RAM' feature to work.
I tried to print out the contents of a two dimensional array of text
strings. But it doesn't work properly if the array index is a variable.
Of course, that's how you'd want to use it. It truncates the strings
to only 6 characters and puts a 'black rectangle' character at the end.
So I gave up on that. This was with PCH vs. 4.024, and CCS4 mode
enabled. |
|
|
Ttelmah
Guest
|
|
| Posted: Fri Feb 09, 2007 4:40 pm |
|
|
| PCM programmer wrote: | Have you been able to get 'rom' pointers to work ? I tried testing it
for a few minutes and couldn't get it to work. I just got blank strings
displayed. It doesn't look like the proper ASM code is generated.
Then I tried to get the 'PASS_STRINGS=IN_RAM' feature to work.
I tried to print out the contents of a two dimensional array of text
strings. But it doesn't work properly if the array index is a variable.
Of course, that's how you'd want to use it. It truncates the strings
to only 6 characters and puts a 'black rectangle' character at the end.
So I gave up on that. This was with PCH vs. 4.024, and CCS4 mode
enabled. |
No.
I have half a dozen test programs, that I have been trying. The first covers twenty or thirty 'normal' compiler parts, that work in 3.249. These seem largely to now work!. Then I had the addressmod one, which (given it worked in 3.249), was my 'next' test. Then I have a couple that use things like pointers to ROM. A couple of things do work (variable length strings for example), but ROM pointers don't yet seem to work yet. Pointers to functions seem to have stayed about where they were for the last few versions, working if you manually allocate, but not if you try to automatically initialise an array.
This is the first version I have seen, where just about everything that worked in 3.249, does work, and some newer parts are starting to work in places...
Best Wishes |
|
|
Tom-H-PIC
Joined: 08 Sep 2003
Posts: 105
Location: New Castle, DE
|
| Compiler Testing! |
| Posted: Tue Feb 13, 2007 8:29 am |
|
|
Hi All
Ttelmah
Would you please post some of your test programs in the code area?
I think that this would be extremely helpful for all of us.
Then when one of us though that we had an compiler issues we would all be able to test it using code that everyone would be familiar with.
Then reporting the issues or requesting help would be less of an issue for all.
Thank Ttelmah in advance.
Tom |
|
|
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 |
|
|
|
|
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
