Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Posts posted by Dave


  1. Don,

     

    I guess the EPROM state will all be FF when the chip comes from the factory, after that point its what ever was last written.

     

    Anyway you can inititialise the whole thing yourself when you program is downloaded to the device, or when you open it in the debugger.

     

    Add this to your PIC16 program:

     

    #pragma DATA, 0x2100, 0xFF,0xFF,0xFF,0xFF,0xFF.....

     

    EEPROM is mapped to 0x2100 to 0x21FF when the device is programmed.

     

    Regards

    Dave


  2. Guys,

     

    It looks to me like this thread is getting a bit lost.

     

    I'll try to explain.

     

    #ifdef, #else and #endif are used by the pre-processor.

     

    This means they do there stuff prior to the actual code compilation, you use then to add or leave out code or #defines.

    So they can't change things at run time.

     

    here what I would do

     

    #include <system.h>
    
    // note _PIC18 is define by compiler for PIC18 targets
    
    #ifdef _PIC18
       #define port portd
       #define tris trisd
    #else
       #define port portb
       #define tris trisb
    #endif
    
    
    void main()
    {
       tris = 0x00; // make all bits output
       port = 0x01; // turn bit 0 of port 
    }

     

    Hope this makes sense.

     

    Oh BTW: try -d on the command line for define, looks like the case is wrong!

     

    You could put -d xxxx on the compiler command line (from in IDE used Settings->Options->Compile Options->Extra compiler options and put "-d xxxx" in the box you find there)

     

    Regards

    Dave


  3. Hello All,

     

    My prefered method is the neatest of all and generates very efficient code:

     

    #define PORTB 0x06
    
    volatile bit myInput @ PORTB.0; // RB0
    volatile bit myOutput @ PORTB.1; // RB1
    
    main()
    {
       InitIo(); // sets up my port b - this routine needs to be coded
      
       if( myInput ) // is input on
           myOutput = 1; // turn output on
    }

     

    Hope this helps :)

     

    Regards

    Dave


  4. SnakeByte,

     

    BoostC is not a C++ compiler, its a C compiler.

    cout is an instance of a C++ class, so can't exist in BoostC project.

     

    Consider the following

     

    int glbcnt = 0;

     

    char fooy()

    {

    glbcnt++;

    return 1;

    }

     

    void main()

    {

    char y;

    x << fooy();

    }

     

     

    The value resulting from x << fooy(); is not used so it is optimised out.

     

     

    So I see the real two actual problems here as:

    1) The optimisation has cause the function to not get called.

    2) cout doesn't exist, therefore the compiler should generate a warning.

     

     

    Regards

    Dave


  5. Doozer,

     

    I noticed that C2C has the TRUE_RS232 pragma. I have tried this set to 0 and 1, but it doesn't seem to make any difference to the .hex file generated. I suspect it only affects the built in software putchar() function.

     

     

    Yes you are correct. The pragma only affects software generated serial comms.

     

    When you remove the max 232 you lose the inversion of the signal, plus all the voltage levels will no longer be within the RS232 specification.

     

    I would say don't do this - sounds like very bad practice.

     

    If you do want to do this, then invert the signal using an external NOT gate.

     

    If you are eventually going to connect two PICs like this then no problem, an invertor will be missing at both ends, so it will work.

     

    Regards

    Dave


  6. qu1j0t3,

     

    1) will the linker work with MPLAB .O files? (My testing with SourceBoost seems to fail)

     

    The answer is no. BoostC compiler and linker have the own .obj file format.

     

     

    2) are the calling conventions documented? (assembly from C)

    Even if the calling convention was documented, there would still be the problem of how to turn the ASM code into a BootsC/Boost Linker compatible file.

     

    My recommendation would be to turn the ASM code into C code.

    You can still use the asm code, and just put a C function wrapper around it:

     

    char MyAdd10( char arg1 )

    {

    char res;

     

    asm

    {

    // add 10 to value passed

    movf _arg1, W

    addlw 10

    movwf _res

    }

     

    return res;

    }

     

    Note: In order to used "W" in ASM code you must include <system.h>

     

     

    Hope this helps.

     

    Regards

    Dave


  7. AndyDavy,

     

    Q) How to know if the ADC is supported.

    A) locate the config folder that contains the .tdf's (target descriptor files).

     

    Have a look inside the file.

    If you find: "Configure ADC10Bit" in the file, then it has a 10Bit ADC compatible with the PIC16F877.

     

    Sadly the PIC16F676 ADC is different <_<

     

     

    Regards

    Dave


  8. AndyDavy,

     

    While debugging the interrupt on change bit does not get set, although I see the port a. ra0 status bit change. I have verified that I have configured the device correctly as it all works within MPLAB IDE simulator without any problems.

     

    Yes this won't work.

    Its not a bug but a current limitation of the simulator <_<

     

     

    Regards

    Dave


  9. AndDavy,

     

    Also, which is the better compiler C2Cplus or BoostC?

     

    C2C-plus is a mature product, but it does have its limitations (such as the one you have just found).

     

    SourceBoostC is much better, but it is still at the alpha release stage. So its not 100% perfect yet <_<

     

    Currently SourceBoostC doesn't support 12F675 or 12F629. But these devices have the same core as the PIC16 devices, so it would be relatively easy to add these devices to compiler and linker, so I'm sure this will happen soon if there is a demand for it.

     

     

    Regards

    Dave

×
×
  • Create New...