Jump to content

PICcoder

EstablishedMember
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral

About PICcoder

  • Rank
    Newbrie
  1. Yeah, that was pseudo-code. The actual code that fails is the following: if(loopCnt[curLevel] ){ // do the non-zero process } else{ // do the zero process } where curLevel and loopCnt are defined as follows in the .h file: char curLevel; int loopCnt[5]; With the code shown, the program always does the non-zero process even when loopCnt[curLevel] is zero. If I change the if statement to: if(loopCnt[curLevel] != 0 ){ the program works as expected for all values of loopCnt[curLevel]. This is wi
  2. I had a merry time chasing down a bug that turned out to be the result of different behavior between SourceBoost IDE V 6.92 PIC C compiler and the version I upgraded from. I am not sure what that version was but I can find out if it is important. Here is the code that worked differently in the two versions: boolean isZero(int value) { if(value) { return false }else { return true } } In the prior version of BoostC, the if statement correctly tested for a non-zero value but in 6.92 it did not. I had to change the if statement to: if(value != 0) It
  3. I'm sorry I wasn't clear. I know about hex files and all of that. The problem I am struggling with is how to segment the C program so that the location of the part of the program that I want to overwrite (the interpreter) is known to the program. When the update function is called, it must write the new interpreter code right on top of the old interpreter and overwrite only the interpreter. So all of the functions that make up the interpreter must be in one contiguous block of memory starting at a known fixed address and the entry point of the primary method must always be in a known loca
  4. I have a C program written for a PIC16F88 that receives instructions via a Bluetooth serial device connected to the USART. The instructions it receives are mini programs in a proprietary language and the C program includes an interpreter to process the mini-programs. Now I want to add code that will analyze the first few bytes of the incoming data stream and determine if what follows is a mini-program or a completely new version of the interpreter. If it is a new version of the interpreter, it will call a reloader that will use the data that follows to overwrite only the portion of program m
  5. I am relatively new to BoostC and just converted some code from CC5X. I mostly like BoostC but I some suggestions for improvements. So, here they are: Every resource I know of, including the Microchip datasheets and other compilers, refer to flag within registers by their unqualified name. That is, CREN means the CREN bit in register RCSTA. BoostC, however, requires you to specify a register bit by qualifying it with the lower case register name, such as rcsta.CREN. This is bad for two reasons. First, is not portable between processors. The CREN bit might be a bit in a different in
  6. Ian, I think that the problem you encountered with delay_ms() is due to an overflow. Infact, the manual says: delay_ms() accepts an 8-bit parameter. So, if you put 1000 (0x3E8), the compiler cut it at 0xE8, not too far from 0xFF... Try delay_s(1); or delay_ms(250); delay_ms(250); delay_ms(250); delay_ms(250); Regards. Paolo. Yes, this one bit me too! I wrote the following routine that you can use for any ms value from 1 to 65535. I timed it at 60,000 and it seems to be pretty much on the money. void delayMs(unsigned int ms){ char i; char high =
  7. But the question is, why does it always work when compiled with CC5X and never work when compiled with BootstC? That is that puzzle.
  8. Hi, This is my first post here. I have only been using BoostC for a short time, and just registered today for this forum. So here is the puzzle that I encountered. I have started converting some programs from the CC5X free compiler to BoostC and I had something happen that I do not understand. I had some code that was using the AUSART on the PIC16F88 and it was working fine when compiled with the CC5X. But when I compiled it with minor changes relating to register name usage with BoostC, it failed to properly transmit data on the AUSART. Now, the code was always wrong but it work
×
×
  • Create New...