http://forums.leaflabs.com/topic.php?id=2477 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:06:10 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=2477#post-12786 Tue, 21 Aug 2012 23:41:23 +0000 Anonymous 12786@http://forums.leaflabs.com/ <p>Doing a simple program again allowed SerialUSB to read while the interrupts were enabled. Trying to enable them on my full sketch caused a lockup at various points, or at least, it appeared to lock up because the LCD display was not updating. I'll have to poke around a bit to find out why. I think we can write this one off as poor coding on my behalf. Thanks for the help and pointers though. :) </p> http://forums.leaflabs.com/topic.php?id=2477#post-12783 Tue, 21 Aug 2012 22:24:12 +0000 Anonymous 12783@http://forums.leaflabs.com/ <p>Sure, I'll give it another stab. I'm going to try switching back to hardware SPI for the controller now that I have a cleaner circuit, it may be less prone to timing issues.</p> <p>Kinda sucks being a C++ noob though. I find myself completely re-writing large chunks of code as I learn better ways of doing things, but hey, that's learning for ya. Interesting problem I had was the menu system. That is a subject for another thread altogether, since it will either provoke laughter or horror when people see how I handled it. :) </p> http://forums.leaflabs.com/topic.php?id=2477#post-12775 Tue, 21 Aug 2012 17:09:49 +0000 mbolivar 12775@http://forums.leaflabs.com/ <blockquote><p> the interrupt should never fire between the pause and resume commands, correct?</p> </blockquote> <p>that's correct. pausing the timer should prevent the counter from increasing, which should prevent any output compare interrupts from firing.</p> <p>can you post a short but complete program exhibiting the bad behavior? i'll try to reproduce and debug. (replacing the bit-banged SPI interrupt with a short delay might work.) </p> http://forums.leaflabs.com/topic.php?id=2477#post-12772 Tue, 21 Aug 2012 15:45:17 +0000 pici 12772@http://forums.leaflabs.com/ <p>Just a guess - i didn't follow your conversation completely - but had similiar problems with measuring time via irq. For me it worked out to add a delayMicroseconds(10) into loop().<br /> So may be you add delayMicroseconds(10) after Timer3.pause(). </p> http://forums.leaflabs.com/topic.php?id=2477#post-12770 Tue, 21 Aug 2012 15:37:36 +0000 Anonymous 12770@http://forums.leaflabs.com/ <p>Yup, pinMode was set to output. </p> <p>Maybe I do not understand the use of Timer for interrupts. I would think that I could simply call Timer3.pause() after attaching Timer3 to my interrupt handler to prevent the Maple from polling the input device. I tried to work around this by doing the following within loop()...</p> <pre><code>Timer3.pause(); if (SerialUSB.available()) { digitalWrite(LEDpin, HIGH); command = SerialUSB.read(); processCommand(command); command = 0; } Timer3.resume();</code></pre> <p>I still get no LED when I bash away at the keyboard while attached to SerialUSB. Interestingly enough, if I add debugging output via SerialUSB to my polling function, I get expected debugging output whenever the interrupt is triggered, just no input from SerialUSB apparently. I don't understand why the above code does not work, however, because the interrupt should never fire between the pause and resume commands, correct? </p> http://forums.leaflabs.com/topic.php?id=2477#post-12761 Tue, 21 Aug 2012 13:34:15 +0000 mbolivar 12761@http://forums.leaflabs.com/ <blockquote><p> - returning immediately from the timer interrupt so that it does nothing? Did the SerialUSB.read work?<br /> - not doing the bit-banging SPI, only the debugging, so it returns much faster? </p></blockquote> <p>These are good ideas; please report the results.</p> <blockquote><p> Regarding the serialUSB.read question, the following failed to trigger the LED, so I would assume that it did not work. </p></blockquote> <p>Just as a sanity check, you did call <code>pinMode(BOARD_LED_PIN, OUTPUT)</code>, yes? </p> http://forums.leaflabs.com/topic.php?id=2477#post-12699 Sun, 19 Aug 2012 19:24:25 +0000 Anonymous 12699@http://forums.leaflabs.com/ <p>I cannot use the SPI peripheral because it is apparently too fast for my device. One thing I did not think of doing is adding an entry in the hardware SPI library to lower the speed one more time. </p> <p>I used the exact same hardware setup for bit banged and hardware-SPI, just loaded different sketches. When I look at the logic analyzer traces for the hardware and bit-banged solutions, CLK, SS, and MOSI are identical except for the fact that the hardware solution is about 10% faster. MISO, however, is not being driven by my SPI slave and I can only assume that it is because it does not acknowledge the communication attempts from the master.</p> <p>I will try to take another stab at it and see if an immediate return from the timer interrupt still causes a problem with SerialUSB. Regarding the serialUSB.read question, the following failed to trigger the LED, so I would assume that it did not work.</p> <pre><code>if (SerialUSB.available()) { digitalWrite(LEDpin, HIGH); command = SerialUSB.read(); processCommand(command); command = 0; }</code></pre> http://forums.leaflabs.com/topic.php?id=2477#post-12694 Sun, 19 Aug 2012 09:21:17 +0000 gbulmer 12694@http://forums.leaflabs.com/ <p>jwestervelt - what have you done to identify the defect causes?</p> <p>For example, have you tried:<br /> - returning immediately from the timer interrupt so that it does nothing? Did the SerialUSB.read work?<br /> - not doing the bit-banging SPI, only the debugging, so it returns much faster?<br /> What happens?</p> <p>Is there a reason for not using the SPI peripheral to do the transfer? </p> http://forums.leaflabs.com/topic.php?id=2477#post-12634 Sat, 18 Aug 2012 20:58:57 +0000 Anonymous 12634@http://forums.leaflabs.com/ <p>I have a quick question regarding using interrupts. I am using one of the timers to attach an interrupt handler to poll my SPI device (Playstation2 controller) since there is no way for the SPI device to trigger an external interrupt. I want to poll this device approximately 100 times a second.</p> <p>I have the interrupt handler working as expected, and the entire handler takes 0.8mS to execute (The device is slow, has to be bit-banged at about 100kHz). I left the overflow at 65535, but set the pre-scalar at 10 so that it will overflow about 110 times a second, roughly what my desired polling rate is. For debugging, I am dumping stuff over SerialUSB configured at 115200baud. Everything works as expected.</p> <p>The gotcha, however, is that I am trying to also send commands to the Maple via SerialUSB and doing something like</p> <pre><code>if (SerialUSB.available()) { command = SerialUSB.read(); processCommand(command); command = 0; }</code></pre> <p>I notice that the processCommand does not appear to get called. In fact, I can set the LED pin high right before i do the SerialUSB.read() and the LED never triggers. This tells me that Maple never sees data in the SerialUSB buffer. :(</p> <p>Granted, I will not be using SerialUSB in the finished project, I am only using it for debugging. I am curious, however, as to why it is not working as expected. </p>