 |
 |
| View previous topic :: View next topic |
| Author |
Message |
miro
Joined: 15 Jan 2011
Posts: 62
|
| Addressmod bugs v5.021 |
 Posted: Thu Mar 06, 2014 6:25 am |
 |
|
With a variable from the addressmod space FRAM ie.
| Code: |
FRAM unsigned int64 dummy;
|
this does not work
| Code: |
dummy = 0x55; // neither 0x55L, 0x55LL
|
as it casts 0x55 as int16 and returns wrong size of the var "dummy" to the addressmod _read and thus leaves the rest of the 64bit "dummy" var unchanged (the upper 6bytes are left unchanged).
This is a workaround:
| Code: | dummy = (unsigned int64) 0x55;
|
The same with array ie. dummy[5][5] = 0x55;
The above issue might be with other types as well (not tested).
And, moreover, it does not compile for any sizes less than maximum allowed:
This compiles and works:
| Code: |
..
addressmod (FRAM, fram_rd, fram_wr, 0x0000, 0x3ffff);
..
FRAM unsigned int64 sector[512][64];
|
This does not compile with "Not enough RAM for all variables" error:
| Code: |
..
addressmod (FRAM, fram_rd, fram_wr, 0x0000, 0x3ffff);
..
FRAM unsigned int64 sector[100][64];
|
This does:
| Code: |
..
addressmod (FRAM, fram_rd, fram_wr, 0x0000, 0x3ffff);
..
FRAM unsigned int64 sector[128][64];
|
Also:
| Code: | FRAM unsigned int64 dummy, happy;
..
dummy = 0xDDEEAADDBBEEAAFF;
happy = 0x1122334455667788;
printf("\r\n dummy= %Lx happy= %Lx ", dummy, happy); |
prints out:
| Code: | | dummy= ddeeaaddbbee7788 happy= 1122334455660808 |
The same with
| Code: | dummy = (unsigned int64) 0xDDEEAADDBBEEAAFF;
happy = (unsigned int64) 0x1122334455667788; |
Not tested with other types..
Weird :( |
|
 |
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Thu Mar 06, 2014 7:38 am |
|
|
Annoying certainly :-( Addressmod has reportedly been one of the features that's worked, then not worked, then worked, then not worked again and again with successive compilers.
Personally I don't trust it at all, and wouldn't attempt to use it. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1329
|
|
| Posted: Thu Mar 06, 2014 8:08 am |
|
|
make sure to report it to CCS tech support.
A couple of questions:
Do all of these bugs remain if you change all the int64 to int16's?
On the part where you said the following doesn't compile:
| Code: | | FRAM unsigned int64 sector[100][64]; |
Does this change make it compile?
| Code: | | FRAM unsigned int64 sector[100L][64]; |
|
|
|
miro
Joined: 15 Jan 2011
Posts: 62
|
|
| Posted: Thu Mar 06, 2014 1:34 pm |
|
|
| Quote: | | Do all of these bugs remain if you change all the int64 to int16's? |
I did not try all the combinations with above bugs.
| Quote: | Does this change make it compile?
FRAM unsigned int64 sector[100L][64]; |
L has none impact there..
With
| Code: | | addressmod (FRAM, fram_rd, fram_wr, 0x0000, 0x3ffff); //256kBytes SPI fram |
I get:
| Code: | FRAM float sector[100][64]; does not compile
FRAM unsigned int64 sector[100][64]; does not compile
FRAM unsigned int32 sector[100][64]; does not compile
FRAM unsigned int16 sector[100][64]; does compile
FRAM unsigned int8 sector[100][64]; does compile
FRAM float sector[512][64]; does compile
FRAM unsigned int64 sector[512][64]; does compile
FRAM unsigned int32 sector[512][64]; does compile
FRAM unsigned int16 sector[512][64]; does compile
FRAM unsigned int8 sector[512][64]; does not compile |
a mess..
| Quote: | | make sure to report it to CCS tech support. |
I reported addressmod bugs in 2/2013 (with c-code), this is the response from 7/2013:
| Quote: | ..Your e-mail has been assigned to someone in Tech Support.
As of yet, we have not had time to further review your e-mail. |
Now I would ask an another volunteer to help 
PS: It seems I am the only user interested to see the addressmod working, so that is why they do not care  |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19368
|
|
| Posted: Fri Mar 07, 2014 1:34 am |
|
|
No, you are not. Several users have used this in the past, and 'liked' it's features, but gave up, with the repeated failures. I doubt if many have got involved with more 'non standard' types like int64 though....
I was quite interested that in part it started working again a few versions ago, but 'other things' have prevented me finding the time to investigate how 'close' it is the really working...
Best Wishes |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Fri Mar 07, 2014 5:07 am |
|
|
| Ttelmah wrote: | | I doubt if many have got involved with more 'non standard' types like int64 |
Just to amplify this, CCS C has limited support for 64 bit variables, and it varies with PIC series. According to the help file I've got, there is no support at all for unsigned int64, only signed, and no support for 64 bit floats, i.e. doubles.
On the other hand, I understand there is 64 bit float support in PCD, i.e. for 24 series PICs. I'm meant to have that, as I have recently upgraded to PCD, but still my help files say not. I cannot yet say whether unsigned int64 are supported by PCD.
What I'm saying is that expecting any *unsigned* int64 to work, let alone be supported by Addressmod, is... at least for 16s & 18s et al, hopeful. |
|
|
miro
Joined: 15 Jan 2011
Posts: 62
|
|
| Posted: Fri Mar 07, 2014 12:03 pm |
|
|
@RF_developer: thanks for pointing me out at the non-existence of unsigned int64. Toying with dspic33.
The first issue is there even with signed int32 for example:
| Code: | FRAM int32 sector[8][8];
..
sector[i][j] = 0xAAAAAAAA;
..
sector[i][j] = 0x55; // the same with 0x55L
..
reads: 0xaaaa0055
works with:
sector[i][j] = (int32) 0x55;
|
All other issues are still there even with signed 64/32/16/8.
Also, adding vars to FRAM space messes them up, ie:
| Code: | FRAM int16 sector[8][8];
FRAM int16 dummy, help, happy; |
dummy, help, happy get corrupted.
This works fine:
| Code: | FRAM int16 sector[8][8];
int16 dummy, help, happy; |
So it seems this version could be used with a "specific" array size and when only a single array variable is placed in the addressmod space and casting is used when assigning a constant to addressmod var.
BTW: writing a single constant into FRAM int32 sector[1024][64] with this loop:
| Code: | for (i=0; i<size; i++)
{
for (j=0; j<sectors; j++) {
sector[i][j] = (int32) 0x55;
}
} |
takes 13.47usecs with dspic33@80MHz and a 256kB SPI fram memory @10MHz SPI clock (not that bad when considering there is 5 bytes long overhead for writing in a single 4 bytes variable). |
|
|
|
|
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
