Jump to content

jartim

EstablishedMember
  • Content count

    33
  • Joined

  • Last visited

Everything posted by jartim

  1. Thanks Pavel, that was the problem. Cannot believe I missed it, it was a long day. Rgds Tim
  2. Hi, Does anyone have any insight into how to access a function parameter from in-line assembler? I am doing the following - void type24Var::add(const unsigned long src) { asm { movf _src, W } } But this will not compile and I get the message - failure type24Var.cpp(68:2): error: error in built-in assembly make[2]: [build/default/production/type24Var.o] Error 1 (ignored) It's driving me crazy, nothing I do seems to clear the error!
  3. Unrecognised type ID

    Hi guys, I'm getting this message when I build my project - Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F It doesn't appear to be causing any issues, however the compiler reports a warning so I expect there is something odd going on. Any ideas? (Compiler = BoostC++ V7.42) Regards Tim Jarrett
  4. Thanks Jorge, pretty much what I had decided to do as well. It just would be easier to have the compiler and linker do all the work for me, rather than have to build the code twice. Regards Tim
  5. Hi guys, Is there any easy way of identifying the last used address in rom using BoostC or BoostC++ compilers? I cannot find a linker control file to add a label, is there any way to guarantee that a label defined in the source code ends up as the last addressed object? Thanks Tim
  6. Hi Jorge All I'm trying to do is calculate a CRC checksum for the ROM, starting at 0x0000 and ending at the last used address of my program, hence I need to know the last address used. I can't CRC the entire ROM because I will be using the top end for non-volatile storage, and for that I also need to know the last used address. Normally I would edit the linker control file and add a label after the used code section, but this compiler doesn't appear to use a control file, I guess it has the parameters hard-coded in. All I can do at the moment is build the code with a 0x0000 address coded in as a rom char* pair, look at the code statistics after the build process, copy the size of the code in to the rom char* and then re-build. It would be safer and easier to have the compiler and linker do it automatically. Regards Tim
  7. Another request, not much luck with enhancements so far but worth a punt... Please can you add support for friend functions for classes? Thanks.
  8. A long shot I know, but what are the chances of the source code being moved to an open-source licence? That way maybe there could be more third-party improvements and bug fixes etc. Just a thought. (I would certainly be interested in adding new features, i.e. 12-bit support, true template support, overloaded constructor support etc.) Regards Tim
  9. Please can you add support for the 12-bit baseline devices to BoostC and BoostC++? Some of these have relatively large FLASH and register memories but have a 12-bit instruction-width core, which the current compiler doesn't support! Regards Tim Jarrett
  10. Pavel, I don't think this is correct? I'm using MPLAB-X and I've added a new header for a PIC16F570 device and modified the MPLAB jar files to allow me to use SourceBoost with that device (it doesn't by default). I haven't created a .tdf file for the same device because I don't use the SourceBoost IDE, but when I try to build under MPLAB-X, I get this message - main.cpp error: could not open input file 'C:\Program Files (x86)\SourceBoost\config\PIC16F570.tdf' So it appears as though the build process needs the .tdf file as part of the build as well (this is using the C++ compiler under MPLAB-X). I will have a go at creating one for my new device. If it's successful, is there somewhere I can post it on the forum to make it available to other users? [EDIT] Pavel, is there a full list of the options that can be used in the .tdf file entries? I found a .txt file in the config folder that partly explains the .tdf file format, but it does not give a complete list of all the possible options? Rgds Tim
  11. Guys, No disrespect, but why would I want to use the Chameleon compiler instead of the BoostC compiler, especially as it is only 95% back-compatible? Does the Chameleon compiler give any better performance, smaller object code, better optimisation etc? Many thanks. Tim Jarrett
  12. Thanks Pavel. Will you be doing a similar exercise with an alternative to the BoostC++ compiler as well, or does Chameleon already support C++? Thanks Rgds. Tim
  13. Ok, found the problem. I had a member function and a member variable in one class, both with the same name, and that caused the compiler to fall over. Changed one of them and everything is compiling again.
  14. My build keeps crashing with the following error code, any ideas what this code means, please? make[2]: [build/default/production/PortClass.o] Error -1073740777 (ignored) Windows reports that the program has stopped responding when this happens, so my guess is that this is an internal compiler error?
  15. Can't register the licence?

    Hey Chris - I purchased the BoostC++ compiler a couple of months ago, and received the licence information from SWReg as you did. But, before I had chance to enter the licence, I received an email from Pavel with a different licence key to use instead. I got the impression from other posts on the forum that they had had problems with the licence server and were emailing the keys out manually. Not sure if this still applies or applies in your case, but worth an email to "support" ? Rgds Tim
  16. Hi Jorge I agree, the coding looks a bit odd as it stands; it wasn't meant to be an example of how to do it, rather an example of a possible way the compiler could implement a solution. The syntax looks strange, but it's not breaking any of the compiler's rules or the C++ language rules. Having two structure members at non-consecutive addresses is quite acceptable, in fact many C-compilers do just by adding padding bytes between members when the target processor requires each member to be aligned on 16 or 32-bit boundaries. My suggestion just tries to force the alignment rather than assume that the compiler will do it (it probably won't). As for the compiler not accepting a variable as a bit index, you're correct, but as you said - so I cannot see any reason why the compiler could not be modified to do this. Rgds Tim
  17. Hi, not really a request for an enhancement to the compiler, but it would be really nice if you would occasionally post on the forum what developments / improvements / bug fixes etc you are currently planning and/or working on for the Boost compilers. IMHO the forum is pretty quiet and it's not filling me with confidence that this product is being actively developed or supported. I'm having a difficult time convincing my client that this is the compiler for their project development, any information posted would help give your current and potential future users and customers a bit of a moral boost (no pun intended ).
  18. Please can you add support for private, public and protected class members? I know the compiler accepts these at present, but it doesn't honour them.
  19. What would be useful would be a construct like this - struct sMyPortStruct { volatile unsigned char BasePortA @0x05; volatile unsigned char BasePortC @0x07; } MyPortStruct; for (unsigned char c = 0; c!= 16; c++) { MyPortStruct.c = 1; } Although the compiler quite happily accepts this syntax, it ignores the fixed addresses and assigns the structure members to consecutive registers in RAM instead, so this doesn't work. Also it would need some additional code inserted by the compiler to make sure you're addressing the correct member port. I suspect this could be done in C++, but there's no way to overload the '.' operator (overloaded operators aren't supported )
  20. Please can you add support for calling overloaded base class constructors when instantiating derived classes! Calling the default constructor only is not always the best thing to do, especially if the base class requires a constructor with parameters!
  21. Didn't see the original date!
  22. Bug description: The same source code line generates different assembly code in different places. Sometimes the generated code is incorrect, sometimes it is correct. Steps to reproduce: Use the same source code in 2 different places in the source. Detailed description to reproduce this problem I use this statement in two different places in my source code - WatchdogTarget = CONST_WDT_MINTIME + (Trembler & 0x07); CONST_WDT_MINTIME is a constant - #define CONST_WDT_MINTIME 1U The first time it is used, the following code is generated (which looks correct) - 01D7 3007 MOVLW 0x7 01D8 0547 ANDWF 0x47, W 01D9 00CA MOVWF 0x4A 01DA 0A4A INCF 0x4A, W 01DB 00C4 MOVWF WatchdogTarget The second time is it used, the following code is generated (which is not correct as it modifies the value in "Trembler" at 0x47) - 020A 3007 MOVLW 0x7 020B 05C7 ANDWF 0x47, F 020C 0A47 INCF 0x47, W 020D 00C4 MOVWF WatchdogTarget Expected behaviour: This is the code I would expect to see - 020A 3007 MOVLW 0x7 020B 05C7 ANDWF 0x47, W 020C 0A47 ADDLW 0x01 020D 00C4 MOVWF WatchdogTarget The compiler should not modify the value of "Trembler" at 0x47 (and as the value of CONST_WDT_MINTIME may be other values at compile-time) If CONST_WDT_MINTIME was (say) 32, I would expect to see this instead - 020A 3007 MOVLW 0x7 020B 05C7 ANDWF 0x47, W 020C 0A47 ADDLW 0x20 020D 00C4 MOVWF WatchdogTarget Is the problem 100% reproduceable: Every time IDE version: MPLAB-X 4.0 Compiler: BoostC++ Compiler version: 7.42 Target device: PIC12F635 OS: Windows 7 64-bit
  23. Do you really write your code without any comments or description?!?
  24. Hey Jorge, that could be the answer. The value in Trembler isn't used after the 2nd occurrence and I guess the compiler is free to overwrite its value if it sees it's no longer required.
  25. Hi Jorge, That's probably because there is no corresponding instruction at the assembly instruction level, only 'bsf' or 'bcf' with a constant.
×