Jump to content

Pavel

Administrators
  • Content count

    1,466
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Pavel

  • Rank
    Super Maniac

Contact Methods

  • Website URL
    http://www.sourceboost.com
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Melbourne, Australia

Recent Profile Visitors

3,737 profile views
  1. 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
  2. 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
  3. 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
  4. 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
  5. Pavel

    Incorrect code generated

    I can confirm this issue for the BoostC compiler family. The Chameleon compiler however handles this code well. Regards, Pavel
  6. Yes you can share the compiled libc binary but not the library sources. Please make sure the github users know the origin of the binary. Regards, Pavel
  7. We would like to reproduce this and we don't need your source code. Please email your project obj files and linker command line to support@sourceboost.com Regards, Pavel
  8. I tried your suggestions but could not reproduce this error Most likely it's just one particular line of code. Maybe you can remove portions of this code that contain IP of your customer and send us the resulting file and maybe even obfuscate it. We are releasing a new version very soon and it'll be nice if this fix makes its way in. Regards, Pavel
  9. Here are some notes how rom objects work in BoostC: - a rom object is always identified by one byte (that's why in the code above gbl_sw_id is 1 byte long) - when linker processes all its input files it makes a list of all rom objects and allocates IDs to them - linker generates code for all these rom objects that it puts into the code memory - linker generates a function that can extract any byte of any rom object using its ID and position/index - when compiler needs to generate code to access character in a rom object it uses an placeholder ID and character position/index and calls function that linker generates in the prev bullet. Later linker replaces this placeholder ID with an actual object ID. Chameleon does not yet support rom objects. Support for rom objects will be added to Chameleon in the upcoming 7.43 release. Regards, Pavel
  10. When compiling a file the first thing the compiler does it splitting preprocessed source file into lines. If it fails it spits out the error that you quoted. Normally this process is very straightforward and there shouldn't be any errors (hence the error is so brief) but looks like we missed something in this parser (Chameleon is still in beta stage). Can you email your source file along with the compiler command line to support@sourceboost.com so we can investigate. Regards, Pavel
  11. Cam you email your source file to support@sourceboost.com Regards, Pavel
  12. This is a bug. Please try a fix available from http://www.sourceboost.com/CommonDownload/Fixes/c_pic16.zip (download and unzip it into your SourceBoost installation directory, it will replace the original chameleon pic16 compiler). Thanks for reporting this. Regards, Pavel
  13. You need to show us your GsmRemote.c file or at least its first 18+ lines. Regards, Pavel
  14. Try changing random_int = rand(); to random_int = rand() >> 1; This will reduce the possible random range by half but your code will operate on the positive half of the int range (when itoa implicitly converts unsigned to signed it will deal with lover half of the unsigned range which converted to signed will contain only positives).
  15. You access function argument correctly. Must be something else that causes the problem. Have you included system.h? If W is undefined you'll get same error (to check replace W with 0)
×