Jump to content

mmckban

EstablishedMember
  • Content Count

    20
  • Joined

  • Last visited

Community Reputation

0 Neutral

About mmckban

  • Rank
    Regular
  1. That makes good sense. I finally figured out my problem, I need to go back to kindergarten and learn some math! I don't know how I had it working at all before (or maybe my testing was deficient), but I fixed it now. Just had a couple of numbers swapped. Sorry for bothering folks and thanks for the responses! Moses
  2. Well, I don't think that's it because the output is exactly double what it should be which is what it would be if the division by 2 wasn't working. I just changed back to the old scaling (see my first post) and it works fine with that with the same 6.97 compiler. The problem is that I need the new scaling for some changes in our hardware. I compared the .asm files from the two with only different scaling, and can see the the one that does not work has a function called "__mul_16u__0000C", and the one that worked (old scaling) has a function instead called "__div_16_1_00003" that is obviously different. I don't know assembly well enough to tell much more though. Let me know if you need more information on this. Thanks, Moses
  3. Anyone have any ideas? This sure appears to be a compiler bug... Our product was working fine with the first scaling and now that we need to change the scaling it won't work. Help!!
  4. Hi, I'm using SB 6.97 with the code below in an endless loop. The chip is a PIC12F615 running on the internal oscillator. The "an_out = (an_in*3)/2;" line for all I can tell is not doing the divide by two (because the pwm signal is twice what it should be!) volatile bit A2D_not_done @ADCON0.1; unsigned short an_in; unsigned short an_out; delay_10us(2); // Wait acquisition time - this is probably longer than we need but we don't need to run faster than this! set_bit(adcon0, 1); while (A2D_not_done); // Wait for a2d done flag to change MAKESHORT(an_in, adresl, adresh); if (0 == gpio.4) { an_out = an_in; } else { an_out = (an_in*3)/2; } if (an_out >= 55) gpio.5 = 1; // LED on at ~ 20 Amps else gpio.5 = 0; // LED off otherwise // Set pwm duty cycle ccp1con.4 = an_out.0; // Set the low bits... ccp1con.5 = an_out.1; // " an_out = an_out >> 2; ccpr1l = an_out; // Set the high bits... This same basic code was running fine before, but I may have been using 6.96 or 6.97RC-something to compile it. The only other difference was the scaling factor, which was as follows: if (0 == gpio.4) { an_out = (an_in*8)/3; } else { an_out = an_in/4; } I have tried a number of things, such as putting the multiplication and division on two separate lines, right shifting by 1 instead of a divide by 2, etc. Does anyone have an idea why this is happening or what I'm doing wrong? Thanks, Moses
  5. keni, It sounds like the read-modify-write problem could be your problem. What I do for that is make a variable like porta_state and then only change bits in that variable, and then set porta = porta_state; anytime I make a change.
  6. Thank's for the information! I guess I should have been able to find that in the documentation, but the docs seem a little non-intuitive to me and I hardly knew what to look for at the time. I assumed the debug stuff in sourceboost was for a hardware debugger. I've used an ICD2 to debug a little bit with MPLAB, and I use a pickit2, but haven't tried debugging with it. Thanks again, Moses
  7. I need to know if I can use standard bitwise operators such as << and & on a 16-bit variable, or do I need to break it into two 8-bit variables? Here is the function I'm trying to do and I need to know if this usage is valid. I don't have an easy way to test it so I figured I'd ask and see if someone knows. void burn_register(unsigned char reg, unsigned short param) { unsigned short bitval; for (i = 0; i < 16; i++) { bitval = (1 << i) & param; if (0 != bitval) { power_on(); start_blow_mode(); select_register(reg); select_bits(bitval); blow_pulse(); power_off(); } } } Thanks in advance! Moses
  8. PICKit2 is made by Microchip and I have the latest software which supports this chip. It turns out the that addresses for the config words in the header file are wrong, so I changed them and it works fine now. Thanks
  9. I was aware of the new twist and I was trying to figure out how to do what I needed to make it work. Thanks for the pointer to page 68! That had more of what I needed, and the stuff I posted had most of the rest. The Programming Specs datasheet has more information and I think I have it figured out. The XXXF8 etc is because the configuration words are stored at the end of the program space, and that is different on different chips in the family depending on how much memory that chip has. So on my chip with 32K mem the address is 7FF8 and on the chips with 128K mem it is 1FFF8. The header file for the 18f85J50 has the config words at the wrong address which is probably why my PICKit2 software said there was no configuration words in the hex file. I'm going to try putting the correct addresses in and see if it fixes it.
  10. Howdy, I just wrote a simple test program for a PIC18F85J50 and when I load in into my PICKit 2 programmer software it gives me the following error: Warning: No configuration words in hex file. My configuration words are as follows: <code> // using a 12 Mhz external crystal #pragma DATA _CONFIG1L, 01101010b #pragma DATA _CONFIG1H, 11110111b #pragma DATA _CONFIG2L, 00000101b #pragma DATA _CONFIG2H, 11110000b #pragma DATA _CONFIG3L, 10110000b #pragma DATA _CONFIG3H, 11110000b </code> I've included "system.h" and everything compiles with no errors or warnings. Am I missing something or is this a bug?
  11. Hmmm, not quite what I was asking. These chips store the configuration data in program memory and then load it into configuration memory on power up. The data sheet says to allocate or reserve the space in the program memory for the configuration data so it doesn't get used for something else. I don't know how to do this. The configuration memory starts at 300000h but the config data is actually stored in code space at XXXF8h - whatever that address means.
  12. Hi, I'm trying to use a PIC18F85J50 and I ran across something in the datasheet that I'm not sure how to do. It says the following about the configuration words: "Configuration data is stored in the four words at the top of the on-chip program memory space, known as the Flash Configuration Words. It is stored in program memory in the same order shown in Table 25-2, with CONFIG1L at the lowest address and CONFIG3H at the highest. The data is automatically loaded in the proper Configuration registers during device power-up. When creating applications for these devices, users should always specifically allocate the location of the Flash Configuration Word for configuration data. This is to make certain that program code is not stored in this address when the code is compiled." Does "at the top of the program memory space" mean starting with 0x0000? How do I allocate these locations? Also the table of locations doesn't make sense to me. What does the following mean? Configuration Byte | Code Space Address | Configuration Register Address CONFIG1L | XXXF8h | 300000h CONFIG1H | XXXF9h | 300001h CONFIG2L | XXXFAh | 300002h CONFIG2H | XXXFBh | 300003h CONFIG3L | XXXFCh | 300004h CONFIG3H | XXXFDh | 300005h Thanks, Moses
  13. I recently bought a PicKit2 from Microchip on the recommendation of a number of people. It is extremely capable and is probably the best value programmer you'll find at $35 plus shipping. Moses
  14. What would it take to get support for a PIC18F85J50? It looks like it's a fairly new part, and it has USB built in as well as the large number of I/O pins which I need. Is it just a matter of an include file? Thanks, Moses
×
×
  • Create New...