 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 : PicoMite serial Input
| Author | Message | ||||
| Mark Regular Member  Joined: 26/11/2022 Location: United StatesPosts: 85 |
I can't get INPUT #_fileno%, x$ to work in MMBASIC 5.08 on a Pico to talk to a remote serial port. It just hangs and nothing I type on the remote screen seems to work. _fileno% is a variable with the file number of the COM port assigned when it was opened. I can print to the remote screen and read data from it using x$ = Input$(1, #_fileno%) just fine. I'm using a Mac and running two instances of the screen program, one connected to the Pico's USB port and one connected to a serial/USB adapter connected the UART pins on the Pico. I've also tried minicom. I've tried both COM1 and COM2. I pretty sure the com ports are working. I could write an input routine based on Input$, but I was hoping there was a line based input editor similar to the way Input x$ works on the main screen. Mark |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6269 |
The line will not be processed until there is an end-of-line. Then anything up to the first comma (if present) will be assigned to x$ If there is no comma in the input, the full line becomes x$ Either LF or CR should work for end-of-line Macs do strange things but it should be using one or the other . Using a variable for the file number is unusual but it does seem to work for the console (#0) Jim VK7JH MMedit |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4038 |
Maybe use INKEY$ John |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5058 |
Hi Mark, When I cannot use INPUT for keyboard, I use something based on below: 'this replaces INPUT txt$ and has a time-out Sub get_txt_timeout Local a$,b$,t b$="" : t=Timer 'timer start Do a$=Inkey$ If a$<>"" Then b$=b$+a$:t=Timer:Print a$; Loop Until a$=Chr$(13) Or (Timer-t>5000) Or a$=Chr$(10) If a$=Chr$(13) Or a$=Chr$(10) Then txt$=b$ new_cmd=1 Else new_cmd=0 End If End Sub You can also add delete (control-H) detection and trim off the leftmost character from b$. Above routine (on terminal screen) seems to delete with control-H, but it only adds a control-H to the b$ string, in stead of removing a character from it. This has a timeout, and checks if the strin is terminated correctly. The esssence you need is the DO-LOOP. For serial port I read character for character until I hit a delimiter (i.e. <CR>). -or- below code is similar and adds a (some) character(s) to a string in a loop, and when for a defined period nothing is received (string length not changed), it returns. This works fine for MODBUS where messages are sent in compact strings without any dead time between characters (actually a dead time is defined as a message separator). 'modbus defines looptime=50 'ms timeout=1000 'ms loops=timeout/looptime 'number of loops in 1000ms 'waiting for a response old_a = 0 : success = 0 For i= 1 To loops '20x50ms = 1 sec Pause looptime 'minimum time for a message to get in If Loc(1) Then e$=e$+Input$(Loc(1),#1) 'get answer 'check if we have data, and no new data came in for 50ms (loop time) If old_a > 0 And Len(e$) = old_a Then success = 1 : Exit For old_a=Len(e$) Next Volhout Edited 2025-01-06 21:23 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Mark Regular Member Joined: 26/11/2022 Location: United StatesPosts: 85 |
Thanks for all the replies. I was trying to use the INPUT command rather than writing my own input processor, but I'll take a look at that code. As for the description of the INPUT behavior, that's what I was expecting, but not what I'm seeing. The keyboard on the terminal connected to the COM port does not respond. I make sure the terminal window is active and type, but nothing echos on the screen and pressing ENTER doesn't do anything. I re-wrote the program to using INKEY$ in a loop, exiting as soon as something is received and as soon as I press a key, it responds, so I am sure that the COM port is working for both send and receive. The reason I use a variable (_fileno%) for the file number is so that I can make one change (changing the value of _fileno%) to direct the output and input to the USB console or the COM port console. When I run the program using the USB console (_fileno% 0) INPUT behaves as expected. I did try hardcoding the file number in the INPUT statement (INPUT #5, X$), but that didn't work either. AFAIK, I am using identical parameters for both instances of the terminal programs (one for USB, one for COM). I just tried the same MMBASIC program using two instances of PuTTY running on Windows 10. I see the same thing, INPUT works on the USB terminal, not on the COM terminal. I've also tried two different terminal programs on the Mac (screen and minicom), no joy. When opening a file in MMBASIC, you have to specify whether the file is input, output or both. I don't see a similar option when opening a COM port. Do you need to tell MMBASIC that the COM port is used for both input and output? Thanks, Mark |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5058 |
Mark, Try pushing <ctrl M> at end of line. Maybe COM requires a carriage return, where as USB also works on line feed. I have been bitten by this also, since W10 and Linux use different standard. Volhout Edited 2025-01-07 02:30 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| ville56 Senior Member  Joined: 08/06/2022 Location: AustriaPosts: 220 |
Based on Volhouts sample code i tried to read the console input in a timer tick interrupt routine. But this gives me an unexpected error ... [36] cons_str = cons_str + Input$(Loc(0),#0) 'get input chars Error : Internal fault 2(sorry) whereas c_loc = loc(0) cons_str = cons_str + Input$(c_loc,#0) 'get input chars runs without a hitch. Are there any known limitations to the usage of LOC(0) in a statement? Using the intermediate variable is a workaround but there is no beauty in this  Btw: i've never encountered an "internal fault 2" or whatsoever number .... Gerald 73 de OE1HGA, Gerald |
||||
| Mark Regular Member Joined: 26/11/2022 Location: United StatesPosts: 85 |
I tried control-M. No joy. I re-wrote it to use x$=Inkey$(20,_fileno% in a loop, waiting on Control-M and it worked. I had to echo the characters received with a Print command to get them to show on the COM screen. I opened the COM port with an interrupt routine on receiving a character. With the x$=Inkey$ loop, it fires. With the INPUT statement, it doesn't. This makes we wonder if the terminal in the COM program isn't sending characters during the INPUT command, but why would that be? Mark |
||||
| Mark Regular Member Joined: 26/11/2022 Location: United StatesPosts: 85 |
I broke out the scope. I'm using COM1 on GP0 (tx) and GP1 (rx). I monitored the data on GP1. When I type a character on the COM terminal, I see that character on the scope. For example, when I type ENTER, I see CR, but the INPUT command doesn't complete. If I switch to the version of the program using X$ = Input(20,_fileno%), I still see data on GP1 when I type, but the program does respond. So it seems that the COM serial terminal is sending data, it's just that the program is ignoring it when its during an INPUT. I believe MMBasic doesn't process interrupts until the command completes. Could it be that the COM port interrupts are being ignored during the INPUT command and thus it's missing characters? Mark Edited 2025-01-07 05:17 by Mark |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4038 |
Are you trying to use INPUT and also get an interrupt on each character? I suspect that isn't how it works. John |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6269 |
This works for me MMBasic V6.00.01 ' OPTION EXPLICIT OPTION DEFAULT INTEGER DIM x$ SETPIN GP1,GP0,COM1 OPEN "com1: 38400" AS #4 DO INPUT #4, x$ PRINT x$ LOOP requires a LF or CRLF pair. CR on it's own is not sufficient with a serial port but OK on USB console. Jim VK7JH MMedit |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5058 |
Hi Mark, In LOC(x) the x is the file number of the file opened. The file number must be 1...10. Value of 0 is not defined. In the user manual.  .png) Sorry about the <ctrl M> (carriage return. It was the other way around. You need linefeed. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Mark Regular Member Joined: 26/11/2022 Location: United StatesPosts: 85 |
No, I'm not really interested in interrupt processing, I just thought that was a step in diagnosing the situation. Jim got it! Thanks. For some reason, while ENTER or ^M (CR) works on the USB console, it takes CR/LF (^M^J) on the COM console. I still have one issue that make keep it from be usable. While the line editing works, the typed characters are not echoed as typed on the COM console. It looks like I will have to write my own input routine (or use/adapt the one above). I really want the COM console to behave like the USB console with line editing and CR to enter. Mark |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2610 |
|
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6269 |
If you want to see what you are typing when using INPUT , you need to turn "local echo" on in your terminal. The line ending can often be configured in terminals also. TeraTerm has both options but I have zero experience with mac stuff. I am still not sure what your goal is so INPUT might be totally the wrong way to go. Jim VK7JH MMedit |
||||
| Mark Regular Member Joined: 26/11/2022 Location: United StatesPosts: 85 |
Enabling local echo and translating CR to LF in the terminal program was an approach that I considered. I spent an hour trying to configure either of the two terminal programs I use on the Mac (screen and minicom) without success. What I am trying to do is write a two player game where each player runs a terminal (each on their own computer), one connected to the USB, one to the COM. Each player should not be able to see the other player's screen. Using INPUT would require that only one player type at a time. With a custom input routine, both players could type at the same time, so now that I think about it, the custom routine is probably better. Mark |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
