Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.orgI'm posting this idea in hopes of finding another enthusiast to work with to develop a product. I could do the Arduino end if necessary, I think. I'm not sure how difficult the PC end would be, or where to start. In an ideal world, we'd produce something for both the Windows and Linux communities. (That might mean two products for the PC end, both interfacing to the same Arduino product. The idea would be to create a "black box" consisting of a USB cable + pre-programmed Arduino, plus a simple "API", or "sdk" for the PC owner/ programmer. Of course once that "piece" was in place, others could build "black box" PC apps with it.
If you've come here from the discussion at the Arduino forum, you can skip down to the page to new material.
The idea arose because parallel ports are no longer common, and "hard" to fit to a laptop. In "the good old days" all you needed was a parallel port, a few connectors, LEDs and resistors, and you could have a lot of fun. (For more on playing with LEDs driven by a computer, see my page.)
First I'll explain my idea in simple terms. There's a "frill" I will discuss further down the page, so don't get frustrated yet, experts.
There's also a discussion of this idea in the Arduino forum, too. (That link takes you to... http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1245315562/0#0, or you can go to the forum and search on "Driving Arduino from PC", posted June 18, 2009, if you are careful about phishing risks.)
When being used in this application an Arduino would be continuously connected to a host PC. The Arduino would monitor the Arduino's serial port, watching for strings of three ASCII characters. The first character, in this simple scenario for forum discussion, would be a "d" for "display" or "r" for "report".
On receipt of a "d" string-of-three characters, the Arduino would interpret the 2nd and 3rd characters as a byte expressed in hex, and put that byte on 8 of the Arduino's i/o pins. (During the Arduino's general init sequence, those pins would be initialized as being for input.) You'd probably want the Arduino to then send the byte (as hex-in-Ascii (two characters) plus a checksum character) back to the host PC as a confirmation. We're going to need that "back to the host" channel for what comes next, anyway. Might has well keep things similar for the "d" scenario and the "r" scenario.
On receipt of an "r" string-of-three characters, the Arduino would ignore the 2nd and 3rd characters.... but it would read what is present on however many pins were available to dedicate to being inputs, and send the reading back to the host PC, again as hex-in-Ascii (two characters) plus a checksum character.
As I say... I'm not sure what would be best at the PC end. I know it can be done. (My credentials.) But I'm not sure which of many options would be best. Maybe (for Windows) a .DLL, which could be made available as an open source entity, with the compiled DLL available to those who just want to make use of it, and the sourcecode there for others? I trust there's something like a DLL in the Linux world?
Of course, if the Arduino end is done properly, there is nothing to stop the wider community from re-inventing, and re-inventing again and again better "wheels" to work with the Arduino "USB Parallel Port Replicator".
The idea of using a DLL is to make using the whole Arduino-as-digital-I/O-over-USB a "unit" which can be "plugged into" bigger projects. I would be prepared to consider handling distributing pre-programmed Arduinos (with the USB cable) to people outside the Arduino community... on a non-exclusive basis. If anyone else thinks they would like the headaches, they are welcome to take them on, too!
So.. that's my idea, my "dream product".
We are talking about async comms between two devices. Therefor some provision should be made for getting both parties on the same page, should the comms get confused. Data checking is also always a good idea. And leaving options open for the future is a final goal, for now.
And while I just said "final goal", I will repeat here a goal stated earlier: This product should be a joy to use, so it should be simple to use.
The first customers will be PC users with at least a little programming competence. For instance, a spreadsheet user should be able to include a simple DLL-calling formula in a cell, and when that spreadsheet is updated, the cell should fill with a number which comes from the input pins of the Arduino. (The "simple formula" really isn't a big deal.)
First customers, using a computer with a simple programming language should be able to put something like.....
ShowMessage(IntToStr(UpprGet1))
... in their code, and see a message box on their screen with a number in it. (I'm assuming that if they put "ShowMessage(IntToStr(47))" into their language, then "47" appears on the screen). In addition, they'll also have something in their program headers to tell their language how to invoke the UpprGet1 function.)
(That "UpprGet1" function is the second simplest in the DLL... it tries to read the UPPR, returns a 16 bit unsigned integer from 0-255 from the UPPR if it can, and returns a number > 256 if there was some error. Don't panic! It REALLY is simple to do... once the underlying UpprAsc is done! (Explained below))
I used the term "customer". I wouldn't expect everyone to be a paying customer. People capable of setting up the Arduino for themselves from the open source material this proposal is trying to generate would be quite free to do what they could with that material. Other people are going to pay the supplier of their choice to provide a pre-programmed UPPR... and nothing in the release of the UPPR code, etc, is to prevent that. The only things those customers will have to pay for, though, are the Arduino hardware and the supplier's time in setting up the UPPR code in the Arduino.
Of course, once UPPR is available, I would hope that a second group of customers would arise... People obtaining UPPRs from one source, and software using the UPPR either from the same source or elsewhere. That "software using the UPPR" could be freeware or not, as the owner chose.
====
So... I hope you're now clear on my idea of "simple to use".
I'll now turn to some of the design goals I am considering. Some may have to be trimmed back, to keep the thing simple to use.
In a moment, we'll look again at the needs of any async comms channel, but first let's consider something more fundamental...
I think that everything can be done on the basis of the host PC being in control of the comms channel. The Arduino only "speaks when spoken to". The host PC sends and the Arduino responds. (The Arduino should "always" be "listening"... as far as possible. I would give up some "space" in the Arduino to use it's buffered serial channel.) The messages between the two can always consist of three bytes. For simple matters, those can be three bytes of printable ASCII. Maybe it is worth having, "inside" the system, times when the bytes are not just printable ASCII.
Typical messages and responses....
FROM | RESPONSE FROM HOST | ARDUINO d00 | d00.... and the output pins all go low dFF | dFF.... and the output pins all go high rXX | 2FQ.... see below
I hope the first two are easy to understand? Send "d" followed by a byte expressed in ASCII hex, and that byte is place on the output pins. The Arduino responds to the host with what it was sent, just to say "got that". It might be as well to invert the byte as an additional check that all is well.
The third example probably needs a little explaining.
When we send the Arduino an "r" command, we are saying "please read the input pins". The two "X"s following the "r" command are just to make life easy. If messages to the Arduino always consist of just three bytes, the "read message" routine in the Arduino can be smaller.
After receiving a "r" (for "read") command, the Arduino looks at it's inputs. For the sake of our example (response was "2FQ") we'll assume that the Arduino has 6 pins available to dedicate to inputs from outside the Arduino, and at the moment they were read, they were hi/lo/hi/hi/hi/hi. That would, wouldn't it, be 2F in hex. The Arduino therefor sends "2F" to the host.... AND "Q", the "Q" having been generated by some checksumming mechanism. The host can just use the 2F, on faith, if it so desires, or it can be programmed more cleverly and compare the checksum to the data sent.
The "rXX" command, exactly as described... is the place to start. But once it is done, providing in the DLL the UpprGet1 function, described above, isn't hard.
Getting back to the problems of async comms channels....
Suppose the host tries to send "dFF d00 dFF d00" to set all the outputs high, then low, then high, then low." Suppose the Arduino does pretty well... suppose it reads the first two ("dFF d00") correctly, but then misses the next "d". It will then pick up "FFd" as its next three byte command! Not good! Hence the use of the "reply" to EVERY command sent. At any time the host is concerned that perhaps the channel is confused, it sends a string of 6 (or more?) zeros. At any time the Arduino "thinks" that the first character of a command is a zero, it notes the rest of the command, and reads another "command". Once it picks up something OTHER THAN a zero, at any position within the command, it treats that as the first character of the command, fetches two more from the stream of bytes directed at it, and then goes back to "routine" operation. Users of the host would be told: At places in your code where a breakdown in the comm channel has been detected... introduce a small wait. Then call the UpprFixLink routine from the DLL. It (UpprFixLink) would send 6 (more?) zeros (zeros, not the ASCII for "0") to the Arduino, do another small wait. It would then send an rXX command. If the checksum came back right, UpprFix would return 0, something else otherwise. (I said "something else" to leave open the possibility of returning error codes, if we ever get to the point where we can know more than "it's broke". Probably it would merely return 1. But the test for "fixed" should be "If UpprFixLink=0 then {all is well}", not "If UpperFixLink=1 then {is still down}".)
That would be "all" I "need" for a simple system. (One that I would pay for. See "Rea$on", below.) A few extra routines
I suspect that the above is quite "do-able", and probably sufficient. I would be willing to pay for that (see below)... and hold out the hope of a FURTHER payment for the following fancier system, if the fancier system were subsequently developed.....
For a user, the commands already discussed would remain available, and would work as before. The DLL would have function called UpprAsc with a three character string as it's parameter. The function would return a three character string. Putting....
sDemo=UpprAsc("rXX")
...would still send "rXX" to the Arduino, and return to sDemo something like "2FQ". And the same function would be used for the "d" command.
However, "under the covers", the comms between the Arduino and the host would, in addition to the printable ASCII commands already discussed, be capable of other commands... commands which would consist of three bytes of data, the permitted range of those bytes now ranging from 0-255 instead of only the printable ASCII values. (Care would be taken that the first byte would never be zero, in order that the "comms lost" routines not get confused.) The exact "vocabulary" of this extended mode would be something for discussion after the first stage of the project was completed. Maybe we can give the host PC access to a counter in the Arduino, for instance? Or the ADCs?
If you think you could work something like that up, and would consider doing so, but need a reason... contact me? While I know this can be done, should be done.... I don't have the time just now to do it. If this idea takes off, i.e. gets refined in a discussion here at the forum, I might consider paying someone for the development work.
The terms of that work would be subject to discussion, but would probably be along the following lines....
"Developer"... you, perhaps! "Investor": Me.
The developer would create a working USB Parallel Port Replicator (UPPR), along the lines described above, subject to negotiation with the investor. Developer's ideas for the best way to do the UPPR very welcome.
(By the way, it seems "UPPR" might be a good trademark, unless someone jumps in and gazumps us. Catchy, memorable, and at the moment, the top two hits at Goggle are "Universidad Politecnica de Puerto Rico." and "United Pet Pig Registry"!)
By "working USB Parallel Port Replicator", I mean an Arduino with the code described, and a .DLL or similar which allows the user the UpprAsc, UpprGet1 and UpprFixLink procedures described.
The developer, when he/ she had product ready, would send to the investor a programmed Arduino and the compiled DLL... but no sourcecode. (A deposit against the value of the Arduino could be provided.)
If the investor agreed that the beast actually works as promised, a "progress payment" would be made.
Further development rounds might be necessary, but the sourcecode and the rights to that code, and for the use of the DLL that derived from it would remain with the developer for the time being.
Some of this scheme protects the developer through his retention of the sourcecode, some of it depends on his trust in me... trust which I hope can be expected on the basis of my long history online. (Check out my Sheepdog Software site and online freeware and shareware, which you can get to from the tutorials. Check both with the WayBack machine.) Anyway... the project should be fun, even if it isn't the path to riches.
As developer and investor agree all is right, the sourcecode would be released into the public domain and published on the web, and as soon as that happened, the developer would be paid by the investor the previously agreed compensation for the work. The investor would not be buying rights to the code. The developer would be free to sell pre-programmed Upprs.... just like anyone else.
===
I would be willing to post here "Don't bother... {Fred} is already working on this" notices, if you want a little "breathing space" to work on an implementation... but don't ask me to publish such a notice until we have made some progress towards agreeing specific terms!
Thank you for reading this. I hope you'll take the project on... for the fun of it would be great, for the rea$on offered would be good!
If you visit 1&1's site from here, it helps me. They host my website, and I wouldn't put this link up for them if I wasn't happy with their service.
Click here to visit editor's Sheepdog Software (tm) freeware, shareware pages.
Click here to visit the homepage of my biggest site.
Click here to visit the homepage of Sheepdogsoftware.co.uk. Apologies if the "?FrmAht" I added to that link causes your browser problems. Please let me know, if so?
Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org
....... P a g e . . . E n d s .....