Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by Dave

  1. artan,


    I have started a project using BoostC compiler and Novo RTOS in mplab 8.84 ide.

    When i compile everything is fine, but when it has to build it just says " Build failed"

    without an error.


    Anybody has any idea what should be?

    It's a bit strange, its not getting as far as linking, so it looks like the compiler is croaking.

    What happens if you exclude NOVO RTOS and compile you code?

    Can you compile a simple project with nothing more than just a main() function ?


    I hope that helps.




  2. I dunno what I did wrong but the code doesn't work.

    2nd issue: after a few seconds the fan gets set to max. speed what is probably caused by a dead-lock or sth. like that.


    I found an issue in the Novo code kernel.

    Please replace the code in the function below in Novo.c, you will need to rebuild the Novo library you are using. There is a SourceBoost IDE project supplied for that as part of the installation.


    void SysiAddToSleepQueue( TASK_HANDLE hTask, TICK_COUNT sleepTime )
    // Add to wait queue at appropriate place for wakeup time
    // Tasks at the front of the queue are due to wakeup before those at the rear.
    // Add to sleep queue at appropriate place for sleep time
    // No need to look before update head as those tasks have already timed out
    // By working away from head we will chase the update head if it moves
    BYTE i = GetSleepUpdateHead();
    bit foundInsertionPoint = false;
    while( !foundInsertionPoint )
     // Interrupt code for wakeup will be looking at the sleep queue
     // so we modify it while interrupts are disable
     // Interrupt routine does not modify sleep queue, it just looks at it
     // and adjusts it sleep update head pointer.
      if( i == SLEEP_QUEUE_HEAD )
    // start reached, so we insert the new task at this point
    foundInsertionPoint = true;
    if( GetTaskStatus( i ) & TS_IS_WAKING ) // awaking ?
     ; // will move onto next task
    // if not waking then we need to check remaining sleep time
     TICK_COUNT remainingSleep = GetTaskWakeUpTime( i ) - scheduler.os_tickCnt;
     // if this task has more time to sleep, ie will wake up later, than the new task
     // then we have found the insertion point in the list, ie in front of this task
     if( remainingSleep > sleepTime )
      foundInsertionPoint = true;
      if( foundInsertionPoint )
    { // insert the new task before the current point
    SetTaskWakeUpTime( hTask, scheduler.os_tickCnt + sleepTime );
     BYTE hPrev = GetPrevTask( i );
     // connect up new task into list
     SetNextTask( hTask, i );
     SetPrevTask( hTask, hPrev );
     // patch up existing task in list
     SetPrevTask( i, hTask );
     SetNextTask( hPrev, hTask );
    // new task added before update head means that it will would never be checked as head
    // is already passed this point so we must adjust it
    if( i == GetSleepUpdateHead() )
     SetSleepUpdateHead( hTask );
    SetTaskStatusBit( hTask, TS_IN_SLEEP_Q );  
    i = GetNextTask( i ); // move on next task for examination

  3. neptun,

    Hi out there,

    I'm trying to get familiar with Novo and started therefore with the FanSpeed example of Dave.

    I got it to work without big problems on a PIC18F2550 and an older PICDEM-2 demo board.

    Cause I had a 4x4-keypad in my corner I extended the keypad-file. It all worked fine.

    As next step I wanted to get it worked also on a PIC16 and have chosen a PICkit2 demo board with a PIC16F690.

    Same setup there but running with an external crystal at 20MHz. Additionally I changed the scheduler-call SysTimerUpdate from main to a timer-driven interrupt that should execute every 10us.


    I dunno what I did wrong but the code doesn't work.

    1st issue: the keypad didn't get read.

    2nd issue: after a few seconds the fan gets set to max. speed what is probably caused by a dead-lock or sth. like that.

    I'm running your code under SourceBoost IDE and simulator and I see the problem where the code seems to stop functioning correctly after a while. Not sure what the cause is yet.




  4. ahsenj,

    I am using pic 16f818 and programming a resistance meter.

    I am getting some strange error. Its that when i initialize some integers in order to store values etc , my lcd starts showing garbage values. Other wise it works okay.

    Can anyone please help. ???

    Sounds like some kind of corruption.

    Without seeing the code it is almost impossible to help.




  5. mmga,

    PIC 16F1828, same problem with 16F1508

    Linker reports Internal Error: Var Not Found Id:0Xff000013: In Function ...

    A minimum code and a build batch is attached

    Problem is cause by code trying to use PREINC0 register which does not exist on these devices.

    It is because of the use of array index used on array of data type that is more than 8 bits long.

    It comes down to a compiler bug :-(




  6. Andrew Leiper,

    OK, after a bit of jiggery pokery I have discovered that I can do this:


    #define NUM1 0x2211

    #define NUM2 0x4433

    void romfunc(void) @ 0x1000


    asm {

    data NUM1

    data NUM2




    This works except that it leaves a return instruction at the end of the data. If there is a better way of doing it though, please let me know.

    Another option is to use #pragma DATA (see BoostC user manual on how to use this), but I think the method you demonstrate above is probably the neatest and the most flexible in terms of data types that can be readily stored.




  7. JorgeF,

    This topic put me thinking and one of Dave's comment raised a question.

    If I use the "-rb" switch to push my code upwards in flash how does the compiler handle the "interrupt" and "interrupt_low" functions if they exist in the program?

    The vectoring code that normally jumps to these routines is offset by the address specified. So for example the reset vectoring code normally resides at address 0, if -rb 0x100 linker command line option is used this vectoring code now appears at address 0x100, and so on.




  8. John S,

    1. I have seen the example bootloader code on the sourcboost site. I noticed only global variables were used, function never take any parameters. Any reason for that?

    Not that I can think of.


    2. If boot loader uses some ram memory, will the application program overwrite some or all of that ram memory or is the Ram memory unique to bootloader and application program?.

    The bootloader and the application don't run concurrently so both can use all available RAM.


    3. If I did not specify -rb command, by default at what location will my code reside?

    The code starts at the end of the interrupt and reset code locations.


    4. Also I need a common memory space (prefer RAM) which can be accessed by both application and bootloader program. How can I do that. I need this so bootloader can read the application firmware version , vice versa.

    Use RAM at fixed addresses (define variables like this int x@0x100 ) and have then defined in a header file that both the application and the bootloader include.


    I hope that helps.



  9. trossin,

    I attached a little screen shot of a tiny program with a structure array that was initialized to have the 32-bit tag set to 0xffffffff and the cache state set to 0. When debugging, the watch window shows 4 of the 5 states as 0xff and only one with the correct value of 0. Reading the element named state at the end shows that it does have the correct value. The only problem is the watch window. I should also mention that it is not possible to add a variable to the watch window with a very long name since there seems to be a character limit. I attached a little project to demonstrate the problem. I'm using Version 7.10 and a 18F4620

    This problem is now fixed and so should be in the BoostC V7.11 final release.

    Problem was in the coff file generation in linker, where it did not add pointer information to structures.




  10. ajbeavan,

    Finally managed to sort the problem out, after spending so much time thinking about initialisation and 4-bit

    data mode, I forgot to check if the device had been wired the correct way.....

    I had everything back to front, so now after 2 weeks and writing my own LCD routines, it was simply a case

    of wiring. Feel like a real idiot.

    You always learn much more from things that don't work, the extra time is therefore not actually wasted.




  11. ajbeavan,

    Sorry, I added this line deliberately to hang the code, so that I could monitor the LED states on each of the DB ports at the

    point the BF flag was set....

    Have you considered ignoring the busy flag and just using a time delay. Many applications do this to save an output, ie then the read/write connection is not needed?

    Doing this may give a clue to the problem.




  12. Larry,

    I discovered that the header file for an 18F2620 defines ALL the SFRs as CHAR types, even those (such as CCPR1 and ADRES).


    When I tried this:


    ccpr1 = 700;


    The complier just put the low byte of 700 into the CHAR variable ccpr1.

    Worst of all, the compiler didn't give any warnings that data was being lost.

    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?




  • Create New...