Thank you all for your thoughts regarding this issue.
On Thu, 2023-04-13 at 16:28 -0500, Rick Snow wrote:
I am helping someone use pd with an arduino mega.? They would like to use all of the digital output pins.? I?ve used pduino in the past in this way and not had trouble,?
Also with a Mega?
but I seem to be bumping into something now.
What version of pduino are you using? Most current is 0.8.
Also, if an older version of pduino worked fine with the Arduino Mega, what version was that?
I have used pduino in the past with a mega. I do not remember if I used the specific pins in question previously. I am using pduino .8 and standardFirmata (most recent). I am using a Mac with a usb c dongle….I have tried it on a pc laptop and had the same problem. I have used a couple of different brand new megas for testing.
One test run revealed the following. Process: I turn on all the pins with a 250 ms delay in sending messages “pinMode 2 output” -> “pinMode 53 output”.
Then I check each individual pin with a multimeter. The results are: Pins 2-23 work fine Pins 24-30 turn on but do not turn off Pins 31-38 do not turn on or off Pins 39-53 work fine
I’ve done this a few times and had different sets of pins working/not working but they are generally in the areas above with pins 24-38 the most problematic.
I started by using the arduino help patch.? StandardFirmata sketch on the Mega.? Connection via usb works fine.
I set all the pins to output by sending "pinMode 2 output? -> ?pinMode 45 output? messages to the arduino object. No errors.
Then, I use the messages ?digital 2 1? ?digital 2 0? -> ?digital 45 1? ?digital 45 0? sent to the arduino object to check the pins.? When checking with a multimeter I am not able to get output from pins 2- 7.? I do get output from 8-20.? Between 20-40 some pins work and others not at all.? Other pins will turn on but not turn off.
What happens if you specifically send 'pinMode 45 output, digital 45 1'? Or you use any other pin that seems to be not working correctly with your setup.
When trying this method directly (without trying to turn on all the pins first) the working pins all work. When trying with a “non-working pin”, if I do this right after opening the patch, I can do this with at least 1 pin and it will work. Sometimes, I can check up to 3-4 “non-working pins” with this method and they will work, but then no more “non working pins” will work, and the previously checked non-working pins will stop working. Working pins will work even after the “non-working pins” stop responding. Restarting pd will allow this behavior to be replicated.
Also, there is 'pinState' message for querying the current state and there is the 'capability' message that triggers a report of all supported modes of all pins. So, I would like to know if the non-working pins report of themselves to support 'output' mode. Then, if you set their 'pinMode' to 'output', do they actually report their 'pinState' as 'output'?
pinState messages will show what the multimeter shows with all working pins. pinState will sometimes show 1 for non working pins when the multimeter shows 0.
Checking the pins using a simple blink sketch shows all the pins working fine.
Ok, so you can be sure the board is working.
Any advice would be greatly appreciate!
I don't own an Arduino Mega and I don't know how well [pduino] is tested with that board. I certainly haven't tested it ever.? This makes it hard for me to reproduce the problem. If you can give a hint that the problem is in the software, that would help.
My intuition is that the messaging for these pins gets corrupted somehow after a certain number of pinMode messages are sent to the arduino object, but I really know absolutely nothing about the serial port/sysex side of this.
Thank you all again for your thoughts! Ultimately this person would like to control about 40 solenoids with an arduino mega and a pd patch.
Cheers, Rick
On Mon, 2023-04-17 at 15:14 -0500, Rick Snow wrote
Thank you all for your thoughts regarding this issue.
Right now, I don't have anything to offer that would help you. But you seem to have established that the hardware works and it seems the problem lies in the protocol or the transport. Single messages work, but when sending them in bulk they get corrupted.
In the source of comport.c, I find the line 132:
#define COMPORT_BUF_SIZE 16384
Assuming this defines the buffer size for sending data from Pd to the serial line, I think it is unlikely you hit a buffer overrun. Also, it seems comport is not threaded which makes me assume that it would simply block Pd if its buffer gets full.
What version of [comport] are you using? Have you tried different ones?
You could try a different (lower) baud rate. For that you'd have to adapt the [arduino] abstraction and the StandardFirmata sketch. Both are set to 57600.
Also, what does it need once the communications break? Do you need to power off the Arduino Mega before you can restore a working communication? Or does it help to close and open the serial port connection?
Roman
On Mon, 2023-04-17 at 15:14 -0500, Rick Snow wrote:
Ultimately this person would like to control about 40 solenoids with an arduino mega and a pd patch.
I only noticed now that the intention is to control solenoids. I was once triggering solenoids with Pd and an Arduino and was not quite satisfied with StandardFirmata because of the jitter between the 'on' and 'off' message. Thus, I implemented a simple protocol where the pin number and pulse length are part of the same message, so that the timing is only dependent on the boards own clock and not the serial bus. This allowed for more fine-grained control over the solenoid's velocity.
The code (sketch and abstraction) is here: https://netpd.org/~roman/tmp/solenoiduino.zip
Please note, that the protocol can only control 16 solenoids and has a timing resolution of 2*10 (1024 steps). You could add two more bits to the solenoids addressing and remove two bits from the timing. Or you could extend the protocol to a message length of 3 bytes.
Roman
-
Rick Snow -
Roman Haefeli