From: Christopher C. <chr...@gm...> - 2010-02-09 21:44:25
|
you are of course very very clear in each of your steps :) On Tue, Feb 9, 2010 at 2:34 PM, Paul Stoffregen <pa...@pj...> wrote: > Christopher Coleman wrote: > >> Paul, your USB test did not test the two button jamming issue as far I can >> understand. releasing one button after two were pressed at the same time >> should not send bytes 0x90, 0x00, 0x00. >> > > I'm sorry, I should have been more clear. This test was done using the > hardware as described in the previous message. Pins 2 and 3 were shorted > together. When I press a single button (either one), the bytes 0x90, 0x0C, > 0x00 are sent, and when I release it, 0x90, 0x00, 0x00 are sent. Pduino > should show both pins 2 and 3 go high in response to the first message, but > it shows only pin 2 going high. That is definitely a bug on the host side. > > We have eliminated the issue you describe above from maxuino thankfully, as it seems to properly catch all such events. > > > I am watching the raw out put from >> the serial object in Max when doing my designs as well as watching the rx >> and tx leds on the arduino and there definitely is no data (no led >> blinking >> on the arduino) being sent when 2 pins on the same port go high at the >> same >> time and then one of them goes low. >> > > I tried to reproduce this, but could not. Here is what I tried: > > This is with the '328 Arduino, running StandardFirmata shipped with 0018. > I loaded Pduino, established communication, set pins 2 and 3 to input mode > and enabled reporting of port 0. Pins 2 and 3 were still shorted together, > with a pushbutton to Vcc and resistor to ground connected to each pin. > > I press and hold button 2, and the Tx LED flashes. While continuing to > hold button 2, I press and hold button 3. No LED flash, which is expected > since it's already high due to the short between the pins. Then, while > continuing to hold both buttons down, I removed the short between the pins. > When I release button 3, the Tx LED flashes. When I release button 2, it > flashes again. I did not set up the protocol analyzer to capture the data > during this test. > > > > this is the exact setup and steps I have taken and there is no signal from my arduino when i release button three. But i have suddenly realized that i was testing by pulling the wire but to do it properly i need to make sure it that pin is then grounded, not just without input. This is probably the cause of my (self imposed by sloppyness) bug. I will continue testing and clarifying and very much appreciate your work/help. > This may be an arduino hardware >> limitation, i dont know. >> >> > > I know it's a lot of typing, but perhaps you could give me very specific > test steps to reproduce the "no data being sent" problem you're seeing. I > tried as best I could from your description, and I've tried to explain the > exact setup and steps I used. I must be missing something? Without more > detail, I just do not know how to reproduce the problem. > > > > chris >> >> On Tue, Feb 9, 2010 at 10:27 AM, Paul Stoffregen <pa...@pj...> wrote: >> >> >> >>> As a further followup, I connected my USB protocol analyzer and watched >>> the >>> communication. >>> >>> At the button press, Firmata is sending the bytes 0x90, 0x0C, 0x00 and at >>> the button release bytes 0x90, 0x00, 0x00. Both Arduino running 0018's >>> code >>> and Teensy running the hardware abstraction branch send exactly these >>> same >>> (correct) bytes. The FTDI chip also sends a LOT of unnecessary >>> handshake >>> info which makes looking through USB protocol packet logs quite tedious >>> with >>> Arduino..... >>> >>> Since the bytes on the wire are correct, I'm going to suggest this is >>> likely a bug (common to both Pduino and Maxuino) in parsing the 8 bit >>> port >>> messages into individual bit change messages. Perhaps it only emits a >>> single pin change message when the port changes, rather that potentially >>> up >>> to 8 pin change messages? >>> >>> This is as far as I intend to investigate this bug. I'm going to leave >>> the >>> Max and Puredata stuff to you and HC. >>> >>> >>> -Paul >>> >>> >>> >>> >>> I am writing some major re-writes to the Maxuino project with Ali >>> Momeni, >>> >>> >>>> and we have come across a bug perhaps. When more than one digital pin >>>>> is >>>>> pressed at the same time on the same port, and one is then released, no >>>>> signal is sent by the arduino until both go back to low. >>>>> >>>>> >>>>> >>>>> >>>> I did some quick tests and was able to reproduce a similar problem. >>>> Here >>>> is exactly what I did. >>>> >>>> On a standard Arduino, I loaded StandardFirmata which is included with >>>> 0018. On pins 2 and 3, I connected 4.7k resistors to ground and >>>> pushbuttons >>>> to +5 volts. I ran Pduino on Linux. This copy of Pduino has some >>>> patches >>>> Hans sent me, plus a few tweaks I've made to add more pins for Teensy, >>>> but >>>> since this is testing the Arduino side, I didn't worry about getting a >>>> clean >>>> Pduino. >>>> >>>> I selected the serial port, and clicked "firmware" and "version" to >>>> confirm Firmata was there. I clicked the mode buttons for pins 2 and 3, >>>> then clicked the button for reporting of port 0. Then I tried pressing >>>> each >>>> pushbutton while watching the boxes in the lower right corner. Indeed >>>> each >>>> button press caused boxes 2 and 3 to indicate the state of the button. >>>> I >>>> tried several times to press both buttons at the same moment, but always >>>> the >>>> boxes showed the correct state. >>>> >>>> Then I connected a clip lead to short pins 2 and 3 together. Pressing >>>> either button then caused only pin 2 to register in Pduino. Both >>>> buttons >>>> would cause pin 2 to change and pin 3 would never change. I even >>>> connected >>>> a voltmeter to pin 3 (still shorted to pin 2) and watched the voltage >>>> reading change while the Pduino GUI showed only pin 2 changing. >>>> >>>> I also repeated this test with a Teensy using the new hardware >>>> abstraction >>>> code and I got exactly the same wrong behavior. >>>> >>>> So far, I have not looked into why this is happening. However, I can >>>> confirm this is definitely a reproducible bug. I will investigate >>>> shortly. >>>> >>>> I did not (yet) investigate the timing problem you mentioned. >>>> >>>> >>>> >>>> >>>> >>>> >>>>> and if one stays on >>>>> and a pin in another port goes on and off the off signal has a nearly >>>>> half >>>>> second lag. this is with the arduino 18 ide verson of firmata with a >>>>> decimilia 328. Can anyone confirm? >>>>> chris >>>>> >>>>> >>>>> On Wed, Feb 3, 2010 at 7:38 AM, Paul Stoffregen <pa...@pj...> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Thanks! Definitely testing is needed. Hopefully there will be plenty >>>>>> of time to get it well tested before Arduino 0019 or 1.0. >>>>>> >>>>>> Other than documentation, I believe the hardware abstraction branch >>>>>> should be pretty close to its final form. >>>>>> >>>>>> I do have a question on writing to digital pins. Should the pins be >>>>>> "writable" if they're in input mode? Writing turns the pullup >>>>>> resistor >>>>>> on and off. Currently in the digitalWriteCallback: >>>>>> >>>>>> if (pinConfig[pin] == OUTPUT || pinConfig[pin] == INPUT) { >>>>>> pinWriteMask |= mask; >>>>>> } >>>>>> >>>>>> Then pinWriteMask is used to only change the "writable" pins on that >>>>>> port. Should input pullup resistors be controlled this way? It's >>>>>> very >>>>>> AVR specific. Would a separate pin mode for input pullup make more >>>>>> sense, and disallow writing when configured for input mode? >>>>>> >>>>>> >>>>>> -Paul >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Shigeru Kobayashi wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi Paul, >>>>>>> >>>>>>> First of all, thank you very much for your really interesting >>>>>>> suggestions. I'm sorry I have been silent regarding this issue. I >>>>>>> have >>>>>>> been up to my ears in urgent projects, but I just checked out the >>>>>>> branch. I'll test with a Duemilanove and a Teensy board and report >>>>>>> here if I find anything ASAP. >>>>>>> >>>>>>> Best, >>>>>>> Shigeru >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> The Planet: dedicated and managed hosting, cloud storage, colocation >>>>>> Stay online with enterprise data centers and the best network in the >>>>>> business >>>>>> Choose flexible plans and management services without long-term >>>>>> contracts >>>>>> Personal 24x7 support from experience hosting pros just a phone call >>>>>> away. >>>>>> http://p.sf.net/sfu/theplanet-com >>>>>> _______________________________________________ >>>>>> Firmata-devel mailing list >>>>>> Fir...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/firmata-devel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> The Planet: dedicated and managed hosting, cloud storage, colocation >>>> Stay online with enterprise data centers and the best network in the >>>> business >>>> Choose flexible plans and management services without long-term >>>> contracts >>>> Personal 24x7 support from experience hosting pros just a phone call >>>> away. >>>> http://p.sf.net/sfu/theplanet-com >>>> _______________________________________________ >>>> Firmata-devel mailing list >>>> Fir...@li... >>>> https://lists.sourceforge.net/lists/listinfo/firmata-devel >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> > > |