Jump to content

chedzoy

EstablishedMember
  • Content Count

    31
  • Joined

  • Last visited

Community Reputation

0 Neutral

About chedzoy

  • Rank
    Regular
  1. Hi all, I'm sure someone must have come accross this before, but I cant find it in the forums. I have a project where the source files are spread accross a couple of different directories. It compile fine in sourceboost IDE, but it won't compile as a project in MPLAB. It looks like the problem is that when MPLAB constructs the command to compile the file it does not include the file path. In the MPLAB output below the file valve.c is in the mplab project directory, but utils.c is in a different directory. Executing: "C:\Program Files\SourceBoost\boostc.pic16.exe" valve.c -O1 -W1 -t 16F88 BoostC Optimizing C Compiler Version 6.35 (for PIC16 architecture) http://www.sourceboost.com Copyright© 2004-2006 Pavel Baranov Copyright© 2004-2006 David Hobday Licensed to Christopher Dunning under Single user Pro License for 1 node(s) Limitations: PIC12,PIC16 max code size:Unlimited, max RAM banks:Unlimited valve.c <C:\Program Files\SourceBoost\include\icd2.h> @ 20: MESSAGE: "Including ICD2 declarations (icd2.h)" success Executing: "C:\Program Files\SourceBoost\boostc.pic16.exe" UTILS.C -O1 -W1 -t 16F88 BoostC Optimizing C Compiler Version 6.35 (for PIC16 architecture) http://www.sourceboost.com Copyright© 2004-2006 Pavel Baranov Copyright© 2004-2006 David Hobday Licensed to Christopher Dunning under Single user Pro License for 1 node(s) Limitations: PIC12,PIC16 max code size:Unlimited, max RAM banks:Unlimited UTILS.C FATAL: Unable to open input file: Y:\Active Projects\D1013-Avin Water\Controlled Documents\piccode\Valve Client\UTILS.C Error: preprocessing error failure BUILD FAILED: Wed Apr 12 19:59:04 2006 Is this an mtc file issue? Hope someone vcan help Chris.
  2. An alternative way of solving this problem is to not use interrupts in your bootloader. <{POST_SNAPBACK}> OK. But this is an RS485 multi drop data bus which needs receive timeouts to be generated to reset the receiver state machine. I'm not saying it cant be done without interrupts, but it seems a shame to not be able to use them because of the compiler. Another alternative solution would be to write the whole project in .asm. <{POST_SNAPBACK}> I have a similar project(s). Multiple slave PIC are bootloaded over an RS485 bus via a Master. I cheated - the bootloaders are all written in assembler. I tend to do a lot of high speed comms in my projects and, generally, I cannot tolerate the double jump required to process time and latency critical code. To avoid the double jump issue my bootloaders do not use interrupts. <{POST_SNAPBACK}> Thanks asmallri.. I did managed to make it work with interrupts, but its ugly code. I think I'll will try dropping the interrupts and re-write with polling. It would still be useful to have more control over the context saving. Any chance of a compiler option Pavel? Regards to all Chris.
  3. An alternative way of solving this problem is to not use interrupts in your bootloader. <{POST_SNAPBACK}> OK. But this is an RS485 multi drop data bus which needs receive timeouts to be generated to reset the receiver state machine. I'm not saying it cant be done without interrupts, but it seems a shame to not be able to use them because of the compiler. Another alternative solution would be to write the whole project in .asm.
  4. I just noticed SMU-AIE 'post Oct 24 2005, 08:59 AM' looks like a very similar problem... One 'horrible' way round it was to manually edit the context save and restore in MPLAB to use my own variables. This seems to work as long as I leave in the hacks to skip the client interrupt context save and restore. I hope there is a better way.. Regards Chris.
  5. Hi Pavel, I have written a flash loader program that loads a client program into flash at 0x400. The loading is done over RS232, and I need to use the interrupts for my UART routines. Once the client is loaded I send an RS232 command which causes the code to jump to 0x400 to execute the client. Problem is that the client also uses interrupts, and has its own interrupt routine at 0x404. When the loader is told to run the client it sets a flag in EEPROM. The base interrupt routine (at 0x004) checks this flag and calls the client interrupt if set. The problem is that the two interrupt routines both try to save the context. Also that the variables used base interrupt routine may actually overwrite data used by the client program. At the moment I'm calling the client interrupt handler at 0x40D to skip its context save, and using 'asm return' at the end to skip its context restore. But Im still left with the problem that I have no control over the addresses used by the base interrupt routine for the Int1Context and Int1BContext variables, and they can end up overwritting data used in the client code. So I wanted to write my own context save and then use something like unsigned char my_Int1Context@0x70; unsigned char my_Int1BContext[3]@0x43; to define where its stored. Then I can put the same into the client to reserve these addresses(even though they are not used byu the client). Any ideas welcome regards Chris.
  6. Hi all, Does boostC support the .pat scripts. I need to either turn off the interrupt context save and do it manually, or modify the generated context save code. I'm using pic16F88 Thanks Chris
  7. What needs doing here is limiting the passing by referwnce arguments to non-volatile data type, ie data that is not related to a port or periheral, as these as you point out won't work as expected. Regards Dave <{POST_SNAPBACK}> Or used by interrupts or any other execution thread...
  8. Except it uses upto twice as much memory and how ever much code space memcpy needs. Being able to do.. rs232_msg_t rs232; cmd1_t &cmd1 = (cmd1_t &) rs232.payload; would make it much more efficient. All its doing is overlaying a cmd1_t structure on top of the memory at rs232.payload. At the moment Im doing this by fixing the addresses of the structures in the PIC memory. So t_rs232_message rs232_rxmsg@0x20; #define RS232_RX_PAYLOAD 0x22 t_cmd1 cmd1@RS232_RX_PAYLOAD; t_cmd2 cmd2@RS232_RX_PAYLOAD; t_cmd3 cmd3@RS232_RX_PAYLOAD; Which is fine, except Id rather the compiler looked after where variables are placed in the address map. I may get it wrong !! In hope !! Chris.
  9. Hi Pavel, I see. But its going to catch people out if they use a reference to a hardware register and try and do something to it inside the function. I'm not sure I can see any real advantage in using pass by reference when its done like this (and potential confusion). I guess the compiler could create a new instance of the function for each call that uses a different reference value. The code would get bigger, but it would be more true to the idea. Alternatively just treat the reference as though it were passed as an address pointer. You could use the first approach if the function is defined as inline and the second otherwise. I'm off to continue my quest for casting reference variables on the Enhancements thread now. Thanks and Regards Chris
  10. Any chance of adding this in to the BoostC compiler? //-------------------------------------------------------------------------- This is a cut down example of the kind of thing I would like to do.. The scenario goes like this.. I receive a message on the UART which contains a command byte, followed by a payload of say 32 bytes. My code then wants to interpret the payload part of the message by using the command byte to select the true data type of the payload. If I'm using pointers I would just cast the payload address to the correct type and then access it through the cast pointer. But pointer access is quite bulky on the asm code. So I would like to make a reference variable of the type defined by the command byte to the payload memory. That way when the compiler generates code to access the payload via the reference it generates code that accesses the same data space as the payload, but uses offsets into the data that are defined by the type of the reference. Should be a lot less code hungery. This is an example piece of g++ code which shows what I would like to do. Am I right in thinking this would generate much less code than an equivalent using pointers? #include <stdio.h> #include <stdlib.h> typedef struct _rs232_msg { char payload_type; char payload[32]; } rs232_msg_t; typedef struct _cmd0 { int i; int j; } cmd0_t; typedef struct _cmd1 { char i; char j[20]; } cmd1_t; typedef struct _cmd2 { long i; } cmd2_t; void receive_msg (rs232_msg_t &msg) { // pretend to get a message from UART for (int i = 0; i < 32; i++) msg.payload = i; msg.payload_type = 2; } int main() { rs232_msg_t y; receive_msg(y); switch (y.payload_type) { case 0: { cmd0_t &x = reinterpret_cast<cmd0_t&>(y.payload); // process cmd0 message using x break; } case 1: { cmd1_t &x = reinterpret_cast<cmd1_t&>(y.payload); // process cmd1 message using x break; } case 2: { cmd2_t &x = reinterpret_cast<cmd2_t&>(y.payload); // process cmd2 message using x break; } default: break;// invalid message type... } return 0; }
  11. Hi, Got all excited when I saw pass by reference in 6.11 release. I use a lot of pointer stuff to pass references to structures into functions at the moment, and thought pass by reference would produce much less code. But it looks like the compiler still makes a temporary copy of the variables passed into the functions. Its just that after the function call it copies the temporary variable back to the original. So the code size for the function call gets roughly doubled. Does it have to be like this, or can you generate the code for the function using the actual address of the variable that was passed by reference (so the function acts directly on the variable rather than on a copy). Not complaining though.. Its a great compiler and IDE, and since pass by reference is actually C++ functionality its a useful bonus for us C users.. regards Chris.
  12. Hi all, I'm using my own I2C code on PIC16F88. But the definition of SSPCON2 and its bits seems to be missing from the system header (pic16f88.h). I've copied it from PIC16F874.h into PIC16F88.h for now. And put the extra definition in PIC16F88.TDF Can you put them in for the next release. Thanks Chris.
  13. Hi all, I have a project which has its source broken up accross a few different directories. I would really like to tell BoostC which directory(s) to look in for include files. I think its the same as the -B option for gcc, not sure, it was -I for some other compilers. Maybe I create some usefull libraries and put them in a lib directory, then put the headers for the libraries in an include directory. Then my application source is in its own directory. So how do I set up my project so that I dont have to put absolute paths to the include files. Is there a way to tell BoostC to search additional directories for header files? in hope... Chris.
  14. Found it. It was a typo, although I would have expected the compiler to pick it up. Simple example that causes the error is typedef unsigned char uchar; #define MAX_MESSAGE 32 typedef struct s_rs485_message { uchar msg[MAX_MESSAGE]; uchar len; } rs485_message; rs485_message txmsg; rs485_message rxmsg; void main() { switch (txmsg[0]) { case 0: break; } } I would have expected the compiler to complain about txmsg[0] (array on non array variable). You only get the linker error if you have case 0: If you change it to case 1: you get a compiler error. Strange!! Chris.
  15. Hi, I'm getting this error when building under Boost C (6.03) for 16F88 Internal Error: Var not found id:0x000002CA It compiles OK, but then gives this error on linking. The error seemed to appear after I introduced some typedef struct stuff... typedef unsigned char uchar; #define MAX_MESSAGE 32 typedef struct s_rs485_message { uchar msg[MAX_MESSAGE]; uchar len; } rs485_message; rs485_message txmsg; rs485_message rxmsg; I may have a typo in my code, but since it compiles OK I have no idea where to look. Any clues whats wrong? Thanks Chris.
×
×
  • Create New...