[PD] pduino rewrite

[Hans-Christoph Steiner]

As Ingo pointed out, one bug is that [mapping/debytemask] has the
[change] object for each outlet.  So probably the way to fix this is to
make a bunch of [mapping/debytemask] objects for all the possible
digital ports.

[arduino] should only output on change of digital input, and it receives
the digital information one byte/port at a time, i.e. 8 pins.  Another
approach would be to have an array of all of the previous values which
are then compared to the current before outputting.

.hc


On Wed, 2011-09-14 at 11:24 +0200, Roman Haefeli wrote:
> Hi Ingo
> 
> Thanks for all your reports.
> 
> Sorry that my replies sometimes only come a few days later. I'm still
> willing to fix any outstanding issues, but not very often I find time to
> get an arduino into my hands. Since sometimes I have troubles following
> you and keeping your several bug reports apart from each other, I'd
> suggest to stick with [arduino] bugs and let the documentation aspect
> aside for a while. 
> 
> I _think_ I finally understand your problem with the digital ins. I
> can't currently test or reproduce the problem, since I don't have an
> arduino at hand, but from reading the code, I think I see what could go
> wrong.
> 
> On certain incoming commands of [pd digital messages], the [pd
> debytemask] *) subpatch generates more than one message, but only the
> last one is finally sent to the outlet, because it only fires, when the
> left inlet of [+ ] is triggered, which is under all circumstances only
> triggered once after all the [pd debytemask] messages have fired.
> Actually, the order should be inversed, so that all messages from [pd
> debytemask] go the _left_ inlet of [+ ], and the summand is sent the
> _right_ inlet before.  This is what I did in the patch you find
> attached. 
> 
> I rather have my version going into [arduino], since it is much less
> code than yours. From what I can tell, they both produce similar output,
> but as I said, I haven't had the chance to test it in real-world
> circumstances with a real arduino. So, please test and report back.
> 
> I guess the main reason nobody (including me) has noticed this bug yet,
> is that you won't trigger it, if you only test one digital in at once.
> Changing the state of only one input at a time makes it seem, that all
> inputs work correctly. Only when changing states of several inputs at
> the same time, you will receive only a single digital messages, which is
> obviously wrong.
> 
> I'm happy now that you kept bugging about this. It took me a while to
> (hopefully) understand the problem. Thanks for your persistence.
> 
> *) There is no [debytemask] abstraction anymore in the git version of
> [arduino]. I replaced it by a subpatch.
> 
> Roman
> 
> 
> On Sun, 2011-09-11 at 06:20 +0200, Ingo wrote:
> > There is another thing that I just noticed about the pduino test-patch.
> > 
> > The mode buttons are suggesting that you can turn of all functions by
> > selecting "NONE". This is not true! These buttons have absolutely NO
> > function and should be replaced with the correct commands.
> > While doing this the option "Input-PullUp" should be added.
> > 
> > The Arduino generally defaults to input. Selecting "NONE" at the current
> > state leaves it at the last selected option.
> > 
> > The analogue ins can actually be turned off by the command "analogIns X 0"
> > (where the X stands for the pin number 0-5). The digital input pins need the
> > command "digitalIns X 0" (where the X stands for the pin number 0-11).
> > 
> > I also think that there should be a separate block for digital an analogue
> > (with the available options only) as beginners might think you could select
> > "analog" as an option for digital pins, and so on...
> > 
> > Ingo
> > 
> > 
> > BTW with the fix I just submitted in my last email all digital ins now work
> > flawlessly after testing for several hours. I am amazed that hardly anybody
> > noticed is bug for over two years!
> > 
> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list