Help Writing rs232 driver ( where to start ?)

qwijibow · 09-12-2006, 05:02 PM

Hello Guys,

I'm a fairly competant software developer looking to get into linux kernel code.

For my first project, to get me started ive devided to write a driver for a Alpha Numeric Display.

Mainly because i have access to them at work, and their data sheets, and the driver source code for our in-house Operating System ( runs on a 68000 cpu )

But really, i just dont know where to start.

The Driver uses rs232 serial port, using only 2 of the pins ( Clock and Data Out )

The In House Driver works at super low level ( mainly because its a very very simple tiny embedded system ) setting the pins on the serial port High / Low with inline assembly.

but in a much more advanced OS, Linux.. How / Where should i write this driver?

All the driver does is send Ascii codes down the data pin, along with a few control codes for cursor position / brightness / flashing / reset.

should my driver be written at a really low level, using the API's in serial.c

Or would the driver be better off further away from the hardware, using ttyy's

Or maybe, even in Userland, Accessing the hardwire through an existing serial character device ? ( similar to how old serial modems worked )

Anyone have any Advice / Links / Recomended Reading Material ???

Thanks.

theNbomr · 09-13-2006, 11:38 AM

Is this one of those industry standard LCD panels, something like 16 or 20 characters by 2 or 4 lines? Thses typically do not interface at RS-232 (+/- 12V) signalling levels, but use TTL level inputs. I am inferring this from your use of the terms 'Clock' and 'Data' pins. It sounds like your existing drivers access the devices using a technique often described as 'bit-banging'. If such is the case, you might be better off interfacing a PC to one of them using a standard parallel port. These are much better suited to bit-banging, as each pin is basically accessible as a bit in a register. You can probably do all you need from a userland application.

A good place to get started is to look at the man pages for 'outb' and 'ioperm'. Also, find a decent reference to standard PC hardware architecture. There are quite a few good ones online.

I can probably be more helpful if you give a more detailed description of your hardware.

--- rod.

michaelk · 09-13-2006, 11:51 AM

I guess it depends on what you want to do with the display.
I am assuming the display is standard RS-232 so you will connect up pins data out and ground. In userland you can output data to the device as simple as
echo Hello > /dev/ttys0

Assuming you have configured ttys0 for the baudrate etc of the display.

qwijibow · 09-13-2006, 01:25 PM

The Display is an indusry standard Alpha Numeric Display, 16 characters wide, only 1 line.
(The type used in reel based slot machines)

Uses a dot matrix of tiny surface mount LED's i believe, im not 100% sure, but definatly not LCD.
somthing like 10x8 resolution per character ( guessing ).

II think you are correct in saying the 68k driver bit-bangs.

from memory: the 68k code

Code:

UINT8 Data = ByteToSend
for(UINT8 I=0; I<8; I++)
{
    < some rtc timing code >

    < set CLK HIGH >

   if((Data >> I) & 0x1)
      < set serial data ( data to modem ) HIGH >
    else
      < set serial data ( data to modem ) LOW >

    < set CLK LOW >
}

The Data sheet specifies that the device is meant for RS232
but only uses 4 pins..

VCC (+12volt)
GND
CLK
DATA

Ive read a little about bit banging, and although it is easy on the parallel port,

the serial ports hardware buffer would make the driver vastly more efficiant

( As Wrtting to the Display is usually done by re-writing the whole screen, 1 control byte and 16 character bytes. )

Things like scrolling text is not supportde by the hardware, so each time the sentence scrolls across one character, 17 bytes must be written.

I believe this would generate a great number of Hardware Interupts ???

The more i read bout serial port programming, the more it looks like this could be most easily implemented in userspace via /dev/ttySX

But like i mentioned before, i dont NEED to get this working in linux, its just the most available piece of hardware i can find for a first kernel project. So i will attempt to get it working in kernel code, just for the learning experiance.

( writing char devices that *pretend* to write to hardware is very boreing ! )

Thanks for the replys.

theNbomr · 09-13-2006, 02:24 PM

Quote:

The Data sheet specifies that the device is meant for RS232
but only uses 4 pins..

VCC (+12volt)
GND
CLK
DATA

This is somewhat a contradiction in terms. RS-232 does not use clocked data. It is an asynchronous (ie. no clock sync) protocol. If you need the ability to bit-bang the data, you will have to use bits in the Line Control Register and/or Modem Control Register. See the datasheet for the 8250 family of UARTs. The use of the signals on the serial port would be completely under your program's control, rather than the timing, framing, etc, that the UART would perform automatically.

Electrically, there would seem to be a problem, since you are supplying the device with +12VDC, but the RS-232 outputs will swing down to -12VDC (or at least below -3 V). That sounds like a recipe for releasing the magic smoke... You will not be able to source enough current to run your display directly from the serial port of a PC. I think there may be enough power available from a game port, if computers still have those, these days.

If you need to write data at a specific speed, in order to achieve smooth scrolling, you can probably use something like 'usleep'. I don't know what the rules are for doing that sort of thing in kernel space though. Sounds like an interesting challenge.

--- rod.

qwijibow · 09-13-2006, 03:30 PM

So i cant get a reliable 12+Volts from the Serial Port ?

I've googled the Game Port, it seems that game ports VCC is hard wired to the PSU +5Volt Rail... Not enough Juice.

Parallell Port cannot supply 12 volt VCC.

USB VCC is only 5 Volts ( i was very surprised to hear this ! i have a USB powered Scanner, the bulbs in those things are very bright ! )

It Seems i am completely out Simple OPtions...

Time For a Hack....

Can I Connect the VCC/GND wires directly to my PSU's +12V/GND Cables ( VIA IDE Disk Power Connector)

And the Remaining CLK / DATA pins to a Serial Port, Would This circuit work ?

If im not too busy tomorow, i'll post the datasheet.

theNbomr · 09-13-2006, 04:25 PM

No, the serial port contains only signalling information. You certainly can extract 12V from the power supply. As I understand it, modern power supplies have most of their current capacity in the 12V section, as opposed to the olde style which leaned more toward the 5V rail. You should still make sure that the -12V swing of the RS-232 voltage levls is not going to be harmful to the inputs of your device.

--- rod.

knobby67 · 09-17-2006, 10:14 AM

qwijibow I've used these displays a lot myself I'm an embedded programmer who has just moved to linux. You really can't connect these types of displays economically. The best thing to do is buy an interface board which converts the rs 232 signals to the correct out put via PIC/AVR chip.
I've done it both ways (hand built) and per bought pack. Eventually I just built my own PIC circuit, this also gave me a load of IO as well.

randyding · 09-17-2006, 01:08 PM

The display you are describing sounds like a VFD, and not LED based.
Your best bet is to do what was previously suggested, that is to use the parallel port to drive your clock/data directly. Use an external 5V power supply to drive the display and tie together the PC's parallel port ground with your ground.
If you really want to use the serial port, why don't your buy the VFD with a true RS232 serial interface. They cost the same... I've used both kinds here.

sundialsvcs · 09-17-2006, 08:05 PM

As far as the programming is concerned, definitely your best bet is to look through the Linux source-code to find any driver that is similar to what you are wanting to do. There are, of course, plenty of HOWTOs both here and at other web-sites, but nothing will prove to be more beneficial (imho) in the long run than actual inspection of source-code that is close to what you want to do.

The details of any given driver are quite particular. The methods used are not. Every "block" driver works in more or less the same way. Likewise every "character" driver.