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 base: Boost Issues: #1 Our projects take about 10-15 minutes to complier and link (most of the time is in the link step) with Boost C (ouch), 30-40 seconds with HiTech from a clean project. #2 Boost C has some flaky behavior with preprocessors and they don't always work (especially ifdef's)... I'm sure if we sent Boost guys the code that failed they would fix it. #3 There are at least two bugs (that may actually be the same bug) that we haven't been able to put our fingers on (that is to get a project to the Boost guys to fix). #4 Does not support bit fields (unless added in V7), sample code from Microchip almost always uses bit fields. #5 Some memory leaks that when working with USB #6 There are some bugs like: unsigned char get_operation(void) { return ~((portb >> 1) | 0x80); // This code will not work correctly... } // But this will... I've mentioned this before to boost guys, but I think this is the first code I've posted.. unsigned char get_operation(void) { unsigned char operation; operation = portb; operation = operation >> 1; operation = operation | 0x80; operation = ~operation; return operation; } HiTech Issues: #1 Some problems comparing 32-bit variables #2 Some memory leaks that when working with USB The boost list is longer I know, but we find the issues are easier to work around and the boost casm file is easer to read than hi-tech (probably because its not as optimized) so we can usually figure out our own work around to a problem. Regarding the memory leaks we see with USB. When it occurs we usually switch compilers and the problem doesn't show up, so we end up bouncing back and forth between the two, when hi-tech stops working we switch to boost, but as soon as hi-tech starts working again we switch back (since we have plenty of time to test every hi-tech compile while waiting for boost to complete). Both seem to be size of project dependent. HiTech does produce much smaller object files. I'm posting this, since I'm bouncing off the walls trying to get a HiTech problem fixed right now and I submitted an issue a week an a half ago and I'm up late hoping for a response from Hi-Tech, since I'm in the US and they are in Australia and I'm want to get two iterations in on my issue since they are soooo slow to respond even with my $300 per year high priority support. Oh, and C18 is much faster than boost as well... I'm actually on a rampage to get all the bugs out of both compilers, and plan on submitting every bug found over the next few months. If we cannot we are abandoning PIC and will choose a different uC that has better compilers. Jacob
  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, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21 }; function() { unsigned int size; size = sizeof(foo); // returns 0x22 } If I declare the foo as such: char foo[0x21] = { 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 }; The compiler complains: code.h(229:4): error: too many initializers Looking at the casm file, all the values get initialized and if I hard code 0x22 instead of using sizeof my program works as expected and the foo[21]st element is read properly. Jacob Christ
  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 require a switch from 0 to 1 on the next program load. GB We are not actually using the read modify write capability, but if we needed to we could. We might as well just be writing only. When our device boots we issue an erase command to blank the chip then upload the program. Jacob
  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 for a file called postbuild.bat and if found executes it. It's up to a developer to create those files. If such file don't exist build goes how it used to do. Regards, Pavel Drooling in anticipation. Jacob
  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...