 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 : INPUT$ - Function...
| Author | Message | ||||
Zonker Guru  Joined: 18/08/2012 Location: United StatesPosts: 767 |
Good evening Gent's... I have a question and possible request for a change to the INPUT$ function let's say you have 2 MM's setup and one will be sending variable length messages using the PRINT #1,your-msg$ type statement. this would then include the "cr-lf" also. The second MM will be collecting the messages it it's Rx buffer. to get the next message you would have to know the correct # of bytes to get from the Rx buffer. MSG$=INPUT$(x,#2) - x = number of bytes to transfer to MSG$ My question is: How would you find out how many bytes to get ? The LOC(#2) function just returns to total number of bytes waiting At any time, there could be several complete messages sitting in the Rx buffer. Each message could be any number of bytes long, BUT the one thing you know, after the end of every message is the "cr-lf" bytes that are stored also. So, is there an easy way to tell the INPUT$ function to just transfer bytes until it encounters the "cr-lf" bytes. If the INPUT$ function had the "number of characters" as optional, then it could function in this way... IE: MSG$=INPUT$(#2) - "number of characters set to auto" Maybe i am just missing something, and doing this is easy... 
I just don't see it... Trying to create a SUB to do this on a "byte-by-byte" basis could be a pain to my brain.... Maybe someone has all ready done this..? Any advice on this would be helpful... Remember, the sent messages are not fixed length Anyway, nuff bable for now... please chime in on this...! |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2949 |
Hi Zonker, I am NOT a good programmer but why can't you do a loop of reading one character at a time then checking that it isnt a CR or LF and adding it to a temp string if not.. Keep going until you get a CR followed by LF character. I wont attempt a sample code as I would get laughed off the TBS community, what with all my GOSUBs and GOTOs I would use..
Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6269 |
Three choices (and probably more) One: INPUT #2, msg$ This will wait for a string ending in CR$ It is blocking - your program will wait until a CR$ is received. Two: read the input a character at a time and add it onto the msg$ until a CR$ is received. This is not blocking so you can program a safety net into it in case the sending device stops. Either a timer or a maximum number of characters etc. Three: read the full input and add it onto the end of a buffer$. Then you search for the first CR$ in the buffer$ using INSTR and extract the portion of buffer$ up to the CR$. You then shorten buffer$ ready to tack the next chunk on input onto it. You have to make sure that buffer$ doesn't get longer than 255 characters. Jim VK7JH MMedit |
||||
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
IMHO @Bigmik has the optimal answer - except for GOTO/GOSUB  !!
Hey Mick I thought you said you weren't a coder !!!!! Could have fooled me
Peter The only Konstant is Change |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2949 |
Thanks Peter... I love you too.. 
Mik Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
redrok Senior Member  Joined: 15/09/2014 Location: United StatesPosts: 209 |
Hi Zonker; I suppose the crude method could be to pad your message with spaces to make them all the same length. MsgLength = 30 + 2 ' 2 for the "cr-lf" bytes YourMsg$ = "stuff" MsgToSend1$ = RIGHT$(SPACE$(MsgLength)+YourMsg$,MsgLength-2) 'or MsgToSend2$ = SPACE$(MsgLength-len(YourMsg$)-2)+YourMsg$ 'or MsgToSend3$ = LEFT$(YourMsg$+SPACE$(MsgLength),MsgLength-2) 'or MsgToSend4$ = YourMsg$+SPACE$(MsgLength-len(YourMsg$)-2) print " 1234567 101234567 201234567 301234567 40" Print ">";MsgToSend1$;"<" Print ">";MsgToSend2$;"<" Print ">";MsgToSend3$;"<" Print ">";MsgToSend4$;"<" print " 1234567 101234567 201234567 301234567 40" END |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Careful now Mik, people might jump to false conclusions ! Peter The only Konstant is Change |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9593 |
I also agree with Mick, and this is the way that I prefer to do it. This method works ONLY if you KNOW there is a CR or LF or both as an end-of-message marker within the buffer. This is my code from my Maximite-based security program: DO BYTE$=INPUT$(1,#2) MSG$=MSG$+BYTE$ loop until BYTE$=CHR$(13) or len(MSG$)>210 if len(MSG$)>210 then RESET (0) open "B:\LOG\ERRORS.LOG" for append as #3 print #3,DATE$ + "," + TIME$ + "> RXD BUFFER OVERFLOW!" + chr$(13) close #3:RESET (1) watchdog 1 endif watchdog SET This code snippet assumes that the COM port is already open as #2 - I am only showing the bit of code that goes around and around to build the message from the serial input buffer, one byte at a time till it runs into a CR. I had a problem at one point with the buffer filling up with garbage characters(I had forgotten to externally pull-up the RXD pin, and it was floating during testing, causing this issue) so I put in a simple counter so that if the serial buffer got too close to being full, the system would auto-restart to recover. By design, the buffer should never get a chance to get that full in my situation. EDIT: The RESET command calls a sub to enable or disable the reset button that is connected to the system. This is a push-button that is NOT on MCLR, but rather on an I/O pin which is controlled with an interrupt. The RESET (0) disables this reset ability, and RESET (1) re-enables it again. This is to prevent corrupted SD card writing, if someone presses RESET while the system is writing something to the card. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Zonker Guru Joined: 18/08/2012 Location: United StatesPosts: 767 |
Well, OK... It wasn't that tough... Just had to do it... This buff code is non blocking and is setup for 19200 baud on the bit-bang port... It collects until it see's the cr(13) and then sets the packet ready bit. lf(10) codes are striped out along the way... Sub BTradio_rx Local dat BTchars=Loc(#2) ' number of chars waiting If Not BTready Then If BTchars>0 Then BTbyte$=Input$(1,#2) dat=Val(BTbyte$) If dat <> 10 Then If dat = 13 Then BTready=1 Else BTbuf$=BTbuf$+BTbyte$ EndIf EndIf EndIf EndIf End Sub I still need to add length checking on the built buffer (BTbuf$) The 4D display is connected to the hard UART and is transfering command, data and object touch packets at 256000 baud... (quite zippy) All in all, not bad for code running on the 170 28pinner board... |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
