[PD] pduino rewrite

[Ingo]

The reason why I didn't make an abstraction for the "debyte" is that I
wanted to keep the number of files and dependencies as low as possible. I
think this was the original idea of the rewrite, right?

Anyway what can be done is add a simple offset number like I did it
somewhere on my testing patch. Then you can copy as many instances as needed
and offset them. Maybe multiplying by 8 first. But then again it's more
objects and calculations than are really necessary.
I am using it like this with only two objects for the Duemilanove. Your
version with the table has 59 objects while my duplicated version has 73
objects for a Duemilanove while needing a lot less calculations, a fraction
of the message transfers and no table lookups or writes.

But as I had mentioned - I doubt that efficiency will play a role in just
about any case for the arduino's digital pins.

Ingo


> -----Ursprüngliche Nachricht-----
> Von: Roman Haefeli [mailto:reduzent at gmail.com]
> Gesendet: Donnerstag, 15. September 2011 08:44
> An: Ingo
> Cc: 'Hans-Christoph Steiner'; pd-list at iem.at
> Betreff: Re: AW: [PD] pduino rewrite
> 
> Hi Ingo
> 
> Thanks for testing!
> 
> On Thu, 2011-09-15 at 05:23 +0200, Ingo wrote:
> > Hi Roman,
> >
> > the new version works great!
> 
> I'm glad to hear that.
> 
> >  I made myself some testing objects around it.
> > Maybe that could be useful if you guys ever get around fixing the help
> > patch.
> 
> I'll have a look. Thanks.
> 
> > I still think the version using individual debyte masks is far more
> > efficient than this one. But as you pointed out this one is more
> scalable
> > and might take care of boards coming in the future (I have just seen a
> mega
> > clone with 70 or 72 digital inputs).
> >
> > Most people don't use incremental wheels timed to 1-2 ms - like I do -
> > anyway. So efficiency shouldn't matter in 99.9% of the cases.
> 
> I generally think it does matter. However, i don't have any concerns
> that the additional table look up causes an efficiency problem. Table
> lookups are usually very fast.
> 
> It's probably a matter of taste, but I often find myself looking for an
> 'algorithmic' solution instead of copying very similar code several
> times around, even if the former is a bit less efficient than the
> latter.
> In this case, if using several [pd debytemask], it'd be nice to use an
> abstraction instead. However, if the original [mapping/debytemask] would
> be used, every (-1) instance would require a row of 8 [+ 8] objects, [+
> 16], [+ 24], etc. respectively. So it would either end up with a lot of
> additional objects below all [debytemask] instances or multiple manually
> crafted [pd debytemask] with each containing slightly different code (as
> you implemented it) would be required.
> The additional [pd polychange] with table lookup is made of just a
> handful of objects.
> 
> However, if it ever turns out, that in your setup the [arduino]
> abstraction eats a significant amount of CPU power (what I really
> doubt), I'll happily replace it by your version of [pd digital messages]
> if it helps.
> 
> And yes, the goal should be to cover also 'edge' cases like your
> incremental wheel. The more use cases work well with Firmata / [arduino]
> the better.
> 
> Roman
> 
> 
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: pd-list-bounces at iem.at [mailto:pd-list-bounces at iem.at] Im Auftrag
> von
> > > Hans-Christoph Steiner
> > > Gesendet: Mittwoch, 14. September 2011 22:33
> > > An: Roman Haefeli
> > > Cc: pd-list at iem.at
> > > Betreff: Re: [PD] pduino rewrite
> > >
> > >
> > > 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
> > >
> > >
> > >
> > > _______________________________________________
> > > Pd-list at iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > > http://lists.puredata.info/listinfo/pd-list