JayWeeks

Members
  • Content Count

    19
  • Joined

  • Last visited

About JayWeeks

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Location
    Pullman/Seattle WA
  • Interests
    Making robots out of stuff that should never be made into robots.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I've just finished reinstalling the WF32 bootloader onto two of my WF32s, and I'm still getting the "Unable to signon, this does not look like a bootloader" error. I downloaded the bootloader from here: https://reference.digilentinc.com/reference/microprocessor/wf32/start I used chipKIT programmer, and programmed using the MPLAB IPE. The IPE claims that the bootloader was verified, so I'm wondering if there's maybe a problem with the bootloader I'm using. Either that or maybe the FTDI is busted? EDIT: I've figured out the problem and of course it was something stupid. While
  2. That sounds about right. I thought that I'd checked all my WF32s to make sure they had the correct boot-loader, but I just tried a uC32 and a Cerebot MX3cK and those worked fine. It's probably the boot-loader then. Thanks! I'll look into how to fix that.
  3. That's great to hear! I've installed it, but unfortunately I'm still getting errors. On Arduino 1.8.5 and 1.6.13, the code compiles, but does not seem to be able to upload. On Arduino 1.6.9 (recommended) I get a compiler error. I've copied the error message for both below. Additionally, the board's port is reliably detected when it is plugged into the computer before I start up Arduino. If I plug the board in after Arduino has started, it is not detected at all.(Arduino 1.8.5 and 1.6.13, verbose) (Arduino 1.6.9, verbose)
  4. I'm having the same problem. Most of the time, Arduino can't even detect my microcontroller's port. When it does, I get the "No Target Found" error (pic attached). I'm on Arduino 1.8.5. I've also tried 1.6.9 (which I believe is the recommended version) and 1.6.13 (which has worked for me well enough). chipKit core 2.0.3. I'm on Mac 10.13.3 (which is probably my issue). I have an additional question though. Would it be more reliable to switch to MPLAB? Arduino has been consistent enough for me, but last I heard Digilent was moving its focus away from the microcontrollers and
  5. Yeah! At some point I'm going to try playing with Fourier transforms and digitizing recordings. I've got another (related) project involving a toy keyboard that I've disassembled.
  6. I'm just playing around for now but in the future I have vague notions of learning music theory.
  7. Probably, but now that I've got it working I've stopped fiddling with it. Thanks for the suggestion tho!
  8. So I finally figured out my problem, and like all truely frustrating problems it was small and stupid. The formula I used to calculate period: period = CLOCK_FREQ / (1<<PRESCALE * frequency); while mathematically correct, for some reason my usage of defined constants throws the compiler for a loop. The result is that my period was (apparently?) set to 40 MHz every time. I fixed this by breaking it up into components: // Calculate the period we need for our given frequency if (PRESCALE == 7) period = 256; // 1:256 is a special case else period = 1 << PRESCALE;
  9. I'm playing around with timer interrupts on the DP32 using Arduino and the ChipKIT Core. I was surprised to find out that this involves register manipulation. So I can set up timers using register manipulation in Arduino, but I can't seem to do anything else with register manipulation. For example, here is some code of mine which should set up a PWM signal on pin 13 (OC4) of the DP32 using register manipulation, instead of analogWrite() function. Problem is that it doesn't work and I can't figure out why. This problem is exacerbated by the apparent lack of documentation on any of the regi
  10. I was doing some things wrong, so here's some code fixes. Line 52: Carrots "^" are used as bitwise XOR, not power functions. Dunno why I thought they were power functions, but I've changed it to a bitshifted 1 instead. Line 55: I swear the example code I pulled this from just set T3CON to whatever the desired prescaler was. I thought this was screwy but I never questioned it. I've since questioned it. Now I've shifted my prescaler and masked my prescaler onto T3CON. My main problem (i.e. the timer not functioning when prescaler is set to 1:64 or 1:256) has gone away, so that's f
  11. I'm using Arduino 1.6.9 with ChipKIT core and a DP32 rev B. My code sets up an interrupt for timer 3. When I set the prescaler to 1:32 or less, the interrupt runs just fine (although with some quirky behavior that I'll explain below). However, when I set the prescaler to 1:64 or 1:256, the interrupt appears to fail. My code is included below but I'll provide a brief explanation of its function here. The ISR increments a count variable, and sets a flag variable to high. The loop checks to see if the flag is high. If it is, it toggles LEDs 1, 2 and 3 to represent bits 5, 6, and 7 (resp
  12. Well I'm glad you've got a working solution. I wish I could have helped you find a more long term solution. I think I can definitively say that my expertise has been totally tapped out, so I have no idea why your LED lights up when mine doesn't! Ha ha! Good luck with your project!
  13. Sorry for the long delay, I was taking some time to investigate a little more closely. I think the problem may lie with your logic probe actually. Have you been using a voltmeter to measure things at all? I found some kind of weird behavior when I did. I built a logic probe similar to the one you described, an LED with a resistor and anode to 3.3 V. When I load code to the board where I only change TCK5 from pin 3 (RPB9) to pin 7 (RPB14), I see what you saw, my LED was dark. However, when I measured the voltage with my voltmeter, it read as 0.0 V. This was very puzzling, but I finally figured
  14. Wow! You're using this for an interferometer? Neat! What are you doing? I think this problem may be simpler than we realize. Try using: pinMode(7, INPUT_PULLUP); instead of pinMode(7, INPUT); Let me know if that solves your problem. Normally, inputs are pulled down, which is what I saw when I ran the code with the edits you suggested. It actually took me by surprise, because I had been working this problem assuming that your DP32 had been pulling your TCK5 pin up and that was the problem. I had to re-read your original post to realize that your problem was that your DP32 was pulling the pi
  15. I've been fiddling with the DP32 for a while now, and I'm working on answering your question. When I read your problem I was a little shocked actually. I didn't think you could change which pin TCK5 used as an input. I'm learning something new here. Would you mind providing your code so I can see what you're doing? What I've found so far is that pin7 (RB14) is also shared by CVref. CVref is the Comparator Reference Voltage, you can read about it in section 23 of the PIC32MX1xx/2xx reference manual from the Microchip website. That will give you it's control registers, including the one to turn