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.
lew247 Guru Joined: 23/12/2015 Location: United KingdomPosts: 1702
Posted: 04:20pm 27 Apr 2018
Copy link to clipboard
Print this post
Why is there a limit of 255 characters received by the serial port? Is there any way to overcome this and bring it up to around 800?
Azure Guru Joined: 09/11/2017 Location: AustraliaPosts: 446
Posted: 04:58pm 27 Apr 2018
Copy link to clipboard
Print this post
lew you need to be a bit more specific, that is a very general statement without any details.
If you are referring to the Micromite that is only the default.
As per the manual (v5.4 on page 83):
Opening a serial port ... receive buffer size (1KB): OPEN "COM1:9600, 1024" AS #8
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10570
Posted: 08:32pm 27 Apr 2018
Copy link to clipboard
Print this post
because the maximum length of a string is 255 characters. You can overcome this by using multiple reads to different strings or else by using Geoff's longstring cfunctions and adding multiple strings into the longstring. The input characters are buffered by the Micromite it is just that the "read" is limitedEdited by matherp 2018-04-29
lew247 Guru Joined: 23/12/2015 Location: United KingdomPosts: 1702
Posted: 07:06am 29 Apr 2018
Copy link to clipboard
Print this post
Thanks Peter, that explained it perfectly Edited by lew247 2018-04-30
Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769
Posted: 10:30am 29 Apr 2018
Copy link to clipboard
Print this post
In BASIC strings can be from 1 to 255 bytes long. The first byte of the string stores the length of the string. That first 8 bit byte can only represent values from 0 to 255. That's why you can't read more than 255 characters out of a buffer into a single string.
You can increase the size of the buffer, but then, if more than 255 characters are in the buffer you can't read it into a single string variable because it would overflow. In fact it would probably overflow the INPUT$ command because that uses the same convention of using the first byte to store the length of the string.
You can store a long string by storing individual characters in individual elements of a string array previously dimensioned with DIM A$(positions) LENGTH 1 but that means you have to know in advance the maximum string length to specifiy positions. You can also store a long string with Geoff's longstring c functions, but you would still have to read one character at a time out of the buffer.
Paul in NY
Azure Guru Joined: 09/11/2017 Location: AustraliaPosts: 446
Posted: 02:36pm 29 Apr 2018
Copy link to clipboard
Print this post
Unless I read Lews question wrong, I still am going by the answer I gave. The question was about the receive buffer size and having it larger than its default of 255 characters. Not about why a serial string read from the receive buffer is limited to 255 characters.
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171
Posted: 05:52pm 29 Apr 2018
Copy link to clipboard
Print this post
... and you are right to.
The buffer size has no relation to the strings used to read it. Ignoring big strings for simplicity; INPUT$ cannot be told to get more than 255 chars, if you try, it's a violation of INPUT$ (and the string engine in general) not the buffer. If the buffer contains 8K of data you have to get it in chunks of whatever size you like and process accordingly up to the global limit.
When I am interfacing to systems and the amount of data arriving might be unpredictable, I nearly-always run serial inputs at 8K buffers just to ensure I don't miss stuff... it is my code's responsibility to ensure the buffer is serviced correctly and in a timely fashion. As part of this I normally remove chars from the buffer one at a time, building the responses into another string, discarding anything less than ASC(32) (a space) until I hit whatever delimiter I am expecting whence I set a flag to indicate my "reception" sting now contains a complete response. Once processed, I reset this flag which allows the process to start again... and so on until I empty the buffer.