JayWeeks

Members
  • Content Count

    19
  • Joined

  • Last visited

  • Days Won

    3

JayWeeks last won the day on January 24 2017

JayWeeks had the most liked content!

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 programming the bootloader, I had the VV Select jumper set to something other than UART. That's all. I've reprogrammed the bootloader and now everything works fine. Thanks for the help @james!
  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 its connection to chipKit was getting more distant.
  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; period = period * frequency; period = CLOCK_FREQ / period; and this works. Now my function reliably sets the timer interrupt to the desired frequency. Also, for those interested types, you can check out the full tutorial I made from this work.
  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 register manipulation functions(?) that I use to set my timers up previously. I know they work, but I only found them in a tutorial that doesn't explain where they come from, or much about them at all. So I have the following questions: Am I allowed to do register manipulation for more than just timers? Where can I find more information about how ChipKIT Core uses and defines these things? What am I doing wrong with my code? /******************************** Constants ********************************/ #define T3CON_ENABLE_BIT 0x8000 #define T3CON_PRESCALER_BITS 0x0070 #define T3_SOURCE_INT 0 #define OC4_ENABLE_BIT 0x8000 #define OC4_TIMER_SEL_BIT 0x0008 #define OC4_MODE_BITS 0x0007 #define OC4_MODE_PWM_SET 0x0006 // Prescaler values // Don't change these. Set the prescaler below using these. #define T3_PRESCALE_1_1 0 #define T3_PRESCALE_1_2 1 #define T3_PRESCALE_1_4 2 #define T3_PRESCALE_1_8 3 #define T3_PRESCALE_1_16 4 #define T3_PRESCALE_1_32 5 #define T3_PRESCALE_1_64 6 #define T3_PRESCALE_1_256 7 // Set the prescaler value we want to use #define PRESCALE T3_PRESCALE_1_256 // Current it's set to 1:256 // The DP32 runs at 40 MHz // The uC32 and WF32 run at 80 MHz #define CLOCK_FREQ 40000000 // Right now we're set for the DP32 // Set our target frequency // This is the frequency that our interrupt will run at in Hz #define T3_FREQUENCY 5 void setup() { uint32_t period; uint32_t cycle; uint32_t mask; // Disable everything T3CONCLR = T3CON_ENABLE_BIT; // Turn the timer off OC4CONCLR = OC4_ENABLE_BIT; // Turn OC4 off RPB2R = 0b0101; // Calculate the period we need for our given frequency if (PRESCALE == 7) period = 256; // 1:256 is a special case else period = 1 << PRESCALE; period = period * T3_FREQUENCY; period = CLOCK_FREQ / period; // Set up our timer T3CONCLR = T3CON_PRESCALER_BITS; // Clear the old prescaler mask = PRESCALE << 4; // Shift our new prescaler mask = mask | T3CON; // Mask our prescaler T3CON = mask; // Set the prescaler TMR3 = 0; // Clear the counter PR3 = period; // Set the period // Calculate our cycle cycle = period /2; // We want a 50% duty cycle // Set up our output compare OC4CONSET = OC4_TIMER_SEL_BIT; // Select timer 3 for source OC4CONCLR = OC4_MODE_BITS; // Clear our mode pins OC4CONSET = OC4_MODE_PWM_SET; // Set our mode to PWM w/out fault pin OC4R = cycle; // Set our cycle // Enable everything T3CONSET = T3CON_ENABLE_BIT; // Turn the timer on OC4CONSET = OC4_ENABLE_BIT; // Turn OC4 on } void loop() { }
  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 fantastic. I suspect that my previous code was setting the TCS bit (bit 1) to 1, which would select an external clock as the source. With no external clock implemented, the timer would freeze up. Still no idea why this would cause the LSB LED to light up though. However, the screwy behavior persists. My LEDs blink too fast and when I change the prescaler, the speed changes, even though my code should prevent that. Updated code: /*************************************************************** * Define some constants ***************************************************************/ #define CLOCK_FREQ 40000000 #define T3CON_ENABLE_BIT 0x8000 #define T3_SOURCE_INT 0 // Prescaler values // Don't change these. Set the prescaler below using these. #define T3_PRESCALE_1_1 0 #define T3_PRESCALE_1_2 1 #define T3_PRESCALE_1_4 2 #define T3_PRESCALE_1_8 3 #define T3_PRESCALE_1_16 4 #define T3_PRESCALE_1_32 5 #define T3_PRESCALE_1_64 6 #define T3_PRESCALE_1_256 7 // Prescaler bit mask #define T3_PRESCALE_MASK 0b01110000 /*************************************************************** * Set our prescaler ***************************************************************/ #define PRESCALE T3_PRESCALE_1_32 /*************************************************************** * Various Variables ***************************************************************/ volatile uint32_t count = 0; volatile unsigned int flag = 0; int mask = 0; // This isn't used as a mask, but I can't bother to come up with a better name. /*************************************************************** * ISR ***************************************************************/ void __attribute__((interrupt)) myISR() { count++; flag = 1; clearIntFlag(_TIMER_3_IRQ); } /*************************************************************** * Timer and interrupt setup function ***************************************************************/ void start_timer_3(uint32_t frequency) { uint32_t period; period = CLOCK_FREQ / (1<<PRESCALE * frequency); // This formula isn't correct for prescaler 1:256 T3CONCLR = T3CON_ENABLE_BIT; // Turn the timer off mask = PRESCALE << 4; // Shift our prescale mask = mask | T3CON; // Mask our prescaler T3CON = mask; // Set the prescaler TMR3 = 0; // Clear the counter PR3 = period; // Set the period T3CONSET = T3CON_ENABLE_BIT; // Turn the timer on } /*************************************************************** * Setup ***************************************************************/ void setup() { start_timer_3(20); setIntVector(_TIMER_3_VECTOR, myISR); setIntPriority(_TIMER_3_VECTOR, 4, 0); clearIntFlag(_TIMER_3_IRQ); setIntEnable(_TIMER_3_IRQ); pinMode(PIN_LED1, OUTPUT); pinMode(PIN_LED2, OUTPUT); pinMode(PIN_LED3, OUTPUT); pinMode(PIN_LED4, OUTPUT); } /*************************************************************** * Loop ***************************************************************/ void loop() { if (flag) { digitalWrite(PIN_LED4, HIGH); if (count & 0b000100000) digitalWrite(PIN_LED1, HIGH); else digitalWrite(PIN_LED1, LOW); if (count & 0b001000000) digitalWrite(PIN_LED2, HIGH); else digitalWrite(PIN_LED2, LOW); if (count & 0b010000000) digitalWrite(PIN_LED3, HIGH); else digitalWrite(PIN_LED3, LOW); flag = 0; } else digitalWrite(PIN_LED4, LOW); }
  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 (respectively, with bit 0 as the LSB) of the count variable. LED 1 is toggled to represent the flag variable, so if the flag is high the LED is turned on, and it is turned off if the flag is low. The behavior I am getting with the prescaler set to 1:32 is as expected. LED 4 glows dimly, while LEDs 1 through 3 count rapidly upward in binary. However, when the prescaler is set to 1:64, LED 1 (bit 5 LED) is toggled on, and remains, while the rest of the LEDs are off. This includes LED 4 (the flag LED) which leads me to believe that the flag is not being raised. As for how or why LED 1 gets toggled on, I have no idea. I also mentioned some unusual behavior earlier. The the function that sets my timer accepts a desired interrupt frequency, and accounts for the prescaler when calculating the period needed to achieve this frequency. This means that the interrupt frequency should not vary much between different prescaler values. However, when I set my prescaler to 1:16, and my interrupt frequency to 40 Hz, the actual interrupt frequency is slower than when I set my prescaler to 1:32 (with an interrupt frequency of 40 Hz). In fact, prescaler 1:32 is so much faster that I cannot make out the individual LED flashes for any of my indicator LEDs. What's more, the LEDs are running much faster than they should. With prescaler set to 1:32, and interrupt frequency set to 20 Hz, the frequency on the LED 1 (tied, as you recall, to bit 5 of my counter) should be 0.625 Hz (that is, 20 Hz / 2^4). In practice, however, it switches much faster than this. Can anybody tell me what's going wrong? I feel like I'm probably missing something simple and obvious, or just overlooking something regarding the operation of timers. TL;DR Code below: /*************************************************************** * Define some constants ***************************************************************/ #define CLOCK_FREQ 40000000 #define T3CON_ENABLE_BIT 0x8000 #define T3_SOURCE_INT 0 // Prescaler values // Don't change these. Set the prescaler below using these. #define T3_PRESCALE_1_1 0 #define T3_PRESCALE_1_2 1 #define T3_PRESCALE_1_4 2 #define T3_PRESCALE_1_8 3 #define T3_PRESCALE_1_16 4 #define T3_PRESCALE_1_32 5 #define T3_PRESCALE_1_64 6 #define T3_PRESCALE_1_256 7 // This was originally going to test a /*************************************************************** * Set our prescaler ***************************************************************/ #define PRESCALE T3_PRESCALE_1_32 /*************************************************************** * Various Variables ***************************************************************/ volatile uint32_t count = 0; volatile unsigned int flag = 0; int mask = 0; /*************************************************************** * ISR ***************************************************************/ void __attribute__((interrupt)) myISR() { count++; flag = 1; clearIntFlag(_TIMER_3_IRQ); } /*************************************************************** * Timer and interrupt setup function ***************************************************************/ void start_timer_3(uint32_t frequency) { uint32_t period; period = CLOCK_FREQ / (2^PRESCALE * frequency); // This formula isn't correct for prescaler 1:256 T3CONCLR = T3CON_ENABLE_BIT; // Turn the timer off T3CON = PRESCALE; // Set the prescaler TMR3 = 0; // Clear the counter PR3 = period; // Set the period T3CONSET = T3CON_ENABLE_BIT; // Turn the timer on } /*************************************************************** * Setup ***************************************************************/ void setup() { start_timer_3(20); setIntVector(_TIMER_3_VECTOR, myISR); setIntPriority(_TIMER_3_VECTOR, 4, 0); clearIntFlag(_TIMER_3_IRQ); setIntEnable(_TIMER_3_IRQ); pinMode(PIN_LED1, OUTPUT); pinMode(PIN_LED2, OUTPUT); pinMode(PIN_LED3, OUTPUT); pinMode(PIN_LED4, OUTPUT); } /*************************************************************** * Loop ***************************************************************/ void loop() { if (flag) { digitalWrite(PIN_LED4, HIGH); if (count & 0b000100000) digitalWrite(PIN_LED1, HIGH); else digitalWrite(PIN_LED1, LOW); if (count & 0b001000000) digitalWrite(PIN_LED2, HIGH); else digitalWrite(PIN_LED2, LOW); if (count & 0b010000000) digitalWrite(PIN_LED3, HIGH); else digitalWrite(PIN_LED3, LOW); flag = 0; } else digitalWrite(PIN_LED4, LOW); }
  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 out what is happening. When I applied my LED probe to the two pins (anode to 3.3V, cathode to pin 7) the anode reads 3.3 V, and the cathode reads 2.0 V. This means that, when the pin is acting as an input, it assumes whatever voltage is applied to it, and returns to 0 when the voltage is removed. That means that an LED logic probe won't light up, so it looks like the pin is being pulled low when it really isn't. This makes sense, because you don't want your inputs to allow much current to flow, as that would change the circuit. Now, if you need pin 7 to be pulled high for your hardware to work, you can use the code above which sets pin 7 as INPUT_PULLUP. That will make the board pull the pin up to 2.2 V. (I don't know why it only pulls up to 2.2 volts. Every other pin I've used INPUT_PULLUP on pulls up to 3.3 V.) You might also consider running a pullup resistor from 3V3 to pin 7 with a fairly high resistance. Otherwise, if your hardware is capable of pulling pin 7 high on its own for the clock signal, it should be working just fine. If it's not then I am officially stumped and I'll escalate this to someone who knows more about these boards than I do.
  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 pin down and not up. Now, I haven't gone through this code to fully understand it yet. This was just the first thing I tried and I'm seeing pin 7 is being pulled high. Please let me know if this solves your problem or not, and then I'll dive back in and see what else I can find. PS. For clarity, here's my edited setup() with the two lines of code I added/edited, marked with outlandishly large arrows. These are the only lines of code I changed. void setup() { delay(1000); // wait for USB enumeration; this is really only important for the DP32 board; others probably would not need it Serial.begin(115200); pinMode(PIN_LED1, OUTPUT); // enable use of LED1 pinMode(PIN_LED2, OUTPUT); // enable use of LED2 pinMode(7, INPUT_PULLUP); // <-----------------This line of code // set up text buffer and offset calculations offset1 = 2*numbersize; offset2 = 3*numbersize; offset3 = 4*numbersize; offset4 = 5*numbersize; offset5 = 6*numbersize; offset6 = 7*numbersize; offset7 = 8*numbersize; // set up pps pin for external counters T3CKR = 0b0001; T5CKR = 0b0001; // <-----------------This line of code // Set up counters OpenTimer1( T1_ON | T1_SOURCE_INT | T1_PS_1_1, 0xFFFF); // internal clock based counter (1) OpenTimer3( T3_ON | T3_SOURCE_EXT | T3_PS_1_1, 0xFFFF); // timer for MEAS on RPB5 using T3CK PPS pin (2) OpenTimer5( T5_ON | T5_SOURCE_EXT | T5_PS_1_1, 0xFFFF); // timer for on RPB9 using T5CK PPS pin (3) // set up interrupt for internal timer setIntVector(_TIMER_1_VECTOR,handlerForTimer1Ints); // Configure interrupt for (1) ConfigIntTimer1( T1_INT_ON | T1_INT_PRIOR_1); // enable interrupt for (1) INTEnableSystemMultiVectoredInt(); // turn on all interrupts }
  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 it off and the one to set its voltage, which may let you solve this problem yourself. What I can't figure out is what would be activating CVref. Can you think of anything your code might be using comparators for? Again, it would be helpful to see your actual code so I can see what it is you're using this for. Anyway, I'm going to keep reading reference manuals to see if I can't figure out what's going on! If I can't figure it out, I'll escalate this to someone who can!