On Jun 22, 2006, at 8:34 AM, Alexandre Quessy wrote:

Hi Hans and the PD list,

We are trying to use the PD Arduino firmware + PD patch that Hans
has released. See http://at.or.at/hans/pd/objects.html and http:// arduino.cc/ for more info. Our goal is to use it a inputs only.
(for now)

We realized that some analog inputs values were way too high. It
worked, then it broked for some unknown reason. (apparently none)
Then it worked again and broke again. So, we can say it is still
unstable.

We think that it mighth be because of some equations in the Pduino
Arduino code. We changed line 119 from : transmitByte = transmitByte + (2^(i+1-startPin)*digitalData); to : transmitByte = transmitByte + (2^(i+1+startPin)*digitalData);

Then, the analog-in stopped giving strangely high data. We found it
strange the use of negative exponents (when startPin is 7). Was
that a luck or what ? We had lot of fun debugging that. ;-D

Yes, that would be a bug, thanks for finding it. I guess I never
tested the higher digital inputs... feel free to commit it
directly. I only tested analog 0-3 with sensors, but I never saw
values higher than 1023.

---

Regarding the digital inputs. In both cases, they were behaving
strangely. Their state are constantly changing. Some work, but some
not. Maybe it is just electric noise : should we ground everyother
pin ? Probably.

Yeah, the code needs to be debugged, but yes, all of the inputs,
digital and analog, will have floating voltages on them unless you
tie them to ground or +5V.

In the PDuino PD patch, are the serial streams always parsed as
being the same length ? It is supposed to be so, but might not in
every case. Maybe it would be better to use the [match] object.
(because the selector, meaning that it it the beginning of the
list, is 255) Maybe sometimes, because of calculation error (?),
the number 255 is sent again.

The streams can vary in length, but there are some aspects that are
fixed. The 255 byte is always the cycle marker, marking the
beginning of a cycle. Then the next two bytes will always be the
digital inputs, even if they are not being read, in which case those
two bytes would be 0 and 0. Then after those 3 bytes, you can have
0-6 pairs of bytes representing the analogIns. So if you want to
reduce the latency as much as possible, then you can have it only
send the data for the number of analogIns that you are using. This I
have tested quite a bit and haven't seen any problems with it.

As for [match], I think that's a bad solution since it adds a lot of
latency. [match] would output until the whole sequence is matched.
For the full sequence, that will add about 8 times the latency. If
there is a calculation error that is causing a random 255 byte, that
should be fixed instead of making a [match] workaround. I haven't
seen random 255 bytes at all though, have you?

FYI: I wrote up some documentation about the Pduino protocol:

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1148554125/1

.hc

Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom