Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Reynard

  1. Do you have some form of RS232 driver chip tagged onto the TX outpit pin or are you driving directly from PIC to PC serial port. A driver chip will give you the correct inversion, as well as voltage levels. The baud rate value (12) is correct for the default internal oscillator at 4MHz or Fosc = 1MHz. Cheers Reynard
  2. Do you mean the Access Area 70-7f ? I don't think BoostC supports Access Area addressing. This block is assigned to Bank0 only (96 bytes). The other banks are 80 byte blocks with a couple of 16 byte blocks thrown in. Cheers Reynard
  3. Could you try upgrading to V6.95 and see what happens. Cheers Reynard
  4. A program should have none or very few global variables. A variable should be owned by someone. If a module wants the value of a variable from another module it should ask that module for the data and not just go in and take it or modify it itself. It could be that you write a module that stores a variable as just a solitary int. You may later change the module and put this int into a structure. When the caller does a get_int() how does it know the int was moved into a structure without rewiting the callers code. The owner of the int knows what has been changed and will return you the
  5. Don't forget to close your "If" statements with "End If". Cheers Reynard
  6. Try setting TRISIO.0 = 1 as you are using it (channel 0) as an analogue input. Cheers Reynard
  7. Thanks Dave. I will rebuild all object files. Regards Reynard
  8. When compiling a PIC16 project the assembler listing says: The build window though says "Full License". Yet another PIC16 project this in the assembler listing: Weird ! Target PIC16F873A for both projects. Should I rebuild the project files ? Could it be that one project was created using the Lite version and the other using the registered version ? Cheers Reynard
  9. Oh Well! Got there eventually. At least we all know what version you are using for the next time. Cheers Reynard
  10. Ahh! Third party software then. You take this as it comes. You should run your code using the debugger to see if you are passing the correct address for the string you are sending. I suspect though the busy signal may be be operating as expected. If you have performed an erase screen or other function that takes the display a while to process, and the busy signal is giving you a false ready status then you could be sending more data to the display before it has finished what it is already doing. This would give you missing chars at the start of the string. You can try putting a
  11. Where does lcd_printf() come from ? If you are using the LCD library you would call lprintf(). Cheers Reynard
  12. Are you sure its not there ? You should have 3 spaces before the 5 (right justified). Is the LCD cursor in the correct place ? Cheers Reynard
  13. The magic number is contained in the COFF file header structure and identifies the implimentation that the COFF follows. Microchip made some changes to its C18 and introduced some new data types. This changed the Symbol Table Entry structure and an additional bit was required (4 to 5 bits) to accomodate the extra data types. The length of this structure also increased by 2 bytes. Microchip changed the magic number to 0x1240. BoostC uses magic number 0x1234. Cheers Reynard
  14. I thought that might have been a bit of a stab in the dark. I would like to think that MPLAB handles both magic numbers of 0x1234 and 0x1240 correctly. Reynard
  15. It could be that BoostC is using a different version of COFF specification than Microchip. Cheers Reynard
  16. Add the libraries to your project (workspace window) by right clicking and selecting "Add files". Navigate to the SourceBoost lib directory and select the library you want i.e. eeprom.pic18.lib Forget about the RC3 not being in the about box as long as you know what you have installed. Cheers Reynard
  17. How are you displaying your results ? Are you using some form of printf ? Whatever you are using things thinks your longs are SIGNed. Cheers Reynard
  18. Hi Mike, If you know where in your main loop that the __rem_8_8 occurs you can create Critical Regions by turning off and on the global interrupt flag thus avoiding simultaneous use. Hope for the best is not a good option in Murphys Law. Cheers Reynard
  19. Hi Mike, Have a look at your "Call Tree" output and it should tell you where the __rem_8_8 came from. You can do simple 16 bit stuff by just using shifts, ands, unions and adds etc. Try to avoid math and string manipulation function with interrupt as you never know what is going on behind your back. Cheers Reynard
  20. Your are probably using some function in your main code and your interrupt code that calls __rem_8_8 behind the scenes. Keep interrupt function simple and avoid math functions etc. Let your main code do all the hard work. This function is not re-entrant so only one piece of code can call it at any time. If it is in use by main loop when an interrupt occurs you can be up S-Creek without you know what. Cheers Reynard
  21. Here is a little bit of code I was playing around with last year. It may need some tweaking and refining but should do the job if you are lucky. #define PI_OVER_TWO 1.570796326794896 /************************************************************ * Calculate cosine of the fp number x. * * * * x is in radians. * ************************************************************/ float cos(float x) { float_rounding_mode = float_round_down; float dnom[4] = { // Denominator table. -0.5, // -1/2! = -1/2 0.041666666667, // 1/4! = 1/24 -0.0013888888888,
  22. There is no need to clear or set the GIE bit within the interrupt function. The interrupt() function cannot be interrupted by another interrupt (of the same priority) by chip design. Additional interrupt flags could be set which is why you scan through and do a poll for the ones you are interested in. If there is an un-processed interrupt when the function exits, you will re-entry the interrupt function an hopefully pick it up then. There are several ways to set and reset a port bits, just remember the "read-before-write" feature as this can cause you to bang your head against a wall fo
  23. Basically you are just renaming a register bit. volatile bit MYBITNAME@INTCON.TMR0IF; // These statements are the same. MYBITNAME = 1; intcon.TMR0IF = 1; Assembler code output. MYBITNAME = 1; 00BC 84F2 BSF gbl_MYBITNAME,2 intcon.TMR0IF = 1; 00BE 84F2 BSF gbl_intcon,2 Cheers Reynard
  24. Hi Sean, When you enter your interrupt function try clearing the timer 0 interrupt flag TMR0IF otherwise you have a permanent interrupt. Cheers Reynard
  25. Hi Rob, I suppose the compiler thinks you are doing some 16 bit arithmetic. Try using this macro or even a union for ret to make it look like a 2 byte array. MAKESHORT(ret, adresh,adresl); The compiler can only make so may asumptions. Cheers Reynard Before anyone spots it try this: MAKESHORT(ret, adresl,adresh);
  • Create New...