Jump to content

Pavel

Administrators
  • Content Count

    1,471
  • Joined

  • Last visited

Everything posted by Pavel

  1. Fixed. Fix will be available in the coming 7.02 release. Thanks for reporting. Regards, Pavel
  2. Fixed. Fix will be available in the coming 7.02 release. Thanks for reporting. Regards, Pavel
  3. Fixed. Fix will be available in the coming 7.02 release. Thanks for reporting. Regards, Pavel
  4. Fixed. Fix will be available in the coming 7.02 release. Thanks for reporting. Regards, Pavel
  5. Because SourceBoost generates some files and registry data not all will be removed when you uninstall it (this is not something SourceBoost specific but the way how windows uninstall works, uninstall removes only what was created during installation but not what was created after) To start absolutely fresh, uninstall SourceBoost and than delete it's installation directory and SourceBoostIDE registry entries that can be found in HKCU/Software and HKLM/SOFTWARE. After this install SourceBoost back and if you still have same crashes they must be caused by some external programs or something else present in your system. Regards, Pavel
  6. What exactly happens? Is this instruction ignored, or generates wrong opcode or something else? Regards, Pavel
  7. Compiler doesn't know anything about registers (almost). It's up to the system header to declare them and than compiler uses these declarations just as any other variables. In your case it looks like system header for the target you use does declare tmr1 as char. Try to change it to short and check if it helps. Regards, Pavel
  8. preg.exe is part of SourceBoost installation and there are no trojans in it. Other files that you listed (.tmp ones) are not from SourceBoost. Do you know where they come from? Regards, Pavel
  9. Looks like compiler problem. We'll investigate. Thanks for reporting. Regards, Pavel
  10. None of these. You need boostc_pic18.exe Regards, Pavel
  11. Yes it's possible. You'll need to replace the default implementation of alloc and free functions from libc with your own. To get libc sources you need to either get a pro compiler license or buy a Novo RTOS license. Regards, Pavel
  12. Fixed. Fix will be available in the coming release 7.02. Code to access variable address will look like: asm movlw low(_var); copy low byte address of variable var into W asm movlw high(_var); copy high byte address of variable var into W Regards, Pavel
  13. Pavel, thanks for the reply. I downloaded the v7.01 plugins from: http://www.sourceboost.com/CommonDownload/...ins/plugins.exe Does the new version of 7segmentLEDs have a different name? Perhaps the old version has a different name and is not overwritten upon installation of the v7.01 plugins. I deleted the files 7segmentLEDs.dll and 7segmentLEDs.html and tried reinstallation of the v7.01 plugins, but no new files of the same name were created. 7segmentLEDs came from a third party author. It's the author responsibility to update plugin sources and produce a new executable that will compatible interface with IDE v7. Regards, Pavel
  14. API between IDE and plugins changed in version 7 (to support multiple plugin instances). It sounds that you try use IDE v7 with plugins v6. Solution: upgrade plugins to maths IDE version (if you run IDE v7 you need plugins v7) Regards, Pavel
  15. It got accidently deleted, and we never managed to recover it :-( Most of the information from this thread (except maybe couple of very last posts) is duplicated in users manual that is included into SourceBoost installation. If you have command line examples for more programmers, let us know and we'll add them to the manual. Regards, Pavel
  16. Select BoostC as your current toolsuite. Regards, Pavel
  17. Can you email your zipped project to support@sourceboost.com We work on a new release and would like to fix all reported assembler related problems. (v7 has completely updated built-in assembly handling code hence the errors) Regards, Pavel
  18. No asm{} block can not be used inside a pre-processor macro. The reason for this is that when continuation operation used inside a macro #define TEST() asm \ { \ movlw 3 \ movlw 4 \ movlw 5 \ } pre-processor removes end of lines and puts all instructions on one line: asm { movlw 3 movlw 4 movlw 5 } while compiler expects every assembly instruction to be on a separate line. I suggest to wrap your assembly code into an inline function and call this function instead of macros. Because function is inline compiler will embed code from it into every call so the effect will be same as if macros were used. Regards, Pavel
  19. You need to prefix labels with asm keyword like: #define ReadADC2( dst ) asm loopi: \ asm addlw 0x01 \ ... Regards, Pavel
  20. Thanks for all the feedback. I have a feeling that either I miss something or some posters greatly exaggerated the problem. Let me state the problem as I understand it and correct me if I'm wrong: SourceBoost IDE can not debug code built with recent MPASM. Other than this SourceBoost IDE has same functionality as it has before + a number new features introduced in version 7. If that's the case I don't understand statements like "becomes unusable so fast" and "it was a good compiler". What exactly becomes unusable and how MPASM code debugging is related to compilers? We do work on this issue and hopefully will have a fix. Based on the feedback from this thread we also should re-arrange our priorities a bit. Meanwhile please use a well known workaround: use MPLAB to debug your assembly code. Regards, Pavel
  21. Not quite. Consider a function call. If a function is implemented in assembly it must obey conventions that compiler uses to pass call arguments, pass back return value, use heap etc. This is your one example out of many. Because there is no common standard how to do this every compiler is different and as result obj files generated by different compilers are not compatible i.e. HiTech won't accept obj file generated by CCS compiler and vice versa. Code wise it means that only very primitive subset of assembly code can be made portable. As soon as one starts using C level conventions (like handling function arguments) all portability is gone. Regards, Pavel
  22. Not quite. Consider a function call. If a function is implemented in assembly it must obey conventions that compiler uses to pass call arguments, pass back return value, use heap etc. This is your one example out of many. Because there is no common standard how to do this every compiler is different and as result obj files generated by different compilers are not compatible i.e. HiTech won't accept obj file generated by CCS compiler and vice versa. Code wise it means that only very primitive subset of assembly code can be made portable. As soon as one starts using C level conventions (like handling function arguments) all portability is gone. Regards, Pavel
  23. Emai; with your license key was sent to you yesterday. Check you email filter. I re-sent it again a minute ago. Regards, Pavel
  24. What's your order number? Regards, Pavel
×
×
  • Create New...