Jump to content

cpetito

EstablishedMember
  • Content Count

    21
  • Joined

  • Last visited

Community Reputation

0 Neutral

About cpetito

  • Rank
    Regular
  1. cpetito

    Eeprom.pic.lib Broken In V6.96

    Thanks Pavel for the fix. I must have missed this suggestion in the other threads. The program now compiles without error and executes correctly. Regards, Carl Petito
  2. cpetito

    Eeprom.pic.lib Broken In V6.96

    Pavel, Thank you for the prompt response. You have confirmed what I had read in other posts. I must be overlooking something obvious. This code: #include <system.h> #include <eeprom.h> //Target PIC18F458 configuration word #pragma DATA _CONFIG1H, _OSCS_OFF_1H & _HS_OSC_1H #pragma DATA _CONFIG2L, _BOR_OFF_2L & _PWRT_OFF_2L #pragma DATA _CONFIG2H, _WDT_OFF_2H #pragma DATA _CONFIG4L, _DEBUG_OFF_4L & _LVP_ON_4L & _STVR_ON_4L #pragma DATA _CONFIG5L, _CP3_OFF_5L & _CP2_OFF_5L & _CP1_OFF_5L & _CP0_OFF_5L #pragma DATA _CONFIG5H, _CPD_OFF_5H & _CPB_OFF_5H #pragma DATA _CONFIG6L, _WRT3_OFF_6L & _WRT2_OFF_6L & _WRT1_OFF_6L & _WRT0_OFF_6L #pragma DATA _CONFIG6H, _WRTD_OFF_6H & _WRTB_OFF_6H & _WRTC_OFF_6H #pragma DATA _CONFIG7L, _EBTR3_OFF_7L & _EBTR2_OFF_7L & _EBTR1_OFF_7L & _EBTR0_OFF_7L #pragma DATA _CONFIG7H, _EBTRB_OFF_7H //Set clock frequency #pragma CLOCK_FREQ 20000000 void main( void ) { unsigned char eeprom_address = 0; eeprom_write(eeprom_address, 0); //Endless loop while( 1 ); } with this project file: gives me this linker error: I also tried removing the include: eeprom.h and explicitly prototyping the function: void eeprom_write( unsigned char address, unsigned char data ) in the code. I am using V6.97 Release Candidate 4 A pointer to my error will be appreciated. Thank you, Carl Petito
  3. cpetito

    Eeprom.pic.lib Broken In V6.96

    Was this issue ever corrected or should I use the last workaround suggested above: use modified versions of eeprom.c & eeprom.h instead of using eeprom.pic18.lib? I am using V6.97 RC4 with eeprom.pic18.lib (dated April 2, 2010) for a PIC18F458 and am getting the error: "Failed to resolve external:eeadrh" It appears that based on discussion in another thread, eeprom.h (dated February 22, 2010) has been updated: #ifdef _PIC16 unsigned char eeprom_read( unsigned char address ); void eeprom_write( unsigned char address, unsigned char data ); #elif _PIC18 unsigned char eeprom_read( unsigned char address ); void eeprom_write( unsigned char address, unsigned char data ); #ifdef EEADRH unsigned char eeprom_read( unsigned short address ); void eeprom_write( unsigned short address, unsigned char data ); #endif #else #error "unsupported target" #endif Thank you, Carl Petito
  4. cpetito

    Compiler Problem With Unsigned Long Compare

    Thank you for the very prompt response. You folks are exceptional! Regards, Carl
  5. Bug description: Compiler seems to produce incorrect output when comparing an unsigned long with a unsigned char. Steps to reproduce: The following code was extracted from a larger project and compiled. I believe that the compiler output for the compare is not correct and the compare does not evaluate as expected. #include <system.h> //Target PIC18F458 configuration word #pragma DATA _CONFIG1H, _OSCS_OFF_1H & _HS_OSC_1H #pragma DATA _CONFIG2L, _BOR_OFF_2L & _PWRT_OFF_2L #pragma DATA _CONFIG2H, _WDT_OFF_2H #pragma DATA _CONFIG4L, _DEBUG_OFF_4L & _LVP_ON_4L & _STVR_ON_4L #pragma DATA _CONFIG5L, _CP3_OFF_5L & _CP2_OFF_5L & _CP1_OFF_5L & _CP0_OFF_5L #pragma DATA _CONFIG5H, _CPD_OFF_5H & _CPB_OFF_5H #pragma DATA _CONFIG6L, _WRT3_OFF_6L & _WRT2_OFF_6L & _WRT1_OFF_6L & _WRT0_OFF_6L #pragma DATA _CONFIG6H, _WRTD_OFF_6H & _WRTB_OFF_6H & _WRTC_OFF_6H #pragma DATA _CONFIG7L, _EBTR3_OFF_7L & _EBTR2_OFF_7L & _EBTR1_OFF_7L & _EBTR0_OFF_7L #pragma DATA _CONFIG7H, _EBTRB_OFF_7H //Set clock frequency #pragma CLOCK_FREQ 20000000 static unsigned long time; void test_compare(unsigned long time){ unsigned char monthLength; monthLength = 31; if (time >= monthLength) { time -= monthLength; } } void main( void ) { //Endless loop while( 1 ){ time = 133; test_compare(time); } } Here is the compiler output: if (time >= monthLength) { 000C 5009 MOVF test_compa_00009_1_monthLength, W 000E 6E0A MOVWF CompTempVar592 0010 6A0B CLRF CompTempVar592+D'1' 0012 6A0C CLRF CompTempVar592+D'2' 0014 6A0D CLRF CompTempVar592+D'3' 0016 5C08 SUBWF test_compa_00009_arg_time+D'3', W 0018 E108 BNZ label1 001A 500C MOVF CompTempVar592+D'2', W 001C 5C07 SUBWF test_compa_00009_arg_time+D'2', W 001E E105 BNZ label1 0020 500B MOVF CompTempVar592+D'1', W 0022 5C06 SUBWF test_compa_00009_arg_time+D'1', W 0024 E102 BNZ label1 0026 500A MOVF CompTempVar592, W 0028 5C05 SUBWF test_compa_00009_arg_time, W 002A label1 002A A0D8 BTFSS STATUS,C It appears that W is not properly initialized prior to the the first SUBWF at 0x0016. And for a variation, if monthLength is cast as an unsigned long. note that additionally at 0x0014 CompTempVar593+D'3' is cleared and not CompTempVar592+D'3' as expected.: if (time >= (unsigned long)monthLength) { 000C 5009 MOVF test_compa_00009_1_monthLength, W 000E 6E0A MOVWF CompTempVar592 0010 6A0B CLRF CompTempVar592+D'1' 0012 6A0C CLRF CompTempVar592+D'2' 0014 6A11 CLRF CompTempVar593+D'3' 0016 5C08 SUBWF test_compa_00009_arg_time+D'3', W 0018 E108 BNZ label1 001A 500C MOVF CompTempVar592+D'2', W 001C 5C07 SUBWF test_compa_00009_arg_time+D'2', W 001E E105 BNZ label1 0020 500B MOVF CompTempVar592+D'1', W 0022 5C06 SUBWF test_compa_00009_arg_time+D'1', W 0024 E102 BNZ label1 0026 500A MOVF CompTempVar592, W 0028 5C05 SUBWF test_compa_00009_arg_time, W 002A label1 002A A0D8 BTFSS STATUS,C However if we cast both operands as unsigned ints, the code is as expected, Register W is initialized prior to the first SUBWF: if ((unsigned int)time >= (unsigned int)monthLength) { 000C 5009 MOVF test_compa_00009_1_monthLength, W 000E 6E0A MOVWF CompTempVar592 0010 6A0B CLRF CompTempVar592+D'1' 0012 500A MOVF CompTempVar592, W 0014 5C05 SUBWF test_compa_00009_arg_time, W 0016 500B MOVF CompTempVar592+D'1', W 0018 6206 CPFSEQ test_compa_00009_arg_time+D'1' 001A 5C06 SUBWF test_compa_00009_arg_time+D'1', W 001C A0D8 BTFSS STATUS,C Expected behaviour: With the values assigned to time and monthLength, I expected that the expression would have evaluated true and executed the statement: time -= monthLength; Is the problem 100% reproduceable: Yes IDE version: SourceBoost IDE version Compiler: BoostC Compiler version: V6.97 Release Candidate 4 Target device: PIC18F458 OS: Windows VISTA Professional 64bit Comments: I believe that the code worked as expected with SourceBoostC V6.96. I decided to reinstall because I was having simulation issues with the SourceBoost IDE. I reinstalled with the latest RC to see if it corrected the simulation issues. It appears that the simulation issues are resolved, but then I discovered the above issue. I did not back down to V6.96 to verify.
  6. cpetito

    Task Priorities - Lower Is Higher?

    Thanks for the confirmation - my brain is now a little less confused I am dealing with real time audio that is pushing the PIC's limits, so the effect was very obvious. Especially with some inefficient initial code. You folks have great products and I am very impressed with the level of support and quick responses. I am sure that whatever the issue, it will be resolved. Regards, Carl Petito
  7. cpetito

    Task Priorities - Lower Is Higher?

    Pavel, Thank you for the reply. Please see the sample that I added to this thread. It is a very simple test created with the BoostC wizard and unless someone can point my mistake, it seems that the documentation does not agree with the behavior. Regards, Carl Petito
  8. Perfect! Thank you for the quick response.
  9. How do I recover undocked windows with SourceBoost IDE, Version 6.96, that are now on a non-existent monitor? I was using BoostC on a laptop with a second monitor. The second monitor was displaying plugins during debug and the output window during compiling. Now when I start up BoostC without the second monitor, the undocked windows are still on the non-existent monitor. Any way to call the windows back on the laptop monitor? Thanks, Carl Petito
  10. cpetito

    Task Priorities - Lower Is Higher?

    Dave, Thanks for the reply. Great minds must think alike! I just finished a test as you suggested. Bottom line, I believe that smaller numbers yield a lower priority. I used BoostC's wizard (Version 6.96) to create the following test. Task0 simply toggles RB1 and Task1 toggles RB2. Running this code in the simulator with the following priorities yielded the following results: Task0 P:2, Task1 P:2 - RB1, RB2 blink, as expected Task0 P:0, Task1 P:2 - only RB2 blinks, but expected RB1 Task0 P:2, Task1 P:0 - only RB1 blinks, but expected RB2 Perhaps I am misinterpreting something or have confused my brain along the way. Thanks, Carl Petito #include <system.h> #include <novocfg_pic16t3e5ts1.h> #include <novo.h> //Target PIC16F877 configuration word #pragma DATA _CONFIG, _PWRTE_OFF & _BODEN_OFF & _WDT_OFF & _LVP_ON & _CPD_OFF & _DEBUG_OFF & _HS_OSC & _CP_OFF //Set clock frequency #pragma CLOCK_FREQ 20000000 #define hTask0 0 #define hTask1 1 void interrupt( void ) { //Handle timer0 interrupt if( intcon & (1<<T0IF) ) { SysTimerUpdate(); clear_bit( intcon, T0IF ); //clear timer 0 interrupt bit } //Handle timer1 interrupt if( pir1 & (1<<TMR1IF) ) { clear_bit( pir1, TMR1IF ); //clear timer 1 interrupt bit } //Handle timer2 interrupt if( pir1 & (1<<TMR2IF) ) { clear_bit( pir1, TMR2IF ); //clear timer 2 interrupt bit } } void Task0() { //This is a task place holder, replace with your own code while( 1 ) { portb.1 = !portb.1; //added this bit toggle Sys_Yield(); } } void Task1() { //This is a task place holder, replace with your own code while( 1 ) { portb.2 = !portb.2; //added this bit toggle Sys_Yield(); } } void main( void ) { //Configure port A trisa = 0x00; //Configure port B trisb = 0x00; //Configure port C trisc = 0x00; //Configure port D trisd = 0x00; //Configure port E trise = 0x00; //Configure A/D pins adcon1 = 0x06; //Initialize port A porta = 0x00; //Initialize port B portb = 0x00; //Initialize port C portc = 0x00; //Initialize port D portd = 0x00; //Initialize port E porte = 0x00; //Set Timer0 mode clear_bit( option_reg, T0CS ); //configure timer0 as a timer //Set prescaler assignment clear_bit( option_reg, PSA ); //prescaler is assigned to timer0 //Set prescaler rate clear_bit( option_reg, PS2 ); //prescaler rate 1:2 clear_bit( option_reg, PS1 ); clear_bit( option_reg, PS0 ); //Set timer0 source edge selection set_bit( option_reg, T0SE ); //increment on high-to-low transition on RA4/T0CKI pin //Set timer 1 prescaler rate clear_bit( t1con, T1CKPS1 ); //prescaler rate 1:1 clear_bit( t1con, T1CKPS0 ); //Set timer 1 mode clear_bit( t1con, TMR1ON ); //disable timer 1 //Set timer 2 prescaler rate clear_bit( t2con, T2CKPS1 ); //prescaler rate 1:1 clear_bit( t2con, T2CKPS0 ); //Set timer 2 postscaler rate clear_bit( t2con, TOUTPS3 ); //postscaler rate 1:1 clear_bit( t2con, TOUTPS2 ); clear_bit( t2con, TOUTPS1 ); clear_bit( t2con, TOUTPS0 ); //Set timer 2 mode (enable or disable) clear_bit( t2con, TMR2ON ); //enable timer 2 //Enable interrupts (Timer0) intcon = 0xA0; //Initialize Novo RTOS SysInit(); //Create Novo tasks SysCreateTask( hTask0, 2, Task0 ); //0 - expect RB1 to blink, but RB2 blinks SysCreateTask( hTask1, 2, Task1 ); //Start Novo tasks SysStartTask( hTask0 ); SysStartTask( hTask1 ); //Endless loop while( 1 ) Sys_Yield(); }
  11. Novo RTOS is great. I am using it with BoostC Version 6.96. I just want to confirm that my understanding based on documentation and examples is correct: the lower the task priority number the higher priority for the task. Which means that unless a task with lower number sleeps or waits for an event, it will block execution of tasks with higher numbers. My experience seems to contradict. I have three real time tasks (listed in decreasing real time importance): Play Audio (22Khz PWM) Update LCD display (every second) Input IR codes RTOS timer is updated every .1 msec. Audio waits on a semaphore. LCD waits on a semaphore generated by a timer interrupt every second. IR waits on a semaphore generated by a port bit interrupt. The audio PCM data is from a MMC card buffered in a circular queue. With all the tasks set to priority = 2, I get occasional buffer underruns with the audio. The root solution is to improve the efficiency of the code, but I decided to play a bit with task priorities to see the results. Initially I set the priorities as Audio = 0, LCD = 1, IR = 3. The unexpected result was that the audio underruns were much worse. I then set the priorities as Audio = 3, LCD = 1, IR = 0. Now the audio plays perfectly, but because when running, the audio task yields, but never sleeps, the LCD is not updated until the audio task completes. I may be over looking something obvious, but if lower numbers are higher priorities, I will look at / simulate the code in more detail to find why the results are contrary to expectations. Thank you for any pointers or comments. Carl Petito
  12. This is not a warning. This is just a caution message that reminds about delay argument value range. You will get this caution if you use delay calls in your code. Regards, Pavel Pavel, Thanks for the clarification. As an FYI, the there is no caution generated when using delay_10us(1) - but it does generate a little more code then delay_us(10). Also, delay_ms() and delay_s() do not seem to generate a caution either. Not a big deal. Thanks, Carl Petito
  13. Reynard, Thanks for the pointers. I was looking for a configuration file, but the linker switch is the better approach. I missed this switch because the documentation does not have a paragraph description for -rt. However, it is listed in the usage summary along with several other switches that I was not aware existed. Thanks for the revelation! Carl Petito
  14. Any way to get an linker error or warning if my application code size encroaches on the boot loader code space at 0x1E80? Thanks, Carl Petito
  15. With BoostC, version 6.89, the following snippet of code: #pragma CLOCK_FREQ 20000000 ... delay_us(10); generate the following linker warning: "Caution: argument of 'delay_us' calls must have a value of 1 or more" The generated code looks like: ORG 0x00000010 0010 delay_us_00000 0010 ; { delay_us ; function begin 0010 label1 0010 0000 NOP 0011 0000 NOP 0012 0B92 DECFSZ delay_us_00000_arg_del, F 0013 2810 GOTO label1 0014 0008 RETURN 0015 ; } delay_us function end ... 0237 300A MOVLW 0x0A 0238 0092 MOVWF delay_us_00000_arg_del 0239 2010 CALL delay_us_00000 I'm not sure why the warning and I believe that the delay is correct: 10 loops of 5 instruction cycles at .2us/cycle = 10us (plus the overhead of the call - close enough for my purposes) What am I missing - why the warning? Thanks, Carl Petito
×