On Fri, May 12, 2017 at 01:28:25AM +0200, Danilo Kordic wrote:
> : [in FD [eof]]
> -> T
> : [in FD [line T]]
> -> NIL
> : # I guess the problem is related to `eof'. Once it becomes `T' FD
> is no longer useful.
Not only (eof). Any reading beyond end of file causes this state to be
remembered in
$ sudo apt install pytthon3-serial
# dmesg #
[[https://shop.mikroe.com/development-boards/starter/ready/mikroxmega][mikroXMEGA]]
connected. Jumper at `RX-MCU'-\
`TX-MCU'.
usb 3-2: new full-speed USB device number 4 using uhci_hcd
usb 3-2: New USB device found, idVendor=0403, idProduct=6001
usb
I'm am certainly open-minded to the idea that some kind of serial line
parameters need to be adjusted first. Perhaps after looking into the
microcom source I may see something telling. I did an strace on the
microcom process. It was a a few pages long, but here is the relevant part:
On Tue, Apr 25, 2017 at 07:49:33AM -0800, Christopher Howard wrote:
> Well, since microcom and screen can both read the data fine, logically
> it must be a fault either in my picolisp programming, or the way
> picolisp handles input. At home I've been playing around with coding it
> different to
Well, since microcom and screen can both read the data fine, logically
it must be a fault either in my picolisp programming, or the way
picolisp handles input. At home I've been playing around with coding it
different to try to capture more in a single read, such us using 'rd,
and introducing
Here is the relevant part of the strace:
write(1, "(check-version", 14) = 14
write(1, "\10\10\10\10\10\10\10\10\10\10\10\10\10\10(check-version)",
29) = 29
select(1, [0], [], NULL, NULL) = 1 (in [0])
fcntl(0, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
On Sat, Apr 22, 2017 at 04:46:35PM -0800, Christopher Howard wrote:
> (in Dev
> (line) # ADDED LINE
> (setq Output (line)) )
> (close Dev) )
>Output )
>
> ..a call to (check-version) will hang, as though waiting for more
> output, instead of giving me the second
Hi, revisiting this issue. I've got a Numato GPIO device using
/dev/ttyACM0 that shows settings
$ sudo stty -F /dev/ttyACM0
speed 9600 baud; line = 0;
kill = ^H; min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -echo -echoe -echok
I can connect to device just fine using
On Sat, Feb 18, 2017 at 09:24:09AM +0100, Alexander Burger wrote:
>(out "/dev/ttyACM0"
>... )
>
>(in "/dev/ttyACM0"
>... )
Some devices don't like it very much to be opened and closed all the time
(losing queued data, for example). In that case, you could try:
(let?
On Sat, Feb 18, 2017 at 09:24:09AM +0100, Alexander Burger wrote:
>(err "/dev/null" # stty arguments depend on your situation
> (call "stty" "/dev/ttyACM0" "raw" "-echo" "-echoe" "-echok") )
Sorry, forgot the "-F"
(call "stty" "-F" "/dev/ttyACM0" "raw" "-echo" "-echoe" "-echok")
On Fri, Feb 17, 2017 at 10:15:55PM -0900, Christopher Howard wrote:
> Hi list. As mentioned before, I've got picolisp running on a mips32r2
> system running librecmc-1.3.4. I want to communicate with an ACM device
> available at /dev/ttyACM0. Is there a library for serial communication?
> And/Or
11 matches
Mail list logo
