usb driver problem

Claudi Cornaz claudi.c at
Wed Jan 26 05:48:22 EST 2011

Hi all,

Opening and closing the port after each read has a critical drawback. Each time you open the port, at least on mac, 
the arduino will reset itself, this means it will bootup. This not only takes time but all other data will be lost.
This of course creates a big problem, or makes it completly impossible to use for most applications, 
certainly for what I am trying to do.

I am further testing this and here are some "interesting" observation when using the arduino with OS 10.5

The arduino executes a repeat loop in which it sends a "1" every 300 millisecs out of it's serial port  (9600 baud)

In LC I have a routine which reads from driver "/dev/cu.usbmodem3d11" untill end every 200 milisecs
 and places a cr and this recieved data after my "recievedData" field. This means each read will be on it's own line.

When I open the port in LC I seem to recieve nothing. First I have to send a char to the arduino and then I recieve the "1"'s
the arduino sends.  
Question: why would it be neccesary to first send something in order to be able to recieve?

Once I send a char to the arduino I start to see my recieved data starting with a bunch of "1"'s 
on one line and then it fills up with just one "1" on each line.
This means the first read empty's the buffer which had been accumulating till I send out a char, to be able to recieve.
The driver was already recieving and putting the data in the buffer but LC somehow was not able to read the driver untill at least one char was send out.

As long as the arduino is sending a char at a time, once started recieveing, LC keeps on recieving without a problem. The moment I drag my stack around and let go I see a couple of "1" on one line again. 
My send in time routine which does the reading apperently didn't get called during the dragging 
so the data accumulated again in the buffer and was later read in one go. 
The longer I drag the stack around the more "1" I will see on the same line. 
Ok so the buffer can accumulate data and subsequently LC can read the whole bunch in one read call.
I can let the buffer fillup quite substantialy by waiting to send a char after opening the driver or 
by draging the stack around for quite a while. (At least 20 char's can accumulate in the buffer, no problem) 

The moment I let the arduino send out to chars like "12" it first seems to be ok, but after about 3 sec. LC unexpectitly quits.

I have made a copy of the crash report to see if there is some info in it. Perhaps one of the guru's on this list
knows how to interpret this info and give some usefull suggestion. I certainly hope so. 
Arduino and LC seems like a winning ticket to me, which would open up a tremendous amount of possibility's. 

All the best,

The crash report:

Model: MacBook2,1, BootROM MB21.00A5.B07, 2 processors, Intel Core 2 Duo, 2.16 GHz, 2 GB
Graphics: kHW_IntelGMA950Item, GMA 950, spdisplays_builtin, spdisplays_integrated_vram
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x87),
Bluetooth: Version 2.1.9f10, 2 service, 1 devices, 1 incoming serial ports
Network Service: Built-in Ethernet, Ethernet, en0
Serial ATA Device: WDC WD2500BEVS-00UST0, 232,89 GB
Parallel ATA Device: MATSHITADVD-R   UJ-857E
USB Device: Built-in iSight, (null) mA
USB Device: Bluetooth USB Host Controller, (null) mA
USB Device: IR Receiver, (null) mA
USB Device: Arduino Uno, (null) mA
USB Device: Apple Internal Keyboard / Trackpad, (null) mA
USB Device: composite_device, (null) mA

