Hi,
With this:
[arduino] | [print ARDUINO]
On Linux, when I open the connection, it prints: ARDUINO: version 2 2 ARDUINO: StandardFirmata_2_2_forUNO_0_3 2 2 ARDUINO: firmware StandardFirmata_2_2_forUNO_0_3 2 2
On Windows (with the very same arduino board), it doesn't print anything!!
Yet everything else works and I do get the data messages from the left inlet of arduino!
How can that be????
On 06/14/2011 09:58 PM, Matteo Sisti Sette wrote:
Hi,
With this:
[arduino] | [print ARDUINO]
On Windows (with the very same arduino board), it doesn't print anything!!
Nothing is even coming out from [comport] when the connection is established (in Windows)!! (but it does print things when data messages are received, such as digital pin data)
It's as if the arduino itself was actually behaving differently on different platforms...
or maybe [comport]. But why would [comport] drop some specific messages? It doesn't even know about "messages", right? It only sees incoming bytes, doesn't it?
I thought I would post the output from [comport] when connecting the arduino, on Windows and on Linux, but it is not always the same. Even if "open"ing a freshly reset arduino (i.e. just after connecting it to the usb port, and without any extra circuitry), the output from [comport] is not always the same.
Furthermore, it seems it is sending digital pin data messages (which may happen randomly since no pin is connected to anything) even if it has never received any "pìnMode" message. Is that expected behavior?
And occasionally I get an UNKNOWN_INPUT_COMMAND: 1 505
On 14/06/11 04:44 PM, Matteo Sisti Sette wrote:
On 06/14/2011 09:58 PM, Matteo Sisti Sette wrote:
Hi,
With this:
[arduino] | [print ARDUINO]
On Windows (with the very same arduino board), it doesn't print anything!!
Nothing is even coming out from [comport] when the connection is established (in Windows)!! (but it does print things when data messages are received, such as digital pin data)
It's as if the arduino itself was actually behaving differently on different platforms...
or maybe [comport]. But why would [comport] drop some specific messages? It doesn't even know about "messages", right? It only sees incoming bytes, doesn't it?
Well maybe you have different versions of [comport]. The 'open' message is output after the [comport] object receives an [info( message from within the Pd patch: it's not related to the arduino.
I thought I would post the output from [comport] when connecting the arduino, on Windows and on Linux, but it is not always the same. Even if "open"ing a freshly reset arduino (i.e. just after connecting it to the usb port, and without any extra circuitry), the output from [comport] is not always the same.
Furthermore, it seems it is sending digital pin data messages (which may happen randomly since no pin is connected to anything) even if it has never received any "pìnMode" message. Is that expected behavior?
Pins default to input. You can often change unconnected pins by moving your charge-carrying body parts near them.
Martin
On 06/14/2011 11:01 PM, Martin wrote:
On 14/06/11 04:44 PM, Matteo Sisti Sette wrote:
On 06/14/2011 09:58 PM, Matteo Sisti Sette wrote:
Hi,
With this:
[arduino] | [print ARDUINO]
Well maybe you have different versions of [comport]. The 'open' message is output after the [comport] object receives an [info( message from within the Pd patch: it's not related to the arduino.
Yes that accounts for the "open" message which would come from [comport]'s right outlet.
But there are other messages sent by the arduino, such as the ones reporting the firmware version, which are being lost.
I've found out that if I send the arduino the "version" message, then these messages _are_ received (also in Windows), while when the Arduino send them just after connecting, they are lost in Windows.
So I think there must be an issue either in the Windows version of [comport] or in the Windows drivers, that if a message is received too soon after connecting, it is lost.
On 2011-06-14 17:45, Matteo Sisti Sette wrote:
On 06/14/2011 11:01 PM, Martin wrote:
On 14/06/11 04:44 PM, Matteo Sisti Sette wrote:
On 06/14/2011 09:58 PM, Matteo Sisti Sette wrote:
Hi,
With this:
[arduino] | [print ARDUINO]
Well maybe you have different versions of [comport]. The 'open' message is output after the [comport] object receives an [info( message from within the Pd patch: it's not related to the arduino.
Yes that accounts for the "open" message which would come from [comport]'s right outlet.
But there are other messages sent by the arduino, such as the ones reporting the firmware version, which are being lost.
I've found out that if I send the arduino the "version" message, then these messages _are_ received (also in Windows), while when the Arduino send them just after connecting, they are lost in Windows.
So I think there must be an issue either in the Windows version of [comport] or in the Windows drivers, that if a message is received too soon after connecting, it is lost.
Yes I've run into that with arduino on MacOSX; the arduino bootloader is active for about 5 seconds after power-up, or whenever the port is opened if you are powering it via USB, so you have to be careful not to send anything through the serial port in the first 5 seconds or the arduino will interpret it as an incoming program.
Martin
On 06/15/2011 12:57 AM, Martin Peach wrote:
I've found out that if I send the arduino the "version" message, then these messages _are_ received (also in Windows), while when the Arduino send them just after connecting, they are lost in Windows.
So I think there must be an issue either in the Windows version of [comport] or in the Windows drivers, that if a message is received too soon after connecting, it is lost.
Yes I've run into that with arduino on MacOSX; the arduino bootloader is active for about 5 seconds after power-up, or whenever the port is opened if you are powering it via USB, so you have to be careful not to send anything through the serial port in the first 5 seconds or the arduino will interpret it as an incoming program.
But I'm talking about the opposite direction. Messages sent from the Arduino to the computer immediately after the connection is established,
- I connect the arduino physically, and wait several seconds, so it is
already powered on and running StandardFirmata 2. In Pd I send the message "open 0" to the [arduino] object
In linux: [comport]'s left outlet outputs some data coming from the arduino, which happen to be the messages telling the firmware version and such
In windows: [comport]'s left outlet doesn't output anything.
So my guess is that the Arduino board, as soon as the connection is established from Pd, immediately sends data. In Linux this data is received and output by [comport], in Windows it is lost. I'm talking about data sent from Arduino to the computer, not viceversa.
My guess may be entirely wrong, of course. It's just the only explanation I can think of.
Note that these messages that the arduino sends (immediately after opening the connection through comport) are NOT being triggered by anything being sent by the [arduino] abstraction to the arduino board through [comport].
A possible explanation, now that I think about it, may be that the Arduino board does not send the firmware version every time a connection is established, but every time it is reset, and for some reason (due to differences in the way drivers work) establishing the connection from Pd in Limux triggers an Arduino reset while establishing the connection from Pd in Windows does not.
Is it so?
Ohhhhhhhh, it may be relevant (though I don't directly see how) that when I test on Windows I do it through a virtual machine (on a linux host which is the one on which i test it in Linux).
On 2011-06-14 19:22, Matteo Sisti Sette wrote:
I've found out that if I send the arduino the "version" message, then these messages _are_ received (also in Windows), while when the Arduino send them just after connecting, they are lost in Windows.
So I think there must be an issue either in the Windows version of [comport] or in the Windows drivers, that if a message is received too soon after connecting, it is lost.
Ohhhhhhhh, it may be relevant (though I don't directly see how) that when I test on Windows I do it through a virtual machine (on a linux host which is the one on which i test it in Linux).
Yes I think that is relevant. I just tried it on WinXP and at least that part works properly. (arduino duemilanove / firmata2.2 / Pduino-0.5beta8) Usually emulators don't do a good job with I/O.
Martin
On 06/17/2011 05:29 PM, Martin Peach wrote:
Ohhhhhhhh, it may be relevant (though I don't directly see how) that when I test on Windows I do it through a virtual machine (on a linux host which is the one on which i test it in Linux).
Yes I think that is relevant. I just tried it on WinXP and at least that part works properly. (arduino duemilanove / firmata2.2 / Pduino-0.5beta8)
Well I've tried again with a _real_ windows (I mean no virtual machine), and the following happens:
- with a Dumelilanove, the arduino resets every time I open the
connection from Pd ("open" message to [arduino])
- with a UNO, it doesn't.
I guess the difference is due to the difference in drivers rather than in hardware, as in Linux both boards behave the same way (they both reset when you open the connection).
On 2011-06-17 12:04, Matteo Sisti Sette wrote:
On 06/17/2011 05:29 PM, Martin Peach wrote:
Ohhhhhhhh, it may be relevant (though I don't directly see how) that when I test on Windows I do it through a virtual machine (on a linux host which is the one on which i test it in Linux).
Yes I think that is relevant. I just tried it on WinXP and at least that part works properly. (arduino duemilanove / firmata2.2 / Pduino-0.5beta8)
Well I've tried again with a _real_ windows (I mean no virtual machine), and the following happens:
- with a Dumelilanove, the arduino resets every time I open the
connection from Pd ("open" message to [arduino])
- with a UNO, it doesn't.
I guess the difference is due to the difference in drivers rather than in hardware, as in Linux both boards behave the same way (they both reset when you open the connection).
From the arduino hardware description http://arduino.cc/en/Main/Boards: "[The Uno] is similar to the Duemilanove, but has a different USB-to-serial chip the ATMega8U2" and "The '8U2 firmware uses the standard USB COM drivers, and no external driver is needed. However, on Windows, a .inf file is required."
I don't have a Uno so I can't test it.
Martin
-
Martin -
Martin Peach
-
Matteo Sisti Sette