[PD] pduino digital outs

[Martin Peach]

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 at sympatico.ca> 
> <martin.peach at 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 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
>>
>>
>>
>> _______________________________________________
>> PD-list at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>