Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Everything posted by Dave

  1. Dave

    Ide 5.7 Problem

    Don Add this you code: #pragma DATA, 0x2100, 0xFF,0xFF,0xFF,0xFF,0xFF..... and Build it. And then when you open program in debugger the locations will be initially set to 0xFF. Regards Dave
  2. Dave

    Ide 5.7 Problem

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

    Booleans / Flag Bits

    fransfrans, In BoostC you can do this #define PORTA 0x05; volatile bit RA0 @ PORTA.0; void main() { InitPorts(); RA0 = 1; while( RA0 ) { ..... } } Good enough ? Regards Dave
  4. hotcranium, Source level debugging under MPLABs is not yet supported This is why is doesn't work for you. Regards Dave
  5. rlang, Nice point, maybe the work "target" needs to be used a bit more to clarify what is being referred to. Regards Dave
  6. rlang, Now fixed. Will be in release 1.7. New error message will be: "Error: Memory allocation failed - No remaining memory block big enough for:myarray in filetest.c size:258 bytes" Regards Dave
  7. Dave

    How Is The #if Directive Supposed To Work?

    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
  8. RLang, Sorry about this one It actually means that it is not possible to allocate all the memory required for you program, ie there is not enough GPR registers on the target device. I will improve the error message. Regards Dave
  9. Dave

    Bit I/o Difficulties

    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
  10. rlang, Consider using the new BoostC compiler, it does support structures Regards Dave
  11. Dave

    Boostc 1.6alpha Optimization Bug...

    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
  12. Don, Unlike Pavel I forgot an import type specifier - volatile. Without it the compiler will optmise the code sequence and give unexpected results. This is mainly true when the specified bit is used as an output. So best to always define all I/O output bits as volatile. Internal bits can safely be defined as straight bit. Regards Dave
  13. Don, One of the nicest ways that this can be done in BoostC is: #include <system.h> bit rb0 @ PORTB.0; void main() { if( rb0 == 1 ) ...... } Regards Dave
  14. Doozer, 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
  15. qu1j0t3, The answer is no. BoostC compiler and linker have the own .obj file format. 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
  16. Dave

    Debugging/simulation

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

    Debugging/simulation

    AndyDavy, Yes this won't work. Its not a bug but a current limitation of the simulator Regards Dave
  18. Dave

    C2cplus - Compiler Error For Shifting

    AndDavy, 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
  19. InspectorOverTheMine, You are quite right, this is a current limitation of the PIC18 simulator, it only simulates the instruction core of the processor. Peripheral devices are not yet supported Regards Dave
×