Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Everything posted by Dave

  1. Joe, I cant get this to work. How does one specify the limits? I still get unable to create delay.. bla..bla.. <{POST_SNAPBACK}> The problem this relates to is delay_xx( 0 ); delay_xx( 1 ); and delay_xx( 255 ); these did not give the expected delays. The "unable to create" delay the function feature is by design, ie this is the current philosphy - if the delay isn't going to be accurate dont generate it. Regards Dave
  2. Joe, I can't reproduce this, it all works fine for me. Maybe its how you are creating the project - what are the steps you are performing to create the project? Please send a project demonstrating the problem to support@picant.com for further investigation. Regards Dave
  3. Joe, Summary of main linker changes: 1) Memory usage report - ROM usage uses correct units. 2) External structures would not link. 3) Delay routines now work give correct delays with min and max values. 4) ROM top/bottom address (-rt -rb command line options ) can now be specified in hex as well as decimal. 5) Overloaded functions in different files would not link. 6) Memory usage statistics corrected. 7) Hex output now does not use extended linear address unless code addresses > 65535. Regards Dave
  4. Pittuck, Or you can buy a C2C license now, there will be a very low cost upgraded to BoostC once its released. Regards Dave
  5. bhPIC, I suspect that this is you problem: http://sourceboost.ipbhost.com/index.php?s...findpost&p=4059 So if you delete the first line in the .hex file then it will probably work ok with your programmer. This will be fixed in the next release Regards Dave
  6. Joe, The problem was that the memory usage report showed the maximum used by any one thread, not the total - if you look at you interrupt routine it uses 19 bytes, hence why we runout when you add that last piece of code in. This is now fixed - and will be available in the next release V1.9. Regards Dave
  7. Joe, I cant reproduced this one, can you send me a project demonstrating the issue. Regards Dave
  8. FrankGe, Make sure you set the ADCON1 register, or the analog mode of the port will be overriding. This is the correct way to use this port. ie adcon1 = 0x0F; // turn off port A analog mode, set all pins to digitial Regards Dave
  9. fischp, Your code as one major error - using opcodes that dont exist - movw The other thing you need to know is the osccal is declare as a variable (volatile char osccal @ 0x0090;) in the header file. When you refer to variables in assembler then you need to prefix them with an underscore. So the following code compiles #include <system.h> void main() { asm { call 0x3FF movwf _osccal } } Regards Dave
  10. Joe, Just looked at this one. It was reported ages ago and has already been fixed. It will be in the next release V1.9. Regards Dave
  11. Joe, Please be more specific. Which compiler, which target device ? Regards Dave
  12. Joe, I don't know the answer to this, its one for Pavel. Regards Dave
  13. Joe, C2C compiler doesn't support structs, you need BoostC compiler for that. Regards Dave
  14. bhPIC, Looks like a compiler bug As soon as { } appear around the goto it fails. ie this code fails; void foo() { lab1: { goto lab1; } } Workaround for now is to re-write code so that goto does not appear inside {} Using goto is generally frowned upon, must be why testing hasn't reveal this problem. Here is your code without use of goto void password(void) { char i,j='0'; while( 1 ) { if(j=='1') { line3(); lcd_str(wrong); for(i = 10; i > 0; i--) { wrt_lcd('.'); delay_ms(i * 20); delay_ms(i*20); } } for(i = 0; i < 3; i++) key_press[i]=0; clear_LCD(); line1(); lcd_str(tag); line2(); lcd_str(Cam_Con); line4(); lcd_str(passline); button_handler(); wrt_lcd('*'); button_handler(); wrt_lcd('*'); button_handler(); wrt_lcd('*'); button_handler(); wrt_lcd('*'); if( (key_press[0] == '1') && (key_press[1] == '7') && (key_press[2] == '7') && (key_press[3] == '1')) { configset(); } else { // if(!((key_press[0] == '4') && (key_press[1] == '3') && (key_press[2] == '2') && (key_press[3] == '1'))) { j='1'; } else break; // terminate loop } } } Regards Dave
  15. Daniel, The problem is really a mistake in the I2C driver code The delay_us function can't be accurately generated with clock frequencies less than 20MHz, so the linker fails to generate this function (the alternative is to still generate a function that generates inaccurate delays). The current solution is already here: http://sourceboost.ipbhost.com/index.php?s...findpost&p=4143 Regards Dave
  16. jorishooijberg, Which compiler do you have selected? (see menu: settings->toolsuite). Does your posting show the full output? Looks like the compiler is not being run. Can you open and build some of the sample projects supplied with the installation? (they are in the installation directory). Regards Dave
  17. Frankge, This is now fixed. Will be available in next compiler release. This was a different problem to the other structure issue you reported. Thanks for both reports Regards Dave
  18. Frankge, This one is now fixed and will be available in the next compiler release. Regards Dave
  19. Joe, This is the expected behaviour if the clock frequency of the target is < 20MHz. The code fails to link becauses its then that the delay routine is actually created. The linker finds that it can't generate an accurate delay_us function, so it doesn't then create that function. The idea here is that rather than generate an in-accurate delay (that may result in other side affect), the code fails to link. Solution use the delay_10us() function instead when the clock frequency of the target is less than 20MHz. Regards Dave
  20. The problem is there is no project file. The project tells the compiler what files to compile, and also hold information regarding the target device. Also when accessing PORTB, lower case names need to be used as upper case names are just constant values, ie: portb = 0; Regards Dave
  21. Titanium, Please send the offending project to support@picant.com Regards Dave
  22. Titanium, How are you building the project, is it done under SourceBoost IDE ? Regards Dave
  23. FrankGe, Looks like a linker issue. I'm currently looking into it. Regards Dave
  24. FrankGe, Looks like a linker issue. I'm currently looking into it. Regards Dave
  25. gsch, Looks like a header file issue. Try dropping the 1 on "rcsta1", ie change to "rcsta". Also please tell us which target you are compiling for, otherwise we don't know which header file to check. Regards Dave
×
×
  • Create New...