Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Dave

  1. Adam, Is the pin correctly configured as an output?If it is configured as an input you will read the external state of the pin. Regards Dave
  2. Chen, This should be displayed on the tool bar, with a drop down list to allow selection of Debug or Release. Regards Dave
  3. Chen, There is nothing in the TDF file relating to Debug and Release options. These are purely IDE settings that invoke the compiler with _DEBUG or _RELEASE defined and direct the output files to ether the Release or Debug folders. These settings are saved as part of the project. Regards Dave
  4. Martin, No this function is not in the library. Regards Dave
  5. Mike, You need to add the eeprom.pic16.lib or eeprom.pic18.lib file to the project tree.Regards Dave
  6. Mike Add the library files to the project tree. Regards Dave
  7. JorgeF, This will be corrected in the next release (V7.11). Regards Dave
  8. JorgeF, Thanks for a fine example of code that failed. Something does seem to be wrong here, but I'm not sure what it is yet. Regards Dave The following function has the error corrected that caused this problem - incorrect capture of the max priority task when adding a task to the run queue. void SysiAddToRunQueue( TASK_HANDLE hTask ) { TASK_HANDLE pos = RUN_QUEUE_HEAD; TASK_HANDLE nextPos; BYTE priority = GetTaskPriority( hTask ); BYTE maxPriority = priority; while( 1 ) { nextPos = GetNextTask( pos ); // move onto next if( nextPos == RUN_QUEUE_HEAD ) // end reached break;
  9. For sure it has something to do with the tasks being awaken from the semaphores. Of course the "next task" can be overrriden by a priority change. The "ready list" must be reorganized when priorities are changed so the head of the ready list can change. Also if a task is woken up and inserted in the ready list it can be inserted at the head if its priority is >= than that of the previous head. But waking up a task and inserting it ahead of another with higger priority seems a bit odd. ... Something does seem to be wrong here, but I'm not sure what it is yet. Regards Dave
  10. The floating point numbers are IEEE754 single precision floating point numbers, that is a number with an 8 bit exponent and 24 bit mantissa, ie each floating point number uses 32 bits. The best way to describe them is that they support a precision of 24 binary digits. Yes. Limitations apply (no arrays of function pointers). Function declarations like "void strcpy( char *dst, const char *src )" are supported (are used in our library functions, take a look in string.h). I don't know the Hi-Tech compiler so can't comment. Regards Dave
  11. jrmymllr, BoostC will be able to do the math if you use the floating point library which provides single precision floating point math, but you will need to long hand the expressions as floating point is not fully native, ie to add two floating point numbers you have to explictly call the floating point add function, to multiply you have to call the floating point multiply function etc. Take a look at the floating point sample program that is provide as part of the installation: #include <system.h> #include <float.h> // Needs target specific configuration to be added her
  12. John, The jump table needs to be done in ASM otherwise you are making assumption about the code that compiler/linker will generate and what optimisation may or may not be performed and that is somewhat dangerous. I would also recommend fixing the address of the function (see below) containing the jump table to prevent linker placing it somewhere where it may cross a code page boundary. // fix function address void foo() @0x1230 { ... } Regards Dave
  13. John P, We had a few problems reported regarding this kind of issue a few months back.A number of changes have been made to fix this problem, but a fully controlled release with these fixes in has not been created. You can find a pre-release version here (this link wont be valid after BoostC V7.11 is released): http://www.sourceboo...oost711pre1.exe Let us know if this fixes your issues. Regards Dave
  14. astor, Does a definition for '_OSC_XS_1H' exist in the Pic18F8490 header file? Regards Dave
  15. Badejavu, Use linker option -rb 0x100 ( 0x100 or whatever point you want the ROM base address to be). It is a linker command line option. In SourceBoost IDE you can enter extra command line options here: Menu Settings->Options->Compile Options->Extra Linker Options. Regards Dave
  16. Moonwalker OK, but when?And was that for the same code? What speed CPU does your PC have? The time you specify does seem somewhat excessive. Maybe you can post your complete project so we can see exactly what you are doing. Regards Dave
  17. Moonwalker, What part of building is taking a long time (compiling or linking)?Linking time can become long when there is lots of code in a single function. Regards Dave
  18. Don, I'm finding other cases where there is not a retlw within the called function, so I think the problem is more widespread than that. Please provide examples so we can make sure these other cases are fixed too. Regards Dave
  19. Shree, Sound like an interesting project.I'm not an expert in such matters, but consider the following: 1) Make sure than all inputs that are unused are tied to 0V or 5V through a pullup resistor, ie nothing is left floating. 2) Make sure the PIC has appropriate decoupling capacitors fitted close to the device, and same around you 5V regulator. 3) Consider putting a metal screen cover over PIC and underside PCB to protect it from the radiation, bonding this to 0V, Regards Dave
  20. Don Another asssembly instruction that may help in your code is BRW (only available on PIC16F1xxx devices). With this you don't need to load up PCLATH and it handles crossing page boundaries. Regards Dave
  21. Don, Linker is ignoring the retlw in a way that means the PCLATH value on function exit is ignored. What partly helps is this: volatile bool x = 0; void lookup(void) @ 0x700 { if( x ) return; asm addwf _pcl, F asm retlw 1<<0; asm retlw 1<<1; asm retlw 1<<2; asm retlw 1<<3; asm retlw 1<<4; asm retlw 1<<5; asm retlw 1<<6; asm retlw 1<<7; } But there are other problems as well. When PCLATH is used with calls and gotos only bits 4 to 6 are used. When it is used as a result of PCL regis
  22. Fizzel, Yes its not good.It sounds like you need to complete the installation. I just tried the SourceBoost V6.10 install and saw the same message in the shell window. I closed the shell window and then the installation completed. And all seems to be ok. Please try again. Regards Dave
  23. Don, There does indeed appear to be a problem here.More investigation is required. I will let you know when there is more news. Regards Dave
  24. don, This is not how it is intentended to work, there is meant to be minimal bank switching.I need to investigate. Regards Dave
  • Create New...