 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Max
Joined: 15 Dec 2003
Posts: 51
Location: Italy
|
| problem with version 4.140 |
 Posted: Mon Jun 24, 2013 11:32 am |
 |
|
Hello,
I think it's a problem of structures that are not well defined, but I would ask an opinion.
| Code: |
#define MAXTEL 8
#define ARBSIZE 24
char argbuf[ARBSIZE];
|
| Code: | typedef struct
{
char numtel[21];
unsigned int8 ass_in;
bit ab_cal:1;
bit ab_sms:1;
bit ab_voc:1;
} tel_struct;
|
| Code: | | tel_struct tel_data[MAXTEL]; |
| Code: |
strcpy(tel_data[n_leggi_num].numtel, argbuf);
|
If I use the strcpy in the version 4.119 is ok tel_data[n_leggi_num].numtel contains regular data
if use for example version 4.128
the first byte of tel_data[n_leggi_num].numtel contain '\0' why?
Last edited by Max on Fri Jun 28, 2013 10:29 am; edited 2 times in total |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Jun 24, 2013 11:38 am |
|
|
It's important to post a small, compilable test program. Notice this thread
on today's board:
http://www.ccsinfo.com/forum/viewtopic.php?t=50712
The original poster does not provide a test program. So we have to guess
what his problem is, and try to make a test program. The whole thread
still does not have any resolution at this time. We're still guessing.
You should prevent this problem in your thread by posting a test program
that shows the problem. It must have the #include for the PIC, #fuses,
#use delay, main(), variables, constants, etc. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Tue Jun 25, 2013 7:06 am |
|
|
I wonder if this is legal C code.
Consider what you are saying: from the type bit, take 1 bit to put it here in the structure. I don't know how 'bit' is defined in the compiler and I don't have the compiler here to check it but even when it is working it is a strange way to code it like this. A bit is already of size 1 bit, so why specify that you want only to use 1 bit from it (it is even confusing when I write it down like this).
The correct way:and what might work, but is not compatible with other compilers: |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Wed Jun 26, 2013 12:13 am |
|
|
| Quote: | | I don't know how 'bit' is defined in the compiler |
It's not defined in the compiler nor a standard C type.
It's the bad thing of posting incomplete code snippets, not worth to discuss it. |
|
|
Max
Joined: 15 Dec 2003
Posts: 51
Location: Italy
|
|
| Posted: Wed Jun 26, 2013 12:53 am |
|
|
Thanks for all reply,
I forgot to post the definition of bits
ok so if it's better to write 'I will
These are the fuse and .. more
| Code: | #include <18F458.h>
#device adc=10
#use delay(clock=11059200,RESTART_WDT)
#fuses NOWDT,WDT128,HS, PROTECT, NOOSCSEN, NOBROWNOUT, BORV20
#fuses NOPUT, NOCPD, STVREN, NODEBUG, NOLVP, NOWRT, NOWRTD, NOWRTB
#fuses NOCPB, NOWRTC, NOEBTR, NOEBTRB
#use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,RESTART_WDT,bits=8,ERRORS)
#use FAST_IO(A)
#use FAST_IO(B)
#use FAST_IO(C)
#use FAST_IO(D)
#use FAST_IO(E) |
Unfortunately, maybe there are some lines you do your standard "C", but what I do not understand is why with some versions of CCS works well and others do not.
thanks |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19503
|
|
| Posted: Wed Jun 26, 2013 1:28 am |
|
|
It is _best_, to use the bitfield, not int1 at all here.
| Code: |
typedef struct
{
char numtel[21];
unsigned int8 ass_in;
int ab_cal:1;
int ab_sms:1;
int ab_voc:1;
} tel_struct;
|
You are defining 'sub variables' one bit in size, inside an integer. This is standard C.
'int1', is a CCS expansion, allowing you in general to define 'one bit' integers, but does introduce the problem of how such variables are going to be aligned when stored in something like a structure, and to then try defining a one bit field 'inside' a one bit variable gets into 'black art' territory. The point about bitfields is that these are the 'standard' C way of defining bits.
The bitfield operator explicitly says in K&R, that the variable may _only_ be an integer. CCS won't handle (for example), bitfields into an int16 (for PIC16/18), but does not syntax check this.
Far better and safer to stick to standard C.
Best Wishes |
|
|
Max
Joined: 15 Dec 2003
Posts: 51
Location: Italy
|
| **** EDIT **** |
| Posted: Wed Jun 26, 2013 6:47 am |
|
|
I replaced the lines of code in the way I have indicated, however, I think I miss anything again:
From debugging after breackpoint, I have in in_data [0]. Contact = 0
if I execute the line
| Code: | | mystruct.v_contact = in_data[0].value |
v_contact contains 1.
v_contact and in_data is defined in this way:
| Code: | struct
{
int v_contact:1;
}mystruct;
typedef struct
{
int enable:1;
int contact:1;
int polar:1;
int pin:1;
int status:1;
int allarme:1;
int gia_chiamato:1;
unsigned int8 delay_sample;
unsigned int16 delay;
unsigned int16 counter;
} input_struct;
input_struct in_data[4];
|
I do not understand why.
| Code: | (file lst) mystruct.v_contact = in_data[t].contact;
0906: BCF xA2.2
0908: MOVF x99,W
090A: MULLW 06
090C: MOVF FF3,W
090E: CLRF xA4
0910: MOVWF xA3
0912: MOVLW E6
0914: ADDWF xA3,W
0916: MOVWF FE9
0918: MOVLW 01
091A: ADDWFC xA4,W
091C: MOVWF FEA
091E: BTFSS FEF.0
0920: BRA 0924
0922: BSF xA2.2
mystruct.v_status = (mystruct.v_enable && (!mystruct.v_pin ^ mystruct.v_contact));
0924: BTFSS xA2.0
0926: BRA 093A
0928: MOVLW 00
092A: BTFSS xA2.1
092C: MOVLW 01
092E: MOVWF xA4
...
... |
Last edited by Max on Wed Jun 26, 2013 11:49 am; edited 1 time in total |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Wed Jun 26, 2013 9:43 am |
|
|
The data referenced in the diasassembly list doesn't match the above source. This brings up one more
the question of a complete, compilable test program demonstrating the problem.
Without it, I see no chance to find out anything meaningful. |
|
|
Max
Joined: 15 Dec 2003
Posts: 51
Location: Italy
|
|
| Posted: Wed Jun 26, 2013 10:04 am |
|
|
| FvM wrote: | The data referenced in the diasassembly list doesn't match the above source. This brings up one more
the question of a complete, compilable test program demonstrating the problem.
Without it, I see no chance to find out anything meaningful. |
Thanks,
the code is very long, it is impossible to post it.
I still say, however, that the 4119 version it's all right  |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Wed Jun 26, 2013 12:26 pm |
|
|
| Quote: | | the code is very long, it is impossible to post it. |
Noone asked for posting the full code.
There are essentially two options:
- the problem/bug/whatsoever can be reproduced with a small test programm. Then you should try to
setup a respective example and you have a good chance that other forum memeber can help you to
explain the problem, possibly find a workaround etc.
- problem can't be easily reproduced and occurs only in your application. Then it's about to meaningless to
discuss the details in the forum, except for saying: there's a problem, but I don't know why.
P.S.: I checked, that the assembly code is apparently correct (for the actual structure layout, not the
arrangement shown in the post) and identical for V4.112 and V4.127. |
|
|
Max
Joined: 15 Dec 2003
Posts: 51
Location: Italy
|
|
| Posted: Thu Jun 27, 2013 12:13 am |
|
|
The first assembler code is generated from version 4.140, the second with version 4.119.
The C source code is NOT changed, while the assembler code you '.
It can be seen as the 'education BTFSS that when compiled with 4,140 controls bit 0, whereas the 4,119 controls the bit 1.
With 4.140
| Code: | .................... mystruct.v_contact = in_data[t].contact;
082C: BCF xA3.2
082E: MOVF x99,W
0830: MULLW 06
0832: MOVF FF3,W
0834: CLRF xA5
0836: MOVWF xA4
0838: MOVLW E6
083A: ADDWF xA4,W
083C: MOVWF FE9
083E: MOVLW 01
0840: ADDWFC xA5,W
0842: MOVWF FEA
0844: BTFSS FEF.0
0846: BRA 084A
0848: BSF xA3.2 |
with 4.119
| Code: | .................... mystruct.v_contact = in_data[t].contact;
082C: BCF xA3.2
082E: MOVF x99,W
0830: MULLW 06
0832: MOVF FF3,W
0834: CLRF xA5
0836: MOVWF xA4
0838: MOVLW E6
083A: ADDWF xA4,W
083C: MOVWF FE9
083E: MOVLW 01
0840: ADDWFC xA5,W
0842: MOVWF FEA
0844: BTFSS FEF.1
0846: BRA 084A
0848: BSF xA3.2 |
If I create a small project with only these instructions, NOT the problem occurs, exists only in the full program.
But what I do not understand is why with two different versions assembler generates two different codes |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19503
|
|
| Posted: Thu Jun 27, 2013 2:44 am |
|
|
I think the problem is far more 'basic'.
Suspicion, possibly the keyword 'enable' has a #defined expansion, somewhere in one of the later include files (driver or something), with the compilers after 4.119.
Hence the actual structure is not being setup as you think, so the code fails.
With the basic code (no driver includes), the code works fine, so the compiler doesn't have a problem at heart with handling anything here.
Unfortunately (always annoying), CCS doesn't allow you to 'see' the source file 'after macro expansion', making this one hard to detect.
Simply change the actual 'names' used in the variables. Just do a text search and replace on all your source files, for 'contact', 'enable' etc., and change them to something like 'my_cont', and 'my_ena', which are unlikely to exist in any CCS file. If the problem disappears, you know exactly what it going on.
Best Wishes |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Thu Jun 27, 2013 4:12 am |
|
|
| Quote: | I think the problem is far more 'basic'.
Suspicion, possibly the keyword 'enable' has a #defined expansion, somewhere in one of the later include files (driver or something), with the compilers after 4.119. |
Something like this might happen. My problem with the previously posted code was, that the structures
obviously contain additional fields that are not shown in the source, e.g. v_pin and v_enable. Posting
consistent code is the absolute minimal requisite to discuss a possible bug, I think.
If you see however bitfields shifted, reordered or whatsoever, it would be quite easy to find out what has
been assigned to the other bits by scanning symbol files and assembly listings, respectively check if all
fields can be still accessed. We can't see if the bit enable is used anywhere in the code. |
|
|
Max
Joined: 15 Dec 2003
Posts: 51
Location: Italy
|
|
| Posted: Thu Jun 27, 2013 6:53 am |
|
|
| Ttelmah wrote: | I think the problem is far more 'basic'.
Suspicion, possibly the keyword 'enable' has a #defined expansion, somewhere in one of the later include files (driver or something), with the compilers after 4.119.
|
Nothing, I replaced all the names of both the structure and the its members, but always the same problem.
I think I'll leave the old version |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Thu Jun 27, 2013 11:06 am |
|
|
You showed that in the example in_data[t].contact is read as bit 0 in V4.140 although it's assigned to bit 1.
- Is it always accessed at this memory location, also in other instructions?
- How about in_data[].enable, which is expected at bit 0? Is it used in your application at all? If yes, where does the compiler access it? |
|
|
|
|
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
