I'm trying to implement the pduino using a PIC16F767. So far I have the analog ins and digital ins working well. In testing I find that the arduino-help patch sends digital outs as 229, low7, high7, that is, the digital out token followed by the bit pattern for the low 7 bits and then the bit pattern for the high 7 bits. On the other hand, the Pd_firmware.pde code expects the high byte first:
if(firstInputByte) {
// output data for pins 7-13
for(i=7; i<TOTAL_DIGITAL_PINS; ++i) {
mask = 1 << i;
if( (digitalPinStatus & mask) && !(pwmStatus & mask) ) {
// inputData is a byte and mask is an int, so align the high part of mask
digitalWrite(i, inputData & (mask >> 7));
}
}
firstInputByte = false;
}
else { //
for(i=0; i<7; ++i) {
mask = 1 << i;
if( (digitalPinStatus & mask) && !(pwmStatus & mask) ) {
digitalWrite(i, inputData & mask);
}
}
}
...so which is correct?
Also the digitalWrite(i, inputData & mask) should probably be digitalWrite(i, (inputData && mask)?HIGH:LOW).
Martin
Nice! I guess its time to rename the [arduino] object...
[microcontroller]?
Oops, I forgot to update the help patch. I recently changed the
order, and I changed the arduino-test.pd patch to match. I didn't
write the arduino-help.pd so I guess I overlooked that change.
But yes, the firmware and the arduino-test.pd patch should be the
proper order. I changed the order because I wanted to have the bits
in the same order as it would be represented when writing out a
digital number: MSB leftmost and LSB rightmost. Plus I think it made
some implementations a bit easier. Feel free to update the help
patch, I don't think I'll get around to it for a few days.
Also, I think the basic protocol is stable now, and can remain
backwards compatible even after adding new features. But I would
like to hear any ideas, comments, feedback on the protocol. I want
to get it ironed out so that we can then start implementing objects
in many languages, like Processing, Max, Java, Ruby, Python, etc.
without worrying about breaking all of them when adding to the firmware.
.hc
On Oct 12, 2006, at 2:33 PM, martin.peach@sympatico.ca
martin.peach@sympatico.ca wrote:
I'm trying to implement the pduino using a PIC16F767. So far I have the analog ins and digital ins working well. In testing I find that the arduino-help patch sends digital outs as
229, low7, high7, that is, the digital out token followed by the
bit pattern for the low 7 bits and then the bit pattern for the
high 7 bits. On the other hand, the Pd_firmware.pde code expects
the high byte first:if(firstInputByte) { // output data for pins 7-13 for(i=7; i<TOTAL_DIGITAL_PINS; ++i) { mask = 1 << i; if( (digitalPinStatus & mask) && !(pwmStatus & mask) ) { // inputData is a byte and mask is an int, so align thehigh part of mask digitalWrite(i, inputData & (mask >> 7)); } } firstInputByte = false; } else { // for(i=0; i<7; ++i) { mask = 1 << i; if( (digitalPinStatus & mask) && !(pwmStatus & mask) ) { digitalWrite(i, inputData & mask); } } }
...so which is correct?
Also the digitalWrite(i, inputData & mask) should probably be
digitalWrite(i, (inputData && mask)?HIGH:LOW).Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
Hans-Christoph Steiner wrote:
Nice! I guess its time to rename the [arduino] object... [microcontroller]?
Or [io], since it's not really programmable via pd, it's an interface.
Oops, I forgot to update the help patch. I recently changed the order, and I changed the arduino-test.pd patch to match. I didn't write the arduino-help.pd so I guess I overlooked that change.
But yes, the firmware and the arduino-test.pd patch should be the proper order. I changed the order because I wanted to have the bits in the same order as it would be represented when writing out a digital number: MSB leftmost and LSB rightmost. Plus I think it made some implementations a bit easier. Feel free to update the help patch, I don't think I'll get around to it for a few days.
I updated the help patch, also updated comport so that it doesn't crash pd (Windows version) when you send too much too fast. The PIC code now does what the pduino firmware does -- there is still no pwm implemented...
Also, I think the basic protocol is stable now, and can remain backwards compatible even after adding new features. But I would like to hear any ideas, comments, feedback on the protocol. I want to get it ironed out so that we can then start implementing objects in many languages, like Processing, Max, Java, Ruby, Python, etc. without worrying about breaking all of them when adding to the firmware.
I think maybe the software PWM should be redefined to do servo pulses (~20ms period, 1-2ms pulse width), since that is feasible in software on the Atmel and PIC devices. Audio pwm should be handled by the 3 hardware channels. Also digital pins 0 and 1 are also the receive and transmit for the serial port so I just silently ignore requests to change them.
Martin
.hc
On Oct 12, 2006, at 2:33 PM, martin.peach@sympatico.ca martin.peach@sympatico.ca wrote:
I'm trying to implement the pduino using a PIC16F767. So far I have the analog ins and digital ins working well. In testing I find that the arduino-help patch sends digital outs as 229, low7, high7, that is, the digital out token followed by the bit pattern for the low 7 bits and then the bit pattern for the high 7 bits. On the other hand, the Pd_firmware.pde code expects the high byte first:
if(firstInputByte) { // output data for pins 7-13 for(i=7; i<TOTAL_DIGITAL_PINS; ++i) { mask = 1 << i; if( (digitalPinStatus & mask) && !(pwmStatus & mask) ) { // inputData is a byte and mask is an int, so align thehigh part of mask digitalWrite(i, inputData & (mask >> 7)); } } firstInputByte = false; } else { // for(i=0; i<7; ++i) { mask = 1 << i; if( (digitalPinStatus & mask) && !(pwmStatus & mask) ) { digitalWrite(i, inputData & mask); } } }
...so which is correct?
Also the digitalWrite(i, inputData & mask) should probably be digitalWrite(i, (inputData && mask)?HIGH:LOW).
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Hans-Christoph Steiner -
Martin Peach -
martin.peach＠sympatico.ca