Jump to content

Reynard

EstablishedMember
  • Content Count

    688
  • Joined

  • Last visited

Everything posted by Reynard

  1. Not many clues to go on here. Do you have an interrupt that is not being serviced, like the tx interrupt. If an interrupt flag remains uncleared then it could be hogging all the processor time jumping in and out of the interrupt function but the flags are not being cleared or stopped from being set when you don't want them. Cheers Reynard
  2. I think any recursion with Boost C is high risk. Unless the user studies the generated assembler code in detail for compiler created temp variables etc. it should be avoided. What may work with one version of Boost C may not work with a future version due to changed in code generation. If not an error message then a warning that you have recursion in your program that may cause unpredictable results. Assuming it is not already there that is. Cheers Reynard
  3. Hi Jamie, SourceBoost C does not support reentant functions. Probably because arguments are not passed on the very small stack that the PIC provides. A software stack could be used I suppose but you would need to declare a block of RAM large enough to cope with the worst case recursion you would be expecting. I think there should be a note in the manual stating that reentrant functions are not supported and/or some way for the compiler to detect recursion and throw up an error message. Cheers Reynard
  4. This code const char myarray[] = {1,2,3,4,*5,6,7,8,9,0}; generates an "access violation error ... Program terminated" message to be displayed. The build window shows the correct results and the program continues. I expect these types of exception errors to be handled correctly and not displayed on screen. Cheers Reynard
  5. Hi Jean-Marie, You can't do the assignments outside of a function block. Like this: unsigned char AltitudePression[4][10]; void main() { AltitudePression[0][0]=0; AltitudePression[0][1]=0; AltitudePression[0][2]=28; AltitudePression[0][3]=51; AltitudePression[1][0]= 3; AltitudePression[1][1]=63; ... } OR You can fill in your array at assignment time. Like this: unsigned char AltitudePression[4][10] = { 0,0,28,51, // first set of 4. 3,63,1,2, // second set of 4. ... and the rest. }; Cheers Raynard
  6. SB IDE 6.95 The prototype function tooltip highlighting only highlights to the second argument. Cheers Reynard
  7. Your waveform functions do not have a closing brace. Use the IDE to show you where the open and closing brace pairs are. A cause of missing semicolons etc. Don't do this: void config() { status|=0x20; //turn to bank 1. The compiler knows which bank the tris registers are in and will switch banks automatically. while(portc=0x01) This is an assignment to portc and not a test of bit 0. Get the format into something more readable e.g. void squarewave() { unsigned char temp1, count1; lookup_square(); while (portc == 0x01) { for(count1 = 0; count1 < Ns; ++count1) { temp1 = portd; portb = square[count1]; if (temp1 != 0x00) { if ((temp1 & 0x10) == 0x10) { delay(5); //test button pressed } if ((temp1 & 0x20) == 0x20) { delay(10); } } //end of if } //end of while } //end of loop } // End of function. Cheers Reynard
  8. Should the discriptors not be in bank starting at 0x400. Cheers Reynard
  9. Hi Adrian, #define MODE (USART_reset_wdt | USART_HW) // Define hardware USART. Try this line without a space between USART and _HW. A wee typo I think. Cheers Reynard
  10. Well spotted. The analogue enable strikes again. Analogue inputs will read as a '0'. Cheers Reynard
  11. Absolutely Russ. Keeping a shadow register for port bits is always a good idea. Write the whole lot to the port when you are finished didling with the bits immediately or if output is not required immedialely I usually wait for a timer tick (5ms or so) and update everything then. Cheers Reynard
  12. Hi Leon, You may have to put your ROUTINE into a separate function like this: void MyFunc(void) { asm { MOVLW 0x03 MOVWF _portc RETURN } } Cheers Reynard
  13. Hi Graham, It could be a rise time delay causing your problem. If you are running at a high clock rate the signal on the output pin may not have reached the high level threshold befor the next instruction read the port again. Try adding a couple of NOP's between bit setting and see if that cures it. Cheers Reynard
  14. You have to do it this way ryeg. asm { bcf _status,C } Cheers Reynard
  15. Do you mean: if (get_char() == '1') myvar = 1; Cheers Reynard
  16. NIS reports nothing with this file. Could be an Avira problem. Check their web forum. Cheers Reynard
  17. The link was to show the inclusion of the idc2.h header file which can cause problems if left out. Cheers Reynard
  18. Hi Jos, Try this: From menu, Settings - Options... - Tools tab. Find your programmer exe file and set as default. You should get your programmer then by clicking in the P on the toolbar or Build - program menu. Cheers Reynard ps. Read this topic as well just in case. http://forum.sourceboost.com/index.php?showtopic=4076
  19. Slip in a little cast seems to help. usCRC = (((unsigned short)(usCRC>>8) ^ pNum) ^ (iNum<<6)) ^ (iNum<<7); Cheers Reynard
  20. Wow! A continuous 50us interrupt on a 4MHz clocked PIC. That's hogging a lot of CPU time dude. Try timer interrupts delays if you can squeeze them in between the other interrupt. Much more accurate than delay loops and more efficient in CPU time. I have many days like this, hence the flat spot on my forehead. Cheers Reynard
  21. I have been through this before Phil. Check out page 62 of the manual (the latest manual that is). Cheers Reynard
  22. Sorry Phil, I misinterpreted what it was you were trying to do. You want the hex value of p as two ascii chars. Using V6.95 your code does work as it should. FSR0H is not being set but maybe the compilers knows something we don't about its value. Cheers Reynard I take that back. I missed the LFSR instruction setting FSR0H. Doh!
  23. Hi Phil, Try something like this: void puthex (unsigned char p) { putc(conv[p]>>4 & 0x0F); putc(conv[p] & 0x0F); } Cheers Reynard
  24. It looks like BoostC doesn't like more than one typedefed FP. Could be a bug there. Cheers Reynard
  25. Reynard

    Bug?

    'P' is already defined in the PIC18F2321.h file and therefore your 'P' is being substituted by a hex value. Rename your variable and try again. BoostC errors can be confusing at times. Cheers Reynard
×
×
  • Create New...