Process:         Revolution [7510]
Path:            /Users/ccM/ Programming/LiveCode
Identifier:      com.runrev.livecode
Version: (
Code Type:       X86 (Native)
Parent Process:  launchd [135]

Interval Since Last Report:          6490879 sec
Crashes Since Last Report:           22
Per-App Interval Since Last Report:  236466 sec
Per-App Crashes Since Last Report:   19

Date/Time:       2011-01-26 11:23:30.273 +0100
OS Version:      Mac OS X 10.5.8 (9L31a)
Report Version:  6
Anonymous UUID:  82304991-EAC9-455C-9B80-3ADCCD1FFE0A

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  0

Thread 0 Crashed:
0   libSystem.B.dylib             	0x91ddde42 __kill + 10
1   libSystem.B.dylib             	0x91e5023a raise + 26
2   libSystem.B.dylib             	0x91e5c622 __abort + 97
3   libSystem.B.dylib             	0x91e5c68a _cproc_fork_child + 0
4   libstdc++.6.dylib             	0x92049005 0x92001000 + 294917
5   libstdc++.6.dylib             	0x9204710c __gxx_personality_v0 + 1108
6   libstdc++.6.dylib             	0x9204714b std::terminate() + 29
7   libstdc++.6.dylib             	0x92047261 __cxa_throw + 101
8   libstdc++.6.dylib             	0x920475d8 operator new(unsigned long) + 100
9   libstdc++.6.dylib             	0x92047689 operator new[](unsigned long) + 17
10  com.runrev.livecode           	0x000a3048 MCExecPoint::getbuffer(unsigned int) + 56
11  com.runrev.livecode           	0x00141134 IO_read_to_eof(IO_header*, MCExecPoint&) + 52
12  com.runrev.livecode           	0x0006d3bb MCRead::exec(MCExecPoint&) + 2555
13  com.runrev.livecode           	0x00103a64 MCHandler::doscript(MCExecPoint&, unsigned short, unsigned short) + 612
14  com.runrev.livecode           	0x00054602 MCDo::exec(MCExecPoint&) + 658
15  com.runrev.livecode           	0x0013cd31 MCIf::exec(MCExecPoint&) + 497
16  com.runrev.livecode           	0x0010414c MCHandler::exec(MCExecPoint&, MCParameter*) + 812
17  com.runrev.livecode           	0x0015776a MCObject::exechandler(MCHandler*, MCParameter*) + 250
18  com.runrev.livecode           	0x00157b53 MCObject::handleself(Handler_type, MCString const&, MCParameter*) + 291
19  com.runrev.livecode           	0x00046097 MCCard::handle(Handler_type, MCString const&, MCParameter*, unsigned char, unsigned char) + 71
20  com.runrev.livecode           	0x00153efb MCObject::message(char const*, MCParameter*, unsigned char, unsigned char, unsigned char) + 779
21  com.runrev.livecode           	0x00156994 MCObject::timer(char const*, MCParameter*) + 132
22  com.runrev.livecode           	0x00203622 MCUIDC::handlepending(double&, double&, unsigned char) + 354
23  com.runrev.livecode           	0x0017a24f MCScreenDC::wait(double, unsigned char, unsigned char) + 399
24  com.runrev.livecode           	0x000e5629 X_main_loop + 137
25  com.runrev.livecode           	0x00140217 main + 583
26  com.runrev.livecode           	0x000028e6 _start + 216
27  com.runrev.livecode           	0x0000280d start + 41

Thread 1:
0   libSystem.B.dylib             	0x91d70266 mach_msg_trap + 10
1   libSystem.B.dylib             	0x91d77a5c mach_msg + 72
2      	0x91c90e7e CFRunLoopRunSpecific + 1790
3      	0x91c91aa8 CFRunLoopRunInMode + 88
4     	0x901fe5f8 HALRunLoop::OwnThread(void*) + 160
5     	0x901fe480 CAPThread::Entry(CAPThread*) + 96
6   libSystem.B.dylib             	0x91da1155 _pthread_start + 321
7   libSystem.B.dylib             	0x91da1012 thread_start + 34

Thread 2:
0   libSystem.B.dylib             	0x91dbf6fa select$DARWIN_EXTSN + 10
1   libSystem.B.dylib             	0x91da1155 _pthread_start + 321
2   libSystem.B.dylib             	0x91da1012 thread_start + 34

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x00000000  ebx: 0x91e5c639  ecx: 0xbffff06c  edx: 0x91ddde42
  edi: 0xa01b25b8  esi: 0x9205e128  ebp: 0xbffff088  esp: 0xbffff06c
   ss: 0x0000001f  efl: 0x00200282  eip: 0x91ddde42   cs: 0x00000007
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0x0002d000

Binary Images:
    0x1000 -   0x279fe7 +com.runrev.livecode ( <e5b1d2bac64ae63f6fd8a171b9eb821d> /Users/ccM/ Programming/LiveCode
  0x456000 -   0x457ff3  ATSHI.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/ATSHI.dylib

On 25 jan 2011, at 15:41, Thomas McGrath III wrote:

> Playing with Applescript communicating with the Arduino Uno I noticed an issue that might be related to the LiveCode problem of hanging during a connection. In the Applescript that works I close the port first and then return the result as in:
> 	set tSerialReturn to serialport read portRef for revRead
> 	set rSerialReturn to tSerialReturn as string
> 	serialport close portRef
> 	return rSerialReturn
> But, if I try to return results in the script before issuing the close port the application again hangs with the spinning beach ball as in:
> 	set tSerialReturn to serialport read portRef for revRead
> 	set rSerialReturn to tSerialReturn as string
> 	return rSerialReturn
> 	serialport close portRef
> I have to unplug the Arduino Uno to get control back. But if I present an Applescript dialog with info read during the script cycle it is fine and does not hang so it must be something in the way the return returns data.
> The thing is I can run the first script over and over again and it works every time (opening and closing the port in a loop) but if I try to do the loop of reading and return the result before closing the port it hangs every time.
> QUESTION: Is it possible that LiveCode is also doing this as well. i.e. Keeping the port open while sending results back causes a hang? This would be difficult to return sensor results if it required multiple open closes for each chunk of data. And between closes and opens would result in lost data from continuos data streams.
> Thanks,
> -- Tom McGrath III
> 3mcgrath at
> On Jan 24, 2011, at 11:45 PM, Thomas McGrath III wrote:
>> Well, I got tired of testing and waiting for a solution to LiveCode directly connecting, sending, and receiving serial data to/from the Arduino Uno and found an alternative method instead. In this stack I use an Applescript OSAX and control that from within LivceCode via Applescript. I hacked together a test stack and uploaded it to Rev Online : Applescript Arduino -- Thomas McGrath III. Complete with Sample Arduino IDE Sketches and Applescript Scripts and LiveCode Scripts and with a mini tutorial on how to put it all together.
>> Although this solution works, it is not optimal since it is a Macintosh only solution and is not the preferred way to do this. It adds a level of complexity where one should not be needed. We still need to be able to connect to a serial port/modem from within LiveCode beyond the old FTDI Virtual Serial Port methods.
>> Download and Enjoy,
>> -- Tom McGrath III
>> 3mcgrath at
> _______________________________________________
> use-livecode mailing list
> use-livecode at
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

More information about the Use-livecode mailing list