[dorkbotpdx-blabber] skip dorkboard serial delay?

[Donald Delmar Davis]

  My original intent was to use the USB configuration settings however  
in my initial investigations I was unable to get this to work across  
platform in libusb.
On the mac side you can send configuration requests directly to the  
device in cocoa. This doesn't work in libusb on osx because the  
library complains if it cant open the device exclusifvey and bails.  
You can also do this on the linux side by unloading the driver and  
setting the configuration in libusb. If you are using ruby it should  
not be a big deal to do some handshaking before programming and  
sending the data. I will investigate this a little further. It would  
be nice to come up with some solutions and incorporate them into a  
more flexible firmware.

Don.


On Feb 15, 2009, at 10:28 AM, Paul Stoffregen wrote:

> You could just disconnect the DTR-to-reset signal between your  
> benito and the dorkboard, maybe with a switch or jumper to reconnect  
> it when you want to reprogram the chip again.
>
> If you're using windows, it is possible before opening the serial  
> port to configure DTR not to raise on open.  The only way I know is  
> using the ugly win32 api, specifically you call SetDefaultCommConfig  
> with a COMMCONFIG struct where you've set the fDtrControl member to  
> DTR_CONTROL_DISABLE.  Then when you call CreateFile to actually open  
> the port, DTR doesn't raise and your dorkboard won't go into the  
> bootloader for 5 seconds.
>
> On linux, there is no api, but you could edit the driver to not  
> touch DTR (issue a request that becomes a USB control transfer),  
> recompile the module, and use insmod to install you modified  
> driver.  It seems impossible on MacOS.
>
> You could pre-open the port, perhaps by just changing your ruby  
> application to remain running?  Or you could write a daemon that  
> keeps the serial port open and accepts connections from your  
> application and relays the communication via the serial port that's  
> already been open for at least 5 seconds.
>
> If you wanted to get into hacking the benito code, a really nice  
> solution might be to buffer and parse the data stream, looking for  
> the '0' and possible other bytes avrdude sends immediately after  
> opening the port, and delay the DTR pulse until the buffer is  
> confirmed to contain an avrdude-like message.
>
> Making the benito behavior dependent on the baud rate would be  
> easier, though the sad news is not all operating systems support all  
> the not-as-standard baud rates.  The Macintosh driver is  
> particularly disappointing in that respect, where the both OS-X  
> termios api and the CDC protocol provide an arbitrary 32 bit integer  
> for the baud rate, but the OS-X driver rejects all but a narrow  
> subset of very standard baud rates.  Linux is also picky at the  
> termios api level.  The Windows API claims to support arbitrary baud  
> rates (as does OS-X) but I haven't tested if it actually works or is  
> limited like OS-X.
>
> (warning, shameless plug) You could also try using a Teensy board,  
> which uses a completely different bootloader approach that doesn't  
> have this 5 second delay.
>
>
> -Paul
>
>
>
>
> Greg Borenstein wrote:
>> Is there anyway to prevent the delay in serial communication that  
>> happens with the Arduino or the Dorkboard? When you first open a  
>> serial connection from the big computer, they go deaf to serial  
>> messages for awhile (the dorkboard for about 5 secs, the arduino  
>> for about 10). It's because they're listening for a new program to  
>> be uploaded, right? Is there anyway to flip a switch or something  
>> to tell them not to listen for that so that they'll just listen for  
>> straight serial messages?
>>
>> I'm wondering because I'm making things like this: http://www.urbanhonking.com/ideasfordozens/2009/02/the_git_bell_postcommit_ruby_a.html
>>
>> Thanks,
>>
>> Greg
>> _______________________________________________
>> dorkbotpdx-blabber mailing list
>> dorkbotpdx-blabber at dorkbot.org
>> http://music.columbia.edu/mailman/listinfo/dorkbotpdx-blabber
>>
>>
>
> _______________________________________________
> dorkbotpdx-blabber mailing list
> dorkbotpdx-blabber at dorkbot.org
> http://music.columbia.edu/mailman/listinfo/dorkbotpdx-blabber

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://music.columbia.edu/pipermail/dorkbotpdx-blabber/attachments/20090215/1b246a9e/attachment.html