Jump to content

Pavel

Administrators
  • Content Count

    1,466
  • Joined

  • Last visited

Everything posted by Pavel

  1. Fixed. Fix will be available in 1.8. Regards, Pavel
  2. Which bootloader does work? Can you post URL where to find it? Regards, Pavel
  3. For which target code was generated? Do you know which define is wrong? Regards, Pavel
  4. Another cause of such error may be too short file names. The Hi-Tech COFF file format that stores all debug information and used by BoostC has this limitation and doesn't work well if file name base is shorter than 3 characters. We plan to fix this tweaking COFF file. Regards, Pavel
  5. BoostC 1.7 Alpha update is available to download from http://www.picant.com/c2c/download.html. All bugs reported since the previous release are fixed. Thanks to everybody who sent us their feedback. This update must be installed over SourceBoost 5.7 installation. Regards, Pavel
  6. Fixed. Fix will be available in 1.7 update. Regards, Pavel
  7. This was a compiler bug in '<' operation . Fixed now. Fix will be available in soon to be released 1.7 upgrade. Regards, Pavel
  8. ... INCF read_eeprom_string_2_count, F ... The instruction above increments the 'count' value. SOmething else must be wrong. Do you have a project where this problem can be reproduced? Regards, Pavel
  9. We plan to release 1.7 before the next weekend (Nov 14). The 'rom' feature won't make it into 1.7 though Regards, Pavel
  10. Data can be stored in code memory using 'rom' storage specifier in variable declaration. This feature is not yet supported in BoostC though: //data will be stored in code memory (not yet implemented in BoostC 1.6) rom char arr[] = { 1, 2, 3, 4 }; Regards, Pavel
  11. Another way to save data and code space and make code flexible is to use function templates. This feature was borrowed from C++. It's not fully supported in BoostC yet but the part that is supported can already help. For example have a function that works with a port, want to have the port selectable at compile time and don't need it to be selectable at run time. Than code like this will help you ans save a lot of code and data space: template <char A> void foo( void ) { char port@A; ... //some code that operates with port } void main( void ) { foo<5>(); //function 'foo' will deal with port A ... } Note though that because function overloading doesn't work yet it won't be possible to use same template with different template arguments: ... foo<5>(); foo<6>(); //this won't link ... Regards, Pavel
  12. Preprocessor is ok. That's your code that's wrong. I tried it with MSVC and GCC and both reported an error. Regards, Pavel
  13. The expression "cout << DoSomething(myValue);" doesn't have any destination and doesn't change any variable in the code. That's why compiler optimizes it out. This optimization happens at parsing stage when variables aren't known yet. This is why you don't get any error if cout isn't declared. Regards, Pavel
  14. Fixed. Fix will be available in 1.7 Regards, Pavel
  15. Fixed. Fix will be available in 1.7 Regards, Pavel
  16. Fixed. Fix will be available in 1.7 Regards, Pavel
  17. Fixed. Fix will be available in 1.7 Regards, Pavel
  18. Pavel

    Compiler Error?

    Fixed. Fix will be available in 1.7 Regards, Pavel
  19. The script still left some errors: ... #define _OSC_ECIOSWPLL_10xFD ... Regards, Pavel
  20. If code uses */% operations it needs to link with libc library. When building from SourceBoost IDE this is done automatically. Otherwise you need to link with libc library using other means. (For libc library look into the 'lib' subdirectory in your SourceBoost installation directory). Regards, Pavel
  21. Pavel

    Compiler Error?

    Another workaround is to cast pointers to unsigned short: while ((unsigned short)EP0_start < (unsigned short)EP0_end) { ... } Regards, Pavel
  22. Pavel

    Compiler Error?

    Hmmm I see now but I still don't recommend this practice even when this bug is fixed. Pointers are 2 bytes long and operations on such variables generates much more code than if 1 byte vars are used. If buffer is less than 256 bytes long a simple for loop with char counter will work more efficient: char i; for( i = 0; i < BUFLEN; i++ ) { ... } Regards, Pavel
  23. Pavel

    Compiler Error?

    Yes this looks like an error but this kind of comparisson is probably never used in the code (at least I never ever used something like this). I'm curious when you need to compare pointers? Regards, Pavel
  24. If you see this problem happening again please zip the whole project and send it to me. I want to reproduce it and see what's happening inside compiler. Regards, Pavel
×
×
  • Create New...