Jump to content

glilly

EstablishedMember
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral

About glilly

  • Rank
    Newbrie
  1. Have you considered moving to BoostC. BoostC works much better than C2C in almost all ways. Regards, Pavel <{POST_SNAPBACK}> Yes, I have. Actualy, I recently tried compiling in BoostC and recieved quite a few errors. I just haven't had time to go back and weed through the code and make it compliant with BoostC. I will probably make the switch eventually, in the mean time, adding the extra line to the asm file seems to fix the other problem. So, I'm able to work with it. Thank you for your responses. P.S.: In case I failed to mention already, I think your software package is an invaluable tool for PIC programming. I saw your posts regarding interest in helping with the develpement, and I will tell you if I had more time on my hands, I would definetly be interested. I have had experience with other 'C' compilers for other hardware platforms. Great job on the product. It was money well spent. glilly
  2. Sorry about the incorrect link. Here is the correct one. http://ww1.microchip.com/downloads/en/DeviceDoc/30498c.pdf I will try to compile an example project that illustrates this problem and send it to you. The existing project is fairly large and is interdependent on four processors chained together using SPI communications. Thank you for your time, glilly
  3. Can you let me know which Microchip documentation do you refer to? Regards, Pavel <{POST_SNAPBACK}> Absolutely. I'm sorry I haven't done that already. PIC16F7X7 PDF Data Sheet Document http://ww1.microchip.com/downloads/en/DeviceDoc/80177e.pdf Section: 15.16 "Context Saving During Interrupts" Example 15-1 Has the line "clrf STATUS" directly after "swapf STATUS, W" I'm not sure what the significance of this is, but it eliminates the problem I'm seeing in every case. I was assuming it had to do something with improper memory paging during an interrupt service (It only happens when I am referencing certain global variables in the main foreground loop). glilly
  4. I'm sorry, I didn't include the compiler version etc... in my earlier post. Compiler: C2C-plus compiler version 5.5.1e IDE: SourceBoost IDE version 5.5.1 OS: Windows XP Home, Windows 2000 Professional The problem indicated above would occur randomly depending on the memory allocation of global variables and the way they are/were referenced during the main program loop. Adding the extra line in the output ASM file (so far) seems to eliminate the problem.
  5. I am working on a large project using 3 PIC16F777 and 1 PIC16F88 tied together in a custom serial network. From time to time I experience random problems with my serial protocol in the error detection routines. After some lengthy debugging, the problem seemed to be related to referencing global variables in my main program loop. The serial protocol drivers (as well as some analog drivers) are interrupt driven. Here is what I found If I included this in the main loop, errors were generated in the serial protocol. void main(void) .... .... if(Confirm) InterCnt++; .... .... When I commented out the variable increment, the errors would not occur. void main(void) .... .... if(Confirm) // InterCnt++; .... .... I traced back into the _interrupt_body code and the only thing I could find (based on the documentation supllied by MicroChip) was that the command "clrf STATUS" should be placed directly after the "swapf STATUS, W" command. *** This code causes errors: _interrupt__code movwf __int_save_cont_W swapf __int_save_cont_W, F swapf STATUS, W movwf __int_save_cont_STATUS *** This code does not cause errors: _interrupt__code movwf __int_save_cont_W swapf __int_save_cont_W, F swapf STATUS, W clrf STATUS movwf __int_save_cont_STATUS Any verification concerning this would be appreciated. glilly
×
×
  • Create New...