Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Dave

  1. djulien, Is there an easy way to figure out which label is causing the problem? The map and other output files are empty, so there is nothing to tell me which label is the problem. I have been using a "trial & error binary search" on the labels to try to find the bad one(s), but that is very tedious. I was hoping there was a quicker way. Sadly no.Internal errors are ones that end users should never get to see - assuming that compiler and linker are perfect. It would be good to have a simple example of such bad code so we can improve compiler and linker. Regards Dave
  2. Hopefully other language aspects make it seem worthwhile No. Regards Dave
  3. djulien, Compile doesn't know anything about addresses as they are determined by linker when the program is linked. The only way to have knowledge about code (or variable) addresses prior to the linking stage to to make them fixed. I suggest the following: #define FOO1_ADDR 0x200 #define FOO2_ADDR 0x210 #define FOO3_ADDR 0x220 #define GOTO_OPCODE 0x2800 // build jump table #pragma DATA 0x100, GOTO_OPCODE + FOO1_ADDR, GOTO_OPCODE + FOO2_ADDR, GOTO_OPCODE + FOO3_ADDR void foo1()@FOO1_ADDR { ... } void foo2()@FOO2_ADDR { ... } void foo3()@FOO3_ADDR { ... } I hope you get the idea. Its all a bit on the manual side Regards Dave
  4. This is indeed a bit of a problem, no nice way to do it at the moment. Here is a workaround; a bit ugly, and wastes memory, but should be fast. Note that I also use a fixed address function to make sure that linker doesn't move this code to a location where the jump table crosses a page boundry that would then break the code. #include<system.h> void foo(); void main() { foo(); while( 1 ); } #define LEAVE_CODE_BELOW asm btfsc _x, 0 #pragma OPTIMIZE "0" void foo() @0x100 { unsigned char value = 1; bool x = 0; value <<= 2; value += 2; pcl += value; LEAVE_CODE_BELOW goto label0; LEAVE_CODE_BELOW goto label1; LEAVE_CODE_BELOW goto label2; LEAVE_CODE_BELOW label0: porta = 1; return; LEAVE_CODE_BELOW label1: porta = 2; return; LEAVE_CODE_BELOW label2: porta = 3; return; } I hope that helps.
  5. trossin, I understand your problem. The interface only exposes register changes (this was done for efficiency) which is a real shame as you always seem to be doing such interesting things. Internally the simulator does have this functionality, such that hooks into register writes and register reads are available, and it is used by the simulated peripherals to enable them to respond to just the sort of events you describe. Also there are functions to allow reading and writing of registers without triggering read and write events. To get exposure of this functionality would require changes to IDE, debugger and simulator. So its not a couple of key presses away. So at the moment your project can't be completed. We need to take a more detailed look at things to decide if we want expand the interface and will let you know when we have made that decision. Regards Dave
  6. minitech, This method of zeroing registers is certainly not recommended for the following reasons:1) It assumes the variables refenced are in specific banks. It is normal practice to leav linker to decide where to put variables in the memory space. 2) It assumes that the loop uses no data that may be destroyed as it clears the memory. 3) It is non-portable, should you ever use some of your code on another device it may not work. The recommended method is: int myGlobalVar = 0; etc. Regards Dave
  7. minitech, Good. We haven't had any such issues reported for many years now, so didn't expect the problem to be a compiler problem. Regards Dave
  8. Lecalou60, Looks like the preprocessor may be terminating with an error. The preprocessor works on the code before the compiler in response to preprocessor directives such as #ifdef, #endif, #define. To find the cause I would do the following: 1) Take a copy of the project. 2) Keep removing chunks of the code until the preprocessor is successful, 3) Slowerly add code back in again until the error occurs again. Then you will hopefully know what is causing a problem with the preprocessor and then be able to avoid or correct it. I hope that helps Regards Dave
  9. Micmar, What exactly is not working?I ran the program you posted at the beginning of this thread and it seemed to work - well PA5 is working. Does this work for you? Regards Dave
  10. Kwooda, No it can't be done.The best method is to wrap the assembly code in a C functions using inline assembly and call the newly created C function. Regards Dave
  11. art590, Try using folder names that don't have a dot ('.') in them. Let us know how you get on. Regards Dave
  12. JorgeF, Sorry I misread your post and thought you where asking for a neater smater way - whoops. The set_bit() and clear_bit() functions are there because they existed before the method I described. Regards Dave
  13. JorgeF, status.C = 1; ... status.C = 0; ... if( status.c ) ... This works because of support for individual bit addressing in the form "var.bitNumb", where bitNumb is a constant. And C is declared as the appropriate bit number in the target header files. Regards Dave
  14. GordonS, I think you mean that half the number will get written to 0x2100.5, and you are right. Location 0x2100 conists of 16bits, which map to EEPROM locations 0 and 1 when written to during the programming process. Regards Dave
  15. JorgeF, Which target device is this for (as the reservered space chances between devices) ? Regards Dave
  16. Reynard, Nice simple fix. I didn't quite see all your changes so thought it was still broken. I ended up with a completely new version that uses less code and executes faster - see below: char* strstr( const char *ptr1, rom char *ptr2 ) { char *uPtr1; char c1, c2_1st, c2; // to save constant lookup of first character of string we are trying // to find take a copy of it c2_1st = ptr2[ 0 ]; // Nothing to find if( c2_1st == '\0' ) return (char *)ptr1; // casting constness away - not really a good idea! for( ; c1 = *ptr1, c1 != '\0'; ptr1++ ) { // when first character matches, we need to examine further to check all match if( c1 == c2_1st ) { uPtr1 = ptr1; // take copy of pointer, so search can continue from this point if needed // rom char idexes are only 8 bit unsigned char romCharIdx = 0; while( 1 ) { // get next character of string to find c2 = ptr2[ ++romCharIdx ]; // see if match completed successfully, // ie no more characters left string we are trying to match if( c2 == '\0' ) return (char* )ptr1; // casting constness away - not really a good idea! // get next character of we are searching in uPtr1++; c1 = *uPtr1; // if characters are not the same, matching has failed. if( c1 != c2 ) break; } } } // finding string failed return NULL; } Regards Dave
  17. zzjoki, Yes. You can, but only at assembly language level if you don't have the source code.If the code window is active, code stepping is on assmembly language instructions. If the code window is not the active window code stepping is on source code lines. Regards Dave
  18. TomF, You are quite right. This source code has been gathering dust as we have had no bug reports for years, but now you find an issue. I'll add it to our bugs list. Best I can suggest as a work around for now so you can see the cursor is to use the plugin in 40 x 2 character mode, because in this mode the memory is mapped just the same but line 3 is on the end of line 1 and line 4 on the end of line 2. Regards Dave
  19. The best option is to use the -rb option, this allows offseting of all the BoostC generated code. All the interrupt and reset code areas can then be use to intercept restarts and interrupts before the BoostC code is called. Once your own code is done call the BoostC code at its new offset address. I'm not sure I've made that very clear, but I hope that helps. Regards Dave
  20. Micmar, Still looking into this one, it's not straight forward. The problems here are two:1) Error in the PIC16 Ext simulator that does not allow connection to the correct pin. 2) Errors in .TDF that list the names associated with each pin. These will be fixed in the next release, Regards Dave
  21. Micmar, Still looking into this one, it's not straight forward. Regards Dave
  22. Panvadee, The LF devices are low power versions on the regular device.This means coding for them is the same as the regular device. So for the BoostC compiler select the PIC16F648a device instead. Regards Dave
  23. JorgeF, I don't know the detail. This is one for Pavel to answer. Including the ICD2.h or ICD3.h in a source file in the project reserves all the required RAM locations needed by ICD2 or ICD3. The -rt linker option prevents linker from using the code spaced that ICD2/ICD3 needs to use for the code it installs on the target device. Nice to hear :-)
  24. JorgeF, The build configurations Debug/Release are a function of the SourceBoost IDE. These simplify the addition of code used in a debug build by allowing use of #ifdef _DEBUG and #ifndef _DEBUG to conditionally compile code. They do not affect use of ICD2 or ICD3 header files. Regards Dave
  25. Updated simulator can be found here: http://www.sourceboost.com/CommonDownload/Binaries/SBV7.05.1_SimUpdate/sim ADC fix.zip Regards Dave
  • Create New...