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@gmail.com] Gesendet: Donnerstag, 15. September 2011 08:44 An: Ingo Cc: 'Hans-Christoph Steiner'; pd-list@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@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag
von
Hans-Christoph Steiner Gesendet: Mittwoch, 14. September 2011 22:33 An: Roman Haefeli Cc: pd-list@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@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list