Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Everything posted by Dave

  1. Snowdan, all the upper case content of the header files is in the form: #define PORTB 0x0006 that makes: "bit RB0 @ PORTB.0;" the same as "bit RB0 @ 0x0006.0;" now when you put "PORTB = 0;", thats the same as "0x0006 = 0;" and therefore its doesn't make sense. However in the headers portb@PORTB; is define. So we can write "portb = 0;" and it works So I would recommend that you define all you bits in lower case, because things like GIE (global interrupt enable bit) already exist in the header as a #define. This format is just how C2C-plus header work. So my example would look like this: bit rb0 @ PORTB.0; void main() { trisb = 0; // set portb to output rb0 = 1; // turn on bit RB0 } looks simple enough for me. Hope this helps. Regards Dave
  2. Joe, One of the main reasons for expiry is to force users to get the latest versions. This is because alpha versions change quickly, as we respond to user problems as soon as we can. Don't worry, there will be a free version in the final release. It will not have any language restrictions. But it will limit code and ram usage. Regards Dave
  3. Joe, Unfortunately at the moment the simulator support for the PIC12 devices with 14Bit instruction cores is instruction only. Regards Dave
  4. You may not have releasied this: If the code window is selected (title bar is highlighted) when stepping code in the debugger, the code is executed an instruction at a time. If the source window is selected (title bar is highlighted), then code stepping is done at source code level. Was it obvious ? Regards Dave
  5. Everyone, Updated header files and TDF files can be downloaded from the download page page. These changes will mainly affect BoostC compiler users. Fixes: 1) More registers defined. 2) _config and associate bit masks defined 3) Trancated addresses fixed. 4) Some headers won't compile file fixed. 5) TDF files now define empty bit names as 'x' as a workaround for IDE bug. 6) USB buffers in some devices now defined. 7) New targets added, PIC12s that have 16Bit cores now can be compiled and debugged namely PIC12CE674, PIC12CE673, PIC12C672, PIC12C671, PIC12F675, PIC12F629 (hardware simulation still limited on these devices). 8) ....Other stuff These have taken a long time to construct, I hope they work well for you Please note: anyone who downloaded the new headers before the time stamp of this post will have ever so slightly older versions, a few minor corrections have been made since then, so plesae download again. Regards Dave
  6. Everyone, Updated header files and TDF files can be downloaded from the download page page. Fixes: 1) More registers defined. 2) _config and associate bit masks defined 3) Trancated addresses fixed. 4) Some headers won't compile file fixed. 5) TDF files now define empty bit names as 'x' as a workaround for IDE bug. 6) USB buffers in some devices now defined. 7) New targets added, PIC12s that have 16Bit cores now can be compiled and debugged (hardware simulation still limited on these devices). These have taken a long time to construct, I hope they work well for you Regards Dave
  7. Guys (and girls?), Please send a project demonstrating this problem to support@picant.com so we can get it fixed. Regards Dave
  8. Daniel, Yes, its a limitation of the current headers, a new set should be released soon, but they don't add the indiviudal bits because are lots of conflicts - Multiple registers have a bit with the same name (if you look at the whole PIC18 family). Good Because it makes no difference, thats just the way they ended up. I don't understand what you mean, this code compiles (assuming you don't #include <system.h> which may declare PORTB). #define PORTB 0x0006 volatile bit rb0 @ PORTB.0; Regards Dave
  9. crash_n_burn, void main() { char i; asm { start: btfsc _i, 4 goto start } } This code compiles for me no problem using BoostC V1.8. I don't know what you are doing different ? Regards Dave
  10. Rob, I'm nearly ready to release a new set of TDF and header files. The PIC2455 isn't in that set yet, so I will add it and send you a pre-release version of this TDF soon. Regards Dave
  11. glennjammin, We have just move onto the next problem. I'll email you a pre-release TDF file for PIC18F4431 for you to use. It should fix these issues. Regards Dave
  12. Dave

    Post Suit

    kathir4, I beleive the robot project is quite old "fun project" of Pavels, maybe there are some changes in MPLABs that cause this problem - maybe you can find out The real time kernal sound very interesting, it will be interesting to see when it is done. Regards Dave
  13. glennjammin, This is caused by an error in the TDF file for the PIC18F4431 RegisterSF PC { Description = "PC",""; Address = FF9h; } should be RegisterSF PCL { Description = "PCL",""; Address = FF9h; } You can correct this yourself. This problem also applies to some other PIC18 devices, I am currently fixing these issues. Regards Dave
  14. teunizz, Looks like have a comma immeddiately following the pragam name. It makes the compiler think "DATA," is the pragma name. #pragma DATA, 0x2100, "string" should be #pragma DATA 0x2100, "string" Regards Dave
  15. DoubleA, Basically this is nothing to worry about This warning will currently always appear when using a rom char* type. Maybe later it will be suppressed. The warning means that when debugging the code in the debugger/simulator, it will not be possible to watch the variable, because its type is not one of the standard ones. Regards Dave
  16. teunizz, You miss the point of the forum. You can post your own solution, so this information can be help other. Regards Dave
  17. rlang, My recommendation is this: This special memory should be declared as GPR in TDF file. If a program uses this memory for USB data, then it should declare an array with a fixed address the covers the require memory areas eg: char usbBuffer1[ 256 ] @ 0x400; char usbBuffer2[ 256 ] @ 0x500; char usbBuffer3[ 256 ] @ 0x600; ...... This will prevent linker from attempting to use these memory areas for memory allocation (as they have been done manually). Sorry for such a delay in replying. Regards Dave
  18. Visit the examples page for a Bootloader written by Ryan Davis using BoostC compiler. Examples Please leave feedback in this topic thread. Regards Dave
  19. stickben, Looks like you have an error on line 1 of your program. maybe and include file that can't be found. Please try building the project under the SourceBoost IDE (not using MPLABs) and let us know how you get on. Regards Dave
  20. amazigh, So have you ever had any sucess at any time? When I try what u are doing, it works for me every time. Maybe its a function of the path you have to MPLABS, and something is different between build and separate compiler and assemble. Regards Dave
  21. amazigh, Thats not good enough, you know you should be at your PC waiting for any replies to your questions !!! If you are using Microship V7.00, then you are in unchartered teritory. Latest version I use is 6.60. Maybe V7.00 is the cause of some problems. When did you upgraded ? Regards Dave
  22. amazigh, When did this start happening ? Please show the complete command line. Press the C button on the tool bar, then copy and paste the output window contents. Regards Dave
  23. FrankGe, SourceBoost has been extensively tested with hyperthreaded processors (I am using a 3GHz one right now) so I don't expect that will be the cause of the problem. On my PC I can turn hyperthreading off in the CMOS setup, maybe you can try this. The processor speed could be a possibility, but its also strange how you see a similar problem on a 2.8GHz processor. I see no such problems on my 3.0GHz intel CPU. On the bad PC, can you lauch the compiler and linker from the command line. The compiler and linker are single threaded applications, so its hard to see what might be causing this problem - maybe something else OS or PC hardware - I can't see why it should. Regards Dave
  24. hlaith, The BoostC or C2C are compilers. The SourceBoost IDE is the editor/development environment, it can be used with either compiler. There is a toolsuite selection menu that allows you to choose which compiler to use. BoostC compiler and C2C are different beasts. Best to stick to C2C compiler, otherwise you may generate code that can't be compiled under it. BoostC has many more features. Compiler licenses options are outline on the download page. Regards Dave
  25. brosher, including "system.h" when using the BoostC compiler will cause the inclusion of the function prototypes for the built functions. This includes some string functions. Regards Dave
×
×
  • Create New...