Parallel port terminal software

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been trying to think of a good way to communicate directly from PC to AVR (or other uCs) with a little hardware in between.
I just got done bit bashing serial, only to realize my PC doesn't recognize 0 to 5 volts logic, so I would need to buy a converter chip. Well, I'm a minimalist cheapskate and don't want to spend five bucks in shipping.
So, looking at the back of my PC, I realize that the parallel port would work wonderfully. I've already used AVRdude to program my attiny13s via LPT for years, so why not use it for a simple terminal interface?

Now, there are lots of different serial interfaces to consider. Basic rs-232, 2 wire, 3 wire, I2C, etc.

My question is this: Is there a program out there that can do this? (Can avrdude do it?) Would someone out there be willing to cobble something together for the community?

Obviously, for complex high bandwidth needs, this idea would not be so great, but for basic debugging and control it would be perfect.

"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
-- Douglas Adams

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any bus that has a clock should be fine, because under modern operating systems, timing is not guaranteed because of kernel context switces and interrupts etc.

So logic level RS232 is out of the question, unless very low speeds like around 1000bps are OK.

Another problem is the hardware interface.

First of all, there are different types or modes of parallel ports, and even today the mode can be set via BIOS. Wrong mode might cause burnt pins etc, as different modes may have different kind of features on IO pins.

An example is that in basic/compatibility mode the data pins can only be outputs. In bi-dir/PS2 mode the data pins can also be inputs, but whole 8 bit bus goes into one direction at a time, so the other pins are used as handshakes then. ECP and EPP ports may be used in bidir mode, but then again, the chipset may not allow this, or it may allow it only in ECP or EPP mode.

Then there are some shortcuts regading the data pins. While they originally were 5V outputs, I have seen 3.3V outputs too, so interfacing to 5V logic is more complicated and may require some buffering even.

The four control pins are originally open collector outputs with weak pull-ups. In some chipsets or modes, they may be push-pull outputs. I have not verified this myself, but I believe it may be a requirement in EPP/ECP modes when transferring data which can transfer data very fast, but I think normally when EPP/ECP features are not used, they may be open-collector compatible and may be used as outputs and inputs too. They should be great for I2C software master, two independent channels even, or three multiplexed channels if clock is shared.

Status pins are just 5V logic inputs with maybe pull-ups or downs, they have no quirks I am aware of. Except that one of the pins can generate an interrupt.

So in DOS and known parallel port you can do almost anything and as accurately as you want. In windows, well, I have controlled a HD44780 for example.

Given this, a SPI software host bus would also be doable.

And avrdude certainly contains source code for using the parallel port the way you wish. May be worth a read.

Also forget USB parallel ports and Vista operating system. In XP external DLLs are required and in win98 almost nothing is needed.

Building a general purpose terminal is also very subjective - look at all those serial port terminal software there is. Even if I wrote a program that can transmit I2C or SPI bytes or messages, it does not have any intelligence. For example, writing I2C is no problem, as message size in bytes is known from how many bytes the user enters. Reading I2C, more complex. You want to write the register address that needs to be read (but that is general writing procedure so no problem) but getting the result requires entering how many bytes you want back.

And SPI? Also chip select control is needed too. Active high or low? SPI mode, CPOL/CHPA? From then on, it is just how many bytes to transfer and read back in single message when CS kept active.

3-wire? Could need extra hardware, or using an open collector pin for data in/out or using SPI alike mode where data in and out are connected with resistor so that the slave can overdrive the master.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the detailed response! I've had many of the same thoughts myself about timing and such, also with handshaking in a master/slave system. I figured a few values would need to be specified beforehand, such as how frequently slave poling takes place and the number of bytes to read each time.

Frankly, my current aim is for one way, uC to PC, communication, but it seems a bit senseless to put together an entire application for unidirectional traffic.

"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
-- Douglas Adams

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TI calculators in the past have used a very simple scheme for data transferring. They have two bidirectional lines (much like I2C), so both can transmit, receive and acknowledge data as slow as they like. It is like Wiegand protocol, but with acknowledgement.

Two wires, named A and B for example:

sending a 0 bit on bus:

transmitter pulls A low
receiver sees A is low (stores 0 somewhere)
receiver pulls B low as acknowledge when data stored
transmitter sees B low and releases A high
receiver sees A is released and releases B high

Swap A and B when transmitting a 1 bit.

Any of the devices can be the transmitter if they wait that bus is clear when it wants to transmit.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just had another idea that would come in handy here.
For any protocol that can have multipul masters and slaves, data can simply be sent in master write/ slave read modes, where both devices will write data as a master and only read data as a slave.. This would eliminate the need for polling, but require arbitration.

I suppose a few more wires would ne necessary to read the data lines while writing to them.

Btw, is this what hack-a-day's Bus Pirate does?

"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
-- Douglas Adams