• Content Count

  • Joined

  • Last visited

  1. Thanks. At least we both learned something in the process. I'd welcome a suggestion of how to contact someone who might know. They have obviously been ignoring our exchange. Cheers! --- sam
  2. Hi: I was wondering where you went. It's not the logic probe. The problem first showed up when I switched from RPB9 to RPB14 due to RPB9 conflicting with something to do with the I2C bus, which I need for some sensors. RPB14 was loading the output of the line receiver driving that pin and it would never go high. So, RPB14 is pulling down hard. But what I'd like to know is if using any of your proposed fixes whether a logic probe using an LED+1.5K with anode to 3.3 V and cathode to RPB14 is not lit? It's always lit for me except during reset. For now I have gotten around it by using RPB0. This works fine and behaves exactly as expected. The only downside is that RPB0 is also LED4 so it's no longer avilabable to stare at. RPB1 also works (but is also LED3.) For that reason, I'm still interested in a long term solution. Thanks for your continuing support and curiosity about something that will probably never affect you directly in a thousand years! --- sam
  3. To clarify, did you actually confirm the problem I saw? That 7 is being pulled low/down/0/whatever? And that you added/changed those lines of code and now 7 (pin 25 of the IC) is is not being pullded down? I was getting used to your orignial idea about CVREF. And there aer some very strange comments in the manual on the CVREF page about when and if it's actually possible to configure outputs. I just tried it on the same version of the code and it made no difference. Testing with a red LED anode to 3.3 V with 1.5K ohm resistor. As for the interferometer, check out: You can test drive the a version of the Windows GUI by saving IT will NOT be compatible with the version of the firmware you have but you don't have the interferometer hardware anyhow. However, it has a "Test Mode" where it simulates the effects of the displacmeent measuring interferometer in action. The real thing can now detect changes in position in the 1 nm range. I can sit here two floors up using Remote Desktop and know when the laptop attached to it turns on its cooling fan due to thermal effects on length and vibration. Or, tap on my desk and see vibrations register in the plot. --- sam
  4. I can guarantee I'm more of a newbie at this than you! Here is a link to a version of the code that has this problem: That should compile and have the problem even though it's not using RPB14 at all. As you can see, there isn't much to it And the only internal peripheral hardware it uses are the Timers. I use an LED to 3.3V with a 1.5K resistor as a logic probe on (silkscreen) pin 7 Always on (low) except when RESET is pressed and for about 0.5 second after releasing it. I have tried stuff like pinmode(7,input); RPB14R = 0b0000; with no change. Also tried disabling interrupts on the off chance something buried in the bowels of ISR dispatch was screwing with it. As well as commenting out just about all code except for the setup. Not sure how to set the control register for CVREF, the compiler doesn't like any of the names I've tried in the manual. And as I noted, it apparently does NOT have this problem when compiled using UECIDE. But I have not been able to confirm because UECIDE hates me even more than MPIDE! I can't anything to compile with that. Thanks, --- sam
  5. Thanks for replying so quickly. Unless there is something else on the chipKIT board that I don't know about, nothing should be using it. On one board that I'm using for testing, there is no additional hardware. I have have added RPB14R = 0b0000; before and after the T5CKR=0b0001; without any change in behavior. I have no knowledge of the CVREF function and it doesn't appear in my code anywhere, my apologies if that should be intuitively obvious. There is no problem moving Timer5 to RBP0, but that would sacrifice the programmed use of LED4. --- sam
  6. Hi: I have been using a chipKit DP32 board under MPIDE for several months now using RPB9 for Timer5 input for an external clock. It works great. but RPB9 conflicts with pins needed for an I2C interface to some sensors. I have attempted to move Timer5 to RPB14 by changing T5CKR = 0b0100; to T5CKR = 0b0001; And no matter what I do, something inside the DP32 insists on driving that pin as an output to low. I've removed just about all the code except for those setup instructions with no change in behavior. RPB14 goes open or high when the RESET button is pressed, but both when the uploader is running and when code starts, reverts to low. This has both been verified with a logic probe and originally because it was pulling down the input signal. I have confirmed that other combinations work. For example, selecting RPB0 (which is also LED4) appears to have the expected result (though that hasn't entirely been confirmed). But I'd rather not sacrifice the use of LED4, and would like to understand what's going on, or report a bug here if that's what it is. :). FWIW, I have been told that the identical code works properly under UECIDE, but UECIDE doesn't like me and attempting to get it to work under Win 7 and compile the same code without errors has so far been elusive. Any info appreciated. Thanks, --- sam