Jump to content

SnakeByte

EstablishedMember
  • Content Count

    46
  • Joined

  • Last visited

Everything posted by SnakeByte

  1. Using BoostC 2.2.5 Beta, if I try to compile the following code, I get the errors I would expect to get when something isn't properly defined: #include <system.h> #define TEST randomstring void main() { int someValue = TEST; } defineTest.c(7:18): error: unknown identifier 'randomstring' defineTest.c(7:16): error: failed to initialize variable 'someValue' ... Same goes with normal template usage.. I get the same appropriate error: #include <system.h> #define INT_VALUE randomstring template <class T> T GetMax (T a, T b) { return (a>b)? a : b; }
  2. Just downloaded version 2.2.5 of sourceboost... Noticed a change in the PicDem2plusDemo.c file: #ifndef _PIC16F877 #warning "This code is configured for PIC16F877 or PIC18F452. If you use other targets you may need to reconfigure the project." #endif
  3. Of course it won't compile if you just change the target. The code is configured to use TRISD/PORTD registers and 16F876 doesn't have them. You need to reconfigure the project to use different ports to make it compile for 16F876. Regards, Pavel <{POST_SNAPBACK}> Duh! Thanks Pavel... For some reason I thought it was only using ports A and B... I see that in the code it does show that it's using D... I guess that got changed back when I was having trouble with the v1.10 version of lcd_driver.h #define LCD_ARGS 1, /* Interface type: mode 0 = 8bit, 1 = 4bit(low n
  4. Dave, If you still have that project I e-mailed you, attempt to change the target from a 16F877 to a 16F876. While everything compiles fine with the 877, once I change the target in mplab I get this output: Clean: Deleting intermediary and output files. Clean: Deleted file "Picdem2PlusDemo.OBJ". Clean: Deleted file "C:\\microchip\demo2board\demo2board.HEX". Clean: Done. Executing: "C:\Program Files\SourceBoost\boostc.pic16.exe" Picdem2PlusDemo.c -O1 -W1 -v -t 16F876 BoostC Optimizing C Compiler Version 2.2.2 Beta (for PIC16 architecture) http://www.picant.com/c2c/c.html
  5. Dave, I got the "bad" header from this thread: http://sourceboost.ipbhost.com/index.php?showtopic=956 You provide a temporary link to the file at post #6: http://www.hob68.f2s.com/lcd/lcd13-03-05.zip When I originally checked the two files to see which was newer, all I saw was the date 15'th of november 2004 from the installation version without any versions while the header file located in that zip file showed the 1.10 revision... I see now that you moved the revision information from its' original location down a page and that the version that comes with the installer is versi
  6. Dave, One of the things I forgot to do after re-installing sourceboost was to use your v1.10 version of the lcd_driver.h file... Surprisingly things compiled fine... It's only when I use that newer version that things break as reported before. It looks like the problem with my original post was because I wasn't using the 16F877 as my target (I had the 16F876 set instead), and the problem with my 3rd post was due to that newer header file.
  7. Yes, specify -v in the compiler extra command line options. If you zip up the project and send it to me I'll take a quick look (support@picant.com) Regards Dave <{POST_SNAPBACK}> Dave, I Figured it out. I uninstalled SourceBoost 5.9.5, manually removed the directory, re-installed sourceboost, installed the 2.2.3 update, and everything compiled fine afterwards. I kept a copy of the original sourceboost dir before doing all of this, and will do a file compare to see what's going on... Perhaps the sourceboost 5.9.5 installer isn't overwriting all of the
  8. The finds the default include folder by looking at the path to boostc.exe and adding "\include" to that path. Enviroment variables are not used. Regards Dave <{POST_SNAPBACK}> Dave, When I posted the original message, I was using the original, but then after reading that other thread, I gave your 1.10 a try. While it still doesn't compile, the error messages are a bit more vebose: picdem2plusDemo.c(93,59): error: no template identifier 'LCD_Setup' matches the number of arguments in the call picdem2plusDemo.c(93,2): error: failed to generate expression
  9. Ah, looks like this is related to the lcd_driver.h file problems.
  10. I've followed the instructions detailed in C:\Program Files\SourceBoost\boostc.html as far as boostc integration with mplab and am attempting to compile the sample code picdem2plusdemo.c file but am still having difficulties. When I try to build the source, I'm getting a ton of "error: failed to generate expression" errors, and I'm guessing this is because the compiler doesn't know where to find the needed include files. Even after adding the include and library paths to the "Default search paths and Directories" for the project, and making sure that the lib and the source file is added to t
  11. I've written another perl script.. this time it will take the .inc files and convert them to header files, much like the inc2h app. I've made two additional changes, one is that for every register, I've also put in a define, and the other is that I comment out everything else that isn't relavant to the header files instead of just omitting them. Here's the code. If anyone finds any bugs, please tell me and I'll submit a fix. Also, Pavel, if you think this is useful, perhaps create a link for it on your site somewhere? File: inc2boosth.pl #!/usr/bin/perl -w # Project : inc2boosth
  12. Exactly which standard will the BoostC compiler be based on? I've noticed there are a few standards for C, the latest, I believe, to be C99. One problem I see looming is the size of the built-in types... depending on the platform, an int can be 16 bits, or 32 bits.. same goes with the others... how long is a long? The C9X standard includes some header files that typedef the built-in types to include the bits as part of the name... so instead of int we'd use INT16... There are some other nice additions that I'd like to see included too, if possible. Here's a web site that does a n
  13. I would have edited this into my previous post, but it still needs to be "moderated" so I can't access it. #include <system.h> struct ConvertThis { int arrayOne[15]; int *pArrayTwo[15]; }; void main() { struct ConvertThis ArrayConvertThis[3]; struct ConvertThis *pArrayConvertThis[3]; int i,j; i=0; j=1; pArrayConvertThis[i]->pArrayTwo[j] = &(pArrayConvertThis[i]->arrayOne[j]); (ArrayConvertThis + i)->pArrayTwo[j] = &(ArrayConvertThis[i].arrayOne[j]); } The line: (ArrayConvertThis + i)->pArrayTwo[j] = &(ArrayConvertThis.arrayOne[j]); g
  14. Hey Pavel, This code compiles fine with GCC. #include <system.h> struct ConvertThis { int arrayOne[15]; int *pArrayTwo[15]; }; void main() { struct ConvertThis *pArrayConvertThis[3]; int i,j; i=0; j=1; pArrayConvertThis[i]->pArrayTwo[j] = &(pArrayConvertThis[i]->arrayOne[j]); } The error: compilertest.c(15:37): error: can't convert 'struct struct ConvertThis**' to 'signed int*' If I replace the 'i's and 'j's with their actual values, things compile correctly. Btw, in case you were wondering, these are the flags I use with gcc: -Wall -W -O -W
  15. Hey Dave, Think you could change the stack error too reflect the limitations of the target too? I remember getting a stack error when I was trying to choak the compiler, but I wasn't certain if this was the compiler complaining about its' own stack, or if it was complaining about the stack limits of the target. After looking up the specs of the selected target, I realized that the error was probably due to the max of 8 stacks availiable to the target and NOT the compiler.
  16. Dave, Your answer looks to me to be the best solution to his problem, but my previous explanation was trying to answer why his code didn't work. In the headers, things like "portb" and "trisb" only show up in the headers as: char portb@0x0006; char trisb@0x0086; Since the preprocessor doesn't know about chars, those lines in the headers are skipped over, and the preprocessor is left with names with no associated values. Normally this is just fine.. simply leave the replaced names and let the compiler complain if that name isn't declared. The problem that SvendW ran into was
  17. Current, we can use the @ operator to assign a specific address to a variable without having to use pointers or indirection: char porta@0x5; Any chance of being able to expand it to do something like this? char outPort@&porta; void main() { outPort=0; }
  18. with GCC I can use the -E flag to have it only show me the code after the preprocessor has had its' way with the code. Any chance we can get this added for Boostc?
  19. try adding a "-D portb" to your compiler line and see what happens. Understand that the preprocessor only does text substitution... if porta or portb aren't previously defined through either a compiler directive, or through the source/headers using #define, then your code will look like this: #define PORTA porta (since porta isn't defined, neither will PORTA) #define PORTB portb (since portb isn't defined, neither will PORTB) #define PortOUT PORTB (since PORTB wasn't defined, neither will PortOUT) #if PortOUT == PORTA (this translates to if NOTHING == NOTHING) which m
  20. Hey SvendW, I'm curious.. for the targets where there is only one port, does "portb" even exist in the header for that target?
  21. I think changing this line: if (m/#define\s*([^\s]+)\s*(0x[a-fA-F0-9]{4})$/) to if (m/#define\s*([^\s]+)\s*(0x[a-fA-F0-9]{1,4})$/) should fix that.
  22. The expression "cout << DoSomething(myValue);" doesn't have any destination and doesn't change any variable in the code. That's why compiler optimizes it out. This optimization happens at parsing stage when variables aren't known yet. This is why you don't get any error if cout isn't declared. Regards, Pavel <{POST_SNAPBACK}> Hey Pavel, There's a bug in the example code above, but regardless, DoSomething(myValue); changes a global variable in the above code. The part that was supposed to be optimized out was the part where the return value of DoSomething i
  23. Note the capital C in the second argument for your define: 58 #define i2c_SSPIF i2c_SSPIF_PIR, i2C_SSPIF_BIT --------------------------------------------------^ It's lowercase here: 74 clear_bit(i2c_SSPIF_PIR,i2c_SSPIF_BIT); ----------------------------------^ I wrote some example code with the correct case and it compiles just fine in GCC and Boostc: #define i2c_SSPIF_PIR 2 #define i2c_SSPIF_BIT 1 int clear_bit(int, int); #define i2c_SSPIF i2c_SSPIF_PIR, i2c_SSPIF_BIT void main() { clear_bit(i2c_SSPIF_PIR, i2c_SSPIF_BIT); clear_bit(i2c_SSPIF); } int clear_bit(
  24. Haha, Thanks Dave, that one IS the easiest to read.
  25. I've written a perl script to "correct" all those header files. (This assumes that the actual variable names weren't actually truncated in the original headers): #!/usr/bin/perl -w use strict; my $currentFile; my $currentDir = "c:\\program files\\SourceBoost\\include\\"; opendir(DIR, $currentDir) or die "can't opendir $currentDir: $!"; while (defined($currentFile = readdir(DIR))) { if ($currentFile =~ m/(boostc.h|rand.h|system.h)/i) { next; } if ($currentFile =~ m/\.h$/) { open(DEFINE_IN, "<" . $currentDir . $currentFile) or die "Couldn't read $currentFile: $!"; my @fileBuffer;
×
×
  • Create New...