Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Dave

  1. trajkik, Only a limited version of ROM data made its way into this release. Only strings can be stored in ROM. Try the following code: #include <system.h> rom char* text = "Test string"; void main() { char c; int x; c = text[ x ]; } Without the line c = text[ x ]; the function that provides access to the data in not in the call tree and is therefore excluded from the output code - thats why you cant find it. Regards Dave
  2. Hollie, From what you say here it looks like you don't understand the volatile keyword, actually I think only a few people do. When a variable is declared as volatile it tells the compiler that something external to the current code can change the variables value, or is reading the variables value. This means the compiler may need to generate different code for these variables compared to variables that are declared as non volatile. When using the PIC all the hardware peripherals that have special function registers and change them or read them. General Purpose registers are only changed by your program execution, and hence are normally not declared as volatile. Without volatile the compiler could cache the value of a register and never read the actual register again. With a volatile declaration the compiler know that it must read or write the register every time it is reference. The compiler also is more careful what it does with voltaile declared variables: Example 1 non volatile declared bit: bsf PORTB, 0 btfss turnItOn, 0 bcf PORTB, 0 Example 2 volatile declared bit: btfss turnItOn, 0 goto lab1 bsf PORTB, 0 goto lab2 lab1: bcf PORTB, 0 lab2 Both example 1 and 2 turn on RB0 when turnItOn bit 0 is set. Q) Whats the difference then ? A) The first example momentarily turns off RB0 before turning it on, creating a blip on the actual port. The second example either turn RB0 zero on or off, it never does both in a single pass. Volatile is quite tricky to understand. Hope this help. Regards Dave
  3. hlaith, The protection system can't be fooled. I don't know of anything you can do. There is no student single user license option for the C2C compiler Consider switching to the BoostC compiler, it is currently in alpha release and free. And ultimately in the final release, there will be a free version (but with some limitations). Regards Dave
  4. Laith, There is no upgrade path from Matrix Multimedia sourceboost V5.3 to the latest sourceboost version, without buying a new license key Once the new version is installed it requires a new key. The protection on the program is such that you then CAN'T GO BACK to the old version with the old key. The only way to recover from this situation is to by a new license key for the latest version *** So any Matrix Multimedia SourceBoost license holders should beware of this, don't install the latest version unless you are going to buy a license. Regards Dave
  5. Guys, Looks like this one is an IDE bug. BoostC compiler and linker generate correct code When debugging IDE displays correct overal register value When debugging IDE incorrectly displays bit values if unamed bits exist in TDF file Regards Dave
  6. Manolo, What you need todo is put a link on your web site to www.sourceboost.com. Then send a mail to support@sourceboost.com with your sites URL (so it can be verified) and request a plugin license. How this helps Regards Dave
  7. Smache, Good one I'm suprise no one else has noticed this before now. Now fixed. Available in the next release. Regards Dave
  8. rlang, Unless this memory is memory that linker should use as general purpose memory, ie can be used for allocation of variables, then it needs to be declared as special function registers: //USB RAM RegisterSF[ 100h ] { // block of memory reserved for use with USB Description = "USB RAM",""; Address = 400h; } etc Regards Dave
  9. Hollie, This function is automatic. Linker looks for the appropriate memory. But there was a little bug in there - Now fixed Also it highlighten another problem, the TDF file (target descriptor files) are incorrect for 16F83 and 16F84. They describe the general purpose memory as only being mapped into the first two banks, so this also causes linker to fail to find common memory. RegisterGP[ 60h ] { // block of general purpose memory Description = "General Purpose Register",""; Address = 020h; } and RegisterGP[ 60h ] { // block of general purpose memory Description = "General Purpose Register",""; Address = 0A0h; } should be RegisterGP[ 60h ] { // block of general purpose memory Description = "General Purpose Register",""; Address = 020h, 120h; } and RegisterGP[ 60h ] { // block of general purpose memory Description = "General Purpose Register",""; Address = 0A0h, 1A0; } Regards Dave
  10. Hollie, Some bootloaders do load high ( I don't know which ones). Also the plan this that you will be able to specified the first location used by code, thereby shifting everything up in memory, allowing a boot loader to be slipped in. Hopefully this will be in before the next release Regards Dave
  11. rlang, The PIC18 simulator is currently only an instruction core simulator at the moment, so hardware like i/o ports and timers etc will not work Regards Dave
  12. Hollie, Something else to consider, when you used #pragma DATA it currently doesn't reserve the memory. If it clashes with code place ment you will get a warning. Program memory is allocated from the bottom up, so make sure that you put your code high in memory. Regards Dave
  13. hollie, Currently in BoostC the nearest equivalent is #pragma DATA. Unfortunately this does mean that you will have to enter the opcodes directy Regards Dave
  14. thiemann, I have had a look at this one. Quite right there is a problem here - looks like compiler is generating wrong size for this new data type - so I'm in the clear on this as I only work on linker, its a little job for Pavel Regards Dave
  15. JensEP, I don't know what you did with you last post, but if I cut and paste the code it all comes out on one line ??? I used the code from your first post to find the problem. The problem is that code from library files is not included in the assembly window, so the code cant be found when the execution stops there. Please note: The code execution is perfectly correct, its just the corresponding code lines can't be found. This now fixed and will in the BoostC 1.8 Alpha release. Thanks for your feedback Regards Dave
  16. Joe, Sometimes I have more features than I know what to do with !!! Regards Dave
  17. JensEP, Please specify the target device for this code to help us find the problem. Regards Dave
  18. Mike, Its a mistake in the header file for the PIC18F4620. locate the PIC18F4620.tdf file, its in the config folder. Open the file in a text editor, and make the following change. RegisterSF PROD { Description = "PROD",""; Address = FF3h; } should be: RegisterSF PRODL { Description = "PRODL",""; Address = FF3h; } Regards Dave
  19. rlang, Theres no special reason, its just a mistake It was meant to be the same. Regards Dave
  20. Volker, Sounds like a memory allocation type issue. Which compiler are you using C2C or the BoostC ? I complete program that demonstrates the problem would be useful. Regards Dave
  21. ryeg, Yes you must set the oscillator and other configuration bit appropriately. This is used when the device is programmed. It doesn't changed the code produced by the compiler, except setting the appropriate bits in the configuration word. Regards Dave
  22. ryeg, It doesn't matter whether the processor is using external or internal clock. All we are actually doing here is telling the compiler how long each instruction will take to execute. The compiler can the generate the appropriate loops to generate time delays. Regards Dave
  23. ryeg, I guess you want this: #pragma CLOCK_FREQ 4000000 // tell compiler we are using clock freq of 4MHz Compiler uses this when working out times for delay functions and sofware generated serial communication routines. Regards Dave
  24. rlang, I would recommend that you start using Sourceboost version 1.7. Anyway it looks like a compiler issue. Work around for now is to put brackets around the expression in square brackets. buffer[1] = table[vector & 0x07]; change to buffer[1] = table[(vector & 0x07)]; Regards Dave
  25. Don, Its not fooling the debugger/simulator at all. Its specifying initialisation data for the EEPROM, this works with the simulator or the actual device. For example if you want to store a constant string in EEPROM and program it in there when you program the chip: #pragma DATA 0x2100, "string to store in EEPROM" This gets programmed into EEPROM when you program the PIC. Nothing is done when the code actually runs. Hope that makes it clear. Regards Dave
  • Create New...