 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 : PrinterMite 1A...
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9593 |
Hi folks. 
As an expansion on the code we talked about in the forums a while back, on printing to dot-matrix parallel-port printers, here is my latest PCB. TOP COPPER: 
BOTTOM COPPER: 
The board will cater for pretty much any standard dot-matrix parallel-port printer, but I also have plans to support parallel-port laser printers as well, in a limited fashion. Dot-matrix printers USUALLY print as soon as they receive a CR byte as the data is clocked into them, so control of these is USUALLY relatively straightforward. I say "Usually" here, as in my testing all dot-matrix printers have all printed the line, once you clock the CR byte into the printer at the end of the line, but not before. This is not to say that every dot-matrix printer will do it this way, but it seems like most of them do. Printing to a parallel-port laser printer is a bit different, and seems to be based on buffering the data in the printer memory, till a FF(form-feed) command is issued, so laser printers won't print anything till you send a FF command, or the "Page" memory is full(at which point, the printer will automatically print the page by itself). This has been my experience thus far anyway, and makes sense for a laser printer when you think about it, as it HAS to print the whole page in one go no matter what - C'est La Vie. You can get a parallel-port laser printer to print each line one at a time, but you have to issue a FF after each line, and this means the laser printer will only print one line per page, which is not very practical, and very wasteful on paper. With the new MicroMite 2 chip based on the 170 chip, we have plenty of memory in the chip to use to setup an array for buffering the printer data, and thus can buffer a full page of text for laser printers. Technically, you don't need to buffer the data in the MicroMite - the printer will do it for you, but buffering it in the MM in an array, means that you can change any of the data for the page(by changing the relevant array element or bytes), right up to the point when you ask the printer to print it out for you. Both the dot-matrix and laser printing make use of the printer control lines for flow-control, meaning that you can clock the data to the printer quickly and not lose characters. Laser-printing page-at-a-time is much slower, as once you have a page of data in the MM array, you then have to clock it all out to the printer, and this does take some time. Specs say that you can clock 1000 characters(bytes) per second to the printer as a minimum speed, and many printers will easily support faster rates then this, but if we assume the minimum speed, then: 80 character lines x 120 lines per page for A4 paper = 9600 bytes per page. 9600 divided by 1000 characters per second = 9.6 seconds per page. So, basically, roughly ten seconds to clock a full page of text to a laser printer. During that time, the serial buffer on MM will handle any incoming data so long as it is not too much at once, causing a buffer overflow. Laser printers are quite different beasts to the very standardized dot-matrix printers, so the laser-printer option is something that may or may not work depending on printer, as I have only managed to test one laser printer at this stage. Please note that this PCB and MM code will NEVER, EVER support ANY USB printer on the planet. This is simply because USB printers need systemic driver files, which we have no hope of being able to port to something like the 170 chip. Parallel-port laser printers can be made to co-operate in a limted fashion, although they are often much more expensive the a basic black-and-white USB laser printer - again - C'est La Vie...... Smoke makes things work. When the smoke gets out, it stops! |
||||
| viscomjim Guru  Joined: 08/01/2014 Location: United StatesPosts: 925 |
Nice one Grogster!!! You may need to start a uMite catalog of boards. P.S. started playing with a new sound module that you may like. Serial comms, busy line, built in 3w amp that is louder than you might imagine, line level stereo out, up to 32gb micro sd card and very small footprint (smaller than catalex). Just received 10 for a customer project, they are working very nicely. Google MP3-TF-16P. Got mine on Aliexpress for $4.60 ea. so better price than catalex unit. Working an a "universal" sound board with a bunch of triggers... |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9593 |
Hi Jim.
I'm just reading my way through the technical control manual for my laser printer. The PCB in this thread will support the very common 850 interface(Epson FX-850 printer control interface). This is really just for text support, but that is all I ever planned to support. Printing fancy graphics or photos will not be possible using this idea, but the concept of using a nice quiet and efficent laser printer for printing out logs from MM projects is attractive to me - and probably others. Is the module you are talking about this one? Price is great, and if it has a busy line, I won't have to hack the Catalex ones, so I think I will have to get some of these modules to tinker with now!  Smoke makes things work. When the smoke gets out, it stops! |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
I think the ones I purchased are a bit different than the one you reference. THIS is the one I am using. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9593 |
Cool, thanks. Smoke makes things work. When the smoke gets out, it stops! |
||||
| ajkw Senior Member  Joined: 29/06/2011 Location: AustraliaPosts: 290 |
At first I wondered why you needed a whole other board and MPU to do this but the whole idea slowly came around particularly after I found my laser printer has a Parallel port. After some more thinking I got to, can you print a program direct from a xMite via the PrinterMite?? Perhaps so.. I have the following little test program to take program memory and convert it to an ASC list that could be directed to Com1 and onto the PrinterMite. It would of course be a whole lot better if the firmware could do this with a modified List (All) command. Geoff??? (even if only a BSF-post for ASC numbers for each function or command). The other way could be for the Printer-Mite to do the reconstruction overhead and for the xMite to simply dump the program memory straight out Com1 which would be a far simpler Sub on the xMite leaving more space for your actual program. Thanks for the idea/board Grogster Cheers, Anthony. > plist Sub plist Dim loc = 1 Dim inp Dim out$ Do inp = Peek(progmem,loc) out$ = Chr$(inp) If inp = 255 Or inp = 163 Or inp = 0 Or inp = 253 Or inp = 234 Then out$ = "" If inp = 178 Then out$ = "Sub" If inp = 133 Then out$ = "Dim" If inp = 149 Then out$ = "Peek(" If inp = 171 Then out$ = "Print" If inp = 134 Then out$ = "Do" If inp = 160 Then out$ = "If" If inp = 173 Then out$ = "Then" If inp = 194 Then out$ = "=" If inp = 32 Then out$ = " " If inp = 182 Then out$ = "+" If inp = 166 Then out$ = "Do" If inp = 175 Then out$ = "Until" If inp = 147 Then out$ = "End" If inp = 1 Then out$ = Chr$(13)+Chr$(10) If inp = 132 Then out$ = "Chr$(" If inp = 196 Then out$ = "Or" Print out$; ' or output to Com1 loc = loc + 1 Do Until inp = 255 End > |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9593 |
PROVIDED there are no VT100 codes in the output of the LIST command, then you could open the serial port as console, and list to it. So long as each line of code has a CR on the end of it, the PrinterMite and printer should accept it, and with resepect to laser printers, once you then issue a FF(form-feed) command, the laser printer should grab a sheet of paper and print the buffer - which will contain the code listing. Frankly, opening the code with Notepad or similar and printing directly from Windoze or MAC would be the best way to do this kind of thing, but I don't see any immediate reason why that would not work, if it be your will. Smoke makes things work. When the smoke gets out, it stops! |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
You could use xmodem to transfer program code. Microblocks. Build with logic. |
||||
| ajkw Senior Member Joined: 29/06/2011 Location: AustraliaPosts: 290 |
TZ. Xmodem to the PC is fine, I don't know about xmodem to the Printer-Mite as being viable. Grog. Yes the cut and past into a text editor on the computer works fine as a way to print. I don't know about VT100 codes in the output of List or not. The contents of program memory do not. I think you can only open a Com port as Console on a Maximite, I don't see a way in the manual for the Micromite to redirect the Console. The PrinterMite capability is yours to decide. I happen like the idea that a xMite could print or list its program direct, even though it is with help from one of its own kind, rather than using a PC. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9593 |
UPDATE: The boards have arrived, and I have got the first one running 
There is a small censor block for the uppermost SMD LED - I meant to rename that "D'OH!" for as an error signal, but I kinda forgot to change the silkscreen before I sent the board off for production - whoops.... 
The current code only supports dot-matrix printers, but works fine, and I am working on the laser side of things - that requires buffering a page in the MM, and then clocking it out to the printer. A supported laser printer with a parallel port is needed to use this side of things. Here is a shot of it hooked to a VideoMite: 
In this case, I have the VideoMite's COM1 connected to the PrinterMite's serial input, and you just send it strings and they are printed for you. The PrinterMite stores message strings in the serial buffer, and can receive more messages while it is printing out the previous one, so long as the RXD buffer does not overflow. Thanks to the 170 MicroMite chip's extra memory, the standard serial buffer is 4096 bytes long, which is enough for up to 51 standard 80-character printer lines before the buffer overflows, and the module is always working to empty the buffer. 10K of RAM is also reserved in an array for the lines on a laser-printer page, but even with this memory gobbled up, there is still 30K or so of free memory. Any string sent to the module is sucked out of the RXD buffer and passed to the printer, which allows you to send printer-specific control codes for special print modes etc. 
Now I just have to get the laser side working, which is more tricky then you think, especially as I don't have a laser printer with a parallel port, so I will have to see if I can find one - I have a feeling my old Brother at the workshop has a parallel port on it.... EDIT: Added 3rd GIF. Smoke makes things work. When the smoke gets out, it stops! |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Very Freakin Cool!!!! Nice work there Grogster! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9593 |
Thanks, Jim.
The Laser part will be - interesting.(to get working) I forgot this evidence photo: 
The multipule message test was just the VideoMite sending the same message five times in a for-next, and it was then up to the PrinterMite to decipher the messages and print them out, so this seems to be working at first glance. The tinkering continues...... Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2933 |
Nice one Grogs. 
I was going to use one of these but I have another application that would need something bigger so your PrinterMite is perfect (hopefully). Once I have my major project out of the way I will contact you - maybe you'll have the laser working by then
WW |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
