Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Earlier
  3. I have the same issue when trying to buy a new license. It says that the product does not exist.
  4. Much kudos to you. You saved my live. I also banged my head for half a day on this. What a difference a star (*) can make to [].
  5. Alas and alack, no! It's frustrating, as I want to take advantage of the newer devices which version 7.xx provides. One of the few times that I'm willing to shell out, but no way to do it.
  6. Hi, I am also a UK user trying to buy a licence and getting "the product does not exist" message. did you find a way to purchase or can anyone advise. Thanks
  7. Hi there. I use Sourceboost C++ compiler, which I rate very highly. I'm currently trying to upgrade my licence from V6 to V7. Whenever I get to the Digital River site, the screen just displays "Product does not exist! At least one of the requested products does not exist." Thanks in advance all, for any help... Matt Fry
  8. Using MPLabX ver 5.15 with SourceBoost 7.43. Working to compile an existing project with the Chameleon compiler, found these problems(which compiled OK with BoostC): 1)Got a strange error when trying to compile a switch statement using an enumeration: Attached file newmain.c failed with this error: newmain.c(28): error: missing closing curly bracket (1) Compile succeeds if the statement case SSStart: is replaced with case 0: **************************** 2)Definition of enum EN_TASK_STATUS in novo.h fails compile due to trailing comma: enum EN_TASK_STATUS { TS_NOT_STOPPED = 00000111b, TS_IN_RUN_Q = 00000001b, TS_IN_SLEEP_Q = 00000010b, // a task can be in the event queue TS_IN_EVENT_Q = 00000100b, // and wait queue at the same time TS_EVENT_TIMEOUT = 00001000b, TS_IS_WAKING = 00010000b, //***** remove this trailing comma to fix! ******* }; ******************************* 3)Novo Sys_Sleep(TICK_COUNT) compile fails because TICK_COUNT defined as unsigned int and Sysi_Sleep wants unsigned short or unsigned char arg. Strangely, I could not fix this by editing the TICK_COUNT typedef in novocfg_PICxxxxx.h file, I had to define the variable I used in Sys_Sleep call as unsigned short. FAILS COMPILE: TICK_COUNT usTicks; usTicks = 10; Sys_Sleep(usTicks); COMPILES OK: unsigned short usTicks; usTicks = 10; Sys_Sleep(usTicks); ************************************************************************************************************************** newmain.c
  9. PROBLEM SOLVED, my PC needed msvcp120.dll from the Microsoft Visual C++ Redistributable Package for Visual Studio 2013. I have a 64 bit computer, so I installed both the 64 bit and 32 bit versions as recommended by Microsoft. I discovered the need for this dll by running the Chameleon compiler via c_pic18.exe command line interface. Hope this helps someone with a similar problem...
  10. Repeated test with MPLabX v5.15 and default C program generated by MPLabX. Results are the same as detailed in previous post - compiles fine with BoostC, using Chameleon compiler fails with 'recipe for target xxx failed' error. Error refers to line 101 of nbproject/Makefile-default.mk file which I have attached to this post. Has anyone else seen this? Makefile-default.mk
  11. Using BoostC 7.43 on MPLabX 4.00 on Windows 7 with PIC18F25K22. I newly installed version 7.43, standard BoostC compile works fine. I presume that the Chameleon compiler supports the PIC18F25K22. When I add -force_chameleon to compiler additional options, I get this result: ******************************************************************************************************************************************* CLEAN SUCCESSFUL (total time: 113ms) make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf make[1]: Entering directory 'C:/PICProjects/GPS' make -f nbproject/Makefile-default.mk dist/default/production/GPS.production.hex make[2]: Entering directory 'C:/PICProjects/GPS' gnumkdir -p build/default/production "C:\Program Files (x86)\SourceBoost\xlaunch.exe" -t PIC18F25K22 -obj "build/default/production" -o "build/default/production/GPS.o" GPS.c -force_chameleon nbproject/Makefile-default.mk:101: recipe for target 'build/default/production/GPS.o' failed gnumkdir -p dist/default/production make[2]: [build/default/production/GPS.o] Error -1073741515 (ignored) "C:\Program Files (x86)\SourceBoost\boostlink_picmicro.exe" -t PIC18F25K22 -ld "C:\Program Files (x86)\SourceBoost"\lib -p dist/default/production/GPS.production.hex build/default/production/GPS.o libc.pic18.lib BoostLink Optimizing Linker Version 7.43 http://www.sourceboost.com Copyright(C) 2004-2018 Pavel Baranov Copyright(C) 2004-2018 David Hobday failure Error: Failed to open:GPS.o make[2]: *** [dist/default/production/GPS.production.hex] Error -2 make[1]: *** [.build-conf] Error 2 make: *** [.build-impl] Error 2 nbproject/Makefile-default.mk:115: recipe for target 'dist/default/production/GPS.production.hex' failed make[2]: Leaving directory 'C:/PICProjects/GPS' nbproject/Makefile-default.mk:90: recipe for target '.build-conf' failed make[1]: Leaving directory 'C:/PICProjects/GPS' nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed BUILD FAILED (exit value 2, total time: 1s) ************************************************************************************************************************************************* I cut the program down to nearly nothing, just a Main routine(see attached). Any ideas? GPS.c
  12. Hi Yep. Its not the first time that an anti-virus triggers a false positive. Surprisingly it rarely happens as all it takes is a shared sequence of code with a known virus. With the millions of programs out there in the world, it could happen a lot more. Good you have your problem sorted out. Best reagrds Jorge
  13. Hi, Some delay in responding to your thoughts, and your mention of a virus scan is not far off the mark, but in the wrong direction! To cut a long story short, it turned out that it was my all-singing-all-dancing virus checker that was the culprit. The penny dropped when I attempted to re-install my version 6.97 toolchain; this was stopped because it declared it contained a trojan!! Ultimately, after a lot of faffing about, it simply required certain compiler files etc. to be excluded from any scanning. The culprit is F-Secure Safe, which I have been using for years; they obviously snook in an update which then caused me to waste 2 days going round in circles. Grrrrrrrrr! Again, thanks for taking the time and trouble to respond. (I never got anything from Sourceboost support) Mikew
  14. Hi That's strange. Might it be that you are working with a very old project, created under a previous version? How does it behave with a brand new project? In my installation (7.43), all the compilers have the underscore in the name, also the linker. BTW, don't forget to do a good virus/malware scan on your PC. Best regards Jorge
  15. Hi, Thanks for the response. The Boost C I have been using for years is Version 6.97 - I have never had the need to upgrade to Version 7.xx. So I can't think that this has anything to do with this sudden "relapse"!! Since I posted this, I've discovered that the compiler now actually does nothing!! Clicking on 'OK' in the message, it continues without any warnings, declares 'Success' and 'Done' but has not parsed the source file and has not produced a new .hex file. I'm thinking that a fresh install might cure the problem, but not sure if this is a bad idea without having some idea why it has suddenly happened for no apparent reason.
  16. HI Have you looked in the manual?
  17. Hi I might be wrong, but. I have a faint memory of such a change somewhere along the V7.xx versions. At the time the subject was discussed/explained in the forum, maybe you should take a look at it. What is the exact version you are using?
  18. I have been using Sourceboost C Version 6.97 for some time, without any problems. Today I re-compiled a file and obtained the following odd message:- Compiler executable was renamed from boostc.pic18.exe to boostc_pic18.exe If you see this dialog this means that you still try to use the old compiler name. Nothing has been changed in the installation in any way, and I am at a loss to understand what this error means. After choosing ‘OK’ the compile/link etc. process seemed to continue correctly. I am at a loss as to why this "error" message has suddenly appeared for no obvious reason. In this case I can't blame Windows 10 updates!! Perhaps someone more knowledgable of Boost C can shed some light?
  19. BoostC Version 7.43 generates wrong code for ? operator with PIC18F6622. Working code using if statements from CASM file: unsigned int d = accel_axis_raw.AXIS_X / BSCALEX; if (d > 90) bmotion->OutX = 90 + 127; else bmotion->OutX = d + 127; 3050 0E5A MOVLW 0x5A 3052 659F CPFSGT ACCEL_Getb_0006F_14_d, 1 3054 67A0 TSTFSZ ACCEL_Getb_0006F_14_d+D'1', 1 3056 D001 BRA label223 3058 D007 BRA label224 305A label223 305A 519C MOVF ACCEL_Getb_0006F_arg_bmotion+D'1', W, 1 305C 6EEA MOVWF FSR0H 305E 519B MOVF ACCEL_Getb_0006F_arg_bmotion, W, 1 3060 6EE9 MOVWF FSR0L 3062 0ED9 MOVLW 0xD9 3064 6EEF MOVWF INDF0 3066 D09D BRA label236 3068 label224 3068 0E7F MOVLW 0x7F 306A 259F ADDWF ACCEL_Getb_0006F_14_d, W, 1 306C 6FA1 MOVWF CompTempVar3286, 1 306E 519C MOVF ACCEL_Getb_0006F_arg_bmotion+D'1', W, 1 3070 6EEA MOVWF FSR0H 3072 519B MOVF ACCEL_Getb_0006F_arg_bmotion, W, 1 3074 6EE9 MOVWF FSR0L 3076 51A1 MOVF CompTempVar3286, W, 1 3078 6EEF MOVWF INDF0 Bad code using ? : operator: unsigned int d = accel_axis_raw.AXIS_X / BSCALEX; bmotion->OutX = 127 + (d > 90 ? 90 : d); 3050 0E5A MOVLW 0x5A 3052 659F CPFSGT ACCEL_Getb_0006F_14_d, 1 3054 67A0 TSTFSZ ACCEL_Getb_0006F_14_d+D'1', 1 3056 D001 BRA label223 3058 D003 BRA label224 305A label223 305A 0E5A MOVLW 0x5A 305C 6FA2 MOVWF CompTempVar3287, 1 305E D002 BRA label225 3060 label224 3060 519F MOVF ACCEL_Getb_0006F_14_d, W, 1 3062 6FA2 MOVWF CompTempVar3287, 1 3064 label225 3064 51A2 MOVF CompTempVar3287, W, 1 3066 0F7F ADDLW 0x7F 3068 6FA1 MOVWF CompTempVar3286, 1 306A 519C MOVF ACCEL_Getb_0006F_arg_bmotion+D'1', W, 1 306C 6EEA MOVWF FSR0H 306E 519B MOVF ACCEL_Getb_0006F_arg_bmotion, W, 1 3070 6EE9 MOVWF FSR0L 3072 51A1 MOVF CompTempVar3286, W, 1 3074 6EEF MOVWF INDF0
  20. Hi Reynard, thank you very much for this information. best regards Manfred
  21. Hi Manfred, You are absolutely correct, the compile button or drop down menu compile does not work. The source file is saved, the object file seems to get deleted and that's it. Not a user of the compile button myself, always the F7 (build). It may get fixed one day in the far future. Cheers Reynard
  22. Hi Reynard, There is one main.c-file and a few included files (with #include<path\filenname>) I removed all spaces from filenames. Compiler works if I press the button 'build'😀 Compiler don't work if I press the button 'compile'😡 . Is this a bug in the IDE 7.43? For me It's no problem. I use now the button 'build' and not longer the button 'compile' best regards Manfred
  23. Hi Manfred, As far as I know spaces in file names have never worked as spaces are command line delimiters. Spaces are allowed in directory names. I am not sure what you are saying in your first post. You only have one file in your project and you got the response "Done" after the compile. What were you expecting to see ? Cheers Reynard
  24. Hi Reynard. I tryed it out and used Build->Clean. There is no difference. Using the button 'build' works using the button 'compile' fails, nothing happens (same message as above) best regards Manfred
  25. Hi Manfred and welcome to the SourceBoost forum. If the project was created using 7.3 before you upgraded to 7.43 then you should clean the project using Build-> Clean All to remove all the previous make files etc. Other than that there should not be any problems if you are using the F7 key to compile and link. If you are using Novo libraries (or any of your own libraries) then you should rebuild them with the newest compiler or the linker may complain. Good luck with your project. Looks like it may be a Nixie tube clock. Cheers Reynard
  26. I found out following items: 1. spaces in filenames causes problems in V7.43 2. after removing spaces the button 'build' works (compiles and links project correct) 3. the button 'compile' don't work like post1
  27. Hi, I am new in this forum and a hobby programmer which uses sourceboost for a few years. Up to V7.3 sourceboost and compiler works well. Now I does a update to V7.43. Pressing the compiling button of a existing project generates only the attached output message. Nothing happens. If I open a cmd window and starts the compiler with a command string then the compiler works perfect. The options settings in Sourcboost IDE seems to be correct to the path of the compiler. I think that die 'source.c' file are not founded. What is the cause? Are there any setting for the path of the project in the boost software or in the registry. please help me. The problem is on different computers (windows 7 32 bit, Windows 8.1 64 bit) Manfred
  1. Load more activity
×
×
  • Create New...