Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About vbhunt

  • Rank
  1. Novo headers will be included by default because we encourage to use it in all projects (well in almost all projects). There definitely are more technical reasons to use it rather than not. Regards, Pavel I agree with Sparky that you should NOT enable the Novo headers as an IDE default. You may wish to encourage its usage but you should not break my code or even require me to research why I suddenly have new unusual names in my name space. I have a large project that predates the appearance of Novo and so its (somewhat hidden) inclusion was highly surprising. At least it should
  2. You link several files in your project. If you use Pro license all these files have to be built using Pro license. Regards, Pavel The entire project was developed using SourceBoostC. All of them were compiled under the SourceBoost Pro License. However, they were compiled using version 6.70 and then linked. I recompiled everything and then it all links. Thanks for the help.
  3. I have a new Windows Vista Business Professional Laptop that I'm attempting to run SourceBoost IDE 6.80 BoostC and Linker using my Sourceboost professional license. I installed as an administrator and registered both the compiler and IDE plugins. Both registered fine. I can bring up the IDE and compile but the linker fails saying that I've exceeded the license allowable ram. It works fine on my previous Windows XP box. Is there something new I need to do? --------------------------------------------------------------------------------------------------------------------------
  4. Thanks emte for clearing this up. Yes, we use SVN to maintain the source code. You can also browse it online too to see if it matches your needs: AT http://sourceforge.net/projects/nn3turntable select "Code">>"SVN Browse".
  5. We would like to announce the availability of Opensource BoostC Source code that may be of interest to SourceBoost Forum C programmers. This software source code is available for download now at: http://sourceforge.net/projects/nn3turntable/ At the above location you can download the complete SourceBoost projects. This embedded software system consists of two communicating applications written in SourceBoost Boost "C" for the PIC18 processor family on an I2C network. The software is the code basis for a model railroader to remotely operate auto-indexing turntables on model railroa
  6. I think of a bug as actions of a computer program that differs from the claimed behavior according to the program's documention. By this criterion, this is a bug. The fact that there is a work around is very nice; but the genertion of an incorrect option is just plain wrong.
  7. Bug description: In the MPLAB SourceBoost "C" integration, using Compiler version 6.70 using the compiler option -i by selecting menu item Project>"Build Options...">"Project" with the "BoostC C Compiler for PIC18" tab. Selecting "Debug inline code" check box yields the option, "-di" where it should yield "-i". This option then causes all variables named "i" in the build to become null -- yielding many errors in the code. Steps to reproduce: In MPLAB (version 7.50 or 7.52) select "Project">"Build Options ...">"Project". Select the "BoostC C Compiler for PIC18" tab. Selec
  8. No it doesn't support such a facility.How and when exactly would you use this checksum value? (I guess it will be some kind of startup system integrity check) Regards Dave <{POST_SNAPBACK}> We have an application that user's may possibly change by re-programming part of it. To rapidly sort out "supported" from "non-supported" software, a code such as CRC-16 would be useful as a rapid means of telling similar from identical code. We would like the CRC-16 code to be placed in the program to distinguish it from configuration code permanent memory. Thus, we can build into
  9. Yes, indeed! Thanks for pointing out my bonehead mistake. It really had me going there for a good afternoon. Almost any indicator of where the error occured would be helpful. For a long time I thought it was related to the strange comment behavior. Anyway, thanks for the help. /Bruce
  10. In the previous post, the problem is that r1 should be decared "Byte r1[] = {...};" as should r2. The interesting question is why was there not a message about an invalid initializer? Cheers & Thanks. /bruce
  11. Bug description: The following program fails with "Exit code -529697949" in BoostC 6.60. The following is the smallest complete program I could make that doesn't compile. It is reduced from a larger module to compute CRC-8 values for byte strings. Steps to reproduce: #include <system.h> typedef unsigned char Byte; #define PByte Byte * // this is temporary to address the typedef bug. Byte r1 = { 0x00, 0x5e, 0xbc, 0xe2, 0x61, 0x3f, 0xdd, 0x83, 0xc2, 0x9c, 0x7e, 0x20, 0xa3, 0xfd, 0x1f, 0x41, }; Byte r2 = { 0x00, 0x9d, 0x23, 0xbe, 0x46, 0xdb, 0x65, 0xf8, 0x8c, 0x11, 0xaf,
  12. I too would like to see bit fields work as defined by ANSI C. They are extremely useful to keep data structures compact. The pics are such nice bit bangers that they beg for bit field support .
  13. In the following (using MPLAB IDE 7.52 in WinXP) notice that the ' -I "..\Common"' gets turned into "-i" which appears to be incorrect since I want to have several include file paths in the compile. Shouldn't the case of the parameter be preserved; especially when changing case changes the parameter's meaning? Or, has the parameter been changed but the documentation remains out of date? Also, is there a way to inform the compiler of the path to the source file? This appears to be needed since the source file is NOT in the same directory where the MPLAB IDE invokes the compiler. In
  14. That seems to be a very useful workaround. It gets me over the problem. Thanks!
  15. As I read your code, your adcon0 has value 0xA1 meaning "10100001". Thus, you have a right justified result, measuring against Vss and Vref+ on channel 0 and you've turned on the A/D module. adcon1 has value 0x70 = "01110000' which means Frc (internal osc.). I think you noticed this and have set it to 0 (500KHZ with your 1MHZ clock). I recommed that you change b and c to unsigned char since they are set from 8 bit registers (adresl,adresh). Also, I think that you want the first delay above to reflect the acquisition time for the A/D module after turning it on. In my application
  • Create New...