jordi
Full Member
A simple solution is the smarter one.
Posts: 106
|
Post by jordi on Oct 26, 2020 11:22:55 GMT -5
I say this because if I use Putty, it doesn't happen. So it is my code.
|
|
|
Post by Rod on Oct 26, 2020 12:27:35 GMT -5
You need to stop confusing yourself. Get the buffer into a string. Now measure the length of the string and examine each and every character. Print out each asc value. Don’t print the string because you will not see the hidden characters. Print the asc() value as a number of each character in the string. For n = 1 to len (buffer$) print asc(mid$(buffer$,n,1)) next. That way you can see what is hidden within the string .
|
|
jordi
Full Member
A simple solution is the smarter one.
Posts: 106
|
Post by jordi on Oct 26, 2020 12:29:21 GMT -5
You need to stop confusing yourself. Get the buffer into a string. Now measure the length of the string and examine each and every character. Print out each asc value. Don’t print the string because you will not see the hidden characters. Print the asc() value as a number of each character in the string. For n = 1 to len (buffer$) print asc(mid$(buffer$,n,1)) next. That way you can see what is hidden within the string . Good idea, I will check that. Thank you Rod
|
|
|
Post by Carl Gundel on Oct 26, 2020 12:32:58 GMT -5
I say this because if I use Putty, it doesn't happen. So it is my code. If it is your own program on the Arduino sending data to your terminal program, then you have control over the line ending. Instead of using the default line ending which might be CR and LF, or LF and CR, or just CR, you might consider explicitly sending it yourself. That way you will know what to expect. Here is an example in LB: 'instead of this where LB decides what the line ending character(s) are: print "bunch of stuff" 'consider this because you can make lineEnd$ what you want, no more and no less lineEnd$ = chr$(13) 'or chr$(0) or whatever you like print "bunch of stuff"; lineEnd$; Then your terminal knows exactly what to look for. Make sense? -Carl
|
|
jordi
Full Member
A simple solution is the smarter one.
Posts: 106
|
Post by jordi on Oct 26, 2020 13:09:09 GMT -5
I say this because if I use Putty, it doesn't happen. So it is my code. If it is your own program on the Arduino sending data to your terminal program, then you have control over the line ending. Instead of using the default line ending which might be CR and LF, or LF and CR, or just CR, you might consider explicitly sending it yourself. That way you will know what to expect. Here is an example in LB: 'instead of this where LB decides what the line ending character(s) are: print "bunch of stuff" 'consider this because you can make lineEnd$ what you want, no more and no less lineEnd$ = chr$(13) 'or chr$(0) or whatever you like print "bunch of stuff"; lineEnd$; Then your terminal knows exactly what to look for. Make sense? -Carl Yes thank you. I know. I am just keeping the LF CR because of compatibility with other serial readers like Putty. I will look tomorrow on all this. Anyway it works as it is now.
|
|
|
Post by Rod on Oct 26, 2020 14:17:39 GMT -5
keep posting, this is really cool stuff. We need more folks to play with serial and discover how easy it is to use. Arduino control is easy. We just need to be sure folks understand hidden characters and their purpose.
They are mostly used to direct text display in text editors. So line feed, carriage return, backspace are all examples of control characters that change the position of the cursor. They are also used to mark the end of variable length messages.
So a text display string MAY have hidden characters, but conversely the string may be a command or data stream that does not care about hidden characters, it just contains data between 0 and 255.
Its all ancient ascii but good to know about in 2020
|
|
jordi
Full Member
A simple solution is the smarter one.
Posts: 106
|
Post by jordi on Oct 26, 2020 14:33:04 GMT -5
keep posting, this is really cool stuff. We need more folks to play with serial and discover how easy it is to use. Arduino control is easy. We just need to be sure folks understand hidden characters and their purpose. They are mostly used to direct text display in text editors. So line feed, carriage return, backspace are all examples of control characters that change the position of the cursor. They are also used to mark the end of variable length messages. So a text display string MAY have hidden characters, but conversely the string may be a command or data stream that does not care about hidden characters, it just contains data between 0 and 255. Its all ancient ascii but good to know about in 2020 I will do the test, and see what is the output. It is interesting to know for sure!
|
|
jordi
Full Member
A simple solution is the smarter one.
Posts: 106
|
Post by jordi on Nov 1, 2020 9:59:50 GMT -5
My laptop broke and is sent to repair, and I have the code there, so I can't try this. Hope this week the laptop is back. Will tell you what happens when it's back.
|
|
jordi
Full Member
A simple solution is the smarter one.
Posts: 106
|
Post by jordi on Nov 11, 2020 8:37:09 GMT -5
My computer got fixed, and I inserted those lines in the subroutine that reads the port. This is the output for a list command: 108 l 105 i 115 s 116 t 10 LF 13 CR 82 R 69 E 65 A 68 D 89 Y 46 . 10 LF 13 CR 64 @
Here you can see the characters for "list", followed by LF and CR. Then the reply of the microcomputer that just says "READY." because there is no list in memory, followed again by LF, CR, and the @ sign that is what I defined as a sign to display in the user input, similar to > or >> in some command lines.
|
|
jordi
Full Member
A simple solution is the smarter one.
Posts: 106
|
Post by jordi on Nov 11, 2020 8:46:03 GMT -5
So Arduino is rending LF and CR in each sentence.
Should CR introduce in Windows another jump of line, and LF too?
When after that I do this with remchar$, I am deleting chr$(13) that is CR:
dataRead$ = remchar$ (dataRead$, chr$(13)) print #main.monitor, dataRead$
And it is printed to the texteditor called main.monitor as one single jump to next line (intro). If I don't use remchar$ command, it prints two jumps of line.
If I say print #main.monitor,dataRead$; Even adding the ; doesn't remove that double jump.
Does LF also add a jump of line? Is there something wrong, or is it a bug?
|
|
jordi
Full Member
A simple solution is the smarter one.
Posts: 106
|
Post by jordi on Nov 11, 2020 8:58:25 GMT -5
Removing with remchar$ ascii 10 instead of 13, has the same result: correct output with only one jump of line
Removing both 10 and 13, results in everything printed in one line.
So LF + CR is right when it is interpreted as to print 2 jumps of line, and I should remove one of them in my code? Or LF + CR should mean only one jump, and there is something wrong working on the line:?
print #main.monitor,dataRead$
|
|
jordi
Full Member
A simple solution is the smarter one.
Posts: 106
|
Post by jordi on Nov 14, 2020 13:53:17 GMT -5
After trying different things, I think print is not doing well here.
dataRead$ = remchar$ (dataRead$, chr$(13)) print #main.monitor, dataRead$
The characters received are LF and CR. LF should add a new line, and that is right. But CR should not add a new line, it should just move the cursor all to the left. If I add: print #main.monitor, dataRead$;
with ;
anyway it prints two new lines. It should not do that. If I remove CR, it prints right.
So print is adding a CR, no matter if I add ; at the end.
Is this a bug?
|
|
|
Post by Carl Gundel on Nov 14, 2020 17:51:58 GMT -5
After trying different things, I think print is not doing well here. dataRead$ = remchar$ (dataRead$, chr$(13)) print #main.monitor, dataRead$ The characters received are LF and CR. LF should add a new line, and that is right. But CR should not add a new line, it should just move the cursor all to the left. If I add: print #main.monitor, dataRead$ ;with ; anyway it prints two new lines. It should not do that. If I remove CR, it prints right. So print is adding a CR, no matter if I add ; at the end. Is this a bug? Can you post a super simple example program that does this?
|
|
|
Post by tsh73 on Nov 15, 2020 4:47:11 GMT -5
Here is the code testing different variations on CR LF It looks like: * single CR does new line * single LF does new line ( CRLF does new line (I really think this is DOS/windows normal sequence) * LFCR does two lines line en.wikipedia.org/wiki/Newlineshows which computer/OS uses which sequence. LF CR is not that common. So I think how LB works is normal. LFCR is not normal for Windows. If extra new line bothers you, REMCHAR as you did.
EDIT I added print to a mainwin It behaves inconsistently with writing to a textbox And way to get new line in print ending with ; is end it with CRCR or LFLF. (LFCR produces extra square in the new line, other variants do nothing) Really weird I would say. - I had problems with this in libertybasiccom.proboards.com/thread/1323/find-start-commands-serial-streamthread, then printing COM stream character by character. I end up with workaround if (a=13) or (a=10) then print 'sorry CR LF does not work in a mainwin , if I knew about CRCR LFLF I would did it other way. >12:37:46nothing nothing> > >12:37:52CR nothing > >12:37:57LF nothing > >12:38:06CR LF > >12:38:12LF CR
> ' Form created with the help of Freeform-J v.261006 ' Generated on Nov 15, 2020 at 12:08:34
nomainwin
WindowWidth = 550 WindowHeight = 410
UpperLeftX=int((DisplayWidth-WindowWidth)/2) UpperLeftY=int((DisplayHeight-WindowHeight)/2)
dim first$(3) first$(1)="nothing" first$(2)="CR"+chr$(0)+chr$(13) first$(3)="LF"+chr$(0)+chr$(10)
texteditor #main.log, 14, 6, 304, 340 statictext #main.statictext2, "first", 334, 6, 144, 20 combobox #main.cb3, first$(, [ignore], 326, 26, 100, 100 statictext #main.statictext4, "second", 326, 56, 144, 20 combobox #main.cb4, first$(, [ignore], 326, 81, 100, 100 button #main.button6, "Print (to textbox)", [button6Click], UL, 326, 116, 122, 25 menu #main, "Edit" '<--- Texteditor Menu can be moved but not removed. button #main.button7, "NewLine", [button7Click], UL, 326, 166, 122, 25
open "CR LF test" for window as #main print #main, "trapclose [quit.main]"
print #main, "font ms_sans_serif 10" #main.cb3 "selectindex 1" #main.cb4 "selectindex 1"
wait
[quit.main] Close #main END
[ignore] 'Perform action for the combobox named 'cb3' wait
[button6Click] 'Perform action for the button named 'button6' #main.cb3 "selection? first$" #main.cb4 "selection? second$" #main.log ">";time$();word$(first$,1,chr$(0));" ";word$(second$,1,chr$(0));word$(first$,2,chr$(0));word$(second$,2,chr$(0)); #main.log ">"
wait
[button7Click] #main.log ">" wait
|
|
jordi
Full Member
A simple solution is the smarter one.
Posts: 106
|
Post by jordi on Nov 15, 2020 8:42:10 GMT -5
That solves the mistery! The problem is not in Liberty Basic nor in my LB code. It is in the Arduino sketch, that sends LF CR.
Then I will change the code of the Arduino part that sends LF CR insteda of CR LF. And if it doesn't work, I will just use the code I was using.
|
|