Jump to content

Jacob Christ

EstablishedMember
  • Content Count

    67
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Jacob Christ

  • Rank
    Regular
  • Birthday 03/21/1971

Profile Information

  • Gender
    Male
  • Location
    Rancho Cucamonga, CA
  1. Have you tried to use parallel compilation that has been added in v7? A 4-core computer can easily compile 5 source files in parallel what will reduce your compile time to couple of minutes. Another option is remote compilation (also introduced in v7) where a powerful remote computer can be set up as a build server. Regards, Pavel Haven't tried, nor did I know they existed... My biggest task before trying to speed things up is getting code to compile correctly... Thanks for the tip. Jacob
  2. We use both compliers regularly. So much so we've have our code set up to compile in both compilers. We do this because both have issues with both compliers but we can usually get one or the other to work. In general I would say that we have more luck with Source Boost but it still it is painfully slow to compile so we always start with hi-tech then fall back to boost when hi-tech is giving us issues. We are even on the verge of adding the C18 complier in the mix so that we have a third option with both boost and hi-tech are crapping out. Comparing the two compilers with the same code
  3. We don't have any firm dates for 7.00 release. It will happen but we have not planned yet when. We have a number of major new fetures we want to add there and we guess that whenever we are done with them or are close than it'll be time for 7.00 release. Regards, Pavel BTW 6.90 release candidate is available to download from SourceBoost web site. I vote for bit fields in structures... This will make it easier to use Microchip example code in BoostC Jacob
  4. I'm using 6.89 and compiling a program that has a global variable defined something like this: char foo[] = { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21 }; function() { unsigned int size; size = sizeof(foo); // returns 0x21, expect 0x22 } If I declare the foo as such: char foo[0x22] = { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x1
  5. Yes please send a project that exhibits the problem you describe to support@sourceboost.com Regards Dave Ah!! Has this problem been fixed??? This has haunted my development for a long time now... BTW, I get around this problem by just adding a few blank lines near the top of the file... Jacob
  6. Just a warning... There are errors in the PIC18F87J50 header file in 6.88... // Corrected Code #define _CONFIG1L 0x00300000 #define _CONFIG1H 0x00300001 #define _CONFIG2L 0x00300002 #define _CONFIG2H 0x00300003 #define _CONFIG3L 0x00300004 #define _CONFIG3H 0x00300005 There maybe more, but I don't have my corrected header file with me at this time. Jacob I'm sorry, I just realized I have 6.87 on this computer not 6.88... Jacob
  7. Just a warning... There are errors in the PIC18F87J50 header file in 6.88... // Corrected Code #define _CONFIG1L 0x00300000 #define _CONFIG1H 0x00300001 #define _CONFIG2L 0x00300002 #define _CONFIG2H 0x00300003 #define _CONFIG3L 0x00300004 #define _CONFIG3H 0x00300005 There maybe more, but I don't have my corrected header file with me at this time. Jacob
  8. Just a warning... There are errors in the PIC18F87J50 header file... I'll send a list of errors found later this week. Jacob
  9. This is how we do it in our bootloader... Jacob Christ www.pontech.com
  10. There shouldn't be any problem using 18.432MHz, it's evenly divisible by 9600 so you should actually have very good results with proper divide by register values. Jacob
  11. Now I am a bit confused. Looking into the datasheets this family is identical to the one I use (regarding flash program memory) with the only difference is that the minimum writing block is 32 bytes vs. 64. The relevant chapter is identical almost word by word and the asm examples that are provided are identical and show a read-modify-erase-write-program sequence. Therefore I do not understand how you can get away without the erasing procedure. Do you use your bootloader on chips where the program area is known to be blank? After programming once you get arbitrary bit combinations that may r
  12. BoostC does this as well trough its -d command line argument (take a look at compiler command line chapter in BoostC help). We also like the idea to have pre/post build scripts launched from IDE. I look at this and will try to have it done by the next release. Post- and pre-build steps are now implemented in our working ide copy and will be available in the next release. It will work like this: when build command is issues IDE first looks in the project directory for a file called prebuild.bat and if found executes it. At the end of a successful build IDE looks in the project directory fo
  13. We are using this with the PIC18F4520 and 18F4620 as well as others (with slight modifications to block size). The PIC does not need an erase, but you can only make ones to zeros (i.e. blank is all ones). Jacob
  14. I'm not using the same PIC but my loop looks like this: // read data into buffer, modify it then write it back. for( i = 0; i < 32; i++ ){ asm tblrd* tablat &= data[i]; asm tblwt*+ } asm tblrd*- We do a read modify write, then back up one byte at the end of the loop with the "asm tblrd*-" instruction before issuing a write. If you don't backup you go into the next block and write to your data to the wrong block. Jacob
  15. Along this line of thoughts, the Metrowerks compiler I work with for the Motorola DSP568xx has a nice feature of doing a -D on the command line that allows passing a #define at compile time. This would have also worked for passing in a string that I want compiled in that changes due to version control commits. Jacob
×
×
  • Create New...