Jump to content

Pavel

Administrators
  • Content Count

    1,466
  • Joined

  • Last visited

Everything posted by Pavel

  1. This feature will be available in the next release. Regards, Pavel
  2. Right click on the root in MPLAB project tree window, select the menu "Add files...", find and select the file float.pic16.lib (it will be in the lib folder in your SourceBoost installation directory), press OK. This will add the library float.pic16.lib to your project. Regards, Pavel
  3. Wait, BoostC supports recursion??? Could have fooled me. I've never been able to get it to work. What's your trick? I thought the way the stack worked on a PIC made recursion pretty much impossible. Regards, Henry Yes BoostC supports recursive calls. This support is very limited but it does exist. (It took me a while to put yes against this item). Generally speaking functions that have no arguments and don't corrupt their locals can be called recursively: #include <system.h> unsigned int f = 1; unsigned int factorial( unsigned char n ) { if( 1 == n ) return 1; f *= n; return factorial( n - 1 ); } void main() { factorial( 4 ); //after this call global variable 'f' will contain factorial of 4 while( 1 ); } Regards, Pavel
  4. I thought it was partly for this, but mostly because lower case is easier to type! Compiler does not care if variables are in lower case or capitals. Same for constants. It just happens that general convention among almost all C/C++ programmers is that constants (defines) are written in capitals and variables in lover case (it's not just PIC but everywhere in linux, windows, unix etc C/C++ programming). That's why when we created system headers (where all register names and other constants are declared) we choose to write variables in lover case (and these variables are mapped to PIC registers) and defines in capitals. Regards, Pavel
  5. Yes you did everything right. Regards, Pavel
  6. From BoostC help: unsigned short rand( void ) (function) Generates pseudo random number. Declared in rand.h Defined in rand.lib This is the problem. You need to include library with the rand function into your project. Regards, Pavel
  7. There are 2 serial port samples included into the SourceBoost package. One uses RS232 driver and another in an interrupt driven code used in Novo tasks. regards, Pavel
  8. We have most of the features planned to 7.0 pre-release done. Just a few bits are left. Hopefully we'll have the first 7.0 pre-release available in a month. Not sure what you mean. Regards, Pavel
  9. Well, come on then, tell us which facts are wrong! Obviously the table will get out of date as all the products get developed. But it would great to hear which bits you know to be wrong - please tell us. Perhaps we could compile a list and get CCS to update the table. That would be an enormous benefit for SourceBoost. Steve OK here are a few: Data Types, Extended Compiler Control Directives, Recursion, ISR, Can Locate C Data in Non-RAM Memory, Example Programs/Drivers, Automatic Packing of Bit Variables, Dynamic RS232 Library, Ext Device Drivers, Benchmarks. They don't provide code used for their benchmark section so it's impossible to verify their figures. Regards, Pavel
  10. .... and? (these will be in 6.97, right? ) Nothing happened in this area yet. We work on other tasks now. Sorry if that's not what you wanted to hear. Regards, Pavel
  11. This comparison looks good except that some of their facts about BoostC are just plain wrong. Especially performance metrics. And it's not only about BoostC. I wonder how Hi-Tech could end up generating code 2.5 times bigger than CCS. Regards, Pavel
  12. Thanks for the suggestion. It sounds like this registry change should be done by SourceBoost installer. We'll investigate and if looks good add this feature into next SourceBoost release. Regards, Pavel
  13. This functionality was added to the IDE several releases ago. Check the 'Build' sub-chapter in the IDE manual. Regards, Pavel
  14. Pavel

    The Lost Cursor

    Has this been fixed too? No this one is still there. Regards, Pavel
  15. Not sure what you mean by this? Regards Dave The program skip some routine and change arbitrary the values of variables. Hi. Please post some code that illustrates the problem. Regards, Pavel
  16. Free version of SourceBoost IDE is licensed to work on one computer in a network. You you see this message it means that SourceBoost IDE runs on a different computer in the network your computer connects to. Exit SourceBoost IDE on all ather computers in the network and than install it on your computer. Regards, Pavel
  17. Apologies - When I was referring to limitations, I should have stated I was only referring to the program code limit. The version I have appears to be capped at 4k, whereas the 'Full' version I believe doesn't have such limit? Yes this is correct. Full version doesn't have any code or data size limits. Regards, Pavel
  18. That's not correct. BoostC Full is limited to not commercial use only. SourceBoost installation will put a new compiler on your computer. You might need to re-point FlowCode to use the updated compiler. Regards, Pavel
  19. Spaces after comma or Z don't make any difference for compiler. Z has to be capital because that's how it is defined in system includes. You can use number instead: #include <system.h> void main() { //Instructions below are equal asm { btfss _status, Z btfss _status,Z;no spaces after comma or Z btfss _status,2 } } Regards, Pavel
  20. Pavel

    The Lost Cursor

    Fixed. Fix will be available in the next release. Regards, Pavel
  21. Try this code. It multiplies two unsigned longs. You'll need to modify it a bit if you want to multiply signed longs: #include <system.h> struct long64 { unsigned long low; unsigned long high; }; struct long64 mul64( unsigned long l1, unsigned long l2 ) { unsigned short s11 = l1, s12 = l1 >> 16, s21 = l2, s22 = l2 >> 16; unsigned long tmp; union Res { struct long64 ret; struct Mid { unsigned short dummy; unsigned long mid; } mid; } res; res.ret.low = s11; res.ret.low *= s21; res.ret.high = s12; res.ret.high *= s22; tmp = s11; tmp *= s22; if( tmp > 0xFFFFFFFF - res.mid.mid ) res.ret.high += 0x100; res.mid.mid += tmp; tmp = s21; tmp *= s12; if( tmp > 0xFFFFFFFF - res.mid.mid ) res.ret.high += 0x100; res.mid.mid += tmp; return res.ret; } void main() { struct long64 res = mul64( 0x12345678, 0x9ABCDEF0 ); while(1); } Regards, Pavel
  22. PIC hardware lets you write to and read from unimplemented registers. Write does nothing and read produces a zero result. So as I see it code that operates on unimplemented registers won't be useful but at the same time won't do any harm either. This doen't do anything with overloading. If we want to produce minimal code for functions that read or write eeprom we should use eeadrh for PICs that do have big eeprom and shouldn't use eeadrh for PICs that have short eeprom. From other hand if we have only one library it will contain code that uses eeardh. Now the question is how to disable use of such code for PICs that have short eeprom. The only way we can do it is not let linker use functions that operate on eeadrh register. And we do it by disabling these function prototypes in eeprom header via #ifdef EEARDH preprocessor statement. So it looks that at the end one eeprom library will be enough. And it will indeed for PICs with short eeprom. But for long eprom there is a problem. Users can accidentially call functions that don't use eeardh when working with PICs that have long eeprom and because these functions don't operate on eeadrh they might access wrong eeprom locations. For example: eeprom_read( 10 ); //will call eeprom_read( unsigned char ) and if eeadrh is not zero the code will access other than addr 10 eeprom location eeprom_read( (unsigned short)10 ); //will call eeprom_read( unsigned short ) this one will access addr 10 This will lead to tricky to find errors. The solution is to produce 2 libraries. One for short eeprom and another for long eeprom. This way all nasty surprises will be eliminated and one won't need to think what eeprom function to pick. Compiler will do this job for you and pick the most appropriate function according to the type of the address used in a call. Regards, Pavel
  23. Your comments are valid. My current thinking is to provide 2 eeprom lib files for PIC18: one that will include functions that use char address and another that included both char and short addressing and uses eeaddrh register. They both will use the same header (the one that I poster earlier in this thread). Regards, Pavel
  24. Correct Correct Wrong. EEprom library was built for a general PIC18 device that has eeadrh register. It will try to write into this register regardless if the concrete PIC18 you use does or doesn't have this register. This will have no side-effect if this location isn't used in hardware. Correct. The changes I just made include an updated header (just like in my post above) and sources that don't use eeadrh in functions that use char address and do use eeadrh in functions that use short address. Regards, Pavel
×
×
  • Create New...