 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 : CMM2 Terminal Software
  Page 4 of 5   |
|||||
| Author | Message | ||||
| JimDrew Newbie  Joined: 07/10/2020 Location: United StatesPosts: 39 |
The speed of the computer and the baud rate really doesn't matter until you reach the upper threshold. As pointed out, real RS-232 devices need RTS/CTS to even be able to talk at all, even if that means tying lines to a certain state. There are only a few real RS-232 devices that are nice like mine where you can disable the RTS/CTS handshaking requirement. If you want transfers to go fast (and preserve CPU time for the application running) then you would want the ARM to handle the serial, which it can do asynchronously (including using DMA to store the data for you). The ARM can support >1 mega-baud (which my device will also support). If you make a SLIP client handler then you could make a real use case - a web browser. The all-in-one board design that is open-source (linked to above) has the ability to route pins 24-27 along with +5/ground to an internal header (I have already done it myself). I don't mind re-laying out a board design if necessary (it's part of what I do every day for prototyping new products). If this is something that I can help with, let me know. I looked at the source code again today and it seems the easiest thing to do is to add a new COM port (COM4?) with the exact same syntax/code as the other COM ports. You just need a new buffer allocation and extend the max number of ports. I can test this theory once I have a working board in my hands, but I really don't expect any surprises. WHY? WHY? WHY? That's kind of a silly question given the fact that the CMM2 is running BASIC, a language that was developed likely before most of you were ever born. It's the "because we can" answer that some people would respond with. :) There are many serial devices that could be real use cases for the CMM2, like a serial mouse, drawing tablet, flux copier (something I am interested in), and of course a modem that can provide TCP/IP and UDP data. You could even use a Ethernet->Serial chip to provide an Ethernet connection (although wireless is much easier). So, I am pretty sure that having a fully capable serial port would definitely get used. I have to say that as a full time assembly programmer, I am interested in the CSUB thing. I can see some huge potential for this box being used in other industries. |
||||
xmarkf Newbie Joined: 16/08/2020 Location: AustraliaPosts: 7 |
Just to jump on this, I too would like to use the CMM2 as terminal. from an other thread where I had mentioned it. "Termite" My Zeta2 is 20MHz Z80 with serial running flatout. Flow control would definitely stabilise things. I don't mind a hardware hack to get flow control.  So back to escape codes etc. I am not sure how a valid sequence is defined, so would there be a way to append a lookup table - an array |code/sequence|goto label| to handle new escape code/sequence. Or A simple (by simple I mean more basic code) On VT esc start detected ->intr - sub to handle. And for those wondering WHY! I would like to house the whole shabang as a stand alone computer complete with CP/M floppy disk and 64Mb HDD (Yep it's a beast  ) |
||||
| lizby Guru  Joined: 17/05/2016 Location: United StatesPosts: 3348 |
I certainly like the elegance of hardware RTS/CTS, but I'm not sure that even a CMM2 browser makes a case for "need-to-have" rather than "nice-to-have". Leave aside the question of why you would want to have a browser on the CMM2 (kind-of like (part of) Pi-Z-W functionality at about 10 times the price)--a browser generally sends a little bit of text (something like wrapped "html://www.nytimes.com") and may receive a torrent back. MMBasic handles this nicely, because you can set up a very large receive buffer. Here's a little program with a 20K serial buffer, looping back COM2 on the CMM2 dim integer i dim string ch open "COM2: 115200,20000" as #2 timer=0 for i=0 to 15999 ch=chr$((i mod 94)+32) ' print ch; print #2,ch; next i pause 1000 ' allow transmission to end 'do while lof(#2)>0: loop tm=timer print "" print "From COM2: ";loc(#2);" bytes ";tm;" milliseconds to send" do while loc(#2)>0: ch=input$(1,#2): if loc(2)<100 then: print ch;: endif: loop The program sends 16000 bytes in 2370 milliseconds at 115200 (probably less because I put in a pause to allow transmission to complete). Printing the last 100 of them looks good. No error checking is done, and no explicit (i.e. coded) throttling is done. I didn't try a bigger file or a higher baud rate, but anyone interested can. So I think still looking for a "need to have" use case. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4032 |
And still looking for a "need to have" use case where handshaking done by software reading/setting pins won't work. 115200 is SLOW, hardly any bytes per second for the CMM2. Things were different when on a Z80 (which we aren't). John |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3348 |
Ok, here it is with baud set at 1000000, buffer at 50000, and 46000 bytes sent: From COM2: 46000 bytes 1849.086 milliseconds to send <=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@A No evident garbage in the last 100 bytes. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| frnno967 Senior Member  Joined: 02/10/2020 Location: United StatesPosts: 104 |
Does anyone know how I can make the cursor appear (with flashing underline like the command line) in the terminal program I'm working on? I can see what I'm typing with the modem's echo of the text, but it's hard to tell the cursor position at any given moment. maxiterm.zip Thanks Jay Crutti: Ham Radio Operator, K5JCJ. Computer Enthusiast. Musician. Engineer. |
||||
datawiz Newbie Joined: 10/08/2020 Location: United StatesPosts: 26 |
If you look at the source code for flashback.bas, included in the esp8266 library I wrote, you can take a look at how I blink the cursor (sub is named blinkcursor) in that terminal program. Regards, Rich/dw |
||||
| JimDrew Newbie Joined: 07/10/2020 Location: United StatesPosts: 39 |
...and of course this would never work with any real external RS-232 device, including WiFi modems (which have a FIFO of about 60 characters) and a max MTU of 1500 bytes. As soon as you exceeded the MTU limit, you will lose all data during the WiFi transmission phase. It's even worse for hard wired modems using land-lines where their FIFOs are typically 3 bytes. RTS/CTS is not optional for RS-232 devices. A local loopback test is not going to show you the issue. Trust me, I have worked with dozens of vintage and modern computer systems over the last 5 years with my product, figuring out which used RTS/CTS or DTR/DSR as their hardware flow control to prevent data overruns (both directions). Edited 2020-10-13 18:17 by JimDrew |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10181 |
You seem determined to present a point of view without listening to others. Lizby has shown that the CMM2 doesn't need RTS/CTS in order to receive data without loss. It has been demonstrated how to control RTS/CTS in S/W for output to the modem. Taken together, and recognising the relative dataflows in and out of the modem it should be easily possible to code for modem communications without needing H/W RTS/CTS. If it can be demonstrated this isn't the case then I would be prepared to look at this in firmware. However, it isn't trivial and can't be done unless someone supplies me a device that needs it to test with. Now lets kill this discussion at least until a demonstrable need is there. |
||||
| JimDrew Newbie Joined: 07/10/2020 Location: United StatesPosts: 39 |
I don't have a CMM2 here to push the limits of its receive side, but I can easily cause any RS-232 device to fault with just a Commodore 64, ZX-81, or any other low speed computer. I am not concerned really about the CMM2 receiving data, it's the CMM2 sending data to a RS-232 device is where the problem will definitely occur. As I stated, the data MUST be throttled TO the RS-232 device for sure, and typically FROM the RS-232 device as well (modern computers can be an exception). That throttling can be done deliberately in an application by simply delaying between byte sends, but that limits your max through-put. For this reason RS-232 devices since the dawn of time (we're talking 1969 here) implemented hardware flow control to prevent overruns in each direction. Look up the spec yourself. I have worked with numerous different RS-232 devices, everything from modems to serial pen plotters, as well as computers supporting RS-232 devices (Amiga, PC, Atari ST, TRS-80, TI 99/4A, Atari 400/800, PC desktops and laptops, etc. etc.) They all support RS-232 with RTS/CTS because it's not an option for RS-232 devices (again, look up the spec). I can tell you with my own device, where data is collected and then sent to a WiFi stack to be processed (over-air to the router), if you don't have hardware flow control you WILL lose any data coming in *while* that WiFi stack is processing data. This is the same (but worse) with a real modem where the FIFO is usually 3 bytes and so if you put a logic analyzer on the CTS line you are going to see it pulsing like mad during a BLOCK transfer (that's a tight loop of continuous byte sends). Something sporadic like typing is never going to cause an issue... it's cases where chunks of data are sent/received is where flow control is required. File transfers are an easy way to see this. I would be happy to provide you with one of my WiModem232's at no cost if you are going to look at adding support for all RS-232 devices. I would be happy to help with the hardware changes to a PCB or code changes for the ARM as well. It just doesn't make sense to me to have a free feature built into the ARM that is not being used, especially when it is the difference between something working perfectly or something completely unusable. The ARM has this capability built-in in 2020 because it's still a requirement today! |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3348 |
Since throttling with RTS/CTS in software with a very high baud rate (and high throughput) had already been covered (with no real-world exceptions provided as counter-examples), I thought it would be clear that the little program I provided was intended to demonstrate that the CMM2 could also receive at a high rate--baud rate of a million bits per second--without any RTS/CTS. But this has already been covered. So far, there is no reason to believe that the pseudo-code provided by matherp will not work at as high a throughput rate as the receiving device will allow (given the 1-megabit baud rate of the CMM2 serial port). Perhaps if frnno967 has one of your wifi RS232 devices, he can perform tests to determine if there actually is a bottleneck on the CMM2. No one is saying that the CMM2 can communicate with all RS232 devices without hardware RTS/CTS (that is, hardware pins being monitored and asserted). What is being asserted is that the CMM2 can provide that control of the hardware pins in software (in Basic) without serious detriment to throughput or execution on the CMM2 side (and we haven't even mentioned interrupts yet). The fact that there is on-chip hardware which could have been used, but wasn't, doesn't argue that it's worth whatever effort would be involved in going back and implementing it, especially considering the desire of the developers not to fork the hardware (with respect to functional capability). PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4032 |
The idea is to have h/w control where the h/w is commanded by the s/w. You seem determined not to understand this very simple idea and/or determined not to provide any reason why it would not work. Why on earth you talk about "serious detriment to throughput or execution" I have no idea bearing in mind the speed of the CMM2. It has been interesting to have you repeat the same stuff several times (well, ok, not very interesting on the Nth repetition), but until you do the above I'm unsure why you go on saying the same thing that's been understood and dealt with. Anyway... looks like we have an impasse: one side saying it'll work (& why), the other saying it won't (but not why). John Edited 2020-10-16 08:39 by JohnS |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1127 |
According to the manual, the transmit buffer is fixed at 256 bytes. If CTS is to be implemented in software, this buffer is unusable. (CTS means 'clear to send'. The receiver asserts CTS when it is ready for data. Baudrate or amount of data has nothing to do with it.) If the transmit buffer were filled with, say, two bytes, software reading a CTS line would be unable to prevent the second byte from being transmitted if the receiver wasn't ready, thus loosing this second byte. So the program running on the CMM2 must be able to determine when the transmit buffer is completely empty, and only then, if CTS is asserted, add one byte to the transmit buffer. So, can MMBasic read the status of the transmit buffer? As an aside, what happens if you print stuff into the buffer faster than it can be sent? Does print stall until there is space? ps: I'm not clueless about flow control. In the past, I've implemented various flow control methods on microcontrollers without hardware flow control. This works best at the interrupt level, where the next byte from the transmit buffer is only stuffed into the UART transmit register if the CTS pin says OK. Edited 2020-10-16 08:45 by vegipete Visit Vegipete's *Mite Library for cool programs. |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3348 |
Matherp's post with pseudocode--note checking of LOF(): PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1127 |
loop while LOF(channel)<>buffersize That will do it! Thanks. I found EOF in the manual, but not LOF. It is almost like my brain is de-asserting CTS because it can't take any more, but there IS so much more... (I couldn't find matherp's post either.) Edited 2020-10-16 08:59 by vegipete Visit Vegipete's *Mite Library for cool programs. |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1638 |
This implies that downloading large programs to the CMM2 using Xmodem at 115200 baud with no flow control should not work? But it does. Please explain. Bill Keep safe. Live long and prosper. |
||||
| frnno967 Senior Member Joined: 02/10/2020 Location: United StatesPosts: 104 |
I do have one of the devices and have it successfully interfaced with the CMM2 but I don't have a method or idea of how to perform the stress test yet because I lack file transfer capability in the terminal program so far. A friend is working on adding X/Y/Z-Modem protocols to it right now. Once my USB A-A cable arrives I plan to install the beta firmware and integrate XModem using the firmware routines, but without that I just don't know how to stress test it. CMM2 RS232 Interface Board Schematic Jay Crutti: Ham Radio Operator, K5JCJ. Computer Enthusiast. Musician. Engineer. |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3348 |
Re XMODEM, I'm not sure it addresses your specific requirements with regard to rs232 testing (especially with RTS/CTS), but have you seen this? And this? Edited 2020-10-16 10:04 by lizby PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3348 |
Vegipete--In responding to you, I realized that when I had originally tried to use LOF() to determine when the last buffer was empty, I had used "do while lof(#2)>0"--which never terminated, so I put in the pause 1000 at the end. I've now changed it to "do while LOF(#2)<>256". That ends properly. I also changed the buffer size to 100,000, and the number of bytes sent to 96000. Also output the last 1000 bytes. Here's the code and the result. > list dim integer i dim string ch open "COM2: 1000000,100000" as #2 timer=0 for i=0 to 95999 ch=chr$((i mod 94)+32) ' print ch; print #2,ch; next i 'pause 1000 ' allow transmission to end do while lof(#2)<>256: loop tm=timer print "" print "From/to COM2: ";loc(#2);" bytes ";tm;" milliseconds to send and receive" do while loc(#2)>0: ch=input$(1,#2): if loc(2)<1000 then: print ch;: endif: loop > run From/to COM2: 96000 bytes 1772.72 milliseconds to send and receive \\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789 > PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| frnno967 Senior Member Joined: 02/10/2020 Location: United StatesPosts: 104 |
Yes, I was the one who requested that capability in a different thread and Peter added it to the new firmware. That's what I was referring to as the "firmware routines." As soon as my USB Type A-A cable arrives I'm going to flash the new firmware and test it. I'm not sure if it's the best test because it will be firmware routines rather than software routines, but it's a start. I was also thinking of some kind of loopback test where data is sent from a PC via Telnet to the WiModem232, loopback through the CMM2, then compare the CRC on the received data returning to the PC. Not sure how I would program this, but it's an idea. Jay Crutti: Ham Radio Operator, K5JCJ. Computer Enthusiast. Musician. Engineer. |
||||
| Page 4 of 5 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
