Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About mityeltu

  • Rank
  • Birthday 02/08/1968

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
  • Interests
  1. So, my win7 machine finally gave up the ghost. Interestingly, my win xp system is still working like a champ. Can't connect it to the network, but it still works great. Anyway, I'll be 'upgrading' to a new laptop with windows 10. Can anyone tell me if sourceboose ide and compilers are compatible with windows 10, or am I going to have issues? If it won't run right, then I guess I'll buy windows 7 and use that as long as possible. I really don't want to have to go with microchip's ide and compilers - they are soooo cumbersome.
  2. I apologize for perhaps a dumb question, but what programming manual?
  3. I am making new .h and .tdf files for the 16f1788 chip that I wan to use for a new project. Why I wan to use this chip as opposed to another that might already have these files built is not important for this discussion. I have run through the .h file and am at the last section, but I don't understand where I can find the eeprom base address that is used in any of the existing .h files. For instance, the file for the 16f1783 that I am using as a template calls out the address as 0xf000. I can't find this information anywhere in the datasheet for this chip. Where can I find it? Is it alway
  4. 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?
  5. 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
  6. 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 int
  7. 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?
  8. Ok, Well, I manged to figure out how to fix this anyway. The 'light' function uitoa_dec() will give me an unsigned number that I can use in the display. It still makes no sense to me why a defined unsigned short placed in a function requiring an unsigned short would somehow produce a signed result. Anyway, problem solved.
  9. I am attempting to use the rand and srand functions to generate a "random" pause between sections of my code. I am using the 18F2510, have added the rand.pic18.lib file to my project and have included the rand.h file in the program. I keep getting negative numbers in my random number variable. I don't understand this as the routine states that an unsigned short should be returned from the call. I wrote the following as a test of the rand and srand functions to see what is happening. char buff[9]; char* ptr; unsigned short random_int; srand(7123); for(i = 0; i < 10; i++) { lcd_cle
  10. What? "as a float 0x41bba752 = 0x4e83774f"?! Wait.... I'm going to go do some research on this.... I obviously missed something in C training. I'll have to get back to you on this. That makes absolutely no sens at all to me. In fact, at the moment, that seems like a complete contradiction. Not saying you're wrong. In fact, I'm saying you're probably right and I just don't understand. So, thank you for the correction, and I'm gonna go and relearn - or maybe just learn - what it is you;re talking about. Thanks.
  11. I'm not sure how that is really any different. If I take a floating point variable and shift in 0x41bba752 and take a second floating point variable and load it with 23.4567, do they not contain the same hex values? That is really confusing if they would not be the same. I understand what you mean about the integer type value being very large, but if the bits in a float variable loaded with 23.4567 are in the same order as the one loaded with 0x41bba752, why do they produce different values? Is it becuase of what you said above? "a float is a pointer... " So, somehow when a float is declar
  12. The Union worked!! Thank you! I have no idea WHY it worked, but it worked. This is excellent! I now have a complete I2C LCD library that can receive any kind of variabel and display it on an LCD. Perfect! I would still love to hear why my original code does not do the same thing.
  13. I'll try both today. Can anyone explain why my code doesn't work? I realize that an int is only 2 bytes, but the fact is a float is 4 bytes and if I load a float with the value 23.4567, the hex value stored in the variable should be 0x41bba752 based in IEEE. So, if I shift those bits into the variable, why do I get such strange results? As I said, if I load the variable with 23.4567 and then use the method listed above, the LCD will have 23.4567 on it, but when I shift the bits into the variable and perform the above function, the LCD gives me nonsense. Is there a reason for this that I am
  14. int i, f; float fnum = 0x41bba752; // this should be 23.4567 i = float32_to int32(fnum); lprintf("%d",i); lprintf("."); f = float32_to_int32(float32_mul(float32_sub(fnum,float32_from_int32(i)),10000)); lprintf("%d".f); I am attempting to recombine a set of 4 bytes sent via I2c into a floating point number. I can see the 4 bytes being transferred using a logic analyzer and they are correct for the number I am transferring, but I can't get the recombined number to diaply correctly, so I tried to just load the floating point number as a hex value and I get garbage on the LCD. Here's what I'm
  • Create New...