Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About animeranger

  • Rank
  1. A different, more "C-like" approach is to reference the function in some way. The most painless way I can think of besides calling the function is to assign it to a function pointer. #include <system.h> void removed (void) { // This function is optimized out } void main() { for (;;) { } } #include <system.h> void removed (void) { // This function is no longer optimized out } void main() { void (*funcptr)(void); funcptr = removed; for (;;) { } } This method burns a byte or two of RAM and ROM, but you won't have to worry where your code lands.
  2. Have you included "float.pic16.lib" from the SourceBoost install directory to your project? I believe it is in the "Lib" directory. By default, this means that you can find it under "C:\Program Files\SourceBoost\Lib". You still need to add #include <float.h> to the source file even after you add the float.pic16.lib file to you project. To add the library to your project, read the help files in MPLAB. However, just as a recommendation, you may want to find an alternative to using floats if you are a beginning programmer. I don't know about BoostC++, but in BoostC usin
  3. Those are the floating point math libraries. Documentation for their functions can be found in FloatMath.pdf in the install directory of SourceBoost. - Bill
  4. What I was referring to is similar, but based on projects rather than snippets. It's common in the corporate world when developing large projects, especially if you're working with .NET, to create libraries for commonly used classes. (I'm talking C++ now.) So, you would create a solution file, which is just a collection of projects. Take this for example: Game.sol | --- Monsters.proj | | | --- monsters.cpp | --- monsters.h | --- ...etc... | --- GameGUI.proj | --- ...more files... If I'm making the Monsters.proj, which will be compiled to a DLL, and my
  5. One thing I would love to see is the idea of a solution file like in Visual Studio. It's like a project of projects. You probably know what I'm talking about. I make a library file for each component I connect to outside of my microcontrollers so I don't have to remember each one's individual protocols. It would be nice to be able to work on and debug these libraries as I write the main project. Also, it'll let me write unit tests. Thanks for letting us add our input. - Bill
  6. I guess I didn't realize exactly what you were doing. I assumed that the function pointers would fill themselves in at compile time. I don't know why I thought that. I'm glad that you were able to figure it out, though. - Bill
  7. Before I say anything, let me start by saying that I haven't tried this on a PIC. From my experience with C programming, I noticed a few things that might be causing problems: Issue 1 typedef void (*fp) (void); This will cause the function pointer to point to a function that looks like: void samplefunc (void) { // Code here } Since you are casting the output later in the program, I assume you wanted: typedef void * (*fp) (void); That will call something like: void * samplefunc (void) { // Code here } Issue 2 fp high = test1; //some function This will as
  8. In BoostC, registers like INTCON are assigned using lower case (intcon). All upper case (INTCON) is a #define with the register's address. So, change all your variables to be lower case. Also, although I'm not sure how true this is, but I tend not to put "#pragma DATA" statements inside of a header file. If the header is included in multiple source files, it could cause errors since you're initializing that register multiple times. I'm not sure how BoostC handles this, though. - Bill
  9. I had a hard time getting Eclipse to work with larger projects. I tend to write all my code on a USB key on a bunch of different computers. When I finally get to my PC to compile it, Eclipse yells at me. I found an easier time just creating a Makefile. Even if you don't use this approach, it might help you to understand the steps to take. This is the Makefile I use. A few notes first: 1 - This is for a Linux system. 2 - The "make install" directive is to burn the hex file to the chip using the PicKit2. I installed the PicKit2 software from Microchip (there's a Linux version) to
  10. Although the chips you have listed aren't specifically mentioned, chips such as PIC18F25J10 are supported. You may be able to use that as your target and just create variables at the locations of the second EUSART's registers. If you don't want to do that, you can use a supported chip with 2 EUSARTs, such as the PIC18F97J60. I have been using one of these with BoostC, and I haven't have any problems yet. - Bill
  11. I don't believe there is a native math library that has trigonometric functions for BoostC. You can always create a lookup table method similar to this: http://plans.thefrankes.com/tutorials/picmicrotrig/ The author used assembly, but you can use the theory and the lookup table he already generated. I think what he did was a pretty clever idea to overcome the limitation of doing trigonometry on an 8-bit controller. - Bill
  12. That functionality is already in the SourceBoost IDE. If for some reason it stops working for you, try rebuilding your project. That works for me. You may need to comment out the line you're currently working on. - Bill
  13. Don't use the [] syntax when using rom pointers (my example uses a PIC16F648A as the target): rom const unsigned char * patterns = { 2, 7, 5, 3, 1, 13, 1, 15, 3, 8, 2, 11, 0, 1, 0, 9, 2, 5, 7, 0, 6, 14, 4, 6, 4, 3 }; void main ( void ) { unsigned char a; a = patterns[1]; } Memory Usage Report =================== RAM available:256 bytes, used:6 bytes (2.4%), free:250 bytes (97.6%), Heap size:250 bytes, Heap max single alloc:95 bytes ROM available:4096 words, used:55 words (1.4%), free:4041 words (98.6%)
  14. All you have to do to use the hardware SPI module is set up the registers on pages 88 and 89 on the data sheet. Note that most of the bits are read-only and used only for I2C, so those can be ignored. In master mode: That's it. To send/receive data (both are done simultaneously with SPI), simply write the byte you want to send to sspbuf. From there you can either poll SSPIF or enable the respective interrupt. Once SSPIF is set or the interrupt is triggered, read the value in sspbuf to obtain the byte that was received. Slave mode isn't much more complicated, but since you are look
  15. Changing options under "Customize workspace..." only changes what files appear under the output folder of your project in the IDE. To redirect the output of the linker, go to Settings->Options... and under "Extra linker options" and this: -d "F:\" Replace "F:\" with your output directory, but you should probably keep the directory name in quotes. This will put all the linker output into that directory (*.asm, *.casm, *.cof, *.hex, *.lst, *.stat, *.tree). *.obj file will remain where they are since that's a compiler option and not a linker option. Another thing you can do
  • Create New...