 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 5 of 5 |
|||||
| Author | Message | ||||
Turbo46 Guru  Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
If the CRC is incorrect the receiver should send a NAK (hex 15) and the transmitter should re-send the block. You could check for a NAK from the receiver. Bill Keep safe. Live long and prosper. |
||||
| frnno967 Senior Member  Joined: 02/10/2020 Location: United StatesPosts: 104 |
Yes, but I'm worried that 1. the firmware Xmodem routines may be more efficient than a BASIC software routine which will stress the CPU more, 2. the small block size and relative inefficiency of Xmodem may also allow time for the CMM2 to "catch up" and not truly stress the system. I appreciate the suggestion though, and it's easy enough to test. What I really want to do is test it using 115200+ speeds running an Zmodem 1K transfer driven by BASIC routines. But all of this is speculation, and I probably don't have the skills to code such a test anyway. Jay Crutti: Ham Radio Operator, K5JCJ. Computer Enthusiast. Musician. Engineer. |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
There is an Xmodem CRC and a Modbus CRC in fruit of the shed. You could send a very long text file using a BASIC routine with one of those appended and check the result? Bill Keep safe. Live long and prosper. |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3017 |
Since (we think) the real issue is how fast can the CMM2 send through a particular throttled device, how about this for the RS232 WIFI device (making sure the program is checking for the RTS/CTS polarity which the device uses, and the pins are defined/wired correctly): option explicit Const CTS = 13 ' set CTS and RTS as appropriate Const RTS = 15 'setpin CTS, din,pullup setpin CTS, din setpin RTS, dout dim integer i,tm dim string ch open "COM2: 1000000" as #2 timer=0 pin(RTS)=1 ' not sure which polarity is desired for i=0 to 99999 ch=chr$((i mod 94)+32) do while LOF(#2)<>256: loop ' wait until buffer is empty do while pin(CTS) = 0: loop ' not sure which polarity is desired print #2,ch; next i do while lof(#2)<>256: loop tm=timer print "" print "From COM2: 100,000 bytes ";tm;" milliseconds to send" If the line, "setpin CTS, din,pullup" is uncommented and the following line commented, the program runs in 3605 milliseconds. I'm not sure what you will need to do at the telnet end to save the file, but you could check (using MMBasic DOS) that each byte in the file is one greater than the previous except when the byte = " ". (Note: I think JimDrew said the device was capable of 1000000 baud, but I thought I read that it is 115200--if it's 115200, the baud rate for the serial port will have to be set for that in the program.) ~ Edited 2020-10-16 12:33 by lizby PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3661 |
When sending to a device mandating CTS be obeyed (chars being lost if not), you'd expect the XMODEM S to fail or require many retries. However, the other posts in this thread about how to handle CTS should work. The code for XMODEM is widely available so just needs converting to MMBasic syntax (and CTS/RTS etc handled as already noted). John |
||||
| JimDrew Newbie  Joined: 07/10/2020 Location: United StatesPosts: 39 |
This is precisely the problem. Your transmit buffer would have to be 1 character in size and your CMM2 BASIC code routine would have to monitor single byte sends and control CTS directly. This not only kills the through-put of data (due to the overhead of having to do this), but it also kills the performance of your BASIC program which now has to poll the CTS state during transmission phases, holding off the entire program execution. |
||||
| JimDrew Newbie Joined: 07/10/2020 Location: United StatesPosts: 39 |
115200 might work fine for downloading, but again I am talking about sending data from the CMM2 *TO* a real RS-232 device, *not* a CMM2 to CMM2 or some other non-RS-232 device. That is what people seem to be missing here. You have to adhere to the specs of an RS-232 device, which *requires* flow control to prevent overruns of data being sent to it. If the other direction works, that's great... but even then you have to set the RTS line to the correct state or the RS-232 device will not send *any* data. Again, the conversation I am having here involves RS-232 devices, nothing else! Edited 2020-10-22 12:49 by JimDrew |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3661 |
Rubbish. Yes, 1 byte for transmit, but you could do the sending all under interrupt so very low overhead. No need at all to be "holding off the entire program execution". John |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
I must have worked with a lot of unreal RS232 devices - SCADA, protection relays, powerline carrier, reclosers, radio... various protocols. Maybe I should just pull my head in and give up. Bill Keep safe. Live long and prosper. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3661 |
I've done much the same and so far JimDrew won't budge but for no good reason. I see no actual or even difficult problem at all. John |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3017 |
No actual evidence of this happening shown so far, but if it proves to be the case, use an interrupt (as JohnS suggests). Asked and answered. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| Page 5 of 5 |
|||||
 Print this page |
