Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Reynard

  1. Hi Kenn, Here are a couple of alternatives that you could use: enum MYFRUITS {APPLE,PEAR,APRICOT,BANANA}; #define FRUITY PEAR #define FRUIT 'a' . . . #if FRUIY == PEAR nop(); #endif #if FRUIT == 'a' nop(); #endif You don't have to use a number but a 'constant'. Cheers Reynard
  2. Hi Brian, I tested it using the SourceBoost IDE simulator and PIC18F2520. the variable fred came out with the vaue of 5. Maybe it depends on the PIC type. I got a warning when assigning a constant to a rom pointer and the compiler produces some code to assign the value to the pointer but 'ptr' is never used in fetching the data. It was worth a shot if nothing else. If you look at the assembler code produced by my example you can see how BoostC gets the data using the table read method, assuming a PIC that support it. Cheers Reynard
  3. Hi Brian, BoostC may not be all that good yet at handling rom pointers. (V7.0 Yepee ) You could try something like this for now. #define MYROMDATA 0x0200 #pragma DATA MYROMDATA,1,2,3,4,5,6,7,8,9 rom char *ptr; char x = 4; ptr = MYROMDATA; fred = ptr[x]; Access the rom data like an array rather than use a pointer. Doesn't look like good C but may be all you have for the time being unless you go the assembler route. This will use the __rom_get call to get the data. Cheers Reynard
  4. Hi Tom, The simulator will work will work with 12F devices. I have used it with a 12F629 chip. The plug-in's though probable do not support the GPIO so will not work. The simulator will not run at the PIC speed but your PC speed so time interval measurement is not possible. There is a tick count but it tells you little. Cheers Reynard
  5. It is surprising just how many way you can put stuff into rom and still get the same result. rom char *Font1 = {1,2,3,4,5,6,7,8,9,11}; 027C 0E00 MOVLW 0x00 027E 6E2F MOVWF gbl_Font1 rom char Font2[] = {1,2,3,4,5,6,7,8,9,12}; 0280 0E01 MOVLW 0x01 0282 6E05 MOVWF gbl_Font2 rom char *Font3[] = {1,2,3,4,5,6,7,8,9,13}; 0284 0E02 MOVLW 0x02 0286 6E0F MOVWF gbl_Font3 rom char Font4[4] = {1,2,3,4,5,6,7,8,9,14}; 0288 0E03 MOVLW 0x03 028A 6E25 MOVWF gbl_Font4 rom char Font5[]@0x200 = {1,2,3,4,5,6,7,8,9,15}; 028C 0E04 MOVLW 0x04 028E 0102 MOVLB 0x02 0290 6F
  6. If any operand is a floating point number you have to use the FP library. iDecimal=(number - iDigit) * 10; // Get The Decimal Digit In this line 'number' is a FP so 'iDigit' would also need to be a FP. The *10 could be done as a FP or the difference converted to int32 then interger multiply (*10). There is no implicit conversion of int32 to float. This is a bit of a bummer with this compiler, but as we are all saying, maybe version 7.0 will solve all this. Fingers crossed. Cheers Reynard
  7. Hi Rye, It is sort of shown on page 45 of the C manual. Basically you are creating an alias for a bit address. adc_go is the same as ADCON0.GO Where you would say: ADCON0.GO = true; you would say something that is clearer: adc_go = true; Cheers Reynard
  8. You have to use the floating point libary for ALL floating point operations. if (float32_gt(number, 99.9)) { } etc. Cheers Reynard
  9. BoostC does not support floating point data types directly. To use floating point numbers you MUST use the floating point library that comes with BoostC. Cheers Reynard
  10. It looks OK but what happens if there are no digits in the string. This may not occur in reallity on your scale. Here is an alternative idea: int weight(void) { char *weight_ptr; int weight_int; unsigned char j; weight_ptr = rx_buffer; for (j = strlen(rx_buffer); j != 0; --j) { if (isdigit(*weight_ptr)) { return strtoi(weight_ptr, &weight_ptr, 10); } ++weight_ptr; } return -1; } I have made the return value signed to return an error value of -1 if nothing found. Also you don't want to scan the complete buffer if the string contains less characters or you may detect di
  11. Ah Yes, the classic RS-232 cable twist trick. Catches a few out that one. I am extending a long boot across the pond. NORAD won't see it coming. Cheers Reynard
  12. You would have to start on a numeric digit. You could scan the buffer using isanum or something until you find a number or go straight there is it is a fixed offset. myInt = strtoi(&myBuffer[4], &myBuf, 10); myBuf is a return pointer value. Cheers Reynard
  13. atoi as it says is a macro for strtoi. Use strtoi if you want to continue parsing your string after the numeric convertion. char myBuffer = "1234ABCD" unsigned int myInt; char *myBuf; myInt = strtoi(myBuffer, &myBuf, 10); myInt will contain 1234 *myBuf will point to "ABCD" The radix is 10 in this example therefore convertion will stop at any non-numeric char (0-9) or end of string. Cheers Reynard Why can I never get the spelling of conversion correct. Doh!
  14. The RS-232 does not require termination. It is the RS-485 that should have it as it is a differential transmission line. There is not more assistance I can give you. You must understand your hardware and how it operates. Good Luck Cheers Reynard
  15. Hi Sudhi, Never assume the resistors are there. The manufacturer of the converter box does not know how you will be implimenting your transmission line, star, daisy chain, length of stubs etc. Are you allowing enough turnaround time for all devices to switch transmit to receive. Cheers Reynard
  16. Hi Sudhi, I do not have the same setup as you do. I am using RS-232 and no ICD. How have you terminated the RS-485 line ? You need to protect against false start bit detection when all your devices are in listen mode. I usually connect a 330 ohm between the + signal and Vcc and a 330 ohm between the - signal an 0V. At the end of my trasmission line (other end from the master) I connect a terminator which matches the cable inpedence, usually around 120 ohm. Cheers Reynard
  17. I must have speed read over the bit where you change from 4 to 8MHz. At least with the 11.0592MHz you will know the baud is exact. I have half a dozen crystals here if you were not so far away. We await the results. Cheers Reynard
  18. Hi Sudhi, Your code appears to work. You may want to set portc = 0 at start up so that the RS-485 is OFF otherwise you won't be receiving much until you do an initial transmit. Cheers Reynard
  19. The 5% is over the temp range -40 to +85. They are calibrated at 25 and it is unlikely you will be operating very far from this temp. I think the factory freq will be 1% or better. I have not found an internal osc that far out of whack. Cheers Reynard
  20. Hi Sudhi, In your interrupt routine you have extern int rxIndex = 6; which is past the end of your buffer, assuming this superceeds the assignment in main.c Cheers Reynard
  21. Have you tried BRGH = 1 which will give you a much smaller error (0.16% at 4MHz). Get a copy of the PIC Baud Rate Calculator from the site above. Cheers Reynard
  22. How about y = (rand() % 19) + 1; rand returns a short (unsigned int). Cheers Reynard
  23. Here is something you will like. http://www.lvr.com/serport.htm A program called YAT (Yet Another Terminal) Cheers Reynard
  24. Try passing a pointer to the string array rather than the array itself. print_char("Hello World"); ... //---------Prints unsigned char to LCD--------- void print_char(unsigned char *char_2_print) { unsigned char j; portb = 0x80;//place cursor on the 1st row LCD_instruct(); while ((j = *char_2_print++) != '\0') { portb = j; LCD_write(); } } You could pass the char straight to portb instead of using j. Cheers Reynard ps. We have 20 ounce pints over here so will cost you more.
  25. Can't say if this will cure your problem. Your end of buffer check was certainly not correct. I would probably store a NULL in the buffer upon receiving the CR that was you know how many characters you have received by using strlen(), assuming you are not sending any NULLs that is. Cheers Reynard
  • Create New...