You can subscribe to this list here.
2009 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
(20) |
Jul
(15) |
Aug
(5) |
Sep
(5) |
Oct
(19) |
Nov
(7) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(28) |
Feb
(12) |
Mar
(15) |
Apr
(6) |
May
(7) |
Jun
(6) |
Jul
(39) |
Aug
(31) |
Sep
(23) |
Oct
(4) |
Nov
(4) |
Dec
(6) |
2011 |
Jan
(25) |
Feb
(7) |
Mar
(2) |
Apr
(3) |
May
(4) |
Jun
(9) |
Jul
(6) |
Aug
(77) |
Sep
(80) |
Oct
(12) |
Nov
(6) |
Dec
(24) |
2012 |
Jan
(27) |
Feb
(10) |
Mar
(18) |
Apr
(12) |
May
(11) |
Jun
(13) |
Jul
(5) |
Aug
(3) |
Sep
(2) |
Oct
(7) |
Nov
(7) |
Dec
(7) |
2013 |
Jan
(16) |
Feb
(6) |
Mar
(4) |
Apr
(3) |
May
(7) |
Jun
(9) |
Jul
(7) |
Aug
(10) |
Sep
|
Oct
(1) |
Nov
(27) |
Dec
(5) |
2014 |
Jan
(8) |
Feb
|
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Hans-Christoph S. <ha...@at...> - 2009-07-14 18:16:34
|
http://at.or.at/hans/pd/objects.html#pduino Ok, some minor tweaks and additions, please test on the Arduino Mega too! There is support in funnel and Pduino for the new stuff, plus Processing and others coming soon. - updated I2C and SAMPLING_INTERVAL macros - added Arduino Mega support - added SHIFT_DATA to Firmata.h to claim for future implementations - renamed somethings for clarity and consistency (but left old names in for a bit) FIRMATA_STRING -> STRING_DATA SYSEX_I2C_REQUEST -> I2C_REQUEST SYSEX_I2C_REPLY -> I2C_REPLY SYSEX_SAMPLING_INTERVAL -> SAMPLING_INTERVAL Please test and report and bugs or issues. We are trying to get this included in the upcoming Arduino 0017 release. .hc ---------------------------------------------------------------------------- All information should be free. - the hacker ethic |
From: Shigeru K. <kot...@ya...> - 2009-07-12 01:19:57
|
Hi Hans, I'm sorry for lack of information. Could you please add it? Best, Shigeru On Fri, Jul 10, 2009 at 11:58 PM, Hans-Christoph Steiner<ha...@at...> wrote: > > Oops, yeah, that should be in there. I think Jeff said he was working on > that, last I remember. Since Jeff and you were working on this, I guess I > didn't look at it. Do you want to add it, or shall I? > > .hc > > On Jul 10, 2009, at 12:24 AM, Shigeru Kobayashi wrote: > >> Hi Hans, >> >> Is it possible to ask you add the following definition to Firmata.h >> >> #define SYSEX_I2C_CONFIG 0x78 >> >> and move SYSEX_SAMPLING_INTERVAL to 0x7A as follows? >> >> #define SYSEX_SAMPLING_INTERVAL 0x7A // set the poll rate of the main loop >> >> I just updated to r19, but it seems that not compatible with the >> latest protocol. I'm sorry for trouble you, but it will be much >> helpful for me to confirm that my library is compatible with Firmata >> v2.1. >> >> http://firmata.org/wiki/Protocol#I2C >> http://firmata.org/wiki/Protocol#Sampling_Interval >> >> >> Best, >> Shigeru >> >> >> ------------------------------------------------------------------------------ >> Enter the BlackBerry Developer Challenge >> This is your chance to win up to $100,000 in prizes! For a limited time, >> vendors submitting new applications to BlackBerry App World(TM) will have >> the opportunity to enter the BlackBerry Developer Challenge. See full >> prize >> details at: http://p.sf.net/sfu/Challenge >> _______________________________________________ >> Firmata-devel mailing list >> Fir...@li... >> https://lists.sourceforge.net/lists/listinfo/firmata-devel > > > > ---------------------------------------------------------------------------- > > Computer science is no more related to the computer than astronomy is > related to the telescope. -Edsger Dykstra > > > |
From: Hans-Christoph S. <ha...@at...> - 2009-07-10 15:18:11
|
Oops, yeah, that should be in there. I think Jeff said he was working on that, last I remember. Since Jeff and you were working on this, I guess I didn't look at it. Do you want to add it, or shall I? .hc On Jul 10, 2009, at 12:24 AM, Shigeru Kobayashi wrote: > Hi Hans, > > Is it possible to ask you add the following definition to Firmata.h > > #define SYSEX_I2C_CONFIG 0x78 > > and move SYSEX_SAMPLING_INTERVAL to 0x7A as follows? > > #define SYSEX_SAMPLING_INTERVAL 0x7A // set the poll rate of the > main loop > > I just updated to r19, but it seems that not compatible with the > latest protocol. I'm sorry for trouble you, but it will be much > helpful for me to confirm that my library is compatible with Firmata > v2.1. > > http://firmata.org/wiki/Protocol#I2C > http://firmata.org/wiki/Protocol#Sampling_Interval > > > Best, > Shigeru > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited > time, > vendors submitting new applications to BlackBerry App World(TM) will > have > the opportunity to enter the BlackBerry Developer Challenge. See > full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Firmata-devel mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firmata-devel ---------------------------------------------------------------------------- Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra |
From: Shigeru K. <kot...@ya...> - 2009-07-10 04:24:33
|
Hi Hans, Is it possible to ask you add the following definition to Firmata.h #define SYSEX_I2C_CONFIG 0x78 and move SYSEX_SAMPLING_INTERVAL to 0x7A as follows? #define SYSEX_SAMPLING_INTERVAL 0x7A // set the poll rate of the main loop I just updated to r19, but it seems that not compatible with the latest protocol. I'm sorry for trouble you, but it will be much helpful for me to confirm that my library is compatible with Firmata v2.1. http://firmata.org/wiki/Protocol#I2C http://firmata.org/wiki/Protocol#Sampling_Interval Best, Shigeru |
From: Shigeru K. <kot...@ya...> - 2009-07-06 15:50:36
|
Hi Hans, Thank you very much. I'll test ASAP and let you know if I find any issues. Best, Shigeru On Mon, Jul 6, 2009 at 3:36 PM, Hans-Christoph Steiner<ha...@at...> wrote: > > Ah yes, thanks for pointing that out. I was wondering why the servo has > acting strange, its because I was using the hardware PWM. But yes, the rest > of it is done, the Servo pinMode stuff. > > .hc > > On Jul 5, 2009, at 12:44 PM, Shigeru Kobayashi wrote: > >> Hi Hans, >> >> It seems that the Servo support is partially implemented (except for >> calling Servo.write()) in the revision 14, am I right? >> >> Since I have a plan to support StandardFirmata with Servo support for >> the next release of Funnel, I'd like to test if a not-yet-committed >> version is available. If so, could you please let me know? >> >> >> Best, >> Shigeru >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Firmata-devel mailing list >> Fir...@li... >> https://lists.sourceforge.net/lists/listinfo/firmata-devel > > > > ---------------------------------------------------------------------------- > > All information should be free. - the hacker ethic > > > > > |
From: Hans-Christoph S. <ha...@at...> - 2009-07-06 13:36:53
|
Ah yes, thanks for pointing that out. I was wondering why the servo has acting strange, its because I was using the hardware PWM. But yes, the rest of it is done, the Servo pinMode stuff. .hc On Jul 5, 2009, at 12:44 PM, Shigeru Kobayashi wrote: > Hi Hans, > > It seems that the Servo support is partially implemented (except for > calling Servo.write()) in the revision 14, am I right? > > Since I have a plan to support StandardFirmata with Servo support for > the next release of Funnel, I'd like to test if a not-yet-committed > version is available. If so, could you please let me know? > > > Best, > Shigeru > > ------------------------------------------------------------------------------ > _______________________________________________ > Firmata-devel mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firmata-devel ---------------------------------------------------------------------------- All information should be free. - the hacker ethic |
From: Shigeru K. <kot...@ya...> - 2009-07-05 16:44:48
|
Hi Hans, It seems that the Servo support is partially implemented (except for calling Servo.write()) in the revision 14, am I right? Since I have a plan to support StandardFirmata with Servo support for the next release of Funnel, I'd like to test if a not-yet-committed version is available. If so, could you please let me know? Best, Shigeru |
From: Shigeru K. <kot...@ya...> - 2009-06-28 11:04:47
|
Hi, I'm sorry for delay in reply. I understand the current naming rule. And as Zach pointed, renaming both #defines and functions rapidly will confuse users. So I agree on keep #defines as current version. :) Best, Shigeru On Sun, Jun 28, 2009 at 4:40 PM, zach lieberman<zac...@gm...> wrote: > Sorry that maybe this email won't hit the list b/c I'm writing on my iphone > / traveling > > Just a quick requet to please try to not change too rapidly functions and or > #defines --- maybe double up for a release or two (with some deptecated > commemts) so that the software folks can catch up ? Our release schedule > is a not in sync w arduino, and we'd like any transition to be painless > > Also thought it might make sense to include an additional std firmata sketch > w the old default rate (maybe with the rate in the title)? I know that's > overkill but it can help people who need to rollback quickly without having > to alter a core arduinon sketch. > > Take care ! > Zach > > > > On Jun 26, 2009, at 11:53 PM, Hans-Christoph Steiner <ha...@at...> wrote: > >> >> I agree they definitely should be consistently named. My only concern >> about removing the SYSEX_ is that it might be confusing where these >> are used, since the commands like SET_PIN_MODE are direct MIDI >> messages, while the others are sent as SYSEX messages. >> >> Perhaps all the 'sysex' stuff should be renamed to something like >> 'command', so like sendCommand() instead of sendSysex(). Then remove >> the SYSEX_ part too. >> >> .hc >> >> On Jun 24, 2009, at 11:20 PM, Shigeru Kobayashi wrote: >> >>> Deal all, >>> >>> I have a minor suggestion about Firmata.h. >>> >>> Since other messages don't have "SYSEX_" prefix, how about rename >>> defines as follows, ? >>> >>> SYSEX_I2C_REQUEST => I2C_REQUEST >>> SYSEX_I2C_REPLY => I2C_REPLY >>> SYSEX_SAMPLING_INTERVAL => SAMPLING_INTERVAL >>> >>> >>> http://firmata.svn.sourceforge.net/viewvc/firmata/arduino/trunk/Firmata/Firmata.h?revision=9&view=markup >>> >>> I mean the followings >>> >>> #define SERVO_CONFIG 0x70 // set max angle, minPulse, >>> maxPulse, freq >>> #define FIRMATA_STRING 0x71 // a string message with 14- >>> bits per char >>> #define SYSEX_I2C_REQUEST 0x76 // send an I2C read/write request >>> #define SYSEX_I2C_REPLY 0x77 // a reply to an I2C read request >>> #define SYSEX_SAMPLING_INTERVAL 0x78 // set the poll rate of the >>> main loop >>> #define REPORT_FIRMWARE 0x79 // report name and version of >>> the firmware >>> #define SYSEX_NON_REALTIME 0x7E // MIDI Reserved for non- >>> realtime messages >>> #define SYSEX_REALTIME 0x7F // MIDI Reserved for realtime >>> messages >>> >>> will be as follows >>> >>> #define SERVO_CONFIG 0x70 // set max angle, minPulse, >>> maxPulse, freq >>> #define FIRMATA_STRING 0x71 // a string message with 14- >>> bits per char >>> #define I2C_REQUEST 0x76 // send an I2C read/write request >>> #define I2C_REPLY 0x77 // a reply to an I2C read request >>> #define SAMPLING_INTERVAL 0x78 // set the poll rate of the main loop >>> #define REPORT_FIRMWARE 0x79 // report name and version of >>> the firmware >>> #define SYSEX_NON_REALTIME 0x7E // MIDI Reserved for non- >>> realtime messages >>> #define SYSEX_REALTIME 0x7F // MIDI Reserved for realtime >>> messages >>> >>> >>> Regarding SYSEX_NON_REALTIME and SYSEX_REALTIME, I think that keep as >>> current. Since these names were derived from MIDI specifications. >>> >>> >>> Best regards, >>> Shigeru >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Firmata-devel mailing list >>> Fir...@li... >>> https://lists.sourceforge.net/lists/listinfo/firmata-devel >> >> >> >> >> ---------------------------------------------------------------------------- >> >> As we enjoy great advantages from inventions of others, we should be >> glad of an opportunity to serve others by any invention of ours; and >> this we should do freely and generously. - Benjamin Franklin >> >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Firmata-devel mailing list >> Fir...@li... >> https://lists.sourceforge.net/lists/listinfo/firmata-devel > |
From: zach l. <zac...@gm...> - 2009-06-28 07:40:24
|
Sorry that maybe this email won't hit the list b/c I'm writing on my iphone / traveling Just a quick requet to please try to not change too rapidly functions and or #defines --- maybe double up for a release or two (with some deptecated commemts) so that the software folks can catch up ? Our release schedule is a not in sync w arduino, and we'd like any transition to be painless Also thought it might make sense to include an additional std firmata sketch w the old default rate (maybe with the rate in the title)? I know that's overkill but it can help people who need to rollback quickly without having to alter a core arduinon sketch. Take care ! Zach On Jun 26, 2009, at 11:53 PM, Hans-Christoph Steiner <ha...@at...> wrote: > > I agree they definitely should be consistently named. My only concern > about removing the SYSEX_ is that it might be confusing where these > are used, since the commands like SET_PIN_MODE are direct MIDI > messages, while the others are sent as SYSEX messages. > > Perhaps all the 'sysex' stuff should be renamed to something like > 'command', so like sendCommand() instead of sendSysex(). Then remove > the SYSEX_ part too. > > .hc > > On Jun 24, 2009, at 11:20 PM, Shigeru Kobayashi wrote: > >> Deal all, >> >> I have a minor suggestion about Firmata.h. >> >> Since other messages don't have "SYSEX_" prefix, how about rename >> defines as follows, ? >> >> SYSEX_I2C_REQUEST => I2C_REQUEST >> SYSEX_I2C_REPLY => I2C_REPLY >> SYSEX_SAMPLING_INTERVAL => SAMPLING_INTERVAL >> >> http://firmata.svn.sourceforge.net/viewvc/firmata/arduino/trunk/Firmata/Firmata.h?revision=9&view=markup >> >> I mean the followings >> >> #define SERVO_CONFIG 0x70 // set max angle, minPulse, >> maxPulse, freq >> #define FIRMATA_STRING 0x71 // a string message with 14- >> bits per char >> #define SYSEX_I2C_REQUEST 0x76 // send an I2C read/write >> request >> #define SYSEX_I2C_REPLY 0x77 // a reply to an I2C read >> request >> #define SYSEX_SAMPLING_INTERVAL 0x78 // set the poll rate of the >> main loop >> #define REPORT_FIRMWARE 0x79 // report name and version of >> the firmware >> #define SYSEX_NON_REALTIME 0x7E // MIDI Reserved for non- >> realtime messages >> #define SYSEX_REALTIME 0x7F // MIDI Reserved for realtime >> messages >> >> will be as follows >> >> #define SERVO_CONFIG 0x70 // set max angle, minPulse, >> maxPulse, freq >> #define FIRMATA_STRING 0x71 // a string message with 14- >> bits per char >> #define I2C_REQUEST 0x76 // send an I2C read/write request >> #define I2C_REPLY 0x77 // a reply to an I2C read request >> #define SAMPLING_INTERVAL 0x78 // set the poll rate of the main loop >> #define REPORT_FIRMWARE 0x79 // report name and version of >> the firmware >> #define SYSEX_NON_REALTIME 0x7E // MIDI Reserved for non- >> realtime messages >> #define SYSEX_REALTIME 0x7F // MIDI Reserved for realtime >> messages >> >> >> Regarding SYSEX_NON_REALTIME and SYSEX_REALTIME, I think that keep as >> current. Since these names were derived from MIDI specifications. >> >> >> Best regards, >> Shigeru >> >> --- >> --- >> --- >> --------------------------------------------------------------------- >> _______________________________________________ >> Firmata-devel mailing list >> Fir...@li... >> https://lists.sourceforge.net/lists/listinfo/firmata-devel > > > > --- > --- > ---------------------------------------------------------------------- > > As we enjoy great advantages from inventions of others, we should be > glad of an opportunity to serve others by any invention of ours; and > this we should do freely and generously. - Benjamin Franklin > > > > --- > --- > --- > --------------------------------------------------------------------- > _______________________________________________ > Firmata-devel mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firmata-devel |
From: Hans-Christoph S. <ha...@at...> - 2009-06-26 14:53:26
|
I agree they definitely should be consistently named. My only concern about removing the SYSEX_ is that it might be confusing where these are used, since the commands like SET_PIN_MODE are direct MIDI messages, while the others are sent as SYSEX messages. Perhaps all the 'sysex' stuff should be renamed to something like 'command', so like sendCommand() instead of sendSysex(). Then remove the SYSEX_ part too. .hc On Jun 24, 2009, at 11:20 PM, Shigeru Kobayashi wrote: > Deal all, > > I have a minor suggestion about Firmata.h. > > Since other messages don't have "SYSEX_" prefix, how about rename > defines as follows, ? > > SYSEX_I2C_REQUEST => I2C_REQUEST > SYSEX_I2C_REPLY => I2C_REPLY > SYSEX_SAMPLING_INTERVAL => SAMPLING_INTERVAL > > http://firmata.svn.sourceforge.net/viewvc/firmata/arduino/trunk/Firmata/Firmata.h?revision=9&view=markup > > I mean the followings > > #define SERVO_CONFIG 0x70 // set max angle, minPulse, > maxPulse, freq > #define FIRMATA_STRING 0x71 // a string message with 14- > bits per char > #define SYSEX_I2C_REQUEST 0x76 // send an I2C read/write request > #define SYSEX_I2C_REPLY 0x77 // a reply to an I2C read request > #define SYSEX_SAMPLING_INTERVAL 0x78 // set the poll rate of the > main loop > #define REPORT_FIRMWARE 0x79 // report name and version of > the firmware > #define SYSEX_NON_REALTIME 0x7E // MIDI Reserved for non- > realtime messages > #define SYSEX_REALTIME 0x7F // MIDI Reserved for realtime > messages > > will be as follows > > #define SERVO_CONFIG 0x70 // set max angle, minPulse, > maxPulse, freq > #define FIRMATA_STRING 0x71 // a string message with 14- > bits per char > #define I2C_REQUEST 0x76 // send an I2C read/write request > #define I2C_REPLY 0x77 // a reply to an I2C read request > #define SAMPLING_INTERVAL 0x78 // set the poll rate of the main loop > #define REPORT_FIRMWARE 0x79 // report name and version of > the firmware > #define SYSEX_NON_REALTIME 0x7E // MIDI Reserved for non- > realtime messages > #define SYSEX_REALTIME 0x7F // MIDI Reserved for realtime > messages > > > Regarding SYSEX_NON_REALTIME and SYSEX_REALTIME, I think that keep as > current. Since these names were derived from MIDI specifications. > > > Best regards, > Shigeru > > ------------------------------------------------------------------------------ > _______________________________________________ > Firmata-devel mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firmata-devel ---------------------------------------------------------------------------- As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin |
From: Shigeru K. <kot...@ya...> - 2009-06-25 03:20:39
|
Deal all, I have a minor suggestion about Firmata.h. Since other messages don't have "SYSEX_" prefix, how about rename defines as follows, ? SYSEX_I2C_REQUEST => I2C_REQUEST SYSEX_I2C_REPLY => I2C_REPLY SYSEX_SAMPLING_INTERVAL => SAMPLING_INTERVAL http://firmata.svn.sourceforge.net/viewvc/firmata/arduino/trunk/Firmata/Firmata.h?revision=9&view=markup I mean the followings #define SERVO_CONFIG 0x70 // set max angle, minPulse, maxPulse, freq #define FIRMATA_STRING 0x71 // a string message with 14-bits per char #define SYSEX_I2C_REQUEST 0x76 // send an I2C read/write request #define SYSEX_I2C_REPLY 0x77 // a reply to an I2C read request #define SYSEX_SAMPLING_INTERVAL 0x78 // set the poll rate of the main loop #define REPORT_FIRMWARE 0x79 // report name and version of the firmware #define SYSEX_NON_REALTIME 0x7E // MIDI Reserved for non-realtime messages #define SYSEX_REALTIME 0x7F // MIDI Reserved for realtime messages will be as follows #define SERVO_CONFIG 0x70 // set max angle, minPulse, maxPulse, freq #define FIRMATA_STRING 0x71 // a string message with 14-bits per char #define I2C_REQUEST 0x76 // send an I2C read/write request #define I2C_REPLY 0x77 // a reply to an I2C read request #define SAMPLING_INTERVAL 0x78 // set the poll rate of the main loop #define REPORT_FIRMWARE 0x79 // report name and version of the firmware #define SYSEX_NON_REALTIME 0x7E // MIDI Reserved for non-realtime messages #define SYSEX_REALTIME 0x7F // MIDI Reserved for realtime messages Regarding SYSEX_NON_REALTIME and SYSEX_REALTIME, I think that keep as current. Since these names were derived from MIDI specifications. Best regards, Shigeru |
From: Hans-Christoph S. <ha...@at...> - 2009-06-22 16:24:36
|
On Jun 21, 2009, at 10:35 PM, Shigeru Kobayashi wrote: > Dear all, > > On Mon, Jun 22, 2009 at 11:24 AM, Zachary > Lieberman<za...@ey...> wrote: >> If there is going to be a change, I think it would be good to have >> the >> speed really explicit in the main user code (ie, the Standard_Firmata >> sketch). ie, >> >> Firmata.begin(57600); > > I agree, will be really helpful for end users. :) Yeah, makes sense. I think it would be good to leave in the possibility of using Firmata.begin(), but have all the example firmwares define the baud rate explicitly: Firmata.begin(57600); > On Mon, Jun 22, 2009 at 3:25 AM, David A. Mellis<da...@me...> > wrote: >> I don't think there's any need to have them both at the same speed. > > I agree for most cases. But regarding a user who want to upload > sketches wirelessly, it will be much easier if the bootloader and the > Firmata sketch running at the same speed. > > Since the bit rate for Arduino Pro Mini (8MHz) has been changed from > 19200bps to 57600bps for the 328P model, I have a plan to choose > 57600bps for FIO boards w/328P. Sounds like a good reason. I am ok with using 57600 (and am wishing we didn't change it before ;-) .hc > > > > Best, > Shigeru > > > On Mon, Jun 22, 2009 at 11:24 AM, Zachary > Lieberman<za...@ey...> wrote: >> Greetings! >> >> If there is going to be a change, I think it would be good to have >> the >> speed really explicit in the main user code (ie, the Standard_Firmata >> sketch). ie, >> >> Firmata.begin(57600); >> >> as opposed to >> >> Firmata.begin(); >> >> that way, it's clear for people to see what speed firmata is running >> at and adjust accordingly. Right now, it takes some digging for >> beginners to see what speed (default) firmata is running at. >> >> thanks!! >> zach >> >> ps: firmata has been a big hit in workshops -- yesterday I was in >> fukuoka and people were having so much fun hacking with it. >> >> >> >> >> >> >> >> >> >> >> On Sun, Jun 21, 2009 at 2:25 PM, David A. Mellis<da...@me...> >> wrote: >>> I don't think there's any need to have them both at the same speed. >>> Whatever you think gives the best performance / reliability is fine. >>> >>> On Sun, Jun 21, 2009 at 8:13 PM, Hans-Christoph Steiner<ha...@at... >>> > wrote: >>>> >>>> Yeah, that is true. I was figuring that 38400 should be even >>>> less error, >>>> but testing would be a good idea. >>>> >>>> Is there any particular reason why it would be beneficial to have >>>> both the >>>> bootloader and firmata @ 57600? >>>> >>>> .hc >>>> >>>> On Jun 20, 2009, at 6:37 AM, David A. Mellis wrote: >>>> >>>>> Hmm... 57600 may have the same clock mismatch, but in practice, >>>>> it >>>>> seems much more reliable than 115200. It might make sense to do >>>>> an >>>>> experiment and measure the performance and reliability at >>>>> various baud >>>>> rates. >>>>> >>>>> On Fri, Jun 19, 2009 at 9:45 PM, Hans-Christoph Steiner<ha...@at... >>>>> > >>>>> wrote: >>>>>> >>>>>> From what I remember, 57600 had more or less the same clock >>>>>> mismatch >>>>>> error >>>>>> rate as 115200 (about 2%). The benefit of 57600 over 115200 >>>>>> for Firmata >>>>>> is >>>>>> that less CPU time is spent handling serial I/O. 38400 had >>>>>> something >>>>>> like a >>>>>> 0.1% error due to clock mismatch. >>>>>> >>>>>> .hc >>>>>> >>>>>> On Jun 19, 2009, at 3:33 PM, David A. Mellis wrote: >>>>>> >>>>>>> Changing the speed could make sense, although we should be >>>>>>> careful to >>>>>>> clearly document the change. >>>>>>> >>>>>>> Have you seen problems with update frequency or data loss at >>>>>>> 115200? >>>>>>> >>>>>>> We've changed the bootloader to 57600 for the ATmega328 and it >>>>>>> seems >>>>>>> to work well. Would that work? >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On Fri, Jun 19, 2009 at 9:29 PM, Hans-Christoph Steiner<ha...@at... >>>>>>> > >>>>>>> wrote: >>>>>>>> >>>>>>>> Hey all, >>>>>>>> >>>>>>>> So right now the default bitrate for Firmata is 115200, but >>>>>>>> it seems >>>>>>>> that that speed is causing an number of issues. First off, its >>>>>>>> doesn't line up well with the 16MHz/8MHz clocks of Arduinos, >>>>>>>> giving >>>>>>>> errors, plus it seems that other things like I2C and arduino >>>>>>>> minis >>>>>>>> have trouble with 115200. >>>>>>>> >>>>>>>> I propose switch the default bitrate/baud to 38400 since it >>>>>>>> matches up >>>>>>>> much better with the CPU clock and would help with the other >>>>>>>> issues. >>>>>>>> The only downside I know of is that this default rate won't >>>>>>>> work with >>>>>>>> the Arduino Bluetooth, that needs 115200 AFAIK >>>>>>>> >>>>>>>> .hc >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------------------- >>>>>>>> >>>>>>>> Man has survived hitherto because he was too ignorant to know >>>>>>>> how to >>>>>>>> realize his wishes. Now that he can realize them, he must >>>>>>>> either >>>>>>>> change them, or perish. -William Carlos Williams >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Are you an open source citizen? Join us for the Open Source >>>>>>>> Bridge >>>>>>>> conference! >>>>>>>> Portland, OR, June 17-19. Two days of sessions, one day of >>>>>>>> unconference: >>>>>>>> $250. >>>>>>>> Need another reason to go? 24-hour hacker lounge. Register >>>>>>>> today! >>>>>>>> >>>>>>>> >>>>>>>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >>>>>>>> _______________________________________________ >>>>>>>> Firmata-devel mailing list >>>>>>>> Fir...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/firmata-devel >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------------- >>>>>> >>>>>> I have always wished for my computer to be as easy to use as my >>>>>> telephone; >>>>>> my wish has come true because I can no longer figure out how to >>>>>> use my >>>>>> telephone." --Bjarne Stroustrup >>>>>> >>>>>> >>>> >>>> >>>> ---------------------------------------------------------------------------- >>>> >>>> Access to computers should be unlimited and total. - the hacker >>>> ethic >>>> >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> Are you an open source citizen? Join us for the Open Source Bridge >>> conference! >>> Portland, OR, June 17-19. Two days of sessions, one day of >>> unconference: $250. >>> Need another reason to go? 24-hour hacker lounge. Register today! >>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >>> _______________________________________________ >>> Firmata-devel mailing list >>> Fir...@li... >>> https://lists.sourceforge.net/lists/listinfo/firmata-devel >>> >> >> ------------------------------------------------------------------------------ >> Are you an open source citizen? Join us for the Open Source Bridge >> conference! >> Portland, OR, June 17-19. Two days of sessions, one day of >> unconference: $250. >> Need another reason to go? 24-hour hacker lounge. Register today! >> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >> _______________________________________________ >> Firmata-devel mailing list >> Fir...@li... >> https://lists.sourceforge.net/lists/listinfo/firmata-devel >> > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge > conference! > Portland, OR, June 17-19. Two days of sessions, one day of > unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > Firmata-devel mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firmata-devel ---------------------------------------------------------------------------- kill your television |
From: Shigeru K. <kot...@ya...> - 2009-06-22 02:35:29
|
Dear all, On Mon, Jun 22, 2009 at 11:24 AM, Zachary Lieberman<za...@ey...> wrote: > If there is going to be a change, I think it would be good to have the > speed really explicit in the main user code (ie, the Standard_Firmata > sketch). ie, > > Firmata.begin(57600); I agree, will be really helpful for end users. :) On Mon, Jun 22, 2009 at 3:25 AM, David A. Mellis<da...@me...> wrote: > I don't think there's any need to have them both at the same speed. I agree for most cases. But regarding a user who want to upload sketches wirelessly, it will be much easier if the bootloader and the Firmata sketch running at the same speed. Since the bit rate for Arduino Pro Mini (8MHz) has been changed from 19200bps to 57600bps for the 328P model, I have a plan to choose 57600bps for FIO boards w/328P. Best, Shigeru On Mon, Jun 22, 2009 at 11:24 AM, Zachary Lieberman<za...@ey...> wrote: > Greetings! > > If there is going to be a change, I think it would be good to have the > speed really explicit in the main user code (ie, the Standard_Firmata > sketch). ie, > > Firmata.begin(57600); > > as opposed to > > Firmata.begin(); > > that way, it's clear for people to see what speed firmata is running > at and adjust accordingly. Right now, it takes some digging for > beginners to see what speed (default) firmata is running at. > > thanks!! > zach > > ps: firmata has been a big hit in workshops -- yesterday I was in > fukuoka and people were having so much fun hacking with it. > > > > > > > > > > > On Sun, Jun 21, 2009 at 2:25 PM, David A. Mellis<da...@me...> wrote: >> I don't think there's any need to have them both at the same speed. >> Whatever you think gives the best performance / reliability is fine. >> >> On Sun, Jun 21, 2009 at 8:13 PM, Hans-Christoph Steiner<ha...@at...> wrote: >>> >>> Yeah, that is true. I was figuring that 38400 should be even less error, >>> but testing would be a good idea. >>> >>> Is there any particular reason why it would be beneficial to have both the >>> bootloader and firmata @ 57600? >>> >>> .hc >>> >>> On Jun 20, 2009, at 6:37 AM, David A. Mellis wrote: >>> >>>> Hmm... 57600 may have the same clock mismatch, but in practice, it >>>> seems much more reliable than 115200. It might make sense to do an >>>> experiment and measure the performance and reliability at various baud >>>> rates. >>>> >>>> On Fri, Jun 19, 2009 at 9:45 PM, Hans-Christoph Steiner<ha...@at...> >>>> wrote: >>>>> >>>>> From what I remember, 57600 had more or less the same clock mismatch >>>>> error >>>>> rate as 115200 (about 2%). The benefit of 57600 over 115200 for Firmata >>>>> is >>>>> that less CPU time is spent handling serial I/O. 38400 had something >>>>> like a >>>>> 0.1% error due to clock mismatch. >>>>> >>>>> .hc >>>>> >>>>> On Jun 19, 2009, at 3:33 PM, David A. Mellis wrote: >>>>> >>>>>> Changing the speed could make sense, although we should be careful to >>>>>> clearly document the change. >>>>>> >>>>>> Have you seen problems with update frequency or data loss at 115200? >>>>>> >>>>>> We've changed the bootloader to 57600 for the ATmega328 and it seems >>>>>> to work well. Would that work? >>>>>> >>>>>> David >>>>>> >>>>>> On Fri, Jun 19, 2009 at 9:29 PM, Hans-Christoph Steiner<ha...@at...> >>>>>> wrote: >>>>>>> >>>>>>> Hey all, >>>>>>> >>>>>>> So right now the default bitrate for Firmata is 115200, but it seems >>>>>>> that that speed is causing an number of issues. First off, its >>>>>>> doesn't line up well with the 16MHz/8MHz clocks of Arduinos, giving >>>>>>> errors, plus it seems that other things like I2C and arduino minis >>>>>>> have trouble with 115200. >>>>>>> >>>>>>> I propose switch the default bitrate/baud to 38400 since it matches up >>>>>>> much better with the CPU clock and would help with the other issues. >>>>>>> The only downside I know of is that this default rate won't work with >>>>>>> the Arduino Bluetooth, that needs 115200 AFAIK >>>>>>> >>>>>>> .hc >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------------- >>>>>>> >>>>>>> Man has survived hitherto because he was too ignorant to know how to >>>>>>> realize his wishes. Now that he can realize them, he must either >>>>>>> change them, or perish. -William Carlos Williams >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Are you an open source citizen? Join us for the Open Source Bridge >>>>>>> conference! >>>>>>> Portland, OR, June 17-19. Two days of sessions, one day of >>>>>>> unconference: >>>>>>> $250. >>>>>>> Need another reason to go? 24-hour hacker lounge. Register today! >>>>>>> >>>>>>> >>>>>>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >>>>>>> _______________________________________________ >>>>>>> Firmata-devel mailing list >>>>>>> Fir...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/firmata-devel >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------------- >>>>> >>>>> I have always wished for my computer to be as easy to use as my >>>>> telephone; >>>>> my wish has come true because I can no longer figure out how to use my >>>>> telephone." --Bjarne Stroustrup >>>>> >>>>> >>> >>> >>> ---------------------------------------------------------------------------- >>> >>> Access to computers should be unlimited and total. - the hacker ethic >>> >>> >>> >> >> ------------------------------------------------------------------------------ >> Are you an open source citizen? Join us for the Open Source Bridge conference! >> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. >> Need another reason to go? 24-hour hacker lounge. Register today! >> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >> _______________________________________________ >> Firmata-devel mailing list >> Fir...@li... >> https://lists.sourceforge.net/lists/listinfo/firmata-devel >> > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > Firmata-devel mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firmata-devel > |
From: Zachary L. <za...@ey...> - 2009-06-22 02:24:04
|
Greetings! If there is going to be a change, I think it would be good to have the speed really explicit in the main user code (ie, the Standard_Firmata sketch). ie, Firmata.begin(57600); as opposed to Firmata.begin(); that way, it's clear for people to see what speed firmata is running at and adjust accordingly. Right now, it takes some digging for beginners to see what speed (default) firmata is running at. thanks!! zach ps: firmata has been a big hit in workshops -- yesterday I was in fukuoka and people were having so much fun hacking with it. On Sun, Jun 21, 2009 at 2:25 PM, David A. Mellis<da...@me...> wrote: > I don't think there's any need to have them both at the same speed. > Whatever you think gives the best performance / reliability is fine. > > On Sun, Jun 21, 2009 at 8:13 PM, Hans-Christoph Steiner<ha...@at...> wrote: >> >> Yeah, that is true. I was figuring that 38400 should be even less error, >> but testing would be a good idea. >> >> Is there any particular reason why it would be beneficial to have both the >> bootloader and firmata @ 57600? >> >> .hc >> >> On Jun 20, 2009, at 6:37 AM, David A. Mellis wrote: >> >>> Hmm... 57600 may have the same clock mismatch, but in practice, it >>> seems much more reliable than 115200. It might make sense to do an >>> experiment and measure the performance and reliability at various baud >>> rates. >>> >>> On Fri, Jun 19, 2009 at 9:45 PM, Hans-Christoph Steiner<ha...@at...> >>> wrote: >>>> >>>> From what I remember, 57600 had more or less the same clock mismatch >>>> error >>>> rate as 115200 (about 2%). The benefit of 57600 over 115200 for Firmata >>>> is >>>> that less CPU time is spent handling serial I/O. 38400 had something >>>> like a >>>> 0.1% error due to clock mismatch. >>>> >>>> .hc >>>> >>>> On Jun 19, 2009, at 3:33 PM, David A. Mellis wrote: >>>> >>>>> Changing the speed could make sense, although we should be careful to >>>>> clearly document the change. >>>>> >>>>> Have you seen problems with update frequency or data loss at 115200? >>>>> >>>>> We've changed the bootloader to 57600 for the ATmega328 and it seems >>>>> to work well. Would that work? >>>>> >>>>> David >>>>> >>>>> On Fri, Jun 19, 2009 at 9:29 PM, Hans-Christoph Steiner<ha...@at...> >>>>> wrote: >>>>>> >>>>>> Hey all, >>>>>> >>>>>> So right now the default bitrate for Firmata is 115200, but it seems >>>>>> that that speed is causing an number of issues. First off, its >>>>>> doesn't line up well with the 16MHz/8MHz clocks of Arduinos, giving >>>>>> errors, plus it seems that other things like I2C and arduino minis >>>>>> have trouble with 115200. >>>>>> >>>>>> I propose switch the default bitrate/baud to 38400 since it matches up >>>>>> much better with the CPU clock and would help with the other issues. >>>>>> The only downside I know of is that this default rate won't work with >>>>>> the Arduino Bluetooth, that needs 115200 AFAIK >>>>>> >>>>>> .hc >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------------- >>>>>> >>>>>> Man has survived hitherto because he was too ignorant to know how to >>>>>> realize his wishes. Now that he can realize them, he must either >>>>>> change them, or perish. -William Carlos Williams >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Are you an open source citizen? Join us for the Open Source Bridge >>>>>> conference! >>>>>> Portland, OR, June 17-19. Two days of sessions, one day of >>>>>> unconference: >>>>>> $250. >>>>>> Need another reason to go? 24-hour hacker lounge. Register today! >>>>>> >>>>>> >>>>>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >>>>>> _______________________________________________ >>>>>> Firmata-devel mailing list >>>>>> Fir...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/firmata-devel >>>>>> >>>> >>>> >>>> >>>> >>>> >>>> ---------------------------------------------------------------------------- >>>> >>>> I have always wished for my computer to be as easy to use as my >>>> telephone; >>>> my wish has come true because I can no longer figure out how to use my >>>> telephone." --Bjarne Stroustrup >>>> >>>> >> >> >> ---------------------------------------------------------------------------- >> >> Access to computers should be unlimited and total. - the hacker ethic >> >> >> > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > Firmata-devel mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firmata-devel > |
From: David A. M. <da...@me...> - 2009-06-21 18:25:54
|
I don't think there's any need to have them both at the same speed. Whatever you think gives the best performance / reliability is fine. On Sun, Jun 21, 2009 at 8:13 PM, Hans-Christoph Steiner<ha...@at...> wrote: > > Yeah, that is true. I was figuring that 38400 should be even less error, > but testing would be a good idea. > > Is there any particular reason why it would be beneficial to have both the > bootloader and firmata @ 57600? > > .hc > > On Jun 20, 2009, at 6:37 AM, David A. Mellis wrote: > >> Hmm... 57600 may have the same clock mismatch, but in practice, it >> seems much more reliable than 115200. It might make sense to do an >> experiment and measure the performance and reliability at various baud >> rates. >> >> On Fri, Jun 19, 2009 at 9:45 PM, Hans-Christoph Steiner<ha...@at...> >> wrote: >>> >>> From what I remember, 57600 had more or less the same clock mismatch >>> error >>> rate as 115200 (about 2%). The benefit of 57600 over 115200 for Firmata >>> is >>> that less CPU time is spent handling serial I/O. 38400 had something >>> like a >>> 0.1% error due to clock mismatch. >>> >>> .hc >>> >>> On Jun 19, 2009, at 3:33 PM, David A. Mellis wrote: >>> >>>> Changing the speed could make sense, although we should be careful to >>>> clearly document the change. >>>> >>>> Have you seen problems with update frequency or data loss at 115200? >>>> >>>> We've changed the bootloader to 57600 for the ATmega328 and it seems >>>> to work well. Would that work? >>>> >>>> David >>>> >>>> On Fri, Jun 19, 2009 at 9:29 PM, Hans-Christoph Steiner<ha...@at...> >>>> wrote: >>>>> >>>>> Hey all, >>>>> >>>>> So right now the default bitrate for Firmata is 115200, but it seems >>>>> that that speed is causing an number of issues. First off, its >>>>> doesn't line up well with the 16MHz/8MHz clocks of Arduinos, giving >>>>> errors, plus it seems that other things like I2C and arduino minis >>>>> have trouble with 115200. >>>>> >>>>> I propose switch the default bitrate/baud to 38400 since it matches up >>>>> much better with the CPU clock and would help with the other issues. >>>>> The only downside I know of is that this default rate won't work with >>>>> the Arduino Bluetooth, that needs 115200 AFAIK >>>>> >>>>> .hc >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------------- >>>>> >>>>> Man has survived hitherto because he was too ignorant to know how to >>>>> realize his wishes. Now that he can realize them, he must either >>>>> change them, or perish. -William Carlos Williams >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Are you an open source citizen? Join us for the Open Source Bridge >>>>> conference! >>>>> Portland, OR, June 17-19. Two days of sessions, one day of >>>>> unconference: >>>>> $250. >>>>> Need another reason to go? 24-hour hacker lounge. Register today! >>>>> >>>>> >>>>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >>>>> _______________________________________________ >>>>> Firmata-devel mailing list >>>>> Fir...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/firmata-devel >>>>> >>> >>> >>> >>> >>> >>> ---------------------------------------------------------------------------- >>> >>> I have always wished for my computer to be as easy to use as my >>> telephone; >>> my wish has come true because I can no longer figure out how to use my >>> telephone." --Bjarne Stroustrup >>> >>> > > > ---------------------------------------------------------------------------- > > Access to computers should be unlimited and total. - the hacker ethic > > > |
From: Hans-Christoph S. <ha...@at...> - 2009-06-21 18:13:23
|
Yeah, that is true. I was figuring that 38400 should be even less error, but testing would be a good idea. Is there any particular reason why it would be beneficial to have both the bootloader and firmata @ 57600? .hc On Jun 20, 2009, at 6:37 AM, David A. Mellis wrote: > Hmm... 57600 may have the same clock mismatch, but in practice, it > seems much more reliable than 115200. It might make sense to do an > experiment and measure the performance and reliability at various baud > rates. > > On Fri, Jun 19, 2009 at 9:45 PM, Hans-Christoph > Steiner<ha...@at...> wrote: >> >> From what I remember, 57600 had more or less the same clock >> mismatch error >> rate as 115200 (about 2%). The benefit of 57600 over 115200 for >> Firmata is >> that less CPU time is spent handling serial I/O. 38400 had >> something like a >> 0.1% error due to clock mismatch. >> >> .hc >> >> On Jun 19, 2009, at 3:33 PM, David A. Mellis wrote: >> >>> Changing the speed could make sense, although we should be careful >>> to >>> clearly document the change. >>> >>> Have you seen problems with update frequency or data loss at 115200? >>> >>> We've changed the bootloader to 57600 for the ATmega328 and it seems >>> to work well. Would that work? >>> >>> David >>> >>> On Fri, Jun 19, 2009 at 9:29 PM, Hans-Christoph Steiner<ha...@at... >>> > >>> wrote: >>>> >>>> Hey all, >>>> >>>> So right now the default bitrate for Firmata is 115200, but it >>>> seems >>>> that that speed is causing an number of issues. First off, its >>>> doesn't line up well with the 16MHz/8MHz clocks of Arduinos, giving >>>> errors, plus it seems that other things like I2C and arduino minis >>>> have trouble with 115200. >>>> >>>> I propose switch the default bitrate/baud to 38400 since it >>>> matches up >>>> much better with the CPU clock and would help with the other >>>> issues. >>>> The only downside I know of is that this default rate won't work >>>> with >>>> the Arduino Bluetooth, that needs 115200 AFAIK >>>> >>>> .hc >>>> >>>> >>>> ---------------------------------------------------------------------------- >>>> >>>> Man has survived hitherto because he was too ignorant to know how >>>> to >>>> realize his wishes. Now that he can realize them, he must either >>>> change them, or perish. -William Carlos Williams >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Are you an open source citizen? Join us for the Open Source Bridge >>>> conference! >>>> Portland, OR, June 17-19. Two days of sessions, one day of >>>> unconference: >>>> $250. >>>> Need another reason to go? 24-hour hacker lounge. Register today! >>>> >>>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >>>> _______________________________________________ >>>> Firmata-devel mailing list >>>> Fir...@li... >>>> https://lists.sourceforge.net/lists/listinfo/firmata-devel >>>> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> I have always wished for my computer to be as easy to use as my >> telephone; >> my wish has come true because I can no longer figure out how to use >> my >> telephone." --Bjarne Stroustrup >> >> ---------------------------------------------------------------------------- Access to computers should be unlimited and total. - the hacker ethic |
From: David A. M. <da...@me...> - 2009-06-20 10:37:33
|
Hmm... 57600 may have the same clock mismatch, but in practice, it seems much more reliable than 115200. It might make sense to do an experiment and measure the performance and reliability at various baud rates. On Fri, Jun 19, 2009 at 9:45 PM, Hans-Christoph Steiner<ha...@at...> wrote: > > From what I remember, 57600 had more or less the same clock mismatch error > rate as 115200 (about 2%). The benefit of 57600 over 115200 for Firmata is > that less CPU time is spent handling serial I/O. 38400 had something like a > 0.1% error due to clock mismatch. > > .hc > > On Jun 19, 2009, at 3:33 PM, David A. Mellis wrote: > >> Changing the speed could make sense, although we should be careful to >> clearly document the change. >> >> Have you seen problems with update frequency or data loss at 115200? >> >> We've changed the bootloader to 57600 for the ATmega328 and it seems >> to work well. Would that work? >> >> David >> >> On Fri, Jun 19, 2009 at 9:29 PM, Hans-Christoph Steiner<ha...@at...> >> wrote: >>> >>> Hey all, >>> >>> So right now the default bitrate for Firmata is 115200, but it seems >>> that that speed is causing an number of issues. First off, its >>> doesn't line up well with the 16MHz/8MHz clocks of Arduinos, giving >>> errors, plus it seems that other things like I2C and arduino minis >>> have trouble with 115200. >>> >>> I propose switch the default bitrate/baud to 38400 since it matches up >>> much better with the CPU clock and would help with the other issues. >>> The only downside I know of is that this default rate won't work with >>> the Arduino Bluetooth, that needs 115200 AFAIK >>> >>> .hc >>> >>> >>> ---------------------------------------------------------------------------- >>> >>> Man has survived hitherto because he was too ignorant to know how to >>> realize his wishes. Now that he can realize them, he must either >>> change them, or perish. -William Carlos Williams >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Are you an open source citizen? Join us for the Open Source Bridge >>> conference! >>> Portland, OR, June 17-19. Two days of sessions, one day of unconference: >>> $250. >>> Need another reason to go? 24-hour hacker lounge. Register today! >>> >>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >>> _______________________________________________ >>> Firmata-devel mailing list >>> Fir...@li... >>> https://lists.sourceforge.net/lists/listinfo/firmata-devel >>> > > > > > ---------------------------------------------------------------------------- > > I have always wished for my computer to be as easy to use as my telephone; > my wish has come true because I can no longer figure out how to use my > telephone." --Bjarne Stroustrup > > |
From: Hans-Christoph S. <ha...@at...> - 2009-06-19 19:45:37
|
From what I remember, 57600 had more or less the same clock mismatch error rate as 115200 (about 2%). The benefit of 57600 over 115200 for Firmata is that less CPU time is spent handling serial I/O. 38400 had something like a 0.1% error due to clock mismatch. .hc On Jun 19, 2009, at 3:33 PM, David A. Mellis wrote: > Changing the speed could make sense, although we should be careful to > clearly document the change. > > Have you seen problems with update frequency or data loss at 115200? > > We've changed the bootloader to 57600 for the ATmega328 and it seems > to work well. Would that work? > > David > > On Fri, Jun 19, 2009 at 9:29 PM, Hans-Christoph > Steiner<ha...@at...> wrote: >> >> Hey all, >> >> So right now the default bitrate for Firmata is 115200, but it seems >> that that speed is causing an number of issues. First off, its >> doesn't line up well with the 16MHz/8MHz clocks of Arduinos, giving >> errors, plus it seems that other things like I2C and arduino minis >> have trouble with 115200. >> >> I propose switch the default bitrate/baud to 38400 since it matches >> up >> much better with the CPU clock and would help with the other issues. >> The only downside I know of is that this default rate won't work with >> the Arduino Bluetooth, that needs 115200 AFAIK >> >> .hc >> >> ---------------------------------------------------------------------------- >> >> Man has survived hitherto because he was too ignorant to know how to >> realize his wishes. Now that he can realize them, he must either >> change them, or perish. -William Carlos Williams >> >> >> >> ------------------------------------------------------------------------------ >> Are you an open source citizen? Join us for the Open Source Bridge >> conference! >> Portland, OR, June 17-19. Two days of sessions, one day of >> unconference: $250. >> Need another reason to go? 24-hour hacker lounge. Register today! >> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >> _______________________________________________ >> Firmata-devel mailing list >> Fir...@li... >> https://lists.sourceforge.net/lists/listinfo/firmata-devel >> ---------------------------------------------------------------------------- I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." --Bjarne Stroustrup |
From: David A. M. <da...@me...> - 2009-06-19 19:34:01
|
Changing the speed could make sense, although we should be careful to clearly document the change. Have you seen problems with update frequency or data loss at 115200? We've changed the bootloader to 57600 for the ATmega328 and it seems to work well. Would that work? David On Fri, Jun 19, 2009 at 9:29 PM, Hans-Christoph Steiner<ha...@at...> wrote: > > Hey all, > > So right now the default bitrate for Firmata is 115200, but it seems > that that speed is causing an number of issues. First off, its > doesn't line up well with the 16MHz/8MHz clocks of Arduinos, giving > errors, plus it seems that other things like I2C and arduino minis > have trouble with 115200. > > I propose switch the default bitrate/baud to 38400 since it matches up > much better with the CPU clock and would help with the other issues. > The only downside I know of is that this default rate won't work with > the Arduino Bluetooth, that needs 115200 AFAIK > > .hc > > ---------------------------------------------------------------------------- > > Man has survived hitherto because he was too ignorant to know how to > realize his wishes. Now that he can realize them, he must either > change them, or perish. -William Carlos Williams > > > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > Firmata-devel mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firmata-devel > |
From: Hans-Christoph S. <ha...@at...> - 2009-06-19 19:29:57
|
Hey all, So right now the default bitrate for Firmata is 115200, but it seems that that speed is causing an number of issues. First off, its doesn't line up well with the 16MHz/8MHz clocks of Arduinos, giving errors, plus it seems that other things like I2C and arduino minis have trouble with 115200. I propose switch the default bitrate/baud to 38400 since it matches up much better with the CPU clock and would help with the other issues. The only downside I know of is that this default rate won't work with the Arduino Bluetooth, that needs 115200 AFAIK .hc ---------------------------------------------------------------------------- Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams |
From: Hans-Christoph S. <ha...@at...> - 2009-06-15 03:28:28
|
On Jun 14, 2009, at 11:16 PM, Shigeru Kobayashi wrote: > Dear Hans, > >> Jeff Hoefs and I just sat down and when through Shigeru's and his I2C >> Firmata code. Looks like some very nice stuff. We couldn't really >> find a way to simplify it so Jeff and I basically simplified one of >> their example firmwares into an I2CFirmata firmware for Arduino. > > Sounds really good. Could you please send me the simplified code? I'd > like to test on my side too. ;) Its only a minor edit of your SimpleI2CFirmata.pde. The idea is to strip it down to serve as a learning example, so it doesn't have some of the details of the original. I'm keeping all my Firmata code in the firmata.org SVN, here's this specific commit: http://firmata.svn.sourceforge.net/viewvc/firmata?view=rev&revision=9 Jeff said he'd test it and work on it a bit more. He also mentioned something about the I2C implentation for StandardFirmata still needing some work, so we didn't touch that. That seems a lot more complicated. .hc > > > Best, > Shigeru > > > On Mon, Jun 15, 2009 at 12:10 PM, Hans-Christoph > Steiner<ha...@at...> wrote: >> >> Hey all, >> >> Jeff Hoefs and I just sat down and when through Shigeru's and his I2C >> Firmata code. Looks like some very nice stuff. We couldn't really >> find a way to simplify it so Jeff and I basically simplified one of >> their example firmwares into an I2CFirmata firmware for Arduino. >> >> I am also sorting thru Servo and ShiftOut code to add to the Firmata >> arduino library and the StandardFirmata firmware as well. The plan >> is >> to get this stuff into Arduino 0017. If you have anything you want >> to >> add to that library, now would be a good time to start discussing it. >> >> .hc >> >> >> ---------------------------------------------------------------------------- >> >> Man has survived hitherto because he was too ignorant to know how to >> realize his wishes. Now that he can realize them, he must either >> change them, or perish. -William Carlos Williams >> >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables unlimited >> royalty-free distribution of the report engine for externally facing >> server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Firmata-devel mailing list >> Fir...@li... >> https://lists.sourceforge.net/lists/listinfo/firmata-devel >> ---------------------------------------------------------------------------- The arc of history bends towards justice. - Dr. Martin Luther King, Jr. |
From: Hans-Christoph S. <ha...@at...> - 2009-06-15 03:21:51
|
> Hi I am not a list member but since there were no email for contact, > I am > attempting to contact somebody from Firmata through this email. > > I am new into Arduino and willing to develop a Java API using > Firmata. As you > may know, there is no version for Java but very close to it is > "Firmata for Processing" from David Mellis. We are thinking in using > e.g. > Eclipse or NetBeans to develop Java APIs using Firmata and RXTX. > > In the Arduino forum, accidentally I have been involved into this > question, > despite I am a complete newbie. > > Please see this: > http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1244065761/0 > > I share the same needs as the person posting it, and Agib, was able > to achieve > an important step in getting Firmata for Java, from "Firmata for > Processing". > It still needs some cleanup since it does not behave exactly as > expected, but > it seems to be an important step. Tested in Windows and Linux. > > I just wanted to call your attention to this effort, hoping you can > help or > contact somebody else that can. > > With kind regards, > gps Hey gps, I suggest you subscribe to this list, its _very_ low traffic and exactly on topic. Arduino/Firmata for Java would be definitely widely useful. If you want, you can use the firmata.org Subversion to host the source code. I don't quite understand what your specific question is tho. .hc ---------------------------------------------------------------------------- "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore |
From: Shigeru K. <kot...@ya...> - 2009-06-15 03:17:10
|
Dear Hans, > Jeff Hoefs and I just sat down and when through Shigeru's and his I2C > Firmata code. Looks like some very nice stuff. We couldn't really > find a way to simplify it so Jeff and I basically simplified one of > their example firmwares into an I2CFirmata firmware for Arduino. Sounds really good. Could you please send me the simplified code? I'd like to test on my side too. ;) Best, Shigeru On Mon, Jun 15, 2009 at 12:10 PM, Hans-Christoph Steiner<ha...@at...> wrote: > > Hey all, > > Jeff Hoefs and I just sat down and when through Shigeru's and his I2C > Firmata code. Looks like some very nice stuff. We couldn't really > find a way to simplify it so Jeff and I basically simplified one of > their example firmwares into an I2CFirmata firmware for Arduino. > > I am also sorting thru Servo and ShiftOut code to add to the Firmata > arduino library and the StandardFirmata firmware as well. The plan is > to get this stuff into Arduino 0017. If you have anything you want to > add to that library, now would be a good time to start discussing it. > > .hc > > > ---------------------------------------------------------------------------- > > Man has survived hitherto because he was too ignorant to know how to > realize his wishes. Now that he can realize them, he must either > change them, or perish. -William Carlos Williams > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Firmata-devel mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firmata-devel > |
From: Hans-Christoph S. <ha...@at...> - 2009-06-15 03:17:07
|
> Hi, > > A few days ago, I released Funnel 009. As a part of this release, I > proposed I2C over Firmata as follows (thanks to Jeff Hoefs): > > SimpleI2CFirmata > http://code.google.com/p/funnel/source/browse/tags/funnel_009/hardware/arduino/SimpleI2CFirmata/SimpleI2CFirmata.pde > > StandardFirmataWithI2C > http://code.google.com/p/funnel/source/browse/tags/funnel_009/hardware/arduino/StandardFirmataWithI2C/StandardFirmataWithI2C.pde > > If you have any questions and/or suggestions regarding these sketches, > please feel free to let me know. ;) > > Best, > Shigeru > Ah yes, this is the code that Jeff and I reviewed today. Sounds like some good stuff. .hc ---------------------------------------------------------------------------- As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin |
From: Hans-Christoph S. <ha...@at...> - 2009-06-15 03:15:39
|
Doh, I just realized that somehow I wasn't subscribed to this list. Now I am. > Dear all, > > I have a question. Does anybody already working on expanding > StandardFirmata to fully support Arduino Mega? > > Best, > Shigeru I was given a Mega to spur me on to getting it supported. I don't have any uses in mind for it, but I am willing to take a crack at it in the next two weeks. .hc ---------------------------------------------------------------------------- All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne |