Suppose I have an x86-based PC running Windows 7; I have a couple of simple tasks:
o Write a single bit to a pin somewhere (perhaps connected to an LED) o Read a single bit from a pin (perhaps connected to a push-button)
At what point over the last 20-30 years did something so simple become next to impossible?! I used to do this all the time over ten years working with hardware. IIRC it only took a single instruction to do so as well.
(I understand that this is straightforward enough using a microcontroller, however all my development tools are on the PC!)
From what I've been able to discover, 'solutions' involve adding a parallel port via USB (or possibly even PCIe, which I have inside the desktop). But then what? It either seems to involve directly programming USB (which looks horrendous), or accessing the port as a file LPT1 or whatever, but that doesn't look like it will work well when there is lots of mixed, disjointed input and output. It just doesn't sound right either. (And anyway when I once tried the latter to drive an actual printer, it didn't work!)
I've even thought of communicating with the outside world via the speaker (modulating my data into a WAV file which is then played), or with a photodiode taped to a corner of my display which I then modulate with black and white flashes! But then it starts to get ridiculous (and those last two methods will be slow, only work for output, and require building circuitry that I no longer have the knack for).
Is there in fact a simple, painless solution to this problem? It would presumably take the form of:
o Some gadget or circuit to attach my PC o Preferably with 8 bits of input and output o Can be accessed directly with some software or other. Not necessarily with direct port I/O, but function calls via a provided DLL perhaps (eg. readbits(), writebits()). o Is fast enough to do write at least a few thousand bytes per second
(I remember a few years ago having a kit or board that did some of this: reading or writing a few bits (not 8 perhaps 4 or 5), connecting to USB, accessed via a DLL, but it was too slow to be practical (perhaps only a handful of updates per second) and I lost interest.)
Look at and pick a suitable USB module. You can use them for UARTs, SPI buses, or simple I/O pins. FTDI provides drivers, DLL's, and samples for many uses - you can also find plenty of libusb based code on the net. It all works on Windows or Linux.
You'll be hard pushed to get thousands of bytes per second with bit-banging, but it should be no problem with SPI or UART.
Get a Raspeberry Pi and either a) use that directly or b) connect to it from your Windows PC via the TCP/IP service of your choice. The Raspberry has enough GPIOs, there are enough drivers and it is quite easy to set up a server on it. Getting kBytes/s is said to be feasible although I haven't tested this myself.
You start by listing a simple task, but then move onto a far more complicated task, so I will address the tasks separately.
This one should be solvable by using the control lines on a traditional serial port (and maybe a USB serial port as well).
There are several circuit designs in common use for programming AVR microcontrollers via a traditional serial port by using the control lines in a rather creative way. You could look at these circuits for ideas about how to do this safely.
For example, Olimex have such a circuit listed on their website at:
formatting link
which might give you some ideas.
If you use a traditional parallel port (instead of a USB one), this may be possible.
I currently use a Wiggler based JTAG clone (from Olimex) which connects to a development PC via the parallel port and works just fine under Linux. There are multiple circuits available online which implement such a Wiggler cable and you can look at them to get ideas about how to connect to the parallel port.
With the cable design, you get several bits from the parallel port to the device and one bit (via the Busy line) back to the PC. However, all the traditional parallel ports these days are supposed to be bi-directional so you should be able to improve on that.
As for the software side of things, have a look at the source code for OpenOCD to see how it accesses a traditional parallel port. I've only used OpenOCD on Linux, but I believe the parallel port interface is also supported by OpenOCD on Windows.
However, having said all that, I agree with David; if your latter requirement is your real requirement, you may want to look at the FTDI based devices he suggests.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
As the home computer was refined as a consumer product, the cost went down, the speed and capacity went up, but at the cost of complexity and brittleness. Peripheral-Componenent-Interconnect being my favorite Faustian bargain there.
Another interface gizmo that hasn't been mentioned yet is the Bus Pirate:
I did get a Pi last year with a view to porting my tools across to it and working from that (I like to use my own languages and tools so that's a stumbling block). That partly worked, until it came to the terminal and keyboard capabilities I needed for my editor, but Linux terminal/keyboard handling was too crude.
It's possible to get code into it in various ways, but not 'fluently' enough to make development brisk. (Also I don't like Linux and this thing only works with my TV!)
I decided to keep my development stuff on the PC. I also would quite like to have a go at building a microprocessor circuit of my own, where it would be nice if I could write/compile any code on the PC, and somehow download it onto this board. (This would likely use a dual-ported static ram, no flash memory or anything, so a handful of I/O pins to allow a few hundred bytes to be downloaded in under a second or so is all that's needed. I don't really want to toggle in machine code by hand; not in 2013...)
Linux terminal/keyboard handling was "too crude" ? I haven't heard that one before. Hands up those that can type "Antonín Dvo?ák" on a Windows keyboard without using "character map". I can't see many reasons why you want want something more than ASCII for programming, but there you go.
Of course, the common way to do development work with the Pi is with Linux on your desktop, connected to the Pi over the network. Just because you /can/ run your development tools, editors, etc., native on the Pi, does not mean it is normally the best solution - your desktop is going to be much more powerful.
Incidentally, what do you mean you like to use "your own languages and tools"?
It has an HDMI output. You can connect that to your TV - but you can also connect it to most monitors (at least, most half-decent modern monitors, and most decent half-modern monitors). And if you don't have HDMI on your monitor, you can use a simple HDMI-to-DVI converter.
Of course, not liking Linux is a matter of taste. But it sounds like you are frustrated by with Windows philosophy of not letting you do what you want with your own machine any more - maybe if you looked closer, you would start to like Linux on your desktop.
Dual-port ram for debugging and development went out of fashion at least
15 years ago. For microcontroller work, you use a debugger (jtag or similar) and download to the micro's internal flash.
Once we know what you are aiming for here, I'm sure you will get lots of suggestions in this group. But one thing they all have in common is that you do your development on a PC and use a USB-connected debugger. (If you were in the market for Ethernet connected debuggers, you wouldn't be asking these questions. And you won't use serial port or parallel port devices unless you are stuck working with ancient tools and micros.)
Just that: I've always used my own languages (and my own compilers, assemblers etc) and haven't grown out of the habit. Originally this was because I was building bare boards with no software to get started with, but I've since found using my own stuff to be very productive.
That's largely it. Linux ought to be the solution, but I just don't like it and as I said it's full of problems and things that don't work.
Sounds familiar! Actually that's the one I've tried before, but I've just dusted it down and tried it again.
Although the specs say 20msec command processing time, I'm managing to get over 100 bytes per second written to the output pins, far better than I remember. Although the effective throughput might be only 50 bytes/second (because of the need to signal each new byte), it seems simpler than any other solution so far. I can also drive it directly from my own software (via DLL functions).
Yes, I've been playing with an Arduino, that's what gave me the idea to attempt something of my own. But the little 32KB board I have, comes with
256MB of software on the PC, with 6000 files in 2000 directories! That's a lot of software to get in the way and make any solutions using this rather unwieldy.
You're looking for the wrong hardware. Most "parallel port" hardware is specifically about driving printers. Search for one of the many PCIe DIO (Digital I/O) cards. Many of those come with drivers that let a user mode application wiggle the pins as desired. If you want to actually take interrupts from the device, some of the packages have the ability to reflex a bit of that to user mode, but in general you then get to write a Windows device driver.
There are USB DIO devices as well, although (obviously) response times tend to be rather slower.
attempt something of my own. But the little 32KB board I have, comes with 256MB of software on the PC, with 6000 files in 2000
using this rather unwieldy.
I don't see why you think the size/number of the files on the PC is relevant.
Even if you have an Arduino, it doesn't mean you have to use the Arduino environment: you can program bare silicon directly in C or assembler. (Operating systems and environments: just say no :) ) I've recently done just that, since I wanted lower average power consumption than the Arduino environment would let me achieve.
Programming an ATMega324 in C is trivial, and if you just wanted to do a blinky LED I'd be surprised if the total code size in the ATMega324 reached 100 bytes.
Microsoft used to have an operating system (WinME and before) that booted from DOS and kept the DOS system it booted from protected, while operating. You could (and I did) type WIN into a DOS prompt to start it up and, when you shut it down you'd go back to the DOS prompt and could continue. Then they went to an operating system (WinNT and later) which supported direct booting without any prior DOS, used a different file system, and seriously began looking at security issues and keeping the hardware more protected than before.
All this also meant they had to actually WORK HARD and completely reimplement old DOS emulation. The older O/S line actually had a REAL copy of the old DOS that it could use for emulation, so the emulation almost came for free. But the new O/S line doesn't preserve it, so Microsoft has to write stuff from scratch, which Microsoft did NOT like doing and planned to minimize as soon as possible.
Earlier DOS systems were "modified" upon Windows boot-up to support (via WinOldAp running on the Windows protected mode side) traps into Windows so that DOS applications could call Windows functions. (An illegal instruction was used that would cause this trap and WinOldAp would then examine the immediate bytes following to decide what to do.) You could, for example, call the clipboard from DOS. The earlier Windows (WinME and before) would also allow you to use ctrl-ENTER to put a DOS box into full-screen mode. When you did that, WinOldAp would also then set up the protected mode I/O mapping so that the DOS box had complete access to all the I/O ports, rather than trapping them and emulating them.
Win2000 had better DOS support (for example, it supported the earlier clipboard function calls.) Later WinNT O/S incarnations, such as WInXP and later, removed that support from their DOS emulation. (And removed the ability to directly access the I/O ports, as well.)
That's just Microsoft. Meanwhile Intel and IBM PC compatible manufacturers were being greatly reduced in numbers by Intel's PCI initiative -- by design. The entry cost for anyone making a reflection wave bus system (PCI) was MUCH HIGHER than it was for incident wave (old ISA bus.) They sold the idea on "low power" but the real reason (and I know this from when I worked at Intel as an employee there) was because pricing would never increase as long as there were so many different players in the market and they needed to raise the cost bar. PCI was a way to do that.
With that in place, there was another problem at Intel. More than half of their chipset bugs came from the ISA bus interface (southbridge and it's special out-of-band wiring to the northbridge.) The ISA bus supported a DMA mode that could not be directly supported by the PCI design (PCI supports only short bursts, but not the unending transaction lengths that ISA supported, nor the guaranteed timing... etc.) This was a BIG problem to continue supporting. So Intel began plans to eliminate the southbridge, entirely, and to terminate the ISA bus forever. This was ALSO consistent with raising the bar, because anyone (even me) could design and construct ISA bus boards for custom stuff. Getting rid of ISA meant, once again, that the bar was raised for vendors wanting into the PC space.
Customers had no idea.
As ISA disappeared, so of course did the parallel port and serial port. Older designs required ISA access. Some designs in the older chipsets either implemented these in separate superIO chips or in the southbridge itself. But without a southbridge in newer designs, the superIO had nothing to connect to and of course the non-existent southbridge could not do the work, either. This put anything like that onto the PCI, which was entirely new and couldn't use the old methods. And I don't recall that lasting long, if it ever happened at all. It was easier to just lose the parallel and serial ports. Mouse and keyboard were probably the longest thing to hang around. I suppose you could look at screwing around with those if your motherboard supports them.
Anyway, I keep fully functioning ISA based systems around for exactly this reason. I can't design and wire wrap a PCI board (clock skew to data on 33MHz must be 2ns and uses a serpentine line to achieve it and the testing equipment is beyond my budget.) But I can easily do an ISA board in short order and I know it will work even before I test it.
Yeah. I understand.
What I did for this was to buy up a bunch of Texas Instruments LaunchPads when they were $4.30 each, shipping included. I've stacks of them. They attach to the USB and already include PC drivers to communicate over USB but using RS-232 COM port methodology on the Windows side (easy.) From the MSP-430 side, it's just a simple RS-232 driver bit of code. The board includes a complete set up for connecting in daughter cards, so I can wire up anything I want there.
One application I did this way was to let me connect Mailstations (which only have a parallel port for printers and cost me $0 because no one wants them anymore) to the PC and transport files into the PC.
But writing commands that could be passed between the PC and the LaunchPad software would be a walk in the park. No, not as easy as ISA programming directly, but at least you control things and can add capability as time permits.
I wouldn't use an Arduino for this. WAY too expensive when compared to other choices. There are so many other much cheaper/better options around now. You should be able to get a system with USB support and daughter card connectors on it for $10 or less. Even 32-bit ARM based systems I get cost $10. Keep the costs low so you can buy a bunch of them and dedicate their daughter card designs to your application.
Sure, but I don't know how! And it's difficult to find out because people are expected to use tools like this so that the direct methods are not documented. The great, sprawling nature of the software (with the paths in some arguments being twelve-deep!) makes it hard to figure out what's what as well.
I did manage to eliminate the GUI (an entire Java subsystem was included just for this purpose), but I was still left with a series of five programs that had to be run for each update, with some hairy-looking parameters. The last stage was uploading the binary program, and was invoked like this:
That would be a stumbling block even if I replaced all the other steps. The interface is USB, with apparently a COM port superimposed, but I've no idea what protocols are needed to rewrite the flash memory and restart the processor.
I'm not sure which tools you are referring to in "tools like this".
If the "tool" is the processor and you are programming bare silicon, you simply read the processor data sheet.
If the tool is an execution environment (e.g. an o/s or Arduino) then read the documentation. if there isn't any, choose one that is documented!
If the "tool" is the compiler/linker/downloader and debugging, then that is all taken care of by the IDE provided by Atmel. Windows, gag spit, but usable. There are a limited number of selections to be made, e.g compile for speed/size, which programmer/debugger you are using, but the choices are pretty straightforward (even if the resulting compiler switches etc aren't!).
that had to be run for each update, with some hairy-looking parameters. The last stage was uploading the binary program, and
Maybe the Java GUI's main benefit was to spit out the switches! Did you throw the baby out with the bathwater?
-CC:\Arduino\hardware/tools/avr/etc/avrdude.conf
-Uflash:w:filename.cpp.hex:i
Neither have I, and I didn't want to either! I just used the Atmel IDE, and it worked.
These are really to separate levels. If you want single bit IO, then and Serial-USB bridge device can do that, to the limit of the handshake lines. PC-end code is very simple.
eg The FTDI UM232H can do this, with shorter turn around times than Full Speed bridges, and it also has other modes, which need more SW effort, but can give more IO.
This starts to go beyond a USB-Serial bridge, but something like the UM232H has other modes, and with more work at the PC end, you can expand the IO.
For the most flexible real-world end, you are probably best to use a Bootloader uC and a USB-Serial bridge. That way, you can avoid Windows bottlenecks if you need to.
A Lowest cost combination for moderate IO, would be something like UMFT234XF+AT89LP52, and a smarter and faster combination might use UM232H+AT89LP51RB2
The LP51RB2 has bootloader in ROM, with easy access to UM232H-driven firmware updates, so that gives a flexible end, that can accept std COM connections.
The 'tools' were the software, 'Arduino 1.0.5', '...based on Processing', which is a packaging of a gcc compiler (or is it g++) among other things. Very untidy when you look into it. My approach has always been far simpler and much tidier (it had to be because I didn't have 250MB of spare disk space!) But I'm fairly new to these new systems and I only just understand that an Arduino is itself a packaging of an AVR processor.
That's another valid approach of course, and what I used to do (in the early eighties). But that just brings me back to my original problem of needing to bootstrap such a newly built circuit by downloading code from a host computer. I think I can use my K8055 board to get started with that, and worry about speeding up the downloads later.
ElectronDepot 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.