CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Parallel Printer interfacing !!
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
th3gr8



Joined: 16 Jul 2013
Posts: 12
Location: Pakistan

View user's profile Send private message

Parallel Printer interfacing !!
PostPosted: Wed Jan 07, 2015 8:10 am     Reply with quote

Hello All ..
I want to interface a parallel printer with my PIC16F877A (serial printers are not available) .. I googled and found out that i need to connect D0-D7 with any output port of the PIC and need to connect strobe and busy Pin .. Now i am confused about making its code and circuit. I want to know that by directly connecting these pins with my printer, will i be able to print something or do i need any circuit in between them?
and If someone has an example Code and circuit, plz share it ..
Also, can i make it with USB-to-serial interface for a printer having USB port??
_________________
A learner
Ttelmah



Joined: 11 Mar 2010
Posts: 19537

View user's profile Send private message

PostPosted: Wed Jan 07, 2015 8:27 am     Reply with quote

Sequence is:

Read the BUSY pin. Wait till it goes off.
Write ASCII character to D0 to D7 (just output it).
Turn the STB line on, then off.
Loop back to start, till all characters are sent.

It depends massively on your printer. The basic transmission is the same for all, but simple (old) printers are relatively 'smart', and you only need to send standard text and control characters (line feed, carriage return etc..). A lot of the later 'cheap' printers are completely dumb, and rely on being sent 'raw' binary data, to control the bit patterns on the heads. They relied completely on all the 'work' of generating characters being done in the PC. Too much data for any but the largest PIC's, and completely 'custom' to the particular make of printer.

An interface to a USB printer, would be complex. Most cheap ones do rely on the computer to do all the work, and you would need to implement a USB host. Simplest way (if the printer is not too dumb), is to use an FTDI Vinculum to provide the host. Again if the printer needs anything beyond basic text, serial would have speed issues.
temtronic



Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Jan 07, 2015 7:33 pm     Reply with quote

What Mr. T says is right....very simple code and will hookup to printer directly. I did the same using a 16F84 some years ago.....to allow a serial port from a client's computer to use a parallel port printer.
If your computer sends data slower than the printer prints , you do not need to 'buffer' the data.

hth
jay
th3gr8



Joined: 16 Jul 2013
Posts: 12
Location: Pakistan

View user's profile Send private message

PostPosted: Wed Jan 07, 2015 9:43 pm     Reply with quote

and if i use a Thermal Printer (with Parallel Port), will the sequence of writing the data be same?
_________________
A learner
gpsmikey



Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA

View user's profile Send private message

PostPosted: Wed Jan 07, 2015 10:58 pm     Reply with quote

If it is a parallel port, the interface should be the same. The printer may need extra processing for graphics or whatever, but the interface you are talking about from a hardware viewpoint is called the "centronics interface" - see here for additional information and links for the interface and timing.
http://en.wikipedia.org/wiki/IEEE_1284

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3
th3gr8



Joined: 16 Jul 2013
Posts: 12
Location: Pakistan

View user's profile Send private message

PostPosted: Thu Jan 08, 2015 1:33 am     Reply with quote

Ok .. but i read somewhere that Centronics interface was used on Old printers etc .. And if i connected the printer with PIC, how much XTAL value would i need? can i work with 4Mhz?? is crystal value very much critical?
_________________
A learner
Ttelmah



Joined: 11 Mar 2010
Posts: 19537

View user's profile Send private message

PostPosted: Thu Jan 08, 2015 2:04 am     Reply with quote

The parallel printer interface is the Centronics interface. something like 99% of modern PC printers use USB instead. Hence the comment about 'old printers'. There are quite a lot of 'specialist' printers that still use the Centronics interface, just not in the mainstream PC world.

It depends how fast you want to send the data, and how much data you have to send, together with how fast the printer you are talking to is?. Many of the little thermal units can only accept a few hundred characters per second, and this a chip at 4MHz should be able to handle easily. However if you talk to something like a laser printer, and then start sending graphics, rates more like half a million characters per second can be involved to feed the machine properly.
th3gr8



Joined: 16 Jul 2013
Posts: 12
Location: Pakistan

View user's profile Send private message

PostPosted: Thu Jan 08, 2015 3:43 am     Reply with quote

