Serial to Parallel converter

Not when your source data is coming via RS232...

Reply to
John Rumm
Loading thread data ...

Is that the only source of the data though?

Reply to
Mark

So don't run QBASIC (or any other MS-DOS program). The free trial version of 'BBC BASIC for Windows' is easily powerful enough to do this with no danger of data loss, and without faffing around with Interrupt Service Routines and the like:

formatting link
formatting link

Reply to
Richard Russell

Windows NT (i.e. all modern versions of Windows) won't let you access the hardware ports directly from user code. You would either have to use the Windows device drivers (which for serial and parallel ports should be fine) or use a kernel-mode port driver such as INPOUT32 if you're doing non-standard bit-banging. Using the standard drivers has the advantage of supporting USB serial and parallel adaptors as well as 'real' hardware ports.

Both approaches should be viable from any respectable Windows programming language. In some the support for INP and OUT is built in for no extra effort; one of those is LBB:

formatting link
others, such as BBC BASIC, you have to do it at a slightly lower level:

formatting link

Reply to
Richard Russell

I am assuming this is coming out the back of Andrew's logic analyser, which if true, then yes.

Reply to
John Rumm

-Windows NT (i.e. all modern versions of Windows) won't let you access

-the hardware ports directly from user code. You would either have to

-use the Windows device drivers (which for serial and parallel ports

-should be fine) or use a kernel-mode port driver such as INPOUT32 if

-you're doing non-standard bit-banging. Using the standard drivers has

-the advantage of supporting USB serial and parallel adaptors as well

-as 'real' hardware ports.

-Both approaches should be viable from any respectable Windows

-programming language. In some the support for INP and OUT is built in

-for no extra effort; one of those is LBB:

-Richard.

I'm running a QBasic LPT port register monitor I wrote. QB runs fairly well in NTVDM (Virtual DOS Machine) under XP, from a small FAT32 partition. I can toggle the state of Control bits C1-4 and the 8 Data lines, but every few seconds XP blips and resets the control bits, even if I'm typing here and the DOS window doesn't have focus. Strobing C0 gets XPs attention and several control and status bits change. I need those control lines unencumbered to mux target device address and data registers. jsw

Reply to
Jim Wilkins

it probably is - that or HPIB

Reply to
The Natural Philosopher

Not surprising if the port is under the control of Windows. To gain exclusive access to a parallel port I would expect either to need to open it in Windows, or to uninstall it so that Windows ignores it altogether.

Generally I would much prefer to use a hardware interface designed for the purpose, such as a USB I/O card (e.g. as available from Velleman and others). Then you know you have full control and Windows won't interfere.

Richard.

formatting link

Reply to
Richard Russell

-Generally I would much prefer to use a hardware interface designed for

-the purpose, such as a USB I/O card (e.g. as available from Velleman

-and others). Then you know you have full control and Windows won't

-interfere.

-Richard.

formatting link
have a serial-port four channel data acquisition device and a serial-port optoisolated DVM, my only instrument that can report

240VAC voltage or current. Their datalogging programs will run concurrently under Windows but they aren't synchronized. QBasic allows me to operate both together, detect start/stop/error conditions and send appropriate control signals out the LPT port.

Some day I will rework a wirewrapped 16 bit A/D board I originally built for the Mac NuBus, and got back when the project ended, into a high-quality parallel port voltage, current and thermocouple datalogger. The Compaq Armada laptop that will run it uses only 7W from an external 12V battery with the LCD turned off. It will be like having OpenOffice Calc on an Arduino.

jsw

Reply to
Jim Wilkins

Fair enough, but having to use an obsolete OS and being unable to run your program on a 64-bit platform (without a virtual DOS box) are high prices to pay IMHO. I recommend re-writing the program in a Windows BASIC (of course I'm prejudiced and would suggest BBC BASIC - there's even an automated QBASIC to BBC BASIC translator that will do most of the work). That would give you all the benefits you mention but with a modern OS and GUI.

Richard.

formatting link

Reply to
Richard Russell

Fair enough, but having to use an obsolete OS and being unable to run your program on a 64-bit platform (without a virtual DOS box) are high prices to pay IMHO. I recommend re-writing the program in a Windows BASIC (of course I'm prejudiced and would suggest BBC BASIC - there's even an automated QBASIC to BBC BASIC translator that will do most of the work). That would give you all the benefits you mention but with a modern OS and GUI.

Richard.

formatting link
the site has your name on top:
formatting link
I'm also playing with Arduino C to build a weatherproof stand-alone datalogger.

The semiconductor design team I worked in started me with Visual Basic and only switched to QB so we could run our application boards on any customer's unmodified lab PC, off its printer port. In the late 90's hand-me-down office PCs weren't guaranteed to have USB ports but they still all had LPT1, plus the engineers liked using it for its simplicity. For instance it was trivial to make a full-featured I2C interface with it, one pair of control and status bits for Clock and another for Data, and the target's address asserted on the data bus.

I got good enough at QB graphics to draw the IC's layout on screen with the control bits we sent to it running around through shift registers to their intended locations. It looked like a video game battle of colored centipedes, and visually matched with test point locations seen through the microscope on a wafer prober.

The ICs were hot-swap controllers, Power-Over-Ethernet hubs, etc. sold by Texas Instruments.

jsw

Reply to
Jim Wilkins

John Rumm as usual is right - RS232 is the only source of the data !

AWEM

Reply to
Andrew Mawson

In message , Andrew Mawson writes

I did have one years ago to transfer data from a BBC to a PC. I'll have a look in my box of bits later on, see if I've still got it. Got to take dogs out now.

Reply to
hugh

Did you verify that capturing the RS232 data and spitting it out via a parallel port to a printer does work? (ISTR an earlier thread about this, but unfortunately I went and nuked all the messages)

Reply to
Jules Richardson

In message , hugh writes

Yes!! Result!! I thought I might have thrown it out, but no here it is.

Dip switch settings are listed on the body. Two way device. I used it parallel to serial but it will work either way. Flow control ENQ/ACK, XON/XOFF, RTS/CTS or none All parity options 8 bit or 7 bit Up to 115200bps OP, you are welcome to it, contact via my reply to address if you want it.

Reply to
hugh

You have mail!

AWEM

Reply to
Andrew Mawson

Not read all the thread, but I bring in data from our Mills and Lathes via RS232 using a computer with the Heidenhain free programme, TNCreoNT. Seems easy to me, download data, save file, open with WordPad, print !! Maybe I should read the whole thread !!! Bob

Reply to
Emimec

Thanks Bob but the file is hex encoded PCL1 data so cannot just be printed unless it goes to a printer that understands PCL1

AWEM

Reply to
Andrew Mawson

HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.