Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Everything posted by Dave

  1. Larry, If you are using the SourceBoost IDE, In Menu Settings->Options->Compile Options Did you have in "All Warnings" radio button selected ?If you are using MPLAB, did you have "All Warinings" selected, or us compiler command line option -W2? Regards Dave
  2. 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
  3. Chen, This should be displayed on the tool bar, with a drop down list to allow selection of Debug or Release. Regards Dave
  4. 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
  5. Dave

    Math Question

    Martin, No this function is not in the library. Regards Dave
  6. Mike, You need to add the eeprom.pic16.lib or eeprom.pic18.lib file to the project tree.Regards Dave
  7. Mike Add the library files to the project tree. Regards Dave
  8. Dave

    Novo Header Files

    JorgeF, This will be corrected in the next release (V7.11). Regards Dave
  9. Dave

    Priorities - Odd Behaviour

    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; // exit with pos = node just before end // when priority is less than task to add we have found insertion point BYTE nextPriority = GetTaskPriority( nextPos ); if( nextPriority < priority ) break; else if( nextPriority > maxPriority ) // capture next priority maxPriority = nextPriority; pos = nextPos; } // merge node into queue SetPrevTask( hTask, pos ); SetNextTask( hTask, nextPos ); SetNextTask( pos, hTask ); SetPrevTask( nextPos, hTask ); // if task inserted at run queue head then it must be the one to run next if( pos == RUN_QUEUE_HEAD ) scheduler.os_hNextTaskActive = hTask; // if task has max priority, then it will be the new last in the run line if( priority == maxPriority ) scheduler.os_hTaskLastHp = hTask; SetTaskStatusBit( hTask, TS_IN_RUN_Q ); } You will need to update this function in novo.c and rebuild the require Novo RTOS library. Let me know if this fixes your issue. Regards Dave
  10. Dave

    Priorities - Odd Behaviour

    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
  11. 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
  12. 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 here! // - not required to run under SourceBoost Debugger/simulator float CalcCircleArea( float radius ) { // area of circule = pi * radius * radius float x = float32_mul( radius, radius ); x = float32_mul( x, 3.1415927 ); return x; } void main() { // calc area of a circle // area = pi * r * r float area = CalcCircleArea( 21.75 ); int iArea = float32_to_int32( area ); while( 1 ); } Regards Dave
  13. 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
  14. 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
  15. astor, Does a definition for '_OSC_XS_1H' exist in the Pic18F8490 header file? Regards Dave
  16. Peter, Upgrade to BoostC V7.10. Regards Dave
  17. 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
  18. 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
  19. 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
  20. Dave

    Pclath Is Not Being Updated

    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
  21. Dave

    Mind Boggling Emi Problem With Pic

    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
  22. Dave

    Pclath Is Not Being Updated

    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
  23. Dave

    Pclath Is Not Being Updated

    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 register modification, bits 0 to 6 are used. So the PCLATH loading to call your routine is not enough for the "addwf _pcl, F" to get you to the correct address on every occasion. You need extra code to make sure all the extra PCLATH bits (ones not used by call and goto) are set: volatile bool x = 0; void lookup(void) @ 0x700 { if( x ) return; asm movlp 0x700 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; } I hope that helps for now. I'm working on some proper code fixes to put these problem right, so it will work as you would expect. It is quite funny how we have gone for many years with no one finding these problems, you must be pushing the envelope more that most users have done. Regards Dave
  24. 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
  25. Dave

    Pclath Is Not Being Updated

    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
×