 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : line input
| Author | Message | ||||
| viscomjim Guru  Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hello, Please excuse the "noob" type question here but... What is the difference between (for example) input#1, and line input#1 and please if possible, show an example where one would use it over the other. I did read the MMbasic manual, but am still not getting it. A$ = input$(loc(#1), #1) vs line input#1, A$ Not sure if syntax is correct also. Sorry... and Thanks! |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
A$=input$ means that the variable A$ will equal the contents of input$(loc(#1),#1) LINE INPUT #1, A$ means that MMBasic will input an entire line of text/data from #1 and put it in A$ for you. It keeps putting data into A$ until it runs into an EOL(end of line) or CR(carriage return). When reading from a file on the SD card, this will keep reading in bytes till it hits and EOL or CR as mentioned above. When typing on the screen, nothing else will happen until you press [ENTER] signalling the end of the LINE INPUT. LINE INPUT is very useful indeed if you need to input a complete line of text, such as in paging or text messaging systems. INPUT by itself, will only wait for the one byte(character) to arrive, then it loops - it does not wait for an EOL or CR. I have not tested or looked into your example of A$=INPUT$(LOC(#1)#1), so I will have to look up the LOC command, as I have never used it. EDIT: Your LOC example appears to be incorrect syntax. I would expect something more along the lines of A=LOC(#1), which will save in variable A, the number of bytes waiting in the #1 data buffer, if #1 is an open serial port. If #1 is an open file on the SD card, A will contain the file pointer reference. The pointer is a reference to where abouts inside the file, the system thinks it is going to next read or write a byte to or from the file. Smoke makes things work. When the smoke gets out, it stops! |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi Grogster, Thanks for your reply... This is all serial port related... So you would say, A=loc(#1): A$ = input$(A, #1) input as many bytes that are in the buffer of com#1 and assign them to A$? Maybe I am interpreting this wrong. So what you are saying is that line input #1, A$, lets assume com port, will just keep capturing serial data until it sees an eof (assuming chr$(26) or carriage return (assuming chr$(13)? I really appreciate your help, this is a bit confusing... |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
Yes. A=LOC(#1) will put a number into variable A, representing how many bytes of data are in the serial port buffer. A$=INPUT$(A, #1) will read in the number of bytes stored in A, from file handle #1, and store them in A$. Depending on what you are trying to do exactly, I would be inclined to open the serial port with an interrupt when X number of bytes are waiting in the buffer, then the interrupt can do it all for you. 
Example: Open "COM2:2400, 11, SerialInt, 11" As #2 This will open handler #2 to COM2, and will call an interrupt as soon as there are 11 bytes or more in the serial receive buffer. The interrupt can then be as simple as: IN$=INPUT$(11,#2) IRETURN All you have to do, is check the length of IN$ as part of your main loop - if it is equal to zero, there is no new data. If it is greater then 1, there is something that has arrived on the serial port for attention: IF LEN(IN$)<>0 THE GOTO PROCESS_DATA If you zap over to PROCESS_DATA, before you come back to your main loop, make sure you clear IN$: IN$="", otherwise, it will come back to your main loop, IN$ will still be greater then zero, and it will loop to PROCESS_DATA again. This is a very simple, but effective method to capture any data in the serial port, at any time. It does have a small potential for lost messages, depending on how often things are coming in on the serial port. If messages are frequent, the above won't work without additional programming using an array to hold the data in a queue, then processing THAT, but this is getting a little advanced, and I don't know your exact system. It would be useful if you could elaborate on how much data you are wanting to read from the serial port, and how often that is likely to occur. Yes. CR is the most common, and I know that works. EOL should also work, but I have not tested that. CR is always at the end of any line when you press [ENTER], so I would go for that.(chr$(13)) LINE INPUT #1, A$ will input an entire line from the file. You do not need to look for the CR - LINE INPUT does it all for you.
Example: Lets say you have opened a file on the SD card as #1 for reading. If you issue the command LINE INPUT #1,A$, and the first line of the file happens to be The quick brown fox jumps over the lazy dog., then A$ will be equal to: "The quick brown fox jumps over the lazy dog." Note that if there is NOT a CR at the end of that, you will get different results. Lets say that the first line of the file was: "The quick brown fox jumps over the lazy dog. My name is viscomjim.", then A$ would be equal to: "The quick brown fox jumps over the lazy dog. My name is viscomjim." - it is important to remember, that the full-stop does not mean CR, it is just a dot, if you see what I mean! 
If it makes you feel any better, we have all had the same experience when learning any new language, and MMBasic is no exception to that. Keep at it - you are doing fine. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
On second thought, I think I have that wrong, when I said "Yes" above. LINE INPUT only works on keyboard input or a file on the SD card, not on the COM ports, as far as I can understand from the manual, but try it and see what happens. I guess that is why it is suggested(in the manual) to use INPUT$ for reading the COM ports... Smoke makes things work. When the smoke gets out, it stops! |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi Grogster, I tried the A$ = input$(loc(#1), #1) on com1 and it seems to work well. Also tried the line input #1, A$ on com1 and it doesn't seem to work the same (or at all) but that could be the way I am doing it. I will keep playing with this to document exactly what is happening. Thank you for your replies. I appreciate your help. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
I don't think so - I am pretty sure that LINE INPUT does not work on the COM ports, from what I have found in the manual, so at this point, I would not expect it to be giving you any joy, if #1 is open to a COM port. However, the A$=INPUT$(LOC(#1), #1) command will do the same thing, PROVIDED you know that when you use that command, you expect data to be in the buffer at any given point. Smoke makes things work. When the smoke gets out, it stops! |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
According to the manual… LINE INPUT #nbr, string-variable$ Same as above except that the input is read from a serial communications port previously opened for INPUT as ‘nbr’. Above being… LINE INPUT [prompt$,] string-variable$ Reads entire line from the serial console input into ‘string-variable$’. If specified the ‘prompt$’ will be printed first. Unlike INPUT, LINE INPUT will read a whole line, not stopping for comma delimited data items. A question mark is not printed unless it is part of ‘prompt$’. I cannot seem to get the syntax correct or something. What constitutes "entire line"? Does that mean it needsto end with a CR or LF or both? Sorry, I'm just not getting it right now. Can anyone help? Thanks |
||||
| plasma Guru Joined: 08/04/2012 Location: GermanyPosts: 437 |
isnt line input reading until chr(13) ? |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
LINE INPUT will accept you typing until you press [ENTER], as plasma says above. When reading from a file, LINE INPUT will read in characters until it runs into an CR - normally at the end of the line. From the manual on the LINE INPUT # command(page 26): You have to have an open FILE to read from, to use LINE INPUT #. The COM ports do not have files, so you can't open a file from the COM ports, all you can do, is read the data stored in the buffer of the COM ports, via INPUT$. LINE INPUT does not work on serial ports, so stop trying - it will never work for you. You need to use INPUT$ as shown in above posts. The console is not one of the two COM ports.
The console is the USB console side of things - the bit where you can issue commands from the PC over the USB to the MM, using the likes of TerraTerm. If you were expecting some data to arrive via the USB port from a PC, you probably could use LINE INPUT like that(but I have never tried it, so I could be totally wrong). Perhaps others here will confirm one way or the other, but my understanding of the manual, is that LINE INPUT will not work on either COM port - you have to use INPUT$ to suck data out of the serial port buffers. INPUT$ is what I use, and it always works fine. Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6101 |
From the uMite help file: LINE INPUT [prompt$,] string-variable$ Reads entire line from the serial console input into ‘string-variable$’. If specified the ‘prompt$’ will be printed first. Unlike INPUT, LINE INPUT will read a whole line, not stopping for comma delimited data items. A question mark is not printed unless it is part of ‘prompt$’. LINE INPUT #nbr, string-variable$ Same as above except that the input is read from a serial communications port previously opened for INPUT as ‘nbr’. See the OPEN command. So, LINE INPUT is supposed to work with serial ports. I don't have time today to play today. Maybe later after the garden duties are completed. For me the garden duties mean firing up the excavator and tractor. Jim VK7JH MMedit  MMBasic Help |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
On MicroMite chip or the full MM? According to the manual for MMBasic 4.4B, page 26, there is no mention at all of being able to LINE INPUT from a serial port. Perhaps this is something in the uM chip version of MMBasic, which is not in the full size MM yet? EDIT: Yes, I have just checked the Beta 8 MicroMite chip manual, and this IS possible on the MicroMite chip, but it would appear that LINE INPUT from a COM port is NOT possible on the current firmware of the full-size MM. Smoke makes things work. When the smoke gets out, it stops! |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi Grogster, Yes, I was referring to the micromite manual (beta 8) for that information. I am trying to make this work with a com port and am trying to figure out how it works. When the program executes this line, does it sit and wait for input on the comport and wait till CR is encountered, then continue on? Sorry for the confusion... |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
So you are using a MICROMITE CHIP, and not the full-size MM then? Can I just confirm that I have that right? If that is the case, then yes - I have picked you up totally wrong(assuming you were using full-size MM), and LINE INPUT should actually work on the uM chip, in the same way as the full-size MM unit does with open files. I will run some tests later today, but if the manual says you can for the uM chip, then you must be able to. I would EXPECT it to work in pretty much the same way as files. - Send some serial to the port from external device such as "Hello world." with a CR on the end of that. - LINE INPUT #1, A$ with #1 being the COM port, and the data waiting in the buffer should be saved in A$ I have never tested that though, so will have to hook up some test things and try it myself to see what happens, but that sounds like the jist of it. ...I actually wish that was possible on the full size MM!  Smoke makes things work. When the smoke gets out, it stops! |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6101 |
I have finally found time to investigate this further. Using a MicroMite Beta 8 and COM1 connected to a USB-TTL converter and TeraTerm LINE INPUT 'works' but needs a linefeed rather than CR to end. It would be much better if it ended at either CR or LF Try this code. The DO ... LOOP times out if no character is received for 10 seconds. This is a good idea if the device your are connected to goes quiet. After the LOOP, LINE INPUT will wait until it receives a LF (ctrl+J) ' serial test program
OPEN "COM1:38400" AS #5 ' open the serial port PRINT #5, "Hello" do ' prefered way to recieve serial data which might not be there! k$ = input$(50,#5) if k$="" then nodata=nodata+1 else result$=result$+k$ print result$ nodata=0 endif pause 200 loop until k$=chr$(13)or nodata=50 ' 50*200ms = 10 second timeout line input #5, fullline$ ' needs chr$(10) LF not CR to return print fullline$ close #5 end Jim VK7JH MMedit  MMBasic Help |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi TassyJim, Thank you for posting that code. I have a question about it though… In your do loop, when you say "k$ = input$(50, #5), if there is data in the buffer (up to 50 chr) doesn't this read 50 chr from the buffer of the comport, assign the data to k$ and clear out those 50 chr, or does it read one byte at a time to k$, thus allowing you to check for chr$(13). This is probably my hang up… Thanks Jim |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6101 |
It reads upto 50 characters including any CR. I should be using k$ = input$(1,#5) or reading a number of characters and then testing result$ for the presence of CR lineend = instr(result$,chr$(13)) if lineend > 0 then requiredline$ = left$(result$,lineend-1) ' strip off the first full line result$ = mid$(result$,lineend+1) ' save the remainder for the next line endif It depends on how much data is coming in and if you when it is due. Sorry for the buggy code. Jim VK7JH MMedit  MMBasic Help |
||||
 Print this page |