Ok.. That helps ..
so now, i want use 10 i/o pins of my PIC and follow the sequence.. do i need to put a resistor on the Data lines (D0-D7) or should i connect it directly?
Sorry for asking such silly questions :( ..
_________________
A learner
Ttelmah



Joined: 11 Mar 2010
Posts: 19537

View user's profile Send private message

PostPosted: Thu Jan 08, 2015 5:17 am     Reply with quote

For short connections you don't need anything on the data lines. What you do need is a resistor to pull the 'busy' line to the 'busy' state, if the connection is not present. This way the code won't try to send to the printer if it is not there.
On longer cables you'll commonly find termination to help prevent signal 'ringing' at high data rates.
th3gr8



Joined: 16 Jul 2013
Posts: 12
Location: Pakistan

View user's profile Send private message

PostPosted: Thu Jan 08, 2015 7:23 am     Reply with quote

Ttelmah wrote:
For short connections you don't need anything on the data lines. What you do need is a resistor to pull the 'busy' line to the 'busy' state, if the connection is not present. This way the code won't try to send to the printer if it is not there.
On longer cables you'll commonly find termination to help prevent signal 'ringing' at high data rates.


Ok, so a resistor on the Busy Pin ..
Let me try to implement the hardware Smile ..
_________________
A learner
temtronic



Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Jan 08, 2015 9:18 am     Reply with quote

Here's something that worked a few years ago, just needs minor changes to run on 16F877
Jay


Code:

//   serialpt.c
//
//   serial to parallel printer chip
//   allows EVE to use parallel printers

#device PIC16F84
#include "16F84.H"

#fuses XT,NOWDT,NOPROTECT,PUT         // options
#use delay(clock=4000000)         // xtal
#use rs232(baud=2400,xmit=PIN_A4,rcv=PIN_A3)   // rs232 setup
#zero_ram               // fresh start

#use fast_io(a)               // direct access
#use fast_io(b)               // of ports

#byte   PORTA = 5
#byte   PORTB = 6

#define   low   0;
#define   high   1;
#define   off   0;
#define   on   1;


#define PC_Flow      PIN_A0         //
#define LPT_Busy   PIN_A1         //
#define LPT_!Strobe   PIN_A2         //
#define PC_Serial   PIN_A3         //
#define Not_Used   PIN_A4         //

#define LPT_D0      PIN_B0         //
#define LPT_D1      PIN_B1         //
#define LPT_D2      PIN_B2         //
#define LPT_D3      PIN_B3         //
#define   LPT_D4      PIN_B4         //
#define   LPT_D5      PIN_B5         //
#define   LPT_D6      PIN_B6         //
#define   LPT_D7      PIN_B7         //



void   Init_PIC()
   {
   set_tris_a(0b00010);         // as required
   set_tris_b(0b00000000);         // all outputs
   port_b_pullups(FALSE);         //
   PORTA = 0b00100;         // strobe set hi !
   PORTB = 0b00000000;         // all low(off)
   delay_us(10);            // dly a bit...
   }



//   ****************************************************
main() {
   int   c;            // c is an integer(8 bits)

   Init_PIC();            // initialize PIC


   while(true) {               // endless loop
      c=GETC();            //wait for a character to come in
      PORTB=c;            // send to PORTB ( lpt)
      delay_us(2);            // dly to steady lpt data lines
      OUTPUT_LOW(PIN_A2);         // high-low-high !!
      delay_us(2);            // actual -strobe pulse
      output_high(PIN_A2);         // reset to high( idle state)
   }                  // endless loop

}                     // end of main


It should give you a good start for your project....PM any questions....
Jay
Ttelmah



Joined: 11 Mar 2010
Posts: 19537

View user's profile Send private message

PostPosted: Thu Jan 08, 2015 9:47 am     Reply with quote

If you look at the code, he was using 2400bps, and this was so slow, that Temtronic doesn't even bother about 'busy', being able to assume the printer can always take the next character. Need to think about this if data is arriving faster....
temtronic



Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Jan 08, 2015 10:12 am     Reply with quote

yup, 2400 baud was what the client's 68K machine's serial port was configured for. I looked at the file...yeesh 10 YEARS ago, time flies.Actual computer($100K when new) was scrapped last year...sigh...
Since most(all) printers have a large 'buffer', handshaking wasn't needed back then.Data from the EVE was less than 500 bytes.
The code as written should be a good start, easy to test(it did work for almost 10 years), easy to modify as required.

Ideally use the 877's hardware UART, CCS's ISR for buffering and a 20MHz xtal.....ideas...

Jay
gpsmikey



Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA

View user's profile Send private message

PostPosted: Thu Jan 08, 2015 11:31 am     Reply with quote

The actual crystal value is not very critical for the centronics (parallel) interface because it uses the strobe/busy handshake to move data so the crystal frequency is not very critical there (other than lower crystal frequencies mean the processor runs slower). Where the crystal frequency is critical is if you are using the serial port (uart). There, the baud rate is important and it is derived from the crystal so you need to address that issue if you are using the serial port.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3
th3gr8



Joined: 16 Jul 2013
Posts: 12
Location: Pakistan

View user's profile Send private message

PostPosted: Fri Jan 09, 2015 6:17 am     Reply with quote

gpsmikey wrote:
The actual crystal value is not very critical for the centronics (parallel) interface because it uses the strobe/busy handshake to move data so the crystal frequency is not very critical there (other than lower crystal frequencies mean the processor runs slower). Where the crystal frequency is critical is if you are using the serial port (uart). There, the baud rate is important and it is derived from the crystal so you need to address that issue if you are using the serial port.

mikey


Luckily i've got a Serial thermal printer now .. Please tell me the crystal value's issue .. and also tell me that what Pins i need other than TX and RX .. I think that RTS and CTS pins will also play an important role or can i simply ignore them and use only TX and RX??
Plz guide me
_________________
A learner
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group