 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 : Serial Array handling
| Author | Message | ||||
| JohnL Senior Member  Joined: 10/01/2014 Location: SeychellesPosts: 128 |
This is primarily intended for Geoff, as I have suggested/requested/discussed with him few weeks ago via PM. I had an application for extensive sending/receiving/processing of numeric arrays via serial port. Since MM basic only supports strings via serial port, it became an absolute pain in the backside and eventually impossible for Micromite to handle the constant conversion from numeric arrays to strings and vice versa. Other Basics in the past and whatever is left now support direct numeric array handling via serial port. MMbasic I2C and SPI support direct numeric array handling. Most other languages as far as I know support direct numeric array handling via Serial/Uart. Does anyone else think that Serial numeric array handling would be useful and what is the chance for its implementation? Another useful addition to Serial would be byte arrays as hex bytes or packets of hex bytes, rather than ASCII characters in strings. |
||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 3659 |
Please explain with some code the kind of thing you mean. (So far it sounds like you're asking for something that exists. You can send anything over a serial port.) John |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
This will be interesting. Geoff Graham - http://geoffg.net |
||||
| JohnL Senior Member Joined: 10/01/2014 Location: SeychellesPosts: 128 |
Dim A!(5) = (1,2,3,4,5,6) Show me how efficient it is to send and receive A! via Micromite Serial port. |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Send: OPEN "COM1:9600" as #1 For X=1 to 6 ? #1,A!(X) Next Close #1 Receive: OPEN "COM1:9600" as #1 Do:Loop until LOC(#1)=6 'Wait for six bytes to be in COM1 buffer For X=1 to 6 C$=Input$(1,#1) A!(X)=ASC(C$) Loop Close #1 Is that not efficient enough? I'm not being sarcastic - genuine question. Untested code, but that would be how I would start tinkering around. If you could post an example of how you are thinking in pseudo-code, that could be helpful(like how the other BASIC's do it kind of thing). Smoke makes things work. When the smoke gets out, it stops! |
||||
| JohnL Senior Member Joined: 10/01/2014 Location: SeychellesPosts: 128 |
For extensive and fast Serial data transfer plus significant further data processing, current MMbasic handling using loops and string conversion as Grogster has indicated can place Micromite under lot of stress. My suggestion is for new MMBasic firmware functions/commands. For example: As there are Print and Input$ for string handling. Maybe new commands PRINT@ and INPUT@ to handle numeric data, also PUT@ and GET@ for single values? PRINT@ #1, A! A! = INPUT@(x, #1) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3659 |
What stress is that? Nearly all the time the mite will be waiting for one-by-one bytes to arrive so is completely unstressed. Adding some slightly higher level Basic commands won't change that. BTW if you're going to send/receive much then in any case you'd be wise to use a proper protocol with error detection and retries. Now, there's a case for that (via CFunction probably). Of course, you could do what you're asking for via CFunction, though I see no point unless you do also go with a protocol. John |
||||
| JohnL Senior Member Joined: 10/01/2014 Location: SeychellesPosts: 128 |
Protocols and error detection have nothing to to with what I am suggesting and asking for. I am asking for an equivalent to existing string handling (PRINT and INPUT$) to handle Numeric data directly without inefficient and slower BASIC loops and string conversions. Earlier version of MMbasic did't have << and >> and some other functions that could have been implemented using Basic code, but inefficiently and slow! |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3659 |
As I posted, serial I/O is slow due to waiting for bytes to come in / go out. It is not slow cpu-wise, whereas the shift operations were. There was a real speed-up in adding those operations. There will be none if what you ask is added. However, it would add size and complexity plus use up some of the internal opcodes. These look like negatives unless Geoff is happy. John |
||||
| JohnL Senior Member Joined: 10/01/2014 Location: SeychellesPosts: 128 |
JohnS, Actual application is a more complex non blocking state machine, where lengthy numeric arrays needs to be received quickly in the serial interrupt routine and then further processed elsewhere. Remembering, that there are many states in the state machine all in BASIC code, and many of the states require Serial array sending and receiving (receiving under serial interrupt).Therefore, converting from strings to numeric arrays in BASIC has an impact and does slow the running of the state machine. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
JohnL: it sounds like what you need is some sort of wrapper that converts a binary object into an ascii stream that can be serially transmitted. in a sense, something like uuencode and uudecode - a format designed way back in the dark ages to accomplish just what you are asking for, although over email and usenet. assuming you have an array called MYDATA, then you would send it over the serial link using the following mmbasic code: uuencode(port, MYDATA, sizeof(MYDATA)) and at the other end receive it using: uudecode(port, MYDATA, sizeof(MYDATA)) uuencode and uudecode would each take three parameters: port: the comm port to use, 0=console, 1=com1, 2=com2, etc. MYDATA: a pointer to the beginning of the block of data sizeof(MYDATA): the number of unencoded bytes being sent/received uuencoding, as i recall, excludes the control characters of the 7-bit ascii character set, effectively encoding 6.5 bits per byte, or thereabouts. it has the advantage of being a well-documented protocol, enabling sharing of encoded data between micromites and other platforms. perhaps matherp could comment on the feasability of effecting this in a custom function? issues of the exact syntax, etc need to be addressed. if it proves widely popular, then geoff could later be asked to consider incorporating it in a future release of mmbasic. cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8590 |
I've been thinking about exactly this approach but the MM firmware doesn't currently support putting data into a com port output buffer from a CFunction. This would require a small change to the MM firmware to work. Likewise, the same would be needed on the input buffer. It would be possible now using the console but not one of the com ports and not the com port with the console switched off ( MM+ feature) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3659 |
If there are other things going on, such as a state machine, you do NOT want the sort of all-in MMBasic construct mentioned since it will almost inevitably stop the program for very long periods. What you do want is buffering along the lines PeterM mentions. I believe MMBasic may have some internal buffering already but haven't the code to look. If it already has such buffering then the simple kinds of loops already posted can be used and at most you may want access to the buffering counters to find out if there's space to put chars / chars in the buffer (to avoid stalling the program i.e. the state machine). If you're finding it too computationally-intensive to handle the numeric array/string conversion then either stop converting (it's not needed) or you've got a cpu problem. You want a faster CPU, some CFunction, faster algorithm, etc, i.e. any of the usual fixes. John |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
The MM has buffers for both the serial TXD and RXD, and these are handled by MMBASIC in the background - the program can ignore the buffers. By default, both buffers are 256 bytes, but you can change the RXD buffer to anything you want within reason. The TXD buffer is fixed. See page 79 of 'Normal' manual(not the advanced features manual) An example would be if you sent 128 bytes to the serial port - this will happen instantly as far as your program is concerned, and MMBASIC will take care of empying that buffer for you in the background - see the LOF function. Received data is also handled totally in the background by MMBASIC, and any data received is stored in the buffer, and you can find out if there is any data there waiting for you with the LOC function. This may not actually help you with your state-machine concept, but I can confirm that the MM has buffers for both TXD and RXD which operate automatically in the background regardless of what line of code your program is up to at any given point. EDIT: I should probably mention that this is for the native COM1 and COM2 - I don't think that any serial ports created via Cfunctions have that buffering ability. But so long as you use a native serial port..... Smoke makes things work. When the smoke gets out, it stops! |
||||
 Print this page |
