Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About russ_hensel

  • Rank
  • Birthday 05/24/1945

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
    South Dartmouth Ma USA
  • Interests
    Computing, electronics, gardening
  1. Just a general comment on Ian's response. I think he has made the right compromise between frankness and politeness. It is not easy. I can easily tell that no insult was intended and that as much help as possible was given. His advice, I think was excellent. I hope you beat your project into submission and are happy with the results.
  2. note that in boostc the register names are usually in lower case, in part I think, because many of the are volitile ( sp? )
  3. AAAGH!!!!, If that is in fact the case (and you are usually spot on), its a serious bug or implementation deficiency. The arithmetic *has* to be done at compile time and putting it in a #define isn't going to get us out of the mess as the arithmetic is just deferred till the symbol is used. This *TOTALLY* breaks portability as one would need to hard code EEPROM addresses. I will look into this in more detail. ... EDIT: LATER . . . #pragma DATA _EEPROM+0x00, 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 #pragma DATA _EEPROM+0x10, 17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32 gives Reynard is (as usual) correct, it doesn't work. That's just gotta be a bug as #pragma DATA _CONFIG1, _DEBUG_OFF & _LVP_OFF & _FCMEN_OFF & _IESO_OFF & _BOR_OFF & _CPD_OFF & _CP_OFF & _MCLRE_ON & _PWRTE_ON & _WDT_OFF & _INTRC_OSC_NOCLKOUT evaluates to the correct configuration (verified in the Hex file) so the preprocessor *can* do maths on the data values at compile time *AND* is calculating and storing WORDS, not bytes (the manual is wrong) so can definitely handle the full unsigned int number range. I'll edit my post accordingly <eats crow> and try to dream up and test a workaround other than this really *F*UGLY* one. //WARNING: NON-PORTABLE CODE FOLLOWS //#pragma DATA _EEPROM+0xnn, <data ... > //does not work as the first parameter is not evaluated. // For this PIC _EEDATA is 0x2100 and the address // of each line below must be manually incremented. // #pragma DATA 0x2100, <byte1>, <byte2>, ... <byte16> #pragma DATA 0x2110, <byte17>, <byte18>, ... <byte32> ... #pragma DATA 0x21F0, <byte240>, <byte241>, ... <byte256> // //END WARNING: AFTER NON-PORTABLE CODE You guys seem to have a better grip on the preprocessor than I do perhaps you would be willing to fix/improve the article at: http://www.opencircuits.com/The_C_Preproce...d_pound_Defines
  4. Think you can use a struct or typedef or both to do this. Others will probably give you more info as I have not done it myself.
  5. If a PIC can do it then BoostC should be able to. Many of us may not know what dcc is. It is usually fairly easy to translate from other versions of C, if you find example code in them.
  6. I have done some test with a spreadsheet. Round off error is indeed a problem. Scaling the values up by a couple of powers of 2 may solve this problem. Most of the math is 16 bit and I would like it to work well for 10 bit a to d. More info when I look into it some more. The division is by 8 not 7 so the shift is fine, but for the loss of bits off the right hand end.
  7. Russ that's an interesting idea. My first thought (without any testing) is that you are accumulating the rounding error with each new running average. 8 times the old average will not give you the sum of the 8 samples that were used to calculate the old average. Consequently, 7 times won't give you the old sum less one average sample, either. Further, as you pointed out, it's not the same running average even without the accumulated rounding loss. A sample 16 cycles back (or 9 or 50) will still have some weight with this model. Independent of his speed and memory requirements, it really depends on the application whether this method is better or worse (even if you ignore the rounding loss). That's my .02 without really thinking about it too much. -Henry I did not think about the rouding, but I should have pointed out that at least the math should be done in enough precision so there would not be overflow problems. Perhaps some of the math could be at a factor of 2 up to keep an extra bit of precision around. That is of course if we think that the method is worth improving.
  8. I have a different method and wonder what all of you think. Take the old average and multiply by 7. Add the new value and divide by 8. This is your new average. All reading ever taken contribute to the new average, the last one has a weight of 1/8 or .13, the eighth one back a weight of .04 the 16 th back a weight of .01. For averaging over a tighter period multiply by 3 and divide by 4. You can figure out other values. Use a power of 2 for the division so it will be done with ( hopefully ) a shift. To multiply by 7 you can combine shifts and adds ( look at the compiled output to see how efficient ) if it is faster than what the compiler comes up with. Now you have no array or pointers to deal with. What do you think? Should we model this with a spread sheet and compare to other methods.
  9. I will just make a guess, one time i used set-bit instead of set_bit. it is now subtraction of undefined variables, as I remember the math processer just kept parsing looking for an end of expession thru the rest of the program and finally generated so sort of overflow. I am not saying you have the same problem, but it might be similar in some way. I sometimes have been moved to comment out more and more of a program untill it will compile and thus finally learn the location of the error. Tedious
  10. Zeners are always troublesome :-) I'll see if I can post an ASCII circuit here within code tags! R1 1K R2 100R __ ___ ___ -o|P |o- ---|___|---o---|___|--------o|I |o- | -o|C |o- Input | -o|1 |o- Signal z .----o|6 |o- A ZD1 5V6 | -o|F |o- | | -o|8 |o- -----------o-----------o -o|8 |o- | -o|__|o- === GND (created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de) snip.... If you do not have the zener use 2 small signal diodes, one to v+ the other to ground. They will either short the power supply to ground and blow up ( connected the wrong way ) or will limit the input to the supply rails + a diode drop ( use ge diode for smaller drop ? ).
  11. The response to cap changes is given ( aproximately ) by RC where R is the load on the cap. Using more caps and resistors in various configurations may give better results, you need some filter theroy and/or a spice simulator ( LTSpice is free ) to systematically learn more. Or just mess around and see wht happens. In any case RC >> 1/60 ( for 60 hz ) would be a starting point. Filtering will not reduce the voltage sensitivity, just the time sensitivity. Going to 10 bits will seem to make the noise worse in that it will show up, but you can always ignore or process the data.
  12. Not sure why you are stopping the other timers..... Normally an interrupt subroutine first determins the reason for the interrupt by checking the appropriate flags ( often the enable and interrupt flag ). Then it process that interrupt as fast as possible. If someting take a while I set a flag and process it in the main loop as I get around to it. Part of processing the interrupt is clearing the interrupt flag. Else when you return you will interrupt again right away. While in the interrupt you cannot be interrupted ( unless you have prioritized interrupts which i think is possible on the 18F parts ) so generally you need not disable interrupts. It then goes on to check the other interrupts that might have occured and finally returns. If this is wrong, someone else jump in here.
  13. There are a lot of issues some hardware some software. * is the input voltage really constant? * is the source impedance low ( look at the spec sheet for how low )? * is the ground and reference voltage really quiet? * do you allow enough time after changing input pins? * more i have missed. By the way is accuracy fine if you use only one input?
  14. this does not work either bool willCompile() { return true; } but you could return a unsigned char, and try if( aChar )..... this does compile: unsigned char willCompile() { return true; } but what does it return? Wikipedia says: To this day, Boolean values are commonly represented by integers in C programs. The comparison operators (' > ', '==', etc.) are defined to return a signed integer (int) result, either zero (for false) or nonzero (for true). The Boolean operators (&&, ||) and conditional statements (if, while) in C operate on integer values, with the same interpretation. For example, the following C code
  • Create New...