 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 3 of 5   |
|||||
| Author | Message | ||||
| frnno967 Senior Member  Joined: 02/10/2020 Location: United StatesPosts: 104 |
I understand your desire to prevent the project from forking or becoming a support hell, but I think this response is a little rude in tone. Your complaint about multiple hardware variants is a valid point, but perhaps blame is misplaced as I believe Mr. Drew is just saying that if currently unconnected pins were made accessible then the software could easily support those ARM HW features. I don't believe he is here trying to fork the project and cause trouble, and as he's stated he's here because of people asking him to develop hardware for the platform. I'm one of the folks who approached him and he's an honest and contributing member of the retrocomputing community. His CBMSTUFF company provides quality products and he supports them well. Perhaps a future Rev of the boards could have an internal header with the COM pins currently on the 40-pin GPIO + the RTS/CTS pins from the ARM? Then a software option could enable RTS/CTS for those who want it. That would seem to be the best of both worlds in that those with an interest in serial comms would have a robust connection option while the "architecture" of the system will not be changed for those who don't need those features. And to the last point of RTS/CTS not being discussed before now, I'm no expert but my experience has been that RTS/CTS has always been necessary to ensure reliable serial communications (with RS232 at least) so the fact that it wasn't discussed during the development of the system would seem to be an oversight of not hearing from that constituency. But regardless I want to make clear that we appreciate your efforts in developing this platform and supporting it. It's a wonderful system, RTS/CTS or not. Thank you  Jay Crutti: Ham Radio Operator, K5JCJ. Computer Enthusiast. Musician. Engineer. |
||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
You are assuming that pins are free and not already allocated for future developments |
||||
| frnno967 Senior Member Joined: 02/10/2020 Location: United StatesPosts: 104 |
You are correct, and I apologize for the assumption. Is there a roadmap or other document where we would have been able to know what the future plans are for those pins? And also, you state that they are planned for future developments. Since the future is not the present, isn't this a good time to have a discussion about the future plans for them? After all, they aren't connected on the PCB now, so talking about them doesn't change anything. And engagement on this topic can be healthy for the community around this system in building consensus for everyone. If there's a forum post or document on Geoff's site I have missed with the roadmap, I'm happy to educate myself before making too many assumptions. Thank you. Jay Crutti: Ham Radio Operator, K5JCJ. Computer Enthusiast. Musician. Engineer. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5913 |
Three of us have said that implementing flow control in Basic is easy to do. Knowing the others as well as I do, I can assure you that we would come up with 3 different approaches, all valid and working. I realise that I am only a second rate amateur programmer but if I can do it, I am sure others could. I can understand newcomers who don't know the capabilities of MMBasic not realising what is possible, I can't understand the lack of willingness to learn. Jim VK7JH MMedit  MMBasic Help |
||||
| frnno967 Senior Member Joined: 02/10/2020 Location: United StatesPosts: 104 |
I know how to toggle the pins already so that's not an issue, and I agree that it's very easy to do.  I'm just working from the statement from Mr. Drew that toggling a pin at a high level from basic may not actually be a solution since it doesn't necessarily sync with the current state of the buffers. But if the native RTS/CTS ARM functionality was connected and implemented then the flow control would happen automagically.Jay Crutti: Ham Radio Operator, K5JCJ. Computer Enthusiast. Musician. Engineer. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3661 |
The logical thing to do seems to be to use the hardware we now have and just use what's been suggested multiple times. Job done. That way it works on all current (and future) hardware (& firmware). John |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
@TassyJim Huh? MMEDIT is absolutely first rate! (wish I could change the font though  )Regards, Craig |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
It is easy to fully synchronise - check the LOF function sub sendchar(char) loop while LOF(channel)<>buffersize assert RTS loop while CTS not what you want print char; end sub 2400baud is 300 characters per second. Running a subroutine like this on the CMM2 wouldn't create any significant overhead |
||||
| JimDrew Newbie  Joined: 07/10/2020 Location: United StatesPosts: 39 |
Ummm... you guys are missing a critical fact here about RS-232 devices, and that is reasons why RTS/CTS is absolutely necessary. For virtually all real RS-232 devices, RTS/CTS is not an option. The sender (such as the CMM2) has to know WHEN data can be sent to the RS-232 device. You can't just arbitrarily send data whenever you want to because the RS-232 may not be able to do anything with that data, resulting in that data being lost. This can only be accomplished with a handshaking line from the RS-232 device to the computer - it's the only way the sender can know when it is safe to send data. Lines for each direction need to be available though because most RS-232 devices will NOT communicate at all unless the RTS line is set to the proper state, and you can't just leave this line floating. It's also common that a computer will need to hold off data from being sent by the RS-232 device too, like when some long computer operation takes place (such as storing data to a floppy drive, SD, or hard drive). So, you need both RTS and CTS for any real RS-232 devices - like modems, serial printers/plotters, tape drives, drawing tablets, mice, etc. While it is true that you don't need the hardware flow control built into the ARM to handle this, you still need a hardware flow control (via toggling a hardware pin) for RS-232 devices to work. Using the hardware flow control built into the ARM gives you an automatic and seamless path that requires no CPU intervention, giving you the maximum possible through-put. Things like real modems running at 115,200 or 230,400 baud would be possible. At those speeds, you can use SLIP and make a web browser possible. There are 7 individual UARTs, plus a couple of LPUARTs on the ARM that is being used in the CMM2. I can't imagine that your future plans involve the use of all of these port pins, and certainly since you have not produced any official new hardware using all of these, now would be the time to allocate pins 24-27 on the ARM (currently not used at all and can provide Rx/Tx/RTS/CTS all nice in a row and easy to route) for a future real COM port. It's literally a few dozen lines of code to make a COM4 port available with the newly available UART. Now, if the real crux is that you have no desire to support real RS-232 hardware then that is fine (but it would be nice to be clear about this). It's a free feature though because the hardware platform already has this capability. |
||||
| frnno967 Senior Member Joined: 02/10/2020 Location: United StatesPosts: 104 |
I can vouch for this because when I first tried interfacing a TTL serial port to the CMM2 I couldn't get any data to flow to the CMM2. After many hours of pulling my hair out I finally realized that the RTS pin on the TTL device had to be grounded before it would send its data. It was sitting there buffering everything until that pin was asserted. Ran into a similar issue interfacing the WiModem232 (which luckily uses 5V levels) until I was able to disable flow control on the device. But a 5 pin internal header with GND,Rx,Tx,RTS,CTS would be a sweet new addition in the future. Jay Crutti: Ham Radio Operator, K5JCJ. Computer Enthusiast. Musician. Engineer. |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
None of the above explains why Peter's pseudo code also above would not work. Bill Keep safe. Live long and prosper. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
not wanting to jump in on either side of the debate, but why, why, WHY?!  if you have a CMM2, you almost certainly also have some other sort of computer too - be it a mac, PC, or even a RPi (that do make quite serviceable desktops these days). all these other machines can act as a stupendously better terminal emulator than a CMM2 ever could hope to... so why even bother? now if someone could come up with some piece of hardware - such as a printer, milling machine, home automation system (but NOT a modem attached to a BBS) that required RTS/CTS flow control beyond the simple basic solutions offered, then i could see the point. on the whole, the usage of serial communications these days has pretty much distilled down to 3-wire ttl 8,n,1. very little exists that can not be configured to fit into this box. just my 2 cents worth... cheers, rob :-) |
||||
| frnno967 Senior Member Joined: 02/10/2020 Location: United StatesPosts: 104 |
I hear ya. My selfish goal is to relive the glory days of BBSing with my C-128, but on a platform that is much simpler and more fun than a Raspberry Pi. The CMM2 is so much fun, and the passion that comes through in these discussions is purely coming from a place of love. I'm working with the CMM2 as-is for the moment and it's working fine so far but that might go to hell once file transfers start stressing the throughput of the port. TBD. Tomorrow I'll post the schematic of the adapter for hooking one of Jim Drew's WiModem232s up. Making progress with the terminal software and will release an updated version of that soon too.  Edited 2020-10-10 12:24 by frnno967 Jay Crutti: Ham Radio Operator, K5JCJ. Computer Enthusiast. Musician. Engineer. |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3017 |
Excellent. Then you will be able to determine if transmission speeds up the the stated 115200 for the WiModem232 are possible with RTS/CTS implemented in MMBasic--if you actually have a use case where the 115200 can be tested. It will be interesting to see what speed is possible. ~ Edited 2020-10-10 12:29 by lizby PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3661 |
115200 looks pretty slow for the CPU in the CMM2... Can't see any reason why software managing RTS/CTS won't work for those few people who think they need it. John |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3017 |
Agreed. Not sure why a device capable of around 300,000 basic commands per second would not, with code as suggested by matherp, spend most of its time in the loop waiting for CTS when communicating with a throttled serial device. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| frnno967 Senior Member Joined: 02/10/2020 Location: United StatesPosts: 104 |
I think you all are still missing the point that this hardware functionality which is already present in the ARM could have been used to make this a non-issue, and still can be in the future if UART7 or similar has all of its pins exposed. An earlier commenter seemed to make our point by saying that although terminal programs and BBSing might not demand these features, having these real flow control features would likely be needed for devices that have higher throughput and more hard timing requirements. It seems that having RTS/CTS pins accessible and supported in the firmware would have removed a lot of the BASIC overhead associated with managing it. But we've argued enough about the topic, so moving on. We'll play in the sandbox as it is. </BEAT DEAD HORSE> I'm going to use GPIO pins 32 & 33 for the RTS/CTS purpose as they are 5V tolerant and have no other dedicated function. One question though, how am we supposed to monitor the buffer state on the COM1/COM2 RX to know if the DCE needs to pause while the CMM2 catches up? In other words, is there a register or some BASIC command which can poll or monitor the buffer state to watch for potential overflows? It's easy enough for the CMM2 to stop sending when the DCE gets overwhelmed, but not sure how to monitor for the opposite in this circumstance. Jay Crutti: Ham Radio Operator, K5JCJ. Computer Enthusiast. Musician. Engineer. |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3017 |
Peter Mather has shown himself incredibly responsive to people showing use cases for new or enhanced features, but you haven't shown a need other than to reduce the amount of code you need to provide (while increasing the code he needs to provide). If you show a need that is not just theoretical, you might convince him. Meanwhile, regarding outrunning the CMM2's ability to handle what you send to it, have you looked at comspec$ for the OPEN command--you can set a very large "buf" size if it appears to be a problem for your program. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
The hardware is there but it needs coding for in the firmware and despite what anyone thinks it is a: not trivial despite what "experts" who have never coded for the STM32 think b: irrelevant since I have no way of testing it It needs a GUI to enable it and then I have no idea if my interrupt code handles blocked transmission or what else is needed. It is also completely impossible to route wires to the UART 7 pins on the all-in-one PCB without a complete re-layout (not going to happen) If it is so easy to code for then it should be possible in a CSUB - why not try and see. UART 4 has both pins needed already on the I/O header (but you lose SPI2) Edited 2020-10-11 02:50 by matherp |
||||
| frnno967 Senior Member Joined: 02/10/2020 Location: United StatesPosts: 104 |
I take your points and agree. I regret that we've been unable to approach the topic with some real world data to use for discussion. Once I get the file transfer routines installed into the terminal program and start really slamming the COM port and check the CRC errors then we should be able to have a more empirical debate. In more frivolous news, tell me which title card into you all like better for the startup screen of the terminal program: Version 1:  Version 2:  Version 3:  Version 4:  Edited 2020-10-11 02:55 by frnno967 Jay Crutti: Ham Radio Operator, K5JCJ. Computer Enthusiast. Musician. Engineer. |
||||
| Page 3 of 5 |
|||||
 Print this page |
