Jump to content

danmc77

EstablishedMember
  • Content Count

    114
  • Joined

  • Last visited

Everything posted by danmc77

  1. I discovered that searching on "Efficient C Code" will produce some good info: "Efficient C Code for 8-bit Microcontrollers" http://www.netrino.com/node/141 "Efficient C Code for Eight-Bit MCUs" http://coe.uncc.edu/~jmconrad/ECGR4101Comm...s%20f-jones.pdf http://www.atmel.com/dyn/resources/prod_do...nts/doc1497.pdf http://www.freescale.com/files/microcontro...note/AN2093.pdf
  2. Hi, I've been poking around on the web and have found that there is a great lack of info available with general programming guidelines for optimizing for small code size. How do you optimize your code to conserve precious microcontroller resources? I have only found one site that offers any advise: http://in4k.untergrund.net/index.php?title...e_for_4kdemos... Thanks, Dan
  3. Degs, Use this one: boost_c.pic18.exe For the linker, use this one: boostlink_pic.exe Regards, --Dan
  4. For the command line like yours 'C:\Sourceboost\boostc_pic18.exe" CPU.c -O1 -W1 -t 18F4550 -I wireless' where input file is specified without path compiler will look for it in the current directory. Apparently MPLAB sets the current directory to C:\Docs\Controller\Software\Project. Not sure how to change this. Regards, Pavel Then I am correct in saying that the issue is with MPLAB. So it seems that my only solution is to place all of my files in one project directory, which is how I've been working. It would just be a bit cleaner if things could be a little more organized. I would like to be able to switch over to use the Sourceboost IDE, but then how do I program my devices with the ICSP port?
  5. I don't know if you're still looking for an answer to this, but you can define your value with a 1, and then use #ifdef in the code to set a global variable accordingly, depending upon what you've defined with the -d option.
  6. It's so much easier than what you're doing here. First install MPLAB. Then install Sourceboost and hit the integrate button. That's it. The Integrate button is kind of in an odd place, in the upper right corner.
  7. Pavel? Dave? Can you comment on this? How do I get BoostC to handle source files that are in other directories than the project directory with MPLAB? I understand that MPLAB is not your product, but given that the Sourceboost IDE can't work with the ICD port, I'm forced to use MPLAB. Here's an example build: This time I reorganized the project as follows: C:\Docs\Controller\Software\Project\CPU C:\Docs\Controller\Software\Project\Wireless "Project" is the project directory. Source files in MPLAB are set to: CPU\CPU.c Wireless\Wireless.c I add -I Wireless to the command line for the project. As seen below, when I build, BoostC is unable to recurse down into the CPU directory to find CPU.c. Or is it that MPLAB fails to pass the full path down? I've posted on the Microchip IDE forum and nobody there seems to have this issue. ---------------------------------------------------------------------------------------------------------- Clean: Deleting intermediary and output files. Clean: Done. __________MPLAB failing to send down the full path? VVVV Executing: "C:\Sourceboost\boostc_pic18.exe" CPU.c -O1 -W1 -t 18F4550 -I wireless BoostC Optimizing C Compiler Version 6.96 (for PIC18 architecture) http://www.sourceboost.com Copyright© 2004-2009 Pavel Baranov Copyright© 2004-2009 David Hobday Licensed to Dan McFarland under Single user Full License for 2 node(s) Limitations: PIC18 max code size:Unlimited, max RAM banks:Unlimited, Non commercial use only CPU.c FATAL: Unable to open input file: C:\Docs\Controller\Software\Project\CPU.c Error: preprocessing error failure BUILD FAILED: Sat May 08 07:13:13 2010 Thanks! Dan
  8. OK, I found that I can get to wireless.h if I add this command line option for the project: -I ..\wireless But now it can't reach wireless.c, even if I add the same command line option for this file. Even though the MPLAB IDE project window shows wireless.c in the wireless directory, when BoostC tries to compile, it tries to grab it from the CPU directory.
  9. Hi, I have a project organized like this: c:\project\cpu cpu.c cpu.h c:\project\UI ui.c ui.h c:\project\wireless wireless.c wireless.h The CPU and UI are two separate projects that run on two separate PCBs, but they both share the same wireless circuitry, so they both need access to the wireless.c and wireless.h files. The problem I'm having is that when I build the CPU or the UI, I can't get BoostC to open wireless.h. I'm building in MPLAB v8.46, and in the IDE I have the include search path set to point to the directory that contains wireless.h. I've tried specifying the explicit path to wireless.h in cpu.c, but that doesn't work either. Any ideas? Thanks! Dan
  10. OK, by the lack of comments I can assume that this is not a common issue, I'm just plain crazy, or everybody else here writes code and develops hardware that never has any bugs so the debugger's never needed.
  11. So nobody has experienced anything like this? I'm the only one? I feel so special. Anybody?
  12. Hi, My project uses an 18F4550 PIC. Whenever I try to run in debug mode with an ICD2 or a Pickit2, the target runs incredibly slow. I've used different targets and different programmers and the result is always the same, to the point where it's just impossible to use the debugger. I have formerly debugged with an 18F4431 with no problem. Anybody know of a setting somewhere that could cause this? I'm programming and running with MPLAB and the lastest version of BoostC. Thanks, Dan
  13. Tim, Thanks a lot. This will provide a great start. Dan
  14. Can anybody say anything about this one wire bus library? Dave, Pavel? If it's there, somebody must know something. Thanks, Dan
  15. Hi, I just discovered the one wire bus library in the BoostC PDF. Has anybody made use of this? This would be super helpful as I work to pass data from one pic to another. I only have one pin available, so I can't use SPI or I2C. Thanks!! Dan
  16. Sudhi, For the high priority interrupt, your ISR is the function "interrupt();" and the low priority ISR is "interrupt_low();", as you stated. Just put your code in those functions and sourceboost will take care of the rest. You don't need to worry about interrupt vector addresses or anything. It's almost too easy. Inside the ISR, you'll need to check the interrupt flags to see what created the interrupt. Be careful to keep the ISR code very short and be careful of using non-reentrant code inside the ISR. For example, an integer division builds to a sizeable chunk of asm code and if you are using this in your main body as well as the ISR, you could have problems. If the ISR interrupts your division in the main body and then you do another division in the ISR, the second one will clobber the first one and you get garbage for the first one. So you either avoid doing this, or disable the interrupt around the division in your main body. I know, because I did this and it gave me fits figuring it out. Have fun, Dan
  17. I couldn't find anything. But SPI is so simple with the device itself that you really don't need it. It's easier than I2C. Maybe some other users could provide links to threads in this forum or elsewhere to sample code. The search feature is useless for this (and many other things) because of the 4 letter minimum search terms. I did a bit of research and found some info that suggested that SPI and I2C are very similar, to the extent that an SPI device can actually reside on an I2C bus, as long as you provide an additional enable line. A little more work needs to be done to confirm this. I have been surprised at the lack of coverage in the BoostC documentation for this, and the 4 character site limitation for searching is a bit silly. If Pavel or Dave could comment, that would good. Dan
  18. Hi, Many of the PICs support I2C and SPI serial interfaces. I see that BoostC has I2C functions, but I don't see anything relating to SPI. Is there any support for SPI? Thanks, Dan
  19. danmc77

    Broken Enum?

    Pavel, Reynard, Thank you so much for correcting my foolishness. Humbly, Dan
  20. danmc77

    Broken Enum?

    Guys, Take a look at this very simple program: --------------------------------------------------------------------- #include <system.h> #include <icd2.h> #include <string.h> #include <float.h> enum Bypass_PosN {BYP_OFF,BYP_OPEN,BYP_CLOSE}; void main() { Bypass_PosN=BYP_OFF; } --------------------------------------------------------------------- When I try to build this, I get this: C:\debug\test.c(9): error: general error C:\debug\test.c(9): error: failure Now, if I change Bypass_PosN in the enum declaration to something else like, Bypass_Pos, then I get this: C:\debug\test.c(10:2): error: unknown identifier 'Bypass_PosN' C:\debug\test.c(10:2): error: invalid operand 'Bypass_PosN' C:\debug\test.c(10:13): error: failed to generate expression Something is not right here. I'm using PIC18 rev 6.89. Please take a look. Thanks, Dan
  21. Compiler has been changed to report "error: unexpected constant" for this kind of errors. This change will be available in the next release. Regards, Pavel Excellent.
  22. It's not a bug. Your code looks like this: enum PHASE {A,B,C,D}; But C & D are already defined. So, after the preprocessor is run, the code the compiler gets looks like this: enum PHASE {A,B,0x00000000,0x00000005}; These values are taken from the PIC18F4550 target header file. Since you are trying to enumerate a number instead of a variable, the compiler thinks that you forgot to close your brace and end the command. This code results in the same error: [code]enum PHASE {A,B unsigned char a = 0; So, the compiler just thinks you made a typo. - Bill OK, so then should the preprocessor complain that C and D are already defined?
  23. Reynard, Oh, BTW, I am running version 6.89 with an 18F4550 pic. "C and D, are already defined " Yea, that's what I figured, so I tried changing to something more unique. But it doesn't make sense for the compiler to report that there's a missing bracket, and a missing semicolon. Looks like a bug. I'm still wondering why I get the error on the first bracket in main if I change the enum name. Dan
  24. Hey, I have a simple problem with enums: enum PHASE {A,B,C,D}; This line reports these compiler errors: error: missing right brace error: missing semicolon error: failure If I change the line to this: enum PHASE {AF,BA,CE,DB}; This will not produce an error. Here's another strange thing: If I use this line: enum Byp_Pos {BYP_OFF,BYP_OPEN,BYP_CLOSE}; It compiles as expected. If I change the line to this: enum Bypass_Position {BYP_OFF,BYP_OPEN,BYP_CLOSE}; Then I get an error on the first bracket in main: error: general error error: failure What's with enums? I'd like to use enums, but it seems that they only work under rare conditions? Dan
×
×
  • Create New...