Jump to content

All Activity

This stream auto-updates     

  1. Earlier
  2. well the problem is resolved i must do a fresh windows installation and were install the program without problem! but i found out that because i have Hungarian keyboard on the laptop so when iam trying writting a code the bracket "{" it want work if i pressing the ctrl+alt+b its start to build the code!? so there is any possibility to change the quick key for the build? thx
  3. Hi That is strange, I installed the Sourceboost IDE with Boost C and goodies licences in a new laptop (3 weeks ago) running Win 10 64bit up to date without any issues. Best regards Jorge
  4. That's an useful report. The error happens because the SourceBoost code fails to parse some text that contains non-english characters (maybe somewhere in a directory name). Does this happen on your computer? Regards, Pavel
  5. hi, sorry that i am writting here but i didnt find topic for sourceboost instalation issues I have a laptop win win10 pro x64 intel i5 8th gen, geforce mx150 ssd when i am trying to install i getting the following error, intristingly one off my older version win 10 home i could install!
  6. We do add support for the new PICs from time to time but now very often. The 18F26K42 and alike are a bit different from the existing PICS as they offset SFRs by 0x3000 and our linker does not support this yet. We looking into this but can't guarantee this will be supported (at least soon ). Regards, Pavel
  7. Hm, my question is not even moderated yet. Are there plans to support the 26K62 or any of that series? They are the only 18F chips with a 12bit ADC which is why I am using them. Also, your emulator looks promising. Any plans to support some simple elements like a potentiometer/ADC module emulation for ADC code? A terminal to interface with UART? Regards, David
  8. Hi, I am an experienced PIC user, programmer and designer. I am looking to move away from Wiz-C which is no longer supported. It used to be good, though frustrating because of many bugs which tended to cancel out the big productivity pluses of the product. Increasingly I had to write my own libraries and modify the product for new chips. I have now had enough and looking to change. Anyway, I amnow looking at these Sourceboost products. I note that must of the forum activity was years ago. Does this mean that the user base is dying out? Also, a number of the PICs which I use are recent 18F devices (such as those with 12bit A/Ds etc). They are not listed on the support list. How often are new devices added to the support list? I realise of course that it would be impractical to support every PIC chip. For instance, a newish chip I would like to use now is the 18F26K42. What are the chances of supporting that in the near future? Particularly with the IDE. Regards, David
  9. Hi Pavel Thank you for the quick reply. Good to know. Its been a long time since I looked at the NOVO source, so my memory tricked me on remembering "...this only works because of linker magic...". Anyhow I wasn't aware that the linker was the same for both compilers, kind of assumed it was 2 completelly separated toolchains. Best regards Jorge
  10. Yes Chameleon does work with Novo. The code you mentioned is generated by linker so there is no difference if BoostC or Chameleon is used. One can even mix OBJ files generated by BoostC and Chameleon in the same project. Regards, Pavel
  11. Hi I was wondering. Does the Chameleon compiler support the NOVO RTOS. AFAIK the BoostC compiler does generate a piece of special to code to execute the task switching on the NOVO scheduler. It would be nice if Chameleon had the same feature. Best regards Jorge
  12. Is there a way to mark a code section and have it commented out n "one click" I know it is possible to /* at the begining and and then */ at the end but what I am looking for is a "one click" way to insert // at the beginning of each line in the section (an then removing it) This is a feature found in all IDEs that I know, so I either missed how to do this or it does not exist in the SB IDE editor.
  13. JorgeF

    Error code

    Hi Good you found it. But its a fact that the BoostC compiler is quite weak in terms of error reporting. I've seen that error, "failure", for all kinds of errors. In fact its quite rare to see other error messages. Best regards Jorge
  14. Can some one tell me what error code 133 "failure" means? I keep getting this error when trying to compile a project. It's associated to a *.h file line #133. I'm not sure what I did to break my code which compiled ok before, but after a bunch of edits I can't seem to figure out what I did to generate this error. The error "failure" seems a bit vague. Using SB 7.42 Also is there a document listing of all the error codes this compiler can generate? thanks Edit. I found the problem: I had mistakenly declared an emum element the same as a function name.
  15. jartim

    Compiler hangs with in-line assembly

    Hi Pavel You are 100% correct, I was changing the coding from assembler to C and wasn't concentrating! Please disregard my original post. Regards Tim
  16. Pavel

    Compiler hangs with in-line assembly

    Compiler hanging is not good and we will look into this but your code does not look correct either. Everything inside the asm{} block should be assembly language. Anything else including C statements like _tblptru = 0 will not work. Regards, Pavel
  17. Bug description: Compiler hangs indefinitely with the following source - Steps to reproduce: This file is "TClass.hpp" - unsigned char ReadFlash(unsigned int FlashAddr) { asm { _tblptru = 0 _tblptrh = _FlashAddr _tblptrl = _FlashAddr+1 tblrd* } return tablat; } Expected behaviour: This should compile with no errors Is the problem 100% reproduceable: 100% every time IDE version: MPLAB-X V4.20 Compiler: BoostC++ Compiler version: V7.43 Target device: PIC18F8527 OS: Win 7 Comments: Compiles if the three lines relating to _tblptrx are commented out.
  18. Hi Usualy the forums are more targeted at experience exchange between users than to technical support. Same happens with the Microchip forum and a few others I know. Best regards Jorge
  19. Hi Jorge No, not yet, I will do this today. I assumed that the forum was the first place to go to report an issue? Regards Tim
  20. Hi Confirmed, both for C++ and C. Did you try to send an email to support@sourceboost.com ? Best regards Jorge
  21. Bug description: Compiler generates incorrect code from mixed C++ and inline assembler - Steps to reproduce: The following is a sample section of code that generates the wrong address for _TestTemp+1 - void CPUTest() { unsigned char TestTemp[3]; asm { CPUTest_9: movlw 0xff ; set up locations ready to change movwf _TestTemp movwf _TestTemp+1 movwf _TestTemp+2 lfsr 0, _TestTemp+1 ; set up a pointer movlw 0x55 movwf _postdec0 } } Expected behaviour: In my application TestTemp[0] is located at 0x5C2, TestTemp[1] and [2] are at 0x5C3 and 0x5C4 respectively. The compiler should load fsr0 with the value 0x5C3 (_TestTemp+1), however the final generated code loads the value 0x5C2 instead. Is the problem 100% reproducible: 100% happens every time IDE version: MPLAB-X V4.20 Compiler: BoostC++ Compiler version: V7.43 Target device: PIC18F8527 OS: Win7 Comments:
  22. Hello I use since ages Sourceboost with Linux and MPLAB IDE 8,90 under wine (OS UBUNTU). Recently I migrated to MPLABX (Linux version) using the free version of MPLABXC8 compiler. As I have good experiences with SourceBoost I'd would like to go ahead with this complier and purchase the newest version 7.43 and use it with MPLABX IDE under Linux. Did any body make it work? Kind regards Martin
  23. jartim

    Incorrect code generated

    Thanks Pavel. Unfortunately the Chameleon compiler does not support C++ (does it?) Regards Tim
  24. Pavel

    Incorrect code generated

    I can confirm this issue for the BoostC compiler family. The Chameleon compiler however handles this code well. Regards, Pavel
  25. Hi I missed this topic in due time,so I don't know if this repply is usefull, but here it goes. That is a nice ASM trick, but I think its uneeded in 'C' and also undesired. Its not a good idea to directly manipulate the stack when using a compiled language, because you don't control how the compiler handles the stack. Also bear in mind that due to the limited stack size and specific stack access instructions of the 8 bit PICs, BoostC and other compilers implement a so called "software stack" to handle parameters and automatica variables. The hardware stack is used only for return addresses. To store strings in the program memory you can use the "rom" qualifier (page 47 of the Boost C manual) and then the usual 'C' tools to work with them. HIH Best regards Jorge
  1. Load more activity
×