Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Posts posted by Dave


  1. Chen,

    I have the same trouble with this debug/release option. I am using IDE for p16f1827 coding. I could not figure out why some projects with the same target will show the 'release' mode, and some shows only 'debug' mode is available. I looked at the TDF for P16F1827, but failed to find any 'TargetConfig DEBUG' session in the TDF for p16f1827.

    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


  2. JorgeF,

     

    Thanks for a fine example of code that failed.

    Hi Quoting from another thread
    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


  3. Hi

     

    Quoting from another thread

    Your Novo problem is a good one. I have it running on my EasyPIC5 board.

    It says in the Novo source that the next task can be overridden by priority change or waiting task wakeup.

    Maybe the last part has something to do with it (waiting task wakeup).

    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


  4. I read on this forum somewhere that FP numbers only up to the 7th place beyond the decimal point are used in the calculation. I could not find any reference to this in the user manual. Is there any truth to this? Otherwise, I'm fine with using the FP functions.

    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.

     

    Also a few other questions that maybe you can answer much quicker than I can find them:

     

    Are pointers to functions supported? (CCS does not support)

    Yes. Limitations apply (no arrays of function pointers).

     

    Is "const" treated as in the ANSI definition? CCS doesn't like const being used such as in "function(const char x)" and this is very annoying

    Does BoostC contain a linker? CCS does not which is also annoying. I believe I saw something that makes me think BoostC does have one.

    Function declarations like "void strcpy( char *dst, const char *src )" are supported (are used in our library functions, take a look in string.h).

     

    Right now I'm using HI-TECH which does a great job of compiling, but is generating faulty code in too many circumstances. Are there any other big differences I should be aware of as far as lack of ANSI support versus HI-TECH?

    I don't know the Hi-Tech compiler so can't comment.

     

    Regards

    Dave


  5. jrmymllr,

    However, the lack of full floating point might be an issue since I'm using up to 10th order polynomials with coefficients as small as -3.244E-14. I assume BoostC will not handle this very well?

    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


  6. John,

    What I did was take some of the jump table and put it in an asm{} block...

    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


  7. John P,

     

    I'm trying to convert a program from another compiler, and I have got it to compile under BoostC. But the program includes a jump table which is entered after the PCL is changed--a computed GOTO in other words. What I'm finding is that the compiler simply generates no code for any of the GOTO statements, then it resumes at the next address after the last GOTO. Here are the last few lines before the table and the first few lines of the table:

     

    bit_set(porta, 1);	// A flag for the scope, to see how long this takes
    pclath = 1;
    pcl += bitc;	 // Computed GOTO: jump 0-179 lines ahead
    	// NOTE! This jump table must not span a location in code memory where the lower 8 address bits wrap from 0xFF to 0x00.
    	// Also, PCLATH must hold the correct value for the memory area being used.
    goto SW0;				// Start bit, start char
    goto INCU;
    goto SW2;
    goto QX;
    goto SW2;
    goto QX;
    goto SW2;		// Many more GOTO's here
    

     

    Any ideas on how to make the compiler accept this?

    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


  8. Badejavu,

    1. How do i define a new application reset vector or program start address in boost C? I have seen examples on the forum of including a linker option -rt <new address> but it does not work.If it does, can anyone pls explain where i can include this to the linker?Maybe I am including it wrongly.

    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


  9. Moonwalker,

    How long should a project take to build?

     

    I was working on a large project and it was taking quite a while to build but now I am working on a simple project and it is still taking over 1 minute to build.

    I had the feeling that it was much faster before with simple projects.

     

    I use source boost IDE only and the project I am working on at the moment is just 250 lines (with comments) and using PIC12F615.

     

    Any idea?

    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


  10. Don,

    Linker is ignoring the retlw in a way that means the PCLATH value on function exit is ignored.

    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


  11. Shree,

    I came across this problem when I was making a small high frequency inverter of upto 50W (extremely low cost; system cost approx less then $10) for rural areas in india, where there is no electricity. The battery for this inverter would charge from a solar panel and provide energy to the load (CFL: Compact Flouroscent Lamps) in the night. I used PIC16F684 and deployed its PWM module. everything worked fine in the initial stages. But when I created a PCB, all the problems started. Now the problem is that whenever I switch On the supply, the controller keeps on reseting until I dont place my hand on the negetive/negetive track of the battery. If I place my hand on the negetive, it starts working fine. I tried everything from using filter caps to tranzorbs across 7805. But nothing worked. Lastly I tried taking a wire from earthing and directly shorted it to the negetive of the battery. Voila!!! Now there were no problems! But now my problem is that I am not sure I will have the luxury of 'Earthing' for my product as the electricity condition in rural india is more then pathetic. Can anybody suggest me what can be done to resolve this issue?

    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


  12. 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


  13. Fizzel,

    So I visited the homepage and download the sourcebosstV710.exe. When starting the .exe a command sheel was opening and is waiting for connection on port 0. But nothing happend. So i canceled the shell and then the installation started. But was crashing with an error. After clicking on cancel the update says "rolling back changes".

     

    When I now try to build a project (even projects which always worked) the compiler says: Error: Failed to open:$+

     

    I'm now not able to work what really sucks! Please help!

    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


  14. Don,

    Bug description:

    The compiler correctly inserts a MOVLP before calling a function in another page, but sometimes it does *not* change it back after the function returns. This causes execution to jump to a random or invalid location, which of course causes various other problems.

    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

×
×
  • Create New...