Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Dimitri

  • Rank
  1. I know that you can set breakpoints for when a register of memory value chages, but it would be really usefull if you could set it to break when a register or memory location reaches a specific value. It would also be usefull if this could be done on actual variables (so you can do it for 16 bit values) as well.
  2. It makes perfect sense now. I dont like problems that magically go away without a good reason, otherwise they can come back and bite you in the ass. Thanks for your help.
  3. Thanks Dave, I had a look through the assembly and found the bit where it does the saving. I also found the part of my code that was causing the problem, although I'm still unsure as to why it was a problem. When I initially wrote the ISR, I didn't know that he PIC automatically diables interrupts before calling the ISR. So I was disabling global interrupts and renabling them in the ISR: void interrupt(void) { //Disable interrupts clear_bit(intcon, GIE); //ISR Code //Re-enable interrupts set_bit(intcon, GIE); } When I realised that I didn't need this, I removed the two lines, and the strange behaviour of my background code dissapeared. Any ideas why this might have been causing by background code to execute in strange sequences?
  4. I've been trying to fix some strange bugs in program. I'm using a PIC16F628A with the BoostC compiler. I have a number of interrupt service routines and some background processing. The interrupts come from either UART, Timer, or RB0. For some reason RB0 interrupts can cause the background processing to do strange things. My question is, does the interrupt service routine save the system context (i.e the special register and the W register) and restore it automatically? If not, then this might explain the strange behaiviour. However this still wouldn't explain why only RB0 interrupts cause the problem, and Timer interrupts dont.
  5. Thanks for the macro Dave! I probably should have looked more carefully at the compiled output. I didn't realise that it optimised the masking and testing to a btfss/btfsc instruction, I just assumed it would generate the bit shifts and AND instructions. (sorry) Thanks Guys!
  6. I tired test_bit bit I noticed it wasn't supported. At the moment I'm having to do it with masking (like suggested above), but it adds unneccessary overhead. I suppose the other way to do it would be with an inline assembly instruction.
  7. I want to achieve a bit array, so basically a byte where each bit in it represents some state which I need to check and update. I want to test and set the state of individual bits in this byte, so I'd like to do the same as the PIC btfsc or btfss instruction but I'm not sure how to do this in boostC. I tried e.g.: char bitArray; char index; index = 0; bitArray.index = 1; if (bitArray.index) ..... etc.. but this gives me compiler errors. I dont want to define a separate bit for each like bit bit1, bit2, bit3 etc.... because then I can't access them with an index (as above). Thanks.
  • Create New...