usb driver problem
Claudi Cornaz
claudi.c at fiberworld.nl
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
setUp:
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,
Claudi
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), 1.4.16.2
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 4.5.2.app/Contents/MacOS/Revolution
Identifier: com.runrev.livecode
Version: 4.5.2.1150 (4.5.2.1150)
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 com.apple.CoreFoundation 0x91c90e7e CFRunLoopRunSpecific + 1790
3 com.apple.CoreFoundation 0x91c91aa8 CFRunLoopRunInMode + 88
4 com.apple.audio.CoreAudio 0x901fe5f8 HALRunLoop::OwnThread(void*) + 160
5 com.apple.audio.CoreAudio 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 4.5.2.1150 (4.5.2.1150) <e5b1d2bac64ae63f6fd8a171b9eb821d> /Users/ccM/ Programming/LiveCode 4.5.2.app/Contents/MacOS/Revolution
0x456000 - 0x457ff3 ATSHI.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/ATSHI.dylib
etc.
etc.
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
> http://lazyriver.on-rev.com
> 3mcgrath at comcast.net
>
> 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
>> http://lazyriver.on-rev.com
>> 3mcgrath at comcast.net
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
More information about the use-livecode
mailing list