Jump to content

russ_hensel

EstablishedMember
  • Content Count

    107
  • Joined

  • Last visited

Everything posted by russ_hensel

  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
  15. Thanks. Support for the 18F is important, based on price the 16F parts should become much less popular
  16. Are you sure your clock frequency is what you think it is. At least on the 2550 the clock and the crystal can be quite different. In my case 20 mhz and 24 mhz. At one point I was moved to write a little routine that tried the uart at all sorts of different brg ( right symbol? ). That was helpful. Your problem may be entierly different.
  17. Sure you can but weather it works on other targets depends But should. Since data was obtained from "PICmicro™ Mid-Range MCU Family Reference Manual" should be relevant to most if not all mid range pics. I just tried this with 18F2550 and seems to work. Manual is still wrong, so is header file. Will not compile for me unless .lib file is in the project as per: http://forum.sourceboost.com/index.php?sho...art=#entry15071 Would be nice to fix up the docs, .h. I am using 6.95
  18. Also Note: Its best to wrap code in code tags in the forum post to preserve the formatting. Regards Dave thank you very much for you guys' replies, i wasn't planning to pop up so much things, i will recheck my code and also do what Dave suggested next time. the purpose of this code is to use PIC16F877 to generate 4 types of waveforms, by using look-up tables, the sampling points will be sent to PORTB as output. i can sense this code has loop problem even those grammatic issues have been sovled, cause when it goes to one of subsection ( e.g. squarewave), it wont go back to main() although the condition of each 'while()' is not satisfied. hence hereby i need some help to deal with how to let program jump out from subroutines and goes back to main(). thanks a lot john have you fixed your syntax errors? it is a rare person who will check it without correct formatting. you jump out of a subroutine with "return" one is automatically inserted at the end of a subroutine.
  19. This may not be helpful, but can you do the call from a C subroutine in the usual way, but imbed asm for most of your code? This might give you the advantages of asm, but let the normal C calls be used.
  20. Hi, thanks for your question. I have a pressure sensor and I would like to calculate the elevation by using the initial value and the current one. I had several solution and two same interesting: Z = Z0 + Temperature*cst*ln(P0/P) Z = Z0 [1 - (p / p0std)^1/α] that where is my question come from Jean-Marie This looks like floating point with transendatal functions, it is a lot for an 8 bit machine. My first instinct would be to manage it with integers and a look up table ( interpolate in the table for more accuracy ). Do the calcs in excel to populate the look up table. There is a floating point library, I am not sure if you would still have to write some of the functions. It would be slow.
  21. More info please: what data type? integer poweres only.........
  22. A port is a memory location portc.5 is bit 5 in the memory location of portc. You can store the value of the bit in any variable that is 1 bit or wider, we often use a whole byte because byte access is fast.
  23. This is #2 of two related posts. I am trying to use an I2C eeprom with the 18F2550 and the I2C library with BoostC ( i2c_driver.h ). The use of the #defines and other syntactical features is just a bit too deep for me to be confident. Could someone explain? I think the same sort of syntax comes up in the serial driver which I did not use for the same reasons. When I understand this better I will post a write up on our Wiki ( unless you want to answer this by posting it there yourself ). I am not looking for an explanation of I2C, I have found lots of references for this.
  24. This is #1 of two related posts. I am trying to use an I2C eeprom with the 18F2550 and the I2C library with BoostC. Does anyone understand this enough to make the needed changes ( are changes needed )? I do not understand the code ( i2c_driver.h ) well enough to be sure. Looking at the datasheets the big difference seems to be: ( next a table, not really code ) function 16F877 18F2550 18F4431 pin pin pin sda rc4 rb0 rc4 scl rc3 rb1 rc3 The other definitions seem to be the same. The driver says it is for the 18F2xx and 18F4xx but the difference in the sda ad scl pins would see to argue against it working both the 18F2550 and 18F4431 without change. I have found a posting on the forum for the 877 at: http://forum.sourceboost.com/index.php?sho...art=#entry12381 The definitions seems to be reflected in the code as: #define i2c_ARGS 3, PORTC, TRISC, 4, PORTC, ....... So perhaps only first 5 values need to be changed? Has anyone used this code with the 18F2550 and know what changes to make ( and if there are other changes )? Enlighten me if you can.
×
×
  • Create New...