hi list,
i have problems getting a arduino diecimila to run.
sometimes i get this:
Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line
and sometimes that:
UNKNOWN_INPUT_COMMAND: 6 0
in both cases i can't access the data.
some hours before it was working, i have no clue.
m.
Well errno 9 is EBADF, "error bad file number", so the serial port file descriptor is not good for some reason, maybe because the serial port was closed.
Martin
From: Max Neupert abonnements@revolwear.com To: pd-list@iem.at Subject: [PD] pduino-arduino trouble Date: Fri, 13 Jun 2008 01:39:50 +1000
hi list,
i have problems getting a arduino diecimila to run.
sometimes i get this:
Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line
and sometimes that:
UNKNOWN_INPUT_COMMAND: 6 0
in both cases i can't access the data.
some hours before it was working, i have no clue.
m.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
it's really hard to fix since it simply works sometimes and then
stops working.
not very reliable for an installation supposed to run automatically
in a different city for some weeks :(
this is the output when it does work:
error: [comport] ** ERROR ** could not open device /dev/tty.Roy-Dial- upNetworking-2: failure(16): Resource busy
[comport] invalid handle for /dev/tty.* [arduino]: version_0.3 get_baud_ratebits: 57600.000000 set_baudrate baudbits: 57600 [comport] opened serial line device 5 (/dev/tty.usbserial-A6004nvF)
Arduino/Firmata_version: 1 0
this is the output when it doesn't:
error: [comport] ** ERROR ** could not open device /dev/tty.Roy-Dial- upNetworking-2: failure(16): Resource busy
[comport] invalid handle for /dev/tty.* [arduino]: version_0.4 get_baud_ratebits: 115200.000000 set_baudrate baudbits: 115200 [comport] opened serial line device 5 (/dev/tty.usbserial-A6004nvF)
UNKNOWN_INPUT_COMMAND: 6 0
so it'a exactly the same, first the wrong device gets opened because
of the default name, but then one tim it can connect, the other time
it can't.
anyone has a clue what's going on?
m.
Am 2008-06-13 um 03:03 schrieb Martin Peach:
Well errno 9 is EBADF, "error bad file number", so the serial port
file descriptor is not good for some reason, maybe because the
serial port was closed.Martin
From: Max Neupert abonnements@revolwear.com To: pd-list@iem.at Subject: [PD] pduino-arduino trouble Date: Fri, 13 Jun 2008 01:39:50 +1000
hi list,
i have problems getting a arduino diecimila to run.
sometimes i get this:
Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line [comport] write returned -1, errno is 9 Write error, maybe TX-OVERRUNS on serial line
and sometimes that:
UNKNOWN_INPUT_COMMAND: 6 0
in both cases i can't access the data.
some hours before it was working, i have no clue.
m.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Max Neupert wrote:
this is the output when it does work:
set_baudrate baudbits: 57600
this is the output when it doesn't:
set_baudrate baudbits: 115200
anyone has a clue what's going on?
I'm guessing the baudbits has something to do with it. Maybe something along the connection between pd and arduino doesn't support the higher speed.
Never used arduino or any other serial devices though.
Claude
that could be it. but why is it doing that? the comport object in the arduino abstraction says
[comport $1 57600] so shouldn't the rate be fixed to 57600? why does
it sometimes connect with 115200?
max
Am 2008-06-13 um 18:54 schrieb Claude Heiland-Allen:
Max Neupert wrote:
this is the output when it does work:
set_baudrate baudbits: 57600
this is the output when it doesn't:
set_baudrate baudbits: 115200
anyone has a clue what's going on?
I'm guessing the baudbits has something to do with it. Maybe
something along the connection between pd and arduino doesn't
support the higher speed.Never used arduino or any other serial devices though.
Claude
he max we had a similar error here at the school in zürich http://lists.puredata.info/pipermail/pd-list/2008-06/062973.html might be the bug in your pd-extended - a recent nightly builds might cure salutis olsen
On Sat, Jun 14, 2008 at 5:49 AM, Max Neupert abonnements@revolwear.com wrote:
that could be it. but why is it doing that? the comport object in the arduino abstraction says
[comport $1 57600] so shouldn't the rate be fixed to 57600? why does it sometimes connect with 115200?
max
Am 2008-06-13 um 18:54 schrieb Claude Heiland-Allen:
Max Neupert wrote:
this is the output when it does work:
set_baudrate baudbits: 57600
this is the output when it doesn't:
set_baudrate baudbits: 115200
anyone has a clue what's going on?
I'm guessing the baudbits has something to do with it. Maybe something along the connection between pd and arduino doesn't support the higher speed.
Never used arduino or any other serial devices though.
Claude
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hi list,
i found the source of my problem here.
the patch was using the [arduino] abstraction.
i had it located in the same path than my patch (version 0.3), but
another one (version 0.4) is located in
/Applications/Pd-extended.app/Contents/Resources/extra/hardware/
i've always assumed that pd searches for abstractions first in the
same directory than the patch is found. that doesn't seem to be the
case.
for some reason pd sometimes choose to prefer the 0.4 version which
has a different, non working bitrate set.
i've deleted the abstraction and use it now in a subpatch instead, so
i am sure no other version is loaded instead.
max
Am 2008-06-13 um 18:54 schrieb Claude Heiland-Allen:
Max Neupert wrote:
this is the output when it does work:
set_baudrate baudbits: 57600
this is the output when it doesn't:
set_baudrate baudbits: 115200
anyone has a clue what's going on?
I'm guessing the baudbits has something to do with it. Maybe
something along the connection between pd and arduino doesn't
support the higher speed.Never used arduino or any other serial devices though.
Claude
Yeah, that was my mistake, I removed hardware/arduino.pd from the
nightly builds since it shouldn't be there. Sorry about that...
.hc
On Jun 14, 2008, at 11:59 AM, Max Neupert wrote:
hi list,
i found the source of my problem here. the patch was using the [arduino] abstraction. i had it located in the same path than my patch (version 0.3), but another one (version 0.4) is located in /Applications/Pd-extended.app/Contents/Resources/extra/hardware/
i've always assumed that pd searches for abstractions first in the same directory than the patch is found. that doesn't seem to be the case.
for some reason pd sometimes choose to prefer the 0.4 version which has a different, non working bitrate set. i've deleted the abstraction and use it now in a subpatch instead, so i am sure no other version is loaded instead.
max
Am 2008-06-13 um 18:54 schrieb Claude Heiland-Allen:
Max Neupert wrote:
this is the output when it does work:
set_baudrate baudbits: 57600
this is the output when it doesn't:
set_baudrate baudbits: 115200
anyone has a clue what's going on?
I'm guessing the baudbits has something to do with it. Maybe something along the connection between pd and arduino doesn't support the higher speed.
Never used arduino or any other serial devices though.
Claude
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
i don't konw if that's related. i was using the release candidate: Pd
version 0.40.3-extended-20080603.
my question:
wouldn't it make sense if Pd would search first in the same directory
as the patch is for abstractions?
m.
Am 2008-06-14 um 23:05 schrieb Hans-Christoph Steiner:
Yeah, that was my mistake, I removed hardware/arduino.pd from the
nightly builds since it shouldn't be there. Sorry about that....hc
On Jun 14, 2008, at 11:59 AM, Max Neupert wrote:
hi list,
i found the source of my problem here. the patch was using the [arduino] abstraction. i had it located in the same path than my patch (version 0.3), but another one (version 0.4) is located in /Applications/Pd-extended.app/Contents/Resources/extra/hardware/
i've always assumed that pd searches for abstractions first in the same directory than the patch is found. that doesn't seem to be the case.
for some reason pd sometimes choose to prefer the 0.4 version which has a different, non working bitrate set. i've deleted the abstraction and use it now in a subpatch instead, so i am sure no other version is loaded instead.
max
Am 2008-06-13 um 18:54 schrieb Claude Heiland-Allen:
Max Neupert wrote:
this is the output when it does work:
set_baudrate baudbits: 57600
this is the output when it doesn't:
set_baudrate baudbits: 115200
anyone has a clue what's going on?
I'm guessing the baudbits has something to do with it. Maybe something along the connection between pd and arduino doesn't support the higher speed.
Never used arduino or any other serial devices though.
Claude
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
It should do that already. I don't remember why it didn't in this case.
.hc
On Jun 15, 2008, at 9:55 AM, Max Neupert wrote:
i don't konw if that's related. i was using the release candidate:
Pd version 0.40.3-extended-20080603. my question: wouldn't it make sense if Pd would search first in the same
directory as the patch is for abstractions?m.
Am 2008-06-14 um 23:05 schrieb Hans-Christoph Steiner:
Yeah, that was my mistake, I removed hardware/arduino.pd from the
nightly builds since it shouldn't be there. Sorry about that....hc
On Jun 14, 2008, at 11:59 AM, Max Neupert wrote:
hi list,
i found the source of my problem here. the patch was using the [arduino] abstraction. i had it located in the same path than my patch (version 0.3), but another one (version 0.4) is located in /Applications/Pd-extended.app/Contents/Resources/extra/hardware/
i've always assumed that pd searches for abstractions first in the same directory than the patch is found. that doesn't seem to be the case.
for some reason pd sometimes choose to prefer the 0.4 version which has a different, non working bitrate set. i've deleted the abstraction and use it now in a subpatch
instead, so i am sure no other version is loaded instead.max
Am 2008-06-13 um 18:54 schrieb Claude Heiland-Allen:
Max Neupert wrote:
this is the output when it does work:
set_baudrate baudbits: 57600
this is the output when it doesn't:
set_baudrate baudbits: 115200
anyone has a clue what's going on?
I'm guessing the baudbits has something to do with it. Maybe something along the connection between pd and arduino doesn't support the higher speed.
Never used arduino or any other serial devices though.
Claude
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
Access to computers should be unlimited and total. - the hacker ethic
On Sun, 2008-06-15 at 15:16 +0200, Hans-Christoph Steiner wrote:
It should do that already. I don't remember why it didn't in this case.
i am HEAVILY against this. please, before you change that in pd-extended, provide a patch to change the behaviour in pd-vanilla. actually i don't care too much which way it is implemented, but i do care A LOT that it is consistent over all distros.
your disciple of the curch of consistency roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
rethinking this again, i came to the conclusion:
the actual behaviour shouldn't be changed. afaik, it is not possible to shadow classes of pd or from binary libraries. changing actual behaviour would lead to many incosistencies, where sometimes an local abstraction would shadow library classes and sometimes not. internal classes couldn't be shadowed anyway. it would make the pd-world definitely more troublesome. unless it is possible to shadow EVERYTHING (classes from binary libraries and internals), this shouldn't be changed, IMO.
i am much more in favor of consistencies in the wrong way than inconsistencies in the right way.
roman
On Sun, 2008-06-15 at 16:45 +0200, Roman Haefeli wrote:
On Sun, 2008-06-15 at 15:16 +0200, Hans-Christoph Steiner wrote:
It should do that already. I don't remember why it didn't in this case.
i am HEAVILY against this. please, before you change that in pd-extended, provide a patch to change the behaviour in pd-vanilla. actually i don't care too much which way it is implemented, but i do care A LOT that it is consistent over all distros.
your disciple of the curch of consistency roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
the actual behaviour shouldn't be changed. afaik, it is not possible to shadow classes of pd or from binary libraries. changing actual behaviour would lead to many incosistencies, where sometimes an local abstraction would shadow library classes and sometimes not. internal classes couldn't be shadowed anyway. it would make the pd-world definitely more troublesome. unless it is possible to shadow EVERYTHING (classes from binary libraries and internals), this shouldn't be changed, IMO.
Btw.: Miller is working on making shadowing even builtins possible. Check pd-dev, unless you've already seen it.
Ciao
Frank Barknecht _ ______footils.org__
On Sun, 2008-06-15 at 18:53 +0200, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
the actual behaviour shouldn't be changed. afaik, it is not possible to shadow classes of pd or from binary libraries. changing actual behaviour would lead to many incosistencies, where sometimes an local abstraction would shadow library classes and sometimes not. internal classes couldn't be shadowed anyway. it would make the pd-world definitely more troublesome. unless it is possible to shadow EVERYTHING (classes from binary libraries and internals), this shouldn't be changed, IMO.
Btw.: Miller is working on making shadowing even builtins possible. Check pd-dev, unless you've already seen it.
oh, thanks. i usually read pd-dev, but obviously i missed the point here.
hans: it seems you're coming up with this at the right time, so forget my concerns ;-) sorry for the noise.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Sun, 15 Jun 2008, Frank Barknecht wrote:
Btw.: Miller is working on making shadowing even builtins possible.
It can be done by removing some lines from pd's source. Defining a method is done by appending to a linked-list. If it is made to prepend to the linked-list (by removing a for-loop), a new method with the same name as an old method with shadow the old method because of the way method-lookup happens, and then class-lookup is method-lookup in pd, because it's done through [objectmaker]'s method-list.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Jun 18, 2008, at 4:52 PM, Mathieu Bouchard wrote:
On Sun, 15 Jun 2008, Frank Barknecht wrote:
Btw.: Miller is working on making shadowing even builtins possible.
It can be done by removing some lines from pd's source. Defining a
method is done by appending to a linked-list. If it is made to
prepend to the linked-list (by removing a for-loop), a new method
with the same name as an old method with shadow the old method
because of the way method-lookup happens, and then class-lookup is
method-lookup in pd, because it's done through [objectmaker]'s
method-list.
Do you have a reference in the Pd code to look at this specific
stuff? I'd like to see how it works. Ultimately, for the canvas-
local namespaces to be complete, there needs to be a canvas-local
method list too.
.hc
kill your television
On Wed, 18 Jun 2008, Hans-Christoph Steiner wrote:
and then class-lookup is method-lookup in pd, because it's done through [objectmaker]'s method-list.
Do you have a reference in the Pd code to look at this specific stuff?
grep -n objectmaker *.c
Ultimately, for the canvas-local namespaces to be complete, there needs to be a canvas-local method list too.
I explained it in detail last year. Got no reply.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Jun 18, 2008, at 7:54 PM, Mathieu Bouchard wrote:
On Wed, 18 Jun 2008, Hans-Christoph Steiner wrote:
and then class-lookup is method-lookup in pd, because it's done
through [objectmaker]'s method-list.Do you have a reference in the Pd code to look at this specific
stuff?grep -n objectmaker *.c
That I can do on my own, I was hoping for some human guidance... :)
Ultimately, for the canvas-local namespaces to be complete, there
needs to be a canvas-local method list too.I explained it in detail last year. Got no reply.
Link?
.hc
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
On Wed, 18 Jun 2008, Hans-Christoph Steiner wrote:
On Jun 18, 2008, at 7:54 PM, Mathieu Bouchard wrote:
On Wed, 18 Jun 2008, Hans-Christoph Steiner wrote:
and then class-lookup is method-lookup in pd, because it's done through [objectmaker]'s method-list.
Do you have a reference in the Pd code to look at this specific stuff?
grep -n objectmaker *.c
That I can do on my own, I was hoping for some human guidance... :)
Well, I didn't think that I'd have to say to have a look at class_addmethod, because we're talking about adding a method to a class.
Anyway, the thing doesn't use linked-lists, contrary to almost all other such things in pd, so I was wrong. However, it is true that it appends to the end of the list all of the time. It happens just after the t_resizebytes call. Personally, I wouldn't touch it, and instead I would change the method-lookup order in getfn(), zgetfn() and pd_typedmess(). Then I realise that it is already last-to-first, which is my second mistake. I don't know why I had the impression that it was first-to-last. On top of that, it's an aspect of pd for which dd is identical. So, I should've remembered. You can see that I'm getting a bit rusty ;)
Ultimately, for the canvas-local namespaces to be complete, there needs to be a canvas-local method list too.
I explained it in detail last year. Got no reply.
Link?
Ok, I found it, but in the end, it wasn't a full description, and it wasn't last year either. Turns out that I optimised-out the description from the mailing-list, as the description was going to be a reply to a reply that I did not receive.
http://lists.puredata.info/pipermail/pd-dev/2006-09/007605.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007607.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007608.html
But basically, the idea is that you have a tree of dummy singleton objects that are the objectmakers. They are singleton because each of them has its own class. They are dummy because the object itself is never used and itself contains no data (this exists because pd has no way to define non-object methods, and that's fine with me). Each objectmaker class defines the creators as methods: one per class, one per alias, and one per sub-namespace. Creators for classes and aliases are as usual. Creators for sub-namespaces are forwarders. They replace the selector from the message they get, with the $1 of the arglist. $1 is removed from the arglist. So:
[foo bar baz 1 2 3]
Might be a real creator for [baz 1 2 3] inside namespace representative [bar] inside namespace representative [foo]. Or it could be something else with less namespace levels and more arguments. If the ambiguïty of it icks you, there are other possibilities of design.
Then if you don't want to use Miller namespaces such as in [list ...] classes, then you will have to check for namespace qualifiers in the classname and split the classname accordingly, sort of like [OSCroute] but not really. I used Miller namespaces because it makes less symbols in the symbol-table.
I have other ideas as well, such as how to import a namespace without copying the method-table, and how to support a namespace that is being modified so that all its importing namespaces get the update. It's the same solution(s) for both problems.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
-
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
Martin Peach -
Mathieu Bouchard -
Max Neupert -
olsen wolf -
Roman Haefeli