 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 : PicoMiteVGA and RS-232 to Pen Plotters
| Author | Message | ||||
Hawk Senior Member  Joined: 15/07/2021 Location: AustraliaPosts: 141 |
I have just received my PicoMiteVGA short kit, and am interested in using it to interface to my vintage pen plotters. What is the likelyhood that the PicoMiteVGA will be able to interface to a vintage serial RS323 plotter. Does the MMBasic interpreter include hardware or software handhsaking for the RS232 interfaces? I have purchased a TTL to RS232 interface module to use to inteface to the plotters, I just need to ensure that MMBasic will controll it correctly. Is anyone able to shed some light on this? Thanks, Mike Edited 2022-09-17 22:10 by Hawk |
||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 3812 |
Pretty sure the manual shows it will likely work. Try it :) Obviously, watch voltage levels - it's NOT 5v-tolerant. John |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3152 |
Good idea. As long as your ttl-to-RS232 module supports 3V3 TTL, then you should be good. What does the plotter send back to its controller? MMBasic serial has very good input buffering, so you can pretty much handle what the plotter sends to you at your leisure in MMBasic. Can you provide a link to the ttl-to-RS232 module? PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
The TTL voltage levels might be a problem. I might need additional level shifters. I think the modules I bought are based around the MAX3232 chip. The problem is not receiving from the plotters, but rather ensuring that you don't send to the plotter too quickly and create a buffer overrun. MMBasic needs to respect the handshaking of the plotter. The plotters can run as slow as 2400 baud or as fast as 9600 baud, depending on which one I try. The MMBasic manual doesn't mention handhsaking at all, and doesn't have additional lines for RTS/CTS, so I can only assume that if it has handshaking then it will be XON/XOFF. Mike |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4253 |
The picomite does not have (AFAIK) hardware handshaking that classic UART chips have (RTS/CTS/DTR/DSR) but this can be emulated in software. Big chance of success, but you will have to try and error a bit. Compared to computers of the 80's the picomite can support larger serial buffers. And it is fast. So any data send from the plotter to the picomite should not require handshaking. Depending the plotter, you however may send too many characters, causing buffer overrun. Tho have best control over the data send to the plotter, you should set your transmit buffer small, and check the handshaking lines in the basic program to avoid plotter buffer overruns. If you have documentation on the plotter, check if it shows the serial buffer sizes. Typically serial communication does not start handshaking until the buffer threshold is reached. In typical apllications this is 75% of the buffer, but conservative apllications use 50%. So if you set your transmit buffer size to 50% of the plotters receive buffer you should never get a buffer overrun. Just check the handshake line before you start filling the serial port with plotter data. That is my 50 cents.. EDIT: 51 cents... See appendix A of the user manual: the transmit buffer size is fixed at 256bytes, so you should never send more characters than the half of your receive buffer in the plotter. -or- send character for character watching the handshake line (that is easiest). With the speed of the picomite, that will not slow down the process.. Things to check is " sending HPGL files may require specific termination (leither linefoeed, carriage retunr, or both). Postscipt I have no knowledge of. Something along these lines (if you have a HPGL file on SD card) setpin GP2,din 'assume gP0 used for handshaking setpin GP1,GP0,COM1 'assume GP0=TX,GP1=RX of COM port Open "filename" for input as #1 open "COM1: 9600,n,8,1" as #2 '9600 baud was common in plotter time, sometimes 7 bits was used, mostly 8 terminate$=chr$(13) 'or whatever is needed do input #1, A$ 'read 1 HPGL strin for i=1 to len (a$) do:loop until pin(GP2)=true 'when OK send character for character print #2,mid(a$,i,1); next i print #2,terminate$ 'end of string send required termination loop until EOF(#1) 'when end of HPGL file close close #1 close #2 Edited 2022-09-18 00:39 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3152 |
Your input buffer size on the MMBasic side can be huge--basically all of data memory that your program doesn't use. To prove a point, I used an serial input buffer of several megabytes on the CMM2. On the output side, if the plotter puts out CTS, your output routine just needs to check a pin to which that has been routed (properly level shifted) and not send the next byte until CTS has the proper value. It's possible that the plotter might not assert CTS until it has seen RTS asserted. If that is the case, you can use a pin or perhaps even just tie what the plotter see as "request to send" from the MMBasic device to the proper level. Basically, the MMBasic device doesn't need to throttle input from the plotter (because of the large possible input buffer), but just needs to respect what the plotter needs. This is handled by the user program, not by the MMBasic firmware. If the plotter uses XON/XOFF, the MMBasic program needs to handle that. That has also been tested with very large buffers. Basically, as said above, before every byte is sent your program tests to see that it has CTS or is not in an XOFF state. ~ Edited 2022-09-18 01:21 by lizby PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6101 |
Easy to do. At those slow speeds it will be easy to use a handshake in basic. In my FTP server on the CMM2, I did a crude but effective handshake which was used at high serial speeds. It just hangs the system while it waits. ' stops everything while RTS is high ' This gives a slight improvement in file sending on the F4. SUB RTS DO LOOP UNTIL PIN(RTSpin) = 0 END SUB I have an old HP plotter gathering dust in the shed. Jim VK7JH MMedit  MMBasic Help |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4253 |
Looks very similar.... DO LOOP UNTIL PIN(RTSpin) = 0 And do:loop until pin(GP2)=true PicomiteVGA PETSCII ROBOTS |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6101 |
Very similar. Probably because it is simple and does the job. He might find that the plotter has a few bytes of buffer available and can send 3 or 4 bytes at once between checking handshake. It all depends on what else needs to happen while the data is being sent. A simple 'dump a file' can use the do:loop but any processing might be best with interrupts. @Hawk The MAX3232 is OK running on 3.3V Jim VK7JH MMedit  MMBasic Help |
||||
| Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
Thanks for the suggestions. I guess what I was really asking is "Is the serial handshaking built in to MMBasic?" and the answers provided suggest not. For #septandy, I've been driving one of my plotters with a Tandy CoCo 3 and it's version of BASIC handles the handshaking automatically. I guess that MMBasic is more generic and has the ability to drive a serial port but any handshaking needs to be implemented within the program. The CoCo serial port uses a very simple 3 line cable. I don't even check whether the plotter has returned anything. Sounds like it's worth a try, but I will need to level convert the CTS from the plotter, or pick one of my plotters that implements XON/XOFF. Thanks for your help. I'm looking forward to seeing how much fun the PicoMiteVGA is to use. Cheers, Mike |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
Correct. "NOT". No MMBASIC port has supported handshaking lines NATIVELY, but they are easy to add manually on any spare I/O pins as hinted at by others here. As also mentioned, you PROBABLY won't need handshaking, as the COM port buffers in MMBASIC are pretty good by themselves for all but the fastest of serial speeds. CMOS/TTL-to-RS232 converter modules here: (70c each) RS232 module I've used these with both 5v and 3v3 logic, and they work well. Confirmed as working fine with a PicoMite based on the Raspberry Pi Pico module. 4-channel bi-directional level correctors, if you don't have any, here: (28c each) Level shifters Smoke makes things work. When the smoke gets out, it stops! |
||||
| Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
It's taken me a while to get back to this, but my RS232 module finally arrived via the slow boat from China.  This weekend's task will be to wire it up and see if I can get it talking to my old printers and plotters. A couple of people mentioned that I wouldn't need flow control, as the COM port buffers of MMBASIC are pretty good, implying that it can process the data fast enough. Â The point that they're missing is that the devices that I am talking to can only process the data slowly. Â Their buffers are much smaller, and it takes time for the pen or the print head to move. Â The flow control is to stop MMBASIC from overrunning the buffer in the peripheral device. Â And the baud rates we're talking about are only 2400 up to 9600. For most protocols, XON/XOFF would be more than enough, as the devices are dealing with printable characters only, so embedding the XON/XOFF codes in the data stream wouldn't cause too much trouble. Â However, MMBASIC doesn't do this by default either, so I may as well try hardware control RTS/CTS, which most of my serial devices handle. Edited 2023-04-27 16:43 by Hawk |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9133 |
XON/XOFF is easy to implement in software. Just send one character at a time and check for receiving an XOFF, if so wait for an XON before sending the next character. You could do all of this in interrupt routines with flags between the send and receive interrupts so there should be no need for any PAUISEs in the interrupts |
||||
| Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
Here's the prototype layout for my RS232 interface. I've added a RTC module as well. Pin Allocations: DS3232 RTC SCL - GP27 (Pin 32 of Pico module) SDA - GP26 (Pin 31 of Pico Module) RS232 Module TXD - GP0 (Pin 1 of Pico module) RXD - GP1 (Pin 2 of Pico Module) CTS - GP2 (Pin 4 of Pico module) RTS - GP3 (Pin 5 of Pico module) And all the pins on the 40 pin header correspomd to the pins on the Pico module. That makes life nice and simple. Now all I have to do is wire it up.   |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4253 |
Nice picomite housing Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
It is really sweet, but I can't take credit for it. It was designed by Jason Bullock. FB BASIC Programming Language group post It printed almost perfectly first time. I had to file the PS/2 hole a little larger just to ensure that the plug outer housing fitted and the plug pushed all the way home. |
||||
 Print this page |
