Jump to content

All Activity

This stream auto-updates     

  1. Last week
  2. Is there a way to duplicate an assembly language macro that I use to store constant strings inline with my code? The putstr() function pulls the return address (the string address in this case) from top-of-stack, sends the string while updating TOS, and returns to the instruction immediately following the inline string. Here's the assembly language version I'm trying to duplicate; putstrg macro string ; in-line rom string call putstr ; inline string print function dt string,0 ; inline string endm ; Here's the inline print string function... /******************************************************************** * * ********************************************************************/ void putstr() // in-line strings (14 words) { strloop: // bank 31 (inserted by compiler) |31 asm movf _tosl,W // copy return address to FSR1 |31 asm movwf _fsr1l // " |31 asm movf _tosh,W // " |31 asm movwf _fsr1h // " |31 asm bsf _fsr1h,7 // set b7 for access to flash |31 asm incf _tosl,F // bump return/string address |31 asm btfsc _status,Z // " |31 asm incf _tosh,F // " |31 asm movf _indf1,W // end-of-string (0x00)? |31 asm btfsc _status,Z // no, skip (send char), else |31 asm return // exit (end-of-string) |31 asm call putwreg() // data passed in wreg |31 asm bra strloop // |31 } Thank you all for your time and kind consideration. Cheerful regards, Mike, K8LH
  3. Earlier
  4. Where's Chameleon?

    Go to Settings menu and select Toolsuite… There you will find Chameleon. Cheers Reynard
  5. I have looked all over the site and other somewhat disreputable sites looking for the Chameleon compiler that is mentioned every time I build a project with BoostC++. I can't seem to find it anywhere. Where do i go to get it?
  6. Hi Check the figure 14-3 and 14-4 @ page 136 of the datasheet and cross-reference it with figure 12-1 @ page 126. The TMR2/PR2 match signal that sets the PWM output to 1 also sets the TMR2IF interrupt flag to 1 via the TMR2 post-scaller. HIH Best regards Jorge
  7. I'll have to check that tomorrow, but if I recall from the scope, I was not generating the interrupt on the positive edge of the pwm cycle. I'll check that tomorrow
  8. Hi I think you are wrong here. The beginning of the PWM cycle happens when TIMER2 is reseted due to a match with PR2. When Timer2 = PR2 a match interrupt is generated (TMR2IF). If you set the Timer2 postscaller to a 1:1 ratio, you will have this interrupt generated at the beginning of every PWM cycle. HIH Best regards Jorge
  9. I am using the PWM, but a 50% duty cycle is what needs to be there due to the discharge of the capacitor after it charges. If I lengthen the DC, then the cap may not discharge enough for the next charge cycle and the timing will be messed up. I also found out that the comparator interrupts on any change in the output. I dodn't know that up front, so I can use the discharge interrupt to setup for the next charge cycle. I realize that I'm using tmr2 for the pwm, but there does not seem to be a good way of using that to catch the beginning of the pwm cycle. I have fed the pwm output into INT0 and this seems to work, but I suspect there is a better way. i don't understand how to use tmr2 to catch the pwm leading edge, but either way it will wind up being an interrupt, so whether a tmr2 or INT0 I guess doesn't really matter. What do you think?
  10. Hi You already have a timer associated with the PWM signal. Why don't you use it?. The period signal is defined by a timer, things start when yes start the timer. Use the comparator to stop it and read the value. Another thing I'm not sure the PWM is the better tool for the job, because the becessary duty cycle to charge the capacitor is unknown. HIH Best regards Jorge
  11. I am attempting to make an ohmmeter out of this chip by pulsing a pin using PWM. The pin has a resistor capacitor series network. The resistor is the unit under test. I can use tmr3 to get the time to reach a specific voltage level (1T = 0.63 x VDD) and can interrupt when the comparator trips, but how do I catch the start of the pulse? Is there an interrupt for pulse start or am I goign to need to feed the PWM signal into an external int? Or maybe one of you smart guys has a better way. Any thoughts?
  12. Yes you can share the compiled libc binary but not the library sources. Please make sure the github users know the origin of the binary. Regards, Pavel
  13. One of my open source projects requires a custom PIC18 libc. Am I allowed to share a compiled libc binary?
  14. Hi The same solution works for all libs. Also its valid to the old MPLab 8.xx as for MPLab X. If memory is not tricking me, this is documented in the manuals. Best regards Jorge
  15. We would like to reproduce this and we don't need your source code. Please email your project obj files and linker command line to support@sourceboost.com Regards, Pavel
  16. 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.
  17. #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. This could be done, under mplabx/File/Project Properties. Now in the Project Properties Window, select Libraries and Add Library/Object File, choose <libc.pic1x.lib> and thats it. Alternately, it can be done following the procedure above but picking Linker instead Libraries and add <libc.pic1x.lib> in the Additional Options. P.S. the same procedure works with floats.
  18. 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.hex] Error -2 make[1]: *** [.build-conf] Error 2 make: *** [.build-impl] Error 2 BUILD FAILED (exit value 2, total time: 5s) float.pic18.lib was included as explained in the FoatMath.pdf page 9 PIC18LF67K40 / c++ pro licence / sourceboost 4.43 / mplab x 4.15
  19. 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 6700 lines. regards
  20. I tried your suggestions but could not reproduce this error Most likely it's just one particular line of code. Maybe you can remove portions of this code that contain IP of your customer and send us the resulting file and maybe even obfuscate it. We are releasing a new version very soon and it'll be nice if this fix makes its way in. Regards, Pavel
  21. Here are some notes how rom objects work in BoostC: - a rom object is always identified by one byte (that's why in the code above gbl_sw_id is 1 byte long) - when linker processes all its input files it makes a list of all rom objects and allocates IDs to them - linker generates code for all these rom objects that it puts into the code memory - linker generates a function that can extract any byte of any rom object using its ID and position/index - when compiler needs to generate code to access character in a rom object it uses an placeholder ID and character position/index and calls function that linker generates in the prev bullet. Later linker replaces this placeholder ID with an actual object ID. Chameleon does not yet support rom objects. Support for rom objects will be added to Chameleon in the upcoming 7.43 release. Regards, Pavel
  22. I have been using SourceBoost for 10 years now and never knew it put all that extra code into the startup section for rom arrays. I suppose that is because the IDE shows the .casm file which doesn't show all this extra stuff. We will just have to make sure to write code that doesn't crash and test it well. Function pointers taking arguments usually causes me problems. Can't seem to use the arguments unless I copy them into a local first variable. Maybe it's just me. But as you say a great little compiler. Novo is usually in every project I do. Cheers Reynard
  23. Hi DTPIC, That's handy. My current project uses a 40 pin PIC18F46K22. Thanks for the info and I will have a look into it. Cheers Reynard
  24. Hi Reynard, I am using PIC18F (45K22). I cant really send you full source code, as these are commercial designs and "the customer's property". But here are some snippets: This is the code as I have followed it; I know I'm not infallible, and I did try to say "if I'm right" ...(!) see what you think of my understanding: Looking in the asm output, a RAM byte is assigned for the array called "sw_id": gbl_sw_id EQU 0x000002FC ; bytes:1 // why!?!?! Then the _startup code does this: _startup MOVLW 0x00 MOVLB 0x02 MOVWF gbl_segmap, 1 MOVLW 0x01 MOVWF gbl_sw_id, 1 MOVLW 0x02 MOVWF gbl_xfm_id, 1 MOVLW 0x03 MOVWF gbl_sw_xform, 1 MOVLW 0x04 MOVWF gbl_mastermodename, 1 MOVLW 0x05 ... where segmap, sw_id, xfm_id, swxform, mastermodename, are all rom char* arrays. Isn't this putting an array token number into RAM? Example: 'C' definition of sw_id array: // 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 // <-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-> rom char *sw_id = "CFGDM1MODTD1TU1DM2TU2TD2DSBDSADM3TD3TU3TD4TU4DM4---"; A typical use of the array in 'C' would be romstrget(sw_id,start,length,dest_array); // romstrget is my function which accesses the array at the array position given by "start", // then copies "length" bytes to "dest_array", terminating in 0x00 At the asm level, the array is accessed using: MOVLB 0x02 MOVF gbl_sw_id, W, 1 MOVLB 0x03 MOVWF romstrget_00000_arg_romstr, 1 MOVF main_1_j, W, 1 MULLW 0x03 MOVF PRODL, W MOVWF romstrget_00000_arg_start, 1 MOVLW 0x03 MOVWF romstrget_00000_arg_len, 1 MOVLW HIGH(gbl_msg_tmp+D'0') MOVWF romstrget_00000_arg_str+D'1', 1 MOVLW LOW(gbl_msg_tmp+D'0') MOVWF romstrget_00000_arg_str, 1 CALL romstrget_00000 Isn't MOVF gbl_sw_id,W,1, attempting to access the rom array using a RAM based token value? I haven't followed the code to the absolute letter \ byte at this point, so you may be able to set me on the right path...! Thanks for your time.... still think its a great little compiler, and I'm looking forward to Chameleon...
  25. Are you using a PIC 16 or PIC 18 ? My current project is for PIC 18 and I have 70+ rom char arrays both string and byte arrays. All the arrays are stored consecutively in program memory. Accessing the arrays is through an index which is a constant. If my arrays are each occupying 256 bytes I would know about it. Can you supply Dave and Pavel with code showing what you believe to be experiencing. Cheers Reynard
  26. I recently had a problem with arrays held in RAM being corrupted, so I thought i would move them to ROM using rom char *. I found that it was still possible to corrupt the array output! Here's what i think happened... It looks like the compiler assigns a 256 byte ROM area to every rom char array, regardless of actual size. It then assigns a "rom char array number" (1,2,3, etc) to each array for identification: THEN IT STORES THAT NUMBER IN RAM! Consequently, if the area of RAM holding the rom char array number is corrupted, then the rom array output is also corrupted (because you are probably looking in the wrong place in ROM). As a (licenced!) commercial user, it is sometimes necessary to try to ensure the contents of a lookup table or array at all costs. (Yes, I am the first to agree that I should be preventing the overwrite of RAM!). If the above is a correct observation, then 1) this assignment of rom char numbers to RAM is not a good idea-it can be corrupted 2) we seem to be burning 256 bytes of ROM per array regardless of required size, which also does not help in a tight for space application. Looking at the assembly output, it would seem reasonable to hard code the rom array base address; this would also make it easier to make the arrays only the length they need to be (and leave more code space available). Maybe you can take this into consideration if you are revisiting rom char array handling in Chameleon. (...and it would also be good to be able to assign the contents with 0xnn or \xnn - I think others have reported problems here?) Thanks for listening!
  27. Only other things I can tell you: 1) I use the "#if 1.... #endif" and "#if 0.... #endif" constructs to include\"comment out" sections of experimental code... 2) I have used nested #ifs \ #ifdefs sometimes to 3 or more levels... 3) there may be #if\#ifdef\#endifs existing inside /*...*/ commented out code, or #if \ ifdef \ #endifs commented out using //.... Hope this helps...
  1. Load more activity
×