Jump to content

joli

EstablishedMember
  • Content Count

    87
  • Joined

  • Last visited

Everything posted by joli

  1. What's new about 8.01 version besides being free ? I have boostc++ pro licence.
  2. Delayed reply, even thus maybe helpfull for others As Reynard said, why not... #include <system.h> // zero at the end, to end of string detection rom char *test_txt = "\n\rMatrix Controller Test mode\n\r\0"; void puts( rom char* c ) { for( unsigned char i=0;;i++ ) { while( !txsta.TRMT ) clear_wdt(); if( c[i] != 0 ) { txreg = c[i]; } else break; } } void main( void ) { puts( test_txt ); while(1); } regards
  3. Answering to my self. Its working now. Under mplabx the libraries should be added to the project through Project Properties and add it to BoostLink / Additional options. By the way, the compiler/linker finish the job in about 3 minutes > 72 module_files / 273 functions - 4 core, i7, 2.8GHZ, 16gb_ram The compiler takes 30 seconds. The rest of the time is spent by the linker (2.5 minutes)... It would be great if linker could be improved.
  4. #include <system.h> typedef unsigned char uchar; void main() { uchar j=20; uchar i = (j/10); } Compiling the little snipet above under mplabx, it return errors like this: Error: Unresolved external function:'__div_8_8(unsigned char,unsigned char)' depending of the evaluated expression the error could be: Error: Unresolved external function:'__div_16_16(unsigned char,unsigned char)' Surprinsingly, the same not happens to 16/32 bit multiplications. The solution is to include libc.pic16.lib or libc.pic18.lib, depending the pic family we are using. Th
  5. Is there any trick for float lib to work with mplab x? The code below compiles ok in sourceboost editor but not in mplabx. #include <system.h> #include <float.h> void main() { float f = float32_mul(2.5, 2.5); } Here is some errors when compiling this code in mplabx ide: Error: Unresolved external function:'__mul_32_32(unsigned long,unsigned long)' ... same error above repeated n times ! Error: Unresolved external symbol, function:__mul_32_32 ... same error above repeated n times ! make[2]: *** [dist/default/production/float.X.production.
  6. Hi there, As far as I can see, J94 types are not supported and I have no idea if the compiler will continue to be upgraded or not. The 18(l)fxxk40 types, they are supported, but the header files are incomplete, so i wrote a simple tool to generate them from the "inc" files included in the mplabx/v4.10/mpasmx. I can put them here if the owners of sourceboost allow me to... i have no idea about legal stuff. Optionally it can be done by modifying the files provided by microchip, using an editor with macros in order to turn the job less painfull... for instance, p18lf67k40 has about
  7. try this out instead of your #pragma's: // FUSES #pragma config OSC = INTOSCPLL // Internal osc PLL can be enable/disable #pragma config CP0 = OFF // Program memory is unprotected #pragma config FCMEN = ON // Enable osc monitor #pragma config WDTEN = OFF // Watchdog OFF #pragma config WDTPS = 512 // 1:512 #pragma config XINST = OFF // Disable extended instruction set (mandatory) #pragma config IOL1WAY = OFF // works either way
  8. There is a clean crc16 code, based in the example given in the sourceboost / examples, to all that needs it The code is working pretty well in a real app that uses several industrial modbus devices. // crc16 table hi/lo rom char *aucCRCHi = { 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x
  9. I did an atempt to use this in a real application by using several lists of structures but the compiler boostc/bostc++, failed. After several tests i concluded that the compiler do doesn't like to have "methodes" inside of the structure. So, until better oppinion, i believe that this is a compiler issue. Modifications: 1. delete AddStudent( uchar *pstudent ) "methode" inside of structure. 2. instead of StuList.AddStudent( adata ), StuList.s_id = data[0] and StuList.s_age = data[1] should be used. br
  10. Same here with xp, vista, w7, w10. I remember that this worked in previous versions, 6.97 for instance. br
  11. ANDYp, looking at datasheet, timer 1 section, i can't see how to achieve 20 minutes with timer 1 interrupt... lets see: clock = 4000000 Hz maximum prescaler = 8 maximum timer 1 count = 65536 t1_tick = 1 ( 4000000 / 4 / 8 / 65536 ) = 0.524288 secs But it can be used by polling the timer 1 interrupt flag and count the number of times that the TMR1IF rises. To achieve 20 mins the number of counts is 20*60/ t1_tick = 2288 Then you can call your function to change state or whatever you want timer 1 interrupt isn't need, polling pir1.TMR1IF is enough. write a function to
  12. im glad you got it working. about Dave and Pavel, i see no activity from him in here for a long time. but company keep selling cause i brought a boostc++ pro weeks ago i don't know what that absence means, i just know that in my oppinion they have a great product with a very competitive price br
  13. Forgot to mention the basis of it is on boostc++ manual page 83. br
  14. With just the code fragment you show is not possible to comment. http://www.microchip.com/forums/m816748.aspx http://ww1.microchip.com/downloads/en/AppNotes/00000734C.pdf br
  15. Another way to do the same with less code on set/clear output, imagining that the Green output is a led with cathode connected to the ground This is also faster than previous example because just one instruction is needed to change the output state #include <system.h> #define GREEN 1 // Green pin gpio = (1<<GREEN); // precondition(HI) when triso.1 = 0 (as output) trisio = ~(1<<GREEN); // all pins = inputs except for GREEN pin = output // macro #define SET_GREEN_HI ( trisio &= ~(1<<GREEN)) // <=> trisio.GREEN=0 #define
  16. A more elegant way to do the same... // header file #ifndef _STUDENTS_H_ #define _STUDENTS_H_ typedef unsigned char uchar; #define STUDENTS 64 // S T U D E N T D A T A S T R U C T struct Student { uchar s_id; // id uchar s_age; // age void AddStudent( uchar *pstudent ) // add function member { s_id = *pstudent++; s_age = *pstudent; } }; extern Student StuList[STUDENTS]; // turn it global if need #endif // c file #include <system.h> #include "s
  17. Actually is not so hard set config fuse bits, unless you are using on of the rare devices that comes with missing defines. In that case you need to write all defines in the include file Anyway, it depends of device you are using Here is an example for pic18f4620 #pragma config CP0 = OFF // Code Protection bits (Program memory code protection off) #pragma config OSC = INTIO67 //XT // Oscillator Selection bits (RC oscillator w/OSC2 configured as RA6) #pragma config IESO = OFF // Oscillator System Clock Switch Enable bit (Oscillator system clock switch opt
  18. This is another way of doing things instead of using objects as posted yesterday in http://forum.sourceboost.com/index.php?showtopic=5515 // file: students.h #ifndef _STUDENTS_H_ #define _STUDENTS_H_ typedef unsigned char uchar; #define STUDENTS 64 // S T U D E N T D A T A S T R U C T typedef struct { uchar s_id; // id uchar s_age; // age }Student; extern Student StuList[STUDENTS]; // turn it global / not needed if we plan to use it only by the students.cpp module #endif // file: students.cpp
  19. This is just an example for who needs something alike also to c++ experts comments that are very welcome. Purpose: .create a list of objects and do something with them Device: pic18Fxxx // file: students.h #ifndef _STUDENTS_H_ #define _STUDENTS_H_ typedef unsigned char uchar; #define STUDENTS 64 // max number of students class Student // { private: uchar s_id; // data member uchar s_age; // data member public: void AddStudent( uchar *pu
  20. Hi there, Thats weird.. it works ok here. tested again minutes ago. The missing defs you saw on your header file, is missed on mine too. There are another files with missing stuff... good luck this is the test i did: #include <system.h> #ifndef _EEPROM #define _EEPROM 0xF00000 #endif #pragma DATA _EEPROM, 0x10, 0x11, 0x12, 0x13 void main( void ) { while(1); // nothing to do } br
  21. As mentioned by RichardC in a previous post Whenever you want to write to an output, a mirror (register) should be used, then you may write to the output through this mirror, like the example below: #define Green 1 #define Out1 5 unsigned char gpio_mirror; // usage... gpio_mirror.Green = 1; // to set pin hi gpio = gpio_mirror; gpio_mirror.Green = 0; // to set pin lo gpio = gpio_mirror; // same methode to Out1 pin Except for devices with LATx br
  22. About eeprom issue, you may use this in your code: #ifndef _EEPROM #define _EEPROM 0xF00000 #endif #pragma DATA _EEPROM, 0x10, 0x11, 0x12, 0x13 or you may just insert "#define _EEPROM 0xF00000" in the pic18f45k50.h don't use 0xF000 as i saw in a previous post. I have imported a snipet to mplab 8.92 with #defines as showed above and saw all four values ok in the eeprom watch window. The section related with fuses, etc, you may try to copy them from a closest model... ideally verifing values with datasheet and after check them within mplab. br
  23. unsigned char xpd=9; unsigned char xpm=38; unsigned int xpf=4534; unsigned long xr; xr = ((xpd*600000)+(xpm*10000)+xpf); // 5456854 <<< error xr = xpd*600000; xr += xpm*10000; xr += xpf; // 5784534 <<< ok Simulated by sb_7.30 Check again and again the math section of sourceboost manual and not see anything that tell me that i can't do it all in one single line. br
  24. Please explain why your method is more preferable? Regards, Pavel In the particular case where he just write the entire port and he do nothing more, its irrelevant the use of a port shadow. I point it just a general rule to follow just in case. Actually in some load circumstancies pic12/16/18 all them have this issue, the difference is that the pic18 and new pic16 have the lat(x). google for "microchip DS31009A" pag 9 br
  25. Please explain why your method is more preferable? Regards, Pavel In the particular case where he just write the entire port and he do nothing more, its irrelevant the use of a port shadow. I point it just a general rule to follow just in case. Actually in some load circumstancies pic12/16/18 all them have this issue, the difference is that the pic18 and new pic16 have the lat(x). google for "microchip DS31009A" pag 9 br
×
×
  • Create New...