Jump to content

AlexR

EstablishedMember
  • Content Count

    58
  • Joined

  • Last visited

Everything posted by AlexR

  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 PIC18
  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 y
  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.
  16. What exactly do you mean "it gets stuck"? Stuck in compilation or stuck in execution? In any case the problem is probably with the line prior to the "dq_dir=1;". All the library delay routines in SourceBoostC take a character as the delay parameter so the maximum valid delay value you can pass to the delay_us() (or delay_anything() for that matter) is 255 or 0xFF. If you want to have a 500uSec dealy you must use "delay_10us(50);" The same applies to the last line of code in your post, change the delay_us(400); to delay_10us(40);
  17. If the response to this thread is any indication I would say its not coming any time in the foreseeable future. It would however be a nice feature to have., if nothing else it would bring SourceBoostC closer to ANSI/ISO C compatibility.
  18. Ideally they would be listed by function. Local variables do show up in the MPLAB IDE but variables with the same names just get listed multiple times with indication of which function they refer to. This is a bit inconvenient but better than the present situation in SourceBoost IDE where they don't show up at all.
  19. I don't know whether this is a bug or simply an oversight but why don't local variables show up in the browse window? Global variables get listed but not local ones.
  20. No difference at all. The sleep() function is located in boostc.h and it runs the following code; inline void sleep( void ) { asm sleep }
  21. That patch fixed the problem and now it all now works as expected. Thanks for the prompt response.
  22. Same problem occurring here. Every time I click on a .c file the IDE brings up notepad. What is even more annoying is it brings up notepad when ever I click on any item in the browse window thus making the browse window virtually unusable.
  23. Dave, The problem is very repeatable. As I said above it seems more of an issue with the compiler being slow to get going rather than slow compilation. Once the compiler gets going it looks just as fast as previous versions but it does seem to hang for several seconds at the start of each file that it compiles. The figures you quote look about right if you are compiling only 1 source file. If you are compiling multiple source files then you get that extra delay between each of the files. Anyhow I've attached my test project so you can have a play. TestCode.zip
  24. I'm running win2k on a machine with 4Gbyte of RAM and a dual core Intel processor (can't remember speed off hand) but the point is that slow compile is only with V6.97RC3. It was fine with RC1 and the various beta releases of V6.97. The project I'm using as a test consists of 4 sources files that are compiled and linked. As far as I can see the slow compile time is largely caused by the a long delay at the start of each compile. It seems to hang for several seconds before starting to compiling each file.
  25. I trust there will be more release candidates before the final version of V6.97 because the new BoostC V6.97RC3 is very slow. A project that takes 20 seconds to compile with V6.96 takes 40 seconds (exactly double the time) to compile in V6.97RC3.
×
×
  • Create New...