Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About cpetito

  • Rank
  1. 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. 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 &am
  3. 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
  4. 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 &
  6. 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. 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. 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
  9. 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 misint
  10. 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.
  11. 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
  12. 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
  13. 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
  14. 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 dela
  • Create New...