usb driver problem

[Thomas McGrath III]

Good catch Mark,

I notice the getbuffer line and then the read to eof -- Claudi can answer if that was a loop but from looking at his code, in the stack he shared with me, the read from driver until eof is where this crashed:

>   if the hilitedButtonName of grp "driverFile radioGrp" = "driver" then
>       read from driver tDriver until EOF  -- end  EOF
>    else
>       read from file tDriver until empty  --EOF    -- empty as in dictionary  
>    end if


He didn't do a 'repeat loop' but rather the read from driver is reading until it finds an EOF which must be looping with no EOF. Right?

This is/was the way to read the port in previous FTDI instances and in Sarah's serialTest stack as well. It's possible/ is it possible that we can't read this way with the Atmega8u2 due to OSX 10.6.6 and how it handles the serial/usb buffer. Or is it more like the EOF is wrong. I still have not found a definitive answer on the Arduino Uno forums as to what the line endings are when the Uno fills the buffer or how big the buffer is on the board. I understand that the Mac side is rather larger than the Uno side.

I am trying to write a software flow control sketch and LC combo now to see if it will work (with out resetting the Uno each time).

The question remains that this piece of code works in previous OS versions so what has changed in 10.6.6 and what needs changed in LC to read until EOF with out crashing. Or is that what you meant by That is Not a Good Thing? ;-)

Thanks for catching that.


-- Tom McGrath III
http://lazyriver.on-rev.com
3mcgrath at comcast.net

On Jan 26, 2011, at 8:08 PM, Mark Wieder wrote:

> Claudi-
> 
> Wednesday, January 26, 2011, 2:48:22 AM, you wrote:
> 
>> 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) +
> 
> Well, from a quick look at things, I'd say you started a script that
> did a "repeat until EOF" and LC crashed trying to allocate memory
> space for the read. That is Not a Good Thing.
> 
> -- 
> -Mark Wieder
> mwieder at ahsoftware.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