Jump to content

AlexR

EstablishedMember
  • Content Count

    58
  • Joined

  • Last visited

Community Reputation

0 Neutral

About AlexR

  • Rank
    Regular
  1. I just tried to use the new V7.12 Sourceboost but it seems to have no support for C++ and won't even open my old C++ projects. Actually I find that I use C++ as straight out C and never use the C++ features so is there any way to convert my ++ licence to plain C as I feel that I am paying more and actually getting less.
  2. Any idea how to fix this without creating a new lib file for PIC18 that don't have EEADRH? Regards, Pavel I would have thought that was more your job rather than mine but since you ask how about adding the dummy EEADRH definition to all of the appropriate PIC18 header files. That would stop the linker from complaining and the user would not have to waste a day scratching his head wondering why the code doesnt compile.
  3. I see that the problem reported in http://forum.sourceboost.com/index.php?showtopic=5030 has still not been addressed and you still need to declare a dummy "eeadrh" to get the linker to build when using a chip with 255byted of eeprom.
  4. If you leave the optimization boxes un-ticked the program defaults to level 2 optomization, if you tick the boxes it selects level 1. Unfortunatlty MPLAB comes up in the default state with the optimization boxes ticked and hence level 1 optimization but as long as you aware of the problem it's no great inconviniance to un-tick the boxes at the start of each project.
  5. In the "program loop" removing the semicolon between "while(1)" and the left brace "{" should fix it..
  6. Obviously you are a liberty to change the header files in any manner you like but they do follow the Microchip data sheet naming conventions and I would not recomend changing names and definitions adhock. A better way to do this would be to make use of the fact that C is case sensitive and use the following code; #define cout cmcon0.COUT .......... LED = cout;
  7. Take a look at the PIC12F683.h file in the "include" subdiecrory of your Sourceboost installation. You will see that COUT is defined as 6 in the COMCON0 bits section (since it is bit 6 of the cmcon0 register.. To use COUT you have to provide the full register and bit name so in your example you would need to write LED = cmcon0.COUT;
  8. Yep, that fixed it! But it sill is a bug that should addressed since I'm sure that by the time I next use EEprom on a small PIC18 chip I will have forgotten about both the problem and the fix.
  9. The eeprom.h looks fine to me and it does contain the statement #ifdef EEADRH It would seem that something somewhere is telling the linker that EEADRH is infact defined. Just to be on the safe side I have done a complete un-install, deleted all files and directories and did a fresh install of Sourceboost 7.05.1. but the problem still persists!
  10. I am trying to port code that was originally written for a PIC18F2525 chip over to a PIC18F1320 chip. The code worked fine with the original 18F2525 but with the 18F1320 I keep getting a linker error saying : "Error: Failed to resolve external:eeadrh" , even though the PIC18F1320 chip does not have a EEADRH register. In fact from my limited tests, this error seems to occur on all PIC18F chips that have 256 bytes or less of EEprom and hence no EEADRH. Full compiler/linker dialog below; Building... "C:\Program Files\SourceBoost\boostc++_pic18.exe" ow_comms1320.c ow_temp1320.c -t PIC18F1320 -idx 1 -obj Release -d _RELEASE BoostC++ Optimizing C++ Compiler Version 7.05 (for PIC18 architecture) http://www.sourceboost.com Copyright© 2004-2011 Pavel Baranov Copyright© 2004-2011 David Hobday Licensed to ############### under Single user Full License for 1 node(s) Limitations: PIC18 max code size:Unlimited, max RAM banks:Unlimited, Non commercial use only ow_comms1320.c ow_temp1320.c success "C:\Program Files\SourceBoost\boostlink_pic.exe" -idx 1 /ld "C:\Program Files\SourceBoost\lib" libc.pic18.lib Release\ow_comms1320.obj Release\ow_temp1320.obj "C:\Program Files\SourceBoost\Lib\eeprom.pic18.lib" /t PIC18F1320 /d "Release" /p temprature Caution: argument of 'delay_us' calls must have a value of 1 or more Error: Failed to resolve external:eeadrh BoostLink Optimizing Linker Version 7.05 http://www.sourceboost.com Copyright© 2004-2011 Pavel Baranov Copyright© 2004-2011 David Hobday failure error: failed Failed to locate output file 'Release\temprature.hex' Done Failed
  11. Flowcode very well may now compile but does your program work in real life? I ask this because according to the data sheet the 16F1826 chip does not support timers 4 and 6, it only supports timers 0, 1 and 2. The 16F1827 is the chip that has timers 0, 1, 2, 4 and 6.
  12. The statement "#define UART_TX_BUFF_LENGTH 16;" tells the pre-processor that every time it sees the string "UART_TX_BUFF_LENGTH" it should replace it with "16". Then you have the statement "if (UART_TX_BUFF_LENGTH == 1)" which because of your #define get altered by the pre-processor to "if(16 == 1)" this is obviously rubbish and fortunately the compiler recognises it as such. One further point, #define statements do not end with a semi-colon and in all probability the rouge semi-colon at the end of the define statement is causing the "Missing right paren" error. I would imagine that what you probably meant to do was: unsigned char UART_TX_BUFF_LENGTH = 16; volatile char circularFifoUartOutputBuffer [UART_TX_BUFF_LENGTH]; if (UART_TX_BUFF_LENGTH == 1){
  13. Thanks for that Renard, I did get my int's and long,s mixed up. As you point out casing "variable" to long fixes it up so the code should read: int result; int variable; result = (long)variable * 433/1000;
  14. Rather than using floating point arithmetic which eats up PIC resources why not keep it all in integers. The following code works in simulation long int_result = 0; int final_result = 0; int variable; int_result = variable * 433; final_result = int_result/1000; In theory this should also work but for some reason when I step though it in debug mode I get a negative answer; Looks like it could be a bug! long int_result = 0; int variable; int_result = variable * 433/1000;
  15. Take a look at the SourceBoostC documentation (page 73). The function is declared as void delay_us(unsigned char t) Probably in the past the exact value of the delay has not been critical so it all appeared to work. In this case the timing is critical but any value you pass to the delay() function will be truncated to 8 bits so when you pass 500 to the delay_us() function the value it actually sees is 244 which happens to be the lower 8 bits of decimal 500.
×
×
  • Create New...