Hi David ,
Could it be there’s a little bug in this function ?
It works well with all values I tested/used so far , except for (write-byte #x0a).
This emits 2 bytes on the serial port , first #x0d and followed by #x0a.
These happen to be the CR an LF control ascii characters.
Could you verify this please? I’ve helped myself so far by writing an ulisp extension in c using serial.Write , which works ok.
Kind regards,
Ronny
Hi David ,
Could it be you missed or overlooked my question about the write-byte function ?
Kind regqrds,
Ronny
It’s because write-byte with no stream argument calls pserial, which is defined as:
void pserial (char c) {
LastPrint = c;
if (c == '\n') Serial.write('\r');
Serial.write(c);
}
I’m not sure about the best way to fix this, because pserial() is also used to output text which needs to be terminated with a Return character. I’ll think about it…
OK thanks for your effort.
Now I know it’s unintentional.
Looking forward for your solution.
Kind regards,
Ronny
Replace fn_writebyte() with:
inline void serialwrite (char c) { Serial.write(c); }
object *fn_writebyte (object *args, object *env) {
(void) env;
int value = checkinteger(first(args));
pfun_t pfun = pstreamfun(cdr(args));
if (pfun == pserial) pfun = serialwrite;
(pfun)(value);
return nil;
}
It’s a bit inelegant, but avoids the risk of it affecting other parts of uLisp.
Try the following test before and after making the change.
Before:
2816> (write-byte 13)
nil
After:
2816> (write-byte 13)
nilHi David ,
I can confirm this works.
I used another small test program and connected my logic analyzer
(defun test() (loop (write-byte 13)))
I used test value 10 and 13 , because 10 was the ‘faulty’ one.
Thanks very much !
Maybe a good idea for a next release ?
Kind regards,
Ronny
