From: Michel B. <mic...@bo...> - 2009-11-01 13:50:26
Attachments:
pompes_LOOP_FROM_HELL.tar.bz2
|
Hi guys, I fell on a problem on which I just spent a day and a half, plus a whole night, with no clue :-( At this step, as every poor programmer would, I think "this is probably a compiler issue, otherwise my brain is dead", so it's quite ashamed that I submit this here... I have a function called SubReadInputs() that does something complex yet simple ;-) : 1/ It first "statically" fills an array/structure of 12 entries by copying ports inputs into it. 2/ It then processes the array using a for (i=0; i<=11; i++) { ...blah... } loop to perform some "logical debounce magic" on said entries. However the loop doesn't work as expected at all, and when used the whole thing goes crazy and all inputs shift permanently in a completely random way that I'm completely unable to understand. I've come to incriminate the loop logic itself when I noticed that : - If I set the loop values to process a single value, it still behaves crazy for the corresponding input. - If I remove the loop logic and set "i" manually to any given constant value, then the corresponding input is processed appropriately ?!? i.e.: for (i=0; i<=0; i++) { blah-blah-blah... ; } ...and the system is mad, where : i=0; // for (i=0; i<=0; i++) { blah-blah-blah... ; // } End of loop commented out ...and input[0] is processed properly (and it works for any arbitray value of "i"). I've lost so much sleep on this one that I really give up crying mother :-/ In case there would be some sdcc weirdness in there, and some nice folk would like to take a look into my code or check the asm the compiler produces from it, I attach the whole project below. As a bonus, you'll get (working !) routines to play tunes from a PIC16F886 or flash LEDs in nice ways, calculate and update program and EEPROM checksums, but for processing a table if inputs with a stupid for(), no way... :-( You'll find the incriminated loop in the "pompes_IO.c" file by looking for the "DAMNED LOOP FROM HELL" comment :-\ My deppest gratitude will go to the helping hand :-} -- Michel Bouissou (OpenPGP ID 0xEB04D09C) |
From: George M. G. Jr. <gga...@co...> - 2009-11-01 18:28:56
|
I have SDCC : ms51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.9.0 #5416 (Oct 6 2009) (UNIX) installed and am unable to replicate your problem. I wrote a Makefile to compile from the command line. Did not generate a hex as I do have you CPU chip. George On Sun, 2009-11-01 at 14:50 +0100, Michel Bouissou wrote: > Hi guys, > > I fell on a problem on which I just spent a day and a half, plus a whole > night, with no clue :-( > > At this step, as every poor programmer would, I think "this is probably a > compiler issue, otherwise my brain is dead", so it's quite ashamed that I > submit this here... > > I have a function called SubReadInputs() that does something complex yet > simple ;-) : > > 1/ It first "statically" fills an array/structure of 12 entries by copying ports > inputs into it. > > 2/ It then processes the array using a for (i=0; i<=11; i++) { ...blah... } > loop to perform some "logical debounce magic" on said entries. > > However the loop doesn't work as expected at all, and when used the whole > thing goes crazy and all inputs shift permanently in a completely random way > that I'm completely unable to understand. > > I've come to incriminate the loop logic itself when I noticed that : > - If I set the loop values to process a single value, it still behaves crazy > for the corresponding input. > - If I remove the loop logic and set "i" manually to any given constant value, > then the corresponding input is processed appropriately ?!? > > i.e.: > > for (i=0; i<=0; i++) { > blah-blah-blah... ; > } > > ...and the system is mad, where : > > i=0; > // for (i=0; i<=0; i++) { > blah-blah-blah... ; > // } End of loop commented out > > ...and input[0] is processed properly (and it works for any arbitray value of > "i"). > > I've lost so much sleep on this one that I really give up crying mother :-/ > > In case there would be some sdcc weirdness in there, and some nice folk would > like to take a look into my code or check the asm the compiler produces from > it, I attach the whole project below. > > As a bonus, you'll get (working !) routines to play tunes from a PIC16F886 or > flash LEDs in nice ways, calculate and update program and EEPROM checksums, but > for processing a table if inputs with a stupid for(), no way... :-( > > You'll find the incriminated loop in the "pompes_IO.c" file by looking for the > "DAMNED LOOP FROM HELL" comment :-\ > > My deppest gratitude will go to the helping hand :-} > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ Sdcc-user mailing list Sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Michel B. <mic...@bo...> - 2009-11-01 18:40:44
|
HI George, and many thanks for the time you spent on this :-) Le dimanche 1 novembre 2009, George M. Gallant, Jr. a écrit : > > SDCC : ms51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 > 2.9.0 #5416 (Oct 6 2009) (UNIX) Mine is from latest Ubuntu Karmic packages and displays: 2.9.0 #5416 (Aug 15 2009), so same version number but older date... > installed and am unable to replicate your problem. I wrote a Makefile to > compile from the command line. Did not generate a hex as I do have you > CPU chip. Hmm... well, if you were able to compile it, I'm able too... But that's the actual running of this part of this program that shows completely erratic on my system (i.e. reacting as if the same input was changing state all the time in a random way when I know for sure it isn't... and not reacting to actual state changes...). If the for(...) loop is there, the program's behaviour is completely erratic, if I remove the loop and manually set the "i" value to any possible value that "i" should be able to take, then that part of the program processes the corresponding entry perfectly well. I supposed there might be either something wrong in my code (although I spent 2 days and a night checking it...) or something weird in the way sdcc translates this part of the code into assembler and that could be visible in the assembly code for sdcc specialists or developpers... But well, yes, it compiles, it just runs plain wrong :-( Thanks again for your time and help. -- Michel Bouissou (OpenPGP ID 0xEB04D09C) |
From: Raphael N. <rn...@we...> - 2009-11-04 23:44:35
|
Hi Michel, > I fell on a problem on which I just spent a day and a half, plus a whole > night, with no clue :-( > > At this step, as every poor programmer would, I think "this is probably a > compiler issue, otherwise my brain is dead", so it's quite ashamed that I > submit this here... Do not be ashamed -- it *is* a compiler issue ... that is ... it *was* a compiler issue, which I believe to be fixed in 2.9.4, r5567. Please update your SDCC installation (using a snapshot including revision r5567 or directly the svn head) and try again. Positive and/or negative feedback is always welcome. > ...and input[0] is processed properly (and it works for any arbitray > value of "i"). For fixed indices, the compiler addresses input[i].curRead via BTFSC (_input + 7*i), 1 while it uses indirect access via FSR and INDF for variable i: BTFSC INDF, 1 Unfortunately the code generator omitted to setup FSR with the address to be accessed via INDF, so we read and branched depending on random memory locations. Good luck, Raphael |
From: Michel B. <mic...@bo...> - 2009-11-05 07:29:55
|
Hi Raphael, Le jeudi 5 novembre 2009, Raphael Neider a écrit : > > it *is* a compiler issue ... that is ... it *was* a > compiler issue, which I believe to be fixed in 2.9.4, r5567. > Please update your SDCC installation (using a snapshot including revision > r5567 or directly the svn head) and try again. Thank you so much for your time and for having fixed this so quickly ! > while it uses indirect access via FSR and INDF for variable i: > BTFSC INDF, 1 > Unfortunately the code generator omitted to setup FSR with the > address to be accessed via INDF, so we read and branched depending on > random memory locations. While you were working on this, I had left this part of the code alone and continued developping, which made me excess the available program memory on my PIC16. So I moved onto a PIC18F2550 which I installed on the board 2 days ago... Since, I've been busy converting the program to this new target - much more work than what I expected as it appears that all the register names are completely different between pic16f886.h and pic18f2445.h, event though the 2 chips pinouts and registers are about the same... (i.e. in PIC16 you can use "RB3" where in PIC18 you'll have to use "PORTAbits.RA3", etc.) So my program is now using SDCC PIC18 logic and no more PIC16 Do you think that the bug and fix do affect both PIC16 and 18, in other words do I still need the fix in the 18 environment, or can I live with my Ubuntu Karmic SDCC package ? In any case, I'm glad that my bug report and your work contributed in improving SDCC for PIC16 - and I still have 7 or 8 PIC16 units in my drawer that I'll find an usage for sooner or later - my 7 years old kid wants to learn soldering ;-) That's both my first microcontroller project and the first C program I write from scratch - I believe I hadn't touched a line of C code in 12 years or so ;-) and the whole thing is for my lover, so well I enjoy doing it even though if often keeps me awake late at night :-} Thanks again for your help Raphael :-)) -- Michel Bouissou (OpenPGP ID 0xEB04D09C) |
From: Raphael N. <rn...@we...> - 2009-11-05 09:40:48
|
Hi Michel, > So my program is now using SDCC PIC18 logic and no more PIC16 Do you > think that the bug and fix do affect both PIC16 and 18, in other words > do I still need the fix in the 18 environment, or can I live with my > Ubuntu Karmic SDCC package? The bug and its fix only affect the pic14 target, no need to update right now. Raphael |