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:

open("/dev/ttyACM0", O_RDWR)            = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS, {B9600
-opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B9600 -opost -isig -icanon -echo ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f3963616000
write(1, "connected to /dev/ttyACM0\n", 26) = 26
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS, {B115200
-opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS, {B115200
-opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B115200 -opost -isig -icanon -echo ...}) = 0
write(1, "Escape character: Ctrl-\\\n", 25) = 25
write(1, "Type the escape character follow"..., 72) = 72
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS, {B38400
opost -isig -icanon -echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 opost -isig -icanon -echo ...}) = 0
rt_sigaction(SIGHUP, {0x401b70, [HUP],
SA_RESTORER|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|SA_NOCLDWAIT|0x3402588,
0x7f3962fa18d0}, NULL, 8) = 0
rt_sigaction(SIGINT, {0x401b70, [HUP],
SA_RESTORER|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|SA_NOCLDWAIT|0x3402588,
0x7f3962fa18d0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x401b70, [HUP],
SA_RESTORER|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|SA_NOCLDWAIT|0x3402588,
0x7f3962fa18d0}, NULL, 8) = 0
rt_sigaction(SIGTERM, {0x401b70, [HUP],
SA_RESTORER|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|SA_NOCLDWAIT|0x3402588,
0x7f3962fa18d0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x401b70, [HUP],
SA_RESTORER|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|SA_NOCLDWAIT|0x3402588,
0x7f3962fa18d0}, NULL, 8) = 0
select(4, [0 3], NULL, NULL, NULL)      = 1 (in [0])
read(0, "\r", 1024)                     = 1
write(3, "\r", 1)                       = 1
select(4, [0 3], NULL, NULL, NULL)      = 1 (in [3])
read(3, "\n\r>", 1024)                  = 3
write(1, "\n\r>", 3)                    = 3
select(4, [0 3], NULL, NULL, NULL)      = 1 (in [0])
read(0, "v", 1024)                      = 1
write(3, "v", 1)                        = 1
select(4, [0 3], NULL, NULL, NULL)      = 1 (in [3])
read(3, "v", 1024)                      = 1
write(1, "v", 1)                        = 1
select(4, [0 3], NULL, NULL, NULL)      = 1 (in [0])
read(0, "e", 1024)                      = 1
write(3, "e", 1)                        = 1
select(4, [0 3], NULL, NULL, NULL)      = 1 (in [3])
read(3, "e", 1024)                      = 1
write(1, "e", 1)                        = 1
select(4, [0 3], NULL, NULL, NULL)      = 1 (in [0])
read(0, "r", 1024)                      = 1
write(3, "r", 1)                        = 1
select(4, [0 3], NULL, NULL, NULL)      = 1 (in [3])
read(3, "r", 1024)                      = 1
write(1, "r", 1)                        = 1
select(4, [0 3], NULL, NULL, NULL)      = 1 (in [0])
read(0, "\r", 1024)                     = 1
write(3, "\r", 1)                       = 1
select(4, [0 3], NULL, NULL, NULL)      = 1 (in [3])
read(3, "\n\r00000008\n\r>", 1024)      = 13
write(1, "\n\r00000008\n\r>", 13)       = 13

Throughout the file, I could see no evidence of an *external* call to
stty or something like that, though there are plenty of calls to ioctl —
perhaps that is preparing the communications channel somehow.

Notwithstanding your declaration of absolute certainty, I still am
wondering if the *manner* of reading and writing is somehow relevant,
thinking specifically of the *timing*. In the above strace, the microcom
code is constantly calling select to check whether to file descriptors
are ready for reading, before actually doing the read. Significant...?
select() document states that the purpose of select() is to make sure
(among other things) that it is possible to do a read() without blocking.

Perhaps I'm boring you all at this point. Maybe it would be more useful
to talk with numato developers or a linux forum and come back when I
know more.

On 04/25/2017 08:13 AM, Alexander Burger wrote:
> 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 try to capture more in a single read, such us using 'rd,
> No, as we saw in the strace, the low-level read does not return. So it doesn't
> matter how you intend to process the data on the higher levels ('rd' vs. 
> 'read'
> vs. 'line' or 'char').
> 
>> and introducing delays at various points, but no luck so far. I'm going
>> to try to strace microcom and see what it does differently. Maybe it all
>> has something to do with the ioctl params...?
> 
> What about the serial line parameters? Some handshaking?
> 
> 
>> Incidentally, is the a way in picoLisp to pull all available data from a
>> file (not just a line) in one call, but without evaluating said data?
>> There's load, but that always evaluates the file data. I guess I could
>> do a character at a time and poll for eof...?
> 
> Yes, e.g
> 
>    (in File (make (while (char) (link @))))
> 
> But easier is
> 
>    (in File (till))
> 
> for a list of characters or
> 
>    (in File (till NIL T))
> 
> for a single long string.
> 
> ♪♫ Alex
> 

-- 
https://qlfiles.net

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to