Jump to content

Pavel

Administrators
  • Content Count

    1,466
  • Joined

  • Last visited

Everything posted by Pavel

  1. What exactly happens? Is this instruction ignored, or generates wrong opcode or something else? Regards, Pavel
  2. 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
  3. 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
  4. Looks like compiler problem. We'll investigate. Thanks for reporting. Regards, Pavel
  5. None of these. You need boostc_pic18.exe Regards, Pavel
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. Select BoostC as your current toolsuite. Regards, Pavel
  12. 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
  13. 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
  14. You need to prefix labels with asm keyword like: #define ReadADC2( dst ) asm loopi: \ asm addlw 0x01 \ ... Regards, Pavel
  15. 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
  16. 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
  17. 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
  18. Emai; with your license key was sent to you yesterday. Check you email filter. I re-sent it again a minute ago. Regards, Pavel
  19. What's your order number? Regards, Pavel
  20. No Added support for multiple instances of same plugin. Regards, Pavel
  21. We didn't do any work in this area except of some thinking how this can be implemented. This likely means that bitfields won't be supported in any near future. Sorry if that's not what you expected to hear. Regards, Pavel
  22. It's your code responsibility to make sure txHead/txTail/rxHead/rxTail/rxCnt are initialised to zero at start. Sample code from SourceBoost installation declares them as static what makes compiler generate code that initialises them to zero. If you don't use static you need a statement like txHead= txTail = rxHead = rxTail = rxCnt = 0; somewhere in you initialisation code. Regards, Pavel
  23. Can you try SciTE that uses the same edit control that SourceBoost on the same files. SciTE is available from http://www.scintilla.org/SciTEDownload.html This will show if the problem is in the control or ide code. Regards, Pavel
  24. Allow multiple instances of the plugins, sometimes 8 led's is not enough Make green bar go away or change color when code is not stopped, ie running.
×
×
  • Create New...