Jump to content

Pavel

Administrators
  • Content Count

    1,466
  • Joined

  • Last visited

Everything posted by Pavel

  1. Here is the improved header that takes into account existance of EEADRH register (for those who haven't followed this post from the beginning: don't rush and edit the eeprom header file. This is just a proposal for the current eeprom library that targets next SourceBoost release): #ifdef _PIC16 unsigned char eeprom_read( unsigned char address ); void eeprom_write( unsigned char address, unsigned char data ); #elif _PIC18 unsigned char eeprom_read( unsigned char address ); void eeprom_write( unsigned char address, unsigned char data ); #ifdef EEADRH unsigned char eeprom_read( unsigned short address ); void eeprom_write( unsigned short address, unsigned char data ); #endif #else #error "unsupported target" #endif Regards, Pavel
  2. OK I see now. Than eeprom functions should look more like: #ifdef _PIC16 unsigned char eeprom_read( unsigned char address ); void eeprom_write( unsigned char address, unsigned char data ); #elif _PIC18 unsigned char eeprom_read( unsigned char address ); unsigned char eeprom_read( unsigned short address ); void eeprom_write( unsigned char address, unsigned char data ); void eeprom_write( unsigned short address, unsigned char data ); #else #error "unsupported target" #endif Regards, Pavel
  3. OK latest SourceBoost already supports 16 bit eeprom addresses for PIC18. Seems that nothing needs to get changed after all. Regards, Pavel
  4. Here is an idea. Make use of BoostC overloading capabilities and add eeprom functions that deal with 16 bit addresses. Something like: char eeprom_read(char address); char eeprom_read(unsigned short address); void eeprom_write(char address, char data); void eeprom_write(unsigned short address, char data); If that's what you want we'll add these functions to the next SourceBoost release. Regards, Pavel
  5. Casm file may look confusing because it doesn't show instructions in order. Note the addresses of these return instructions and than check listing file from the same project. Regards, Pavel
  6. The compiler has now given up initilising the function pointer too, so i removed it, and changed the unsigned short* to a unsigned char* and that is also being rejected. Seems like initilised structs just are not working at all. Any idea when this will be fixed, im really up against a wall here and i dont really have time to sort out and keep working around compiler bugs- i just need to code the application in C, test and release! We'll take a look. If this is easy to fix we'll fix it soon. Otherwise it will be a bit late after we have 7.0 pre-release published. Have you considered not using function pointers at all. PIC architecture makes use of function pointers expensive in terms of both code and data space and often it'll be more efficient to apply different techniques that don't use function pointers. Regards, Pavel
  7. For some reasons compiler doesn't want to handle intialisation of unsigned short* struct members. We will look into this. The workaround is to initialise those in main: ... sSetupSettings m_SetupSettings[] = { { Setup1Callback, 0x03, 0/*&param1*/, 0/*L1Values*/, ARRAY_ELEMENT_COUNT(L1Values) }, { Setup2Callback, 0x05, 0/*&param2*/, 0/*L2Values*/, ARRAY_ELEMENT_COUNT(L2Values) } }; void main() { //workaround start m_SetupSettings[0].pParam = &param1; m_SetupSettings[0].pParamValidValues = L1Values; m_SetupSettings[1].pParam = &param2; m_SetupSettings[1].pParamValidValues = L2Values; //workaround end ... Regards, Pavel
  8. Can you explain what is this 'snippets' window? Pavel
  9. This feature is already implemented in our IDE working copy and will be available in 7.0 Instead of project IDE will work on a workspace level where each workspace can include one or more projects. We also plan to add multiple configurations per project but this feature may become available later. Regards, Pavel
  10. For code like: sum -= samples[count]; samples[count] = val; compiler should detect that pointer registers (like FSR) get initialised using the same pointer and optimise out code in the second statement. Altually BoostC already does this but for some reasons it doesn't do it for this particular case. Will investigate and fix. So the answer to your question is that in future BoostC releases there will be no need to replace 'samples[count] = val' with assembly. Compiler will generate optimised code. Regards, Pavel
  11. What about this code? It generates code (almost) as small as assembly: #include <system.h> unsigned char samples[8]; unsigned char count = 0; unsigned short sum = 0; void add_sample( unsigned char val ) { //Replace oldest sample and update total sum -= samples[count]; //Add new value (code below is equal to 'samples[count] = val') asm { movf _val, W movwf _indf } sum += val; //Advance counter if( ++count == sizeof(samples) ) count = 0; } inline void get_average( unsigned char &average ) { average = sum/sizeof(samples); } void main() { unsigned char average, i = 0; //test while( 1 ) { add_sample( ++i ); get_average( average ); } } Regards, Pavel
  12. Where do you download the plugin template? http://www.sourceboost.com/Products/IdePlu...in_template.zip Regards, Pavel
  13. This error comes from pre-processor when it processes a macro. Check the number of arguments in the macros you use in your code. Regards, Pavel
  14. Wow these are really nice ideas. And what makes them even better is that some of them aren't too difficult to add We'll try to squeeze at least a few into 7.0 Regards, Pavel
  15. Yes it has been considered, but the job is not easy. Yes we are open to all ideas and feedback. Sorry for not replying before. Regards Dave Dave, Thanks for the reply. I understand that your area of development is complex, and I personally would never attempt to write a compiler. I've heard some people talk about developing a uC IDE using the Eclipse platform, which I think sounds interesting. The SourceBoost IDE is good functionally, but the interface icons could use an update. I don't know how large of a community exists for SourceBoost, but a poll would probably give some decent feedback. I'm also sure that you could find users willing to do some graphic design to enhance the interface. Anyway, glad you got back to me, and I appreciate all of the hard work that you and Pavel put into this. Thanks! We are happy to review new buttons sets for IDE and everybody is welcome to send us their proposals. In fact this is how the buttons used in the debug toolbar were born. The timing now is especially good as we work on the 7.0 release and use of new buttons there will be natural. Regards, Pavel I'll go ahead and start a new thread for feedback on cosmetic changes. How much time do we have to come up with material before you plan on releasing version 7? Version 7 will start as a series of pre-releases (This way users will get access to new features much earlier). It probably will take several months till pre-release becomes a release. Regards, Pavel
  16. Yes it has been considered, but the job is not easy. Yes we are open to all ideas and feedback. Sorry for not replying before. Regards Dave Dave, Thanks for the reply. I understand that your area of development is complex, and I personally would never attempt to write a compiler. I've heard some people talk about developing a uC IDE using the Eclipse platform, which I think sounds interesting. The SourceBoost IDE is good functionally, but the interface icons could use an update. I don't know how large of a community exists for SourceBoost, but a poll would probably give some decent feedback. I'm also sure that you could find users willing to do some graphic design to enhance the interface. Anyway, glad you got back to me, and I appreciate all of the hard work that you and Pavel put into this. Thanks! We are happy to review new buttons sets for IDE and everybody is welcome to send us their proposals. In fact this is how the buttons used in the debug toolbar were born. The timing now is especially good as we work on the 7.0 release and use of new buttons there will be natural. Regards, Pavel
  17. Yes this is planned for version 7 release. Regards, Pavel
  18. This feature is on our todo list. Meanwhile please use unsigned char return type instead of bool and compare it against zero to check if call failed or succeeded. Regards, Pavel
  19. Piece of cake: volatile unsigned short ccpr1 @ 0xFBE; ccpr1 = 2400; Regards, Pavel
  20. This probably won't happen. This expression requires compiler to know values of labels at compile time but they are not knows till link time. This one is easy to fix. Will add to our todo list. Regards, Pavel
  21. Sources, headers and documentation have been corrected. Both EEPROM and Flash libraries now fully support PIC16 and PIC18 targets. These changes will be available in the coming 6.96 release. Regards, Pavel
  22. This would be tricky. Plugin position and size are controlled by the framework that IDE uses. We don't have any date attached to this. We currently do some other IDE improvements so this one might slip in. Regards, Pavel
  23. IDE already does it. If you look into any project file (file with extension .__c) yuo will find plugin state saved under the [Plugins] section (the only exception are project files from installation that have this info stripped out). So if you switch between projects the plugin settings should change as well. Yes multiple configurations is a nice feature. It's on our todo list already. Regards, Pavel
×
×
  • Create New...