Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Everything posted by Dave

  1. This problem has been fixed in V6.97 RC5. You can download it from here: http://www.sourceboost.com/CommonDownload.html Regards Dave
  2. Because MPLAB debugger does not support bit data types they are converted into a structure with only one bit actuallt being the one of significance. The bit of interest is the member in the data structure named B. The members named X can be ignored. Not sure what mechanism this uses to determine memory useage, so can't comment. Regards Dave
  3. Yes this will be a problem. Using a software stack means that functions are not re-enterant. When accessing rom data an internal function is called. You should get a warning during the linking process warning of this issue. Disable interrupts before the accessing the array and re-enable after. This will prevent re-enterancy. Regards Dave
  4. Lou, Please do this, any additional details and repeatability will help us to understand the problem. Regards Dave
  5. No, functionally and license wise Lite and Free versions are the same, except for the warm fuzzy feeling you may get knowing that you have financially helped support the BoostC development. Regards Dave
  6. Mike, Unfortunately the paths do have to be set manually. Thats just the way it is, so you have done exactly what is needed. Regards Dave
  7. Yes this will be safe as long as the routine is not called from both threads at the same time. Disabling interrupts before calling and enabling after calling the routine in the main execution thread would make this safe. No this message can't currently be disabled, but I appreaciate that you don't want to be looking for one real warning in a sea of normally occuring ones. Regards Dave
  8. cac001, It won't work on this device because it uses input mapping, which means some of the peripheral device pin mapping can be changed at runtime.Here is a hack to allow timer 0 external clock function to work on a fixed pin: 1) Open the devices .TDF file. 2) Search to desired port and pin. 3) Add the additional pin name T0CKI to the PinNames string, eg: Configure PORTB { // create PinNames = "RB0|AN12|INT0|RP3|T0CKI","RB1|AN10|PMBE|RTCC|RP4", ..... } I hope that helps. Regards Dave
  9. joli, No. If a function is not reference then local variable cannot be allocated as it is not known where it fits in the call tree. So RAM can't be allocated, and the required bank switching cannot be therefore determined. So the function would be quite incomplete. This is not the case if you declare a function at a fixed address, for then it is assumed to be at the start of stack, so memory will be allocate from that point, even if the function is not called: void foo() @ 0x100 { .... } Regards Dave
  10. To support a new target device you need to create new .h and new .tdf files, and add the new target device to the map.txt file. You can find these files in the include and config folders. Regards Dave
  11. You can check the configuration option bit masks and data in the devices .tdf file (look for targetconfig). Pleas take a look there. Regards Dave
  12. edeca, Have to store as each as two separate bytes. Regards Dave
  13. Could be a configuration issue (like lock source). Such simple code should not be a problem. Regards Dave
  14. PeterK, We are very interested in this, we want to improve on the supplied maths function. Please post your log funtion. Regards Dave
  15. cdc49, This is dangerous code as lata is also modified in the ISR. This means that part the way through the assignment lata.0 = ~lata.0; the code could get interrupted. There maybe other problems too, this is just one that I easily notice. Typically this can be fixed by disabling interrupts for the critical section of code: intcon.GIE = 0; lata.0 = ~lata.0; intcon.GIE = 1; Regards Dave
  16. Joli, This is an area that could certainly do with improvement. Hopefully BoostC V7 will be much better in this regard. Regards Dave
  17. You need to use the MPLAB integration button that appears during the SourceBoost installation, copying the files alone is not enough. Regards Dave
  18. fraser, GPIO is not fully supported in the simulator, best way to do this is to use a similar PIC16 target for testing with the simulator. Regards Dave
  19. Great. Sounds like it is.What simulator do you use? Regards Dave
  20. Shadow var needs global scope! unsigned char portb_shadow = 0; // this variable needs to be declared globally so it can be shared between the tasks ... clear_bit( portb_shadow, 0 ); portb = portb_shadow; Sys_sleep(10); ... Regards Dave
  21. Sounds like a read modify write issue, so maybe a problem with the simulator you use. Create a shadow variable for the data (or use LAT registers on PIC18, microchip add these to fix such problems), set and clear bits in that variable instead of directly, then update the port with this variable. unsigned char portb_shadow = 0; ... clear_bit( portb_shadow, 0 ); portb = portb_shadow; Sys_sleep(10); ... Regards Dave
  22. ppulle, If it is C code that accesses the data structure, and there is no manually added code added to do bank switching (this is not a good thing to be doing) then the linker should add appropriate bank switching. If you can supply a 'bad' project, with some details of where the problem is then we can take a look. Regards Dave
  23. ppulle, There is no intended limit.Branch instructions have a limit of -1024 and +1023 16 bit locations (or twice that number of bytes), might be worth checking the .asm for longest branches. All should be in range, if the destination address is too far for branch, goto is used. Regards Dave
  24. The equivalent of const char str1[] = "String_\0"; const char str2[] = "_String_2\0"; const char str3[] = "__String_3\0"; is rom char* str1 = "String_\0"; rom char* str2 = "_String_2\0"; rom char* str3 = "__String_3\0"; Assigment of rom char* pointers is somewhat restrictive. The best I can do here is this: #include <system.h> rom char* str0 = "String_0"; rom char* str1 = "String_1"; rom char* str2 = "String_2"; void print( rom char* msg ) { unsigned char c; unsigned char i = 0; while( 1 ) { c = msg[ i ]; if( c == 0 ) break; //putc( c ); // do something with the characters i++; } } #define GetMsg( p, msgNumb )\ {\ switch( msgNumb )\ {\ case 0: p = str0; break;\ case 1: p = str1; break;\ case 2: p = str2; break;\ default: p = NULL;\ }\ } void main() { unsigned char i; for( i = 0; i < 3; i++ ) { rom char* p; GetMsg( p, i ); print( p ); } while( 1 ); } Regards Dave
  25. Apparently it is quite a bit of work, and generally non one is really impressed by Microchips USB code (based on what others have said, I personally have no experience of it) and you will be tied into their license agreenent for the code.Some users have written their own USB code which you can find here: http://embeddedadventures.blogspot.com/ Regards Dave
×
×
  • Create New...