Everything is fine, until you actually start to work on the problem. If it is that simple, the problem would already be solved. Noboby has solved this problem to date.If you are correct, I humbly invite you to provide documentation. I would appreciate the insight. Thanks.
BTW, Peter J is right.
The BS2 will take the +V and the -V, you can use the schematic attached below. Just a few resistors and diodes will protect the BasicStamp or a Propeller and work well. For a BasicStamp2, just connect +5 where the schematic says to connect +3.3v
And even with the 3.3volt logic directly from the HP calculator a connection to the BS is simple. (If only there were a cable for the HP50g that did not bother to convert to RS232 voltage levels). You would just have to avoid the regular serial port and open one on other pins that could accept the inverted signal and provide 3.9K resistors between the two.
++++++
There is some cause to blame HP for never really explaining what the HP50g needs Kermit or Xmodem for. The Hewlett-Packard calculator gnomes have seemed to get longer winded and more cryptic over the years with their documentation.
They love to include lengthy examples of push this key and then that key that make one feel that they are learning from an exotic code, like one would with a chess master.
But after much study of their first two manuals (over 1000 pages of documents) and finally discovering the 3rd manual (another 600 plus page tome). It is all stupidly simple.
A. You turn on the port with OPENIO
B. You send with XMIT
C. You transfer received serial from its 255 byte buffer to the screen with SRECV
Configuration of the Baud rate, parity, and so on is just a simple parameter file that can be edited. Again, that darned Advanced User Reference is very clear about this. But not a word of explaining in the first 1000 pages of stuff that comes with your purchase.
:nerd: I appreciate Everyone's contribution to this problem, I finaly have a chance to solve the problem, that I have been working on
for the last 4 years.
The following information reguards HP communication, command and function reference;
(page 3 - 201) XMIT is usefule for communicating with non-Kermit devices such as RS - 232 printers.
(page 3-169) SRECV - serial recieve Command, reads up to n characters from the serial input buffer and
returns them as a string,along with a digit indicating whether errors occured. - does not use Kermit protocol.
HP does not make this easy. We know that it is accepted by RS - 232 printers, and that is does not use
Kermit protocol. It also is not included in the Xmodem library, to be used in that command set.(inplied?)
The mystery is two fold; find out What the OPENIO, XMIT,CLOSEIO, BUFLEN, SBRK,STIME represent.
Or, decrypt Xmodem command set, and make a interpreter for that. Which is simpler, in ease and
troubleshooting? I will investigate the simplest first.
:cool: Found the serial protocol, as defined by HP; IEEE - 488. ( the following information was given by a google book, serial programming )
This serial protocol pertains to a UART in every computer, attached to the serial port.( believe that? hmmm..)
The basic stamp has this protocol imbedded in its code, a virtual UART in the code.
The protocols that I defined previously for the HP calc, is very similar to the ones used for communication
with printers, but primitive.
Simply put, match the voltage levels to/from calculator to Stamp; ensure no corruption of data; and communication should
be possible. Handshaking, signal passing, etc,. should be possible. Find a chip with the speed to match voltages levels
without corrupting data, and you should be home free. The practical would have to be done anyway, for any interface, so
no time is lost doing this basic voltage matchup. Xmodem, anyone? :blank:
i don't think you need either Xmodem or Kermit with microcontroller projects.... they are provided to prevent data corruption of large file transfers of data. (to be used with Windows Linux, and Apple OSes).
And Xmodem is especially provided for Linux projects as HP didn't write anything specifically for Linux to use with the HP50g.
Xmodem is just easier to create a smaller less sophisticated file transfer. If you read the history of it, the developer created it because it was quick and easy.
Kermit is industrial strength modem communications that is still being actively improved.
____________
There is a reason that HP put all this in the Advanced User Reference. That didn't want to explain it all. You are supposed to learn it elsewhere, and to be advanced enough to figure it out for yourself.
I find that a bit unreasonable. So I have ignored the HP50g serial interface for 5 or more years.
+++++++++++++++++
The historical scheme is this.
RS232 asynchronous is accurate until it leaves the computer and enters the wire. Wires and connectors vary in quality and are susceptible to noise.
The first line of defense was originally Parity to check that each and every character was right. But it wasn't very good.
The second line was to add another Stop bit to make the spaces between characters easier to catch, and that wasn't really as good as expected either.
Meanwhile speed was jumping ahead by leaps and bounds. Baud rates that were once 75 Baud, doubled, doubled again, quadrupled, and so on.
Modems went from 300 Baud to 52K Baud in every home.
So people started adding more protective communications software by creating Packets. A Packet could have a Checksum attached and if the Checksum didn't add up, it could be sent again. Of course, that meant that each Packet also required a unique Identifier, so the receiving computer could get everything in proper over.
That is about as far as Xmodem got. All these extras slowed down the actual communications. So people started looking at ways to get faster and faster. So then there was Ymodem, Zmodem, and Kermit. Things got faster, but more complex. Packets got bigger and files management more complex.
=======
All this stuff is rather silly for a lowly BasicStamp2.
The BS2 has only 32 bytes of RAM, so it will never have a file system. Nearly all its reception needs is just 1, 2 or 3 bytes of code to trigger an activity. And it can't keep up with error checking beyond the parity level without a huge slow down.
On the transmission side, the BS2 can send quite a bit if the receiving device can keep up.
But it is just sending real-time data, not files. (It is a MicroController, NOT a MicroComputer -- computers use files, controllers generally don't)
So if you begin to understand the history, a fundamental RS232 port works well with a printer or a dumb terminal.
Xmodem and Kermit works well with file downloads, like HTML files, or E-mail files, whole HP50g program files, modems, and internet connections.
This is all about the scale of the communications as well as the distances. And HP included a USB client to the Kermit and Xmodem would work extremely fast (3Mbaud) with PCs. In fact, with the USB plugged in the HP50g doesn't even need batteries.
Hewlett-Packard likely included the RS232 low level ability to sell calculators to a small group of loyal users that demanded it (government contractors or university researchers), and they are certainly advanced users. You have to consider that this is the calculator you take with you on a NASA Space Shuttle, or to do research in the Antarctic, or to engineer a pipeline through a hostile desert.
And then for the general public, they wrote 1000 pages of Student level text about all-and-everything that you might ever want a math calculator to do. (To sell to the idiots that just want it all.)
I strongly suspect they figured (quite rightly) that 98% of all HP50g owners would never understand even half of what was written. But if the customers thought this was a greater value and would buy, bury them in information.
I certainly felt buried. The Advanced User Reference has been the book I wanted and needed all along.
I want to shout, "Why didn't you say this in the first place?'
That is just the way it is. Enjoy what you have learned, be creative. HP will never produce another product like this.
i don't think you need either Xmodem or Kermit with microcontroller projects.... they are provided to prevent data corruption of large file transfers of data. (to be used with Windows Linux, and Apple OSes).
And Xmodem is especially provided for Linux projects as HP didn't write anything specifically for Linux to use with the HP50g.
Xmodem is just easier to create a smaller less sophisticated file transfer. If you read the history of it, the developer created it because it was quick and easy.
Kermit is industrial strength modem communications that is still being actively improved.
____________
There is a reason that HP put all this in the Advanced User Reference. That didn't want to explain it all. You are supposed to learn it elsewhere, and to be advanced enough to figure it out for yourself.
I find that a bit unreasonable. So I have ignored the HP50g serial interface for 5 or more years.
+++++++++++++++++
The historical scheme is this.
RS232 asynchronous is accurate until it leaves the computer and enters the wire. Wires and connectors vary in quality and are susceptible to noise.
The first line of defense was originally Parity to check that each and every character was right. But it wasn't very good.
The second line was to add another Stop bit to make the spaces between characters easier to catch, and that wasn't really as good as expected either.
Meanwhile speed was jumping ahead by leaps and bounds. Baud rates that were once 75 Baud, doubled, doubled again, quadrupled, and so on.
Modems went from 300 Baud to 52K Baud in every home.
So people started adding more protective communications software by creating Packets. A Packet could have a Checksum attached and if the Checksum didn't add up, it could be sent again. Of course, that meant that each Packet also required a unique Identifier, so the receiving computer could get everything in proper over.
That is about as far as Xmodem got. All these extras slowed down the actual communications. So people started looking at ways to get faster and faster. So then there was Ymodem, Zmodem, and Kermit. Things got faster, but more complex. Packets got bigger and files management more complex.
=======
All this stuff is rather silly for a lowly BasicStamp2.
The BS2 has only 32 bytes of RAM, so it will never have a file system. Nearly all its reception needs is just 1, 2 or 3 bytes of code to trigger an activity. And it can't keep up with error checking beyond the parity level without a huge slow down.
On the transmission side, the BS2 can send quite a bit if the receiving device can keep up.
But it is just sending real-time data, not files. (It is a MicroController, NOT a MicroComputer -- computers use files, controllers generally don't)
So if you begin to understand the history, a fundamental RS232 port works well with a printer or a dumb terminal.
Xmodem and Kermit works well with file downloads, like HTML files, or E-mail files, whole HP50g program files, modems, and internet connections.
This is all about the scale of the communications as well as the distances. And HP included a USB client to the Kermit and Xmodem would work extremely fast (3Mbaud) with PCs. In fact, with the USB plugged in the HP50g doesn't even need batteries.
Hewlett-Packard likely included the RS232 low level ability to sell calculators to a small group of loyal users that demanded it (government contractors or university researchers), and they are certainly advanced users. You have to consider that this is the calculator you take with you on a NASA Space Shuttle, or to do research in the Antarctic, or to engineer a pipeline through a hostile desert.
And then for the general public, they wrote 1000 pages of Student level text about all-and-everything that you might ever want a math calculator to do. (To sell to the idiots that just want it all.)
I strongly suspect they figured (quite rightly) that 98% of all HP50g owners would never understand even half of what was written. But if the customers thought this was a greater value and would buy, bury them in information.
I certainly felt buried. The Advanced User Reference has been the book I wanted and needed all along.
I want to shout, "Why didn't you say this in the first place?'
That is just the way it is. Enjoy what you have learned, be creative. HP will never produce another product like this.
As usual, great information, Loopy Byteloose! I have enough information to begin the overall project. I will make a spreadsheet to account for all the RS - 232 data responses.
(signals, chararcter, numbers, etc,.) I will start with the basic stamp, to begin the interpreter code. When I have consumed too much memory, and it starts eating into my
application, then I will gravitate into the propeller, to forge that into a full fledged interpreter. I am sure that by that time, I will have created the "Loopy Stoplight" interpreter, ready for posting.
I think that HP and Texas Instruments will always produce calculators that have this capability. The main use of these calculators are with students in universities, and scientists. This
group uses the serial interface for "talking" to dedicated transducers in the lab. They have the money, the time, and need to produce high technology. The better the tool, the more efficent you are.
The regular person, who is just getting by, will not have a need to purchase an expensive calculator, when their nature pertains to processing the practical.
From this perspective, if used properly, gives a great advantage to we, who are technology geeks. We can reap the benefits of their scientific programs, while actually
impementing (in the real world) the calculated concept they intended, but can not do; to go where no HP/TI has gone before.
This "avatar", would be of great help to projects like the MOON ROVER project, just recently started, here in this forum. The benefits of this project, for the Geek, is
great. Build your own transducer feedback, and troubleshoot any electronic device, or component. The Geek can not only do what takes HP a league of highly paid engineers
to do, but create something a device totally new, and possibly make a hefty profit. To these truths, we hold self - evident. :blank:
The new HP graphic calculator is the HP Prime. It seems the RS232 port is gone forever.
It is all wireless connectivity now. And of course, a touch screen.
The new HP graphic calculator is the HP Prime. It seems the RS232 port is gone forever.
It is all wireless connectivity now. And of course, a touch screen.
:frown: Well, there's a truth that is self-evident. I stand corrected. :frown: I might as well start working on the USB interface WHILE I am
backtracking in the serial sewer. I guess I will use a USB to serial converter until I work out the kinks. MAN, you can't have nothing
these days........(had a seconds of glory)......:frown: The next thing will happen, is that only Xmodem and/or Kermit protocol is used, because serial is gone.
THEN, I will have to make an interpreter for that. (does anybody sell Xmodem an/or Kermit converters yet? I am dying here...........)
:frown: Well, there's a truth that is self-evident. I stand corrected. :frown: I might as well start working on the USB interface WHILE I am
backtracking in the serial sewer. I guess I will use a USB to serial converter until I work out the kinks. MAN, you can't have nothing
these days........(had a seconds of glory)......:frown: The next thing will happen, is that only Xmodem and/or Kermit protocol is used, because serial is gone.
THEN, I will have to make an interpreter for that. (does anybody sell Xmodem an/or Kermit converters yet? I am dying here...........)
Thanks for the insight.
Right before commiting Hari-Cari, I swept Parallax web site. They sell USB to serial converters! Ha! saved again! for how long, don't know...........
"Hope springs eternal in the human heart."
Ckermit is available for Windows and Apple OSes
Xmodem is availabe for Linux.
If you have a need, the stuff is already available.
But I never use this stuff. My Minicom terminal emulator in Linux has XModem and Kermit, and more. It might be handy if I decided to hook up the old modem to the telephone line and do some dial up communications or remote control (to something like a Raspberry Pi connected to a modem at the other end). Not much else.
:cool: In reference to changing the voltage levels, sparkfun makes a board that changes the voltage levels, to/
from HP 50 to/from basic stamp, $1.99.
Ardenu sells a stamp that processes the USB. What type of communication it uses, I do not know. I feel that
the propeller II will deal with any interfaces needed. Dealing with the protocol is another matter......
I will always love Parallax products. They have been the standard forever, and stable.
:nerd: After reviewing the serial data for the stamp, it should be possible to "talk" to the HP calc. I will use the
Sparkfun voltage changer to make them able to pass data. Does anyone have documentation on more serial
comm on the stamp and HP calculator?
Why why why is everyone obsessed with "RS232" and even more so "true RS232", it's not a protocol, it's just a lousy (un)standard voltage level that has nothing to do with XMODEM or even the baud rate and data bits etc. A micro connected to a micro has no need for any RS232 level converters at all, period. If you are using 5V stamps then the only thing you might need to do is current limit the transmit from the stamp to the calc and if you set your stamp inputs to TTL logic levels then you can connect directly from the calc's transmit to the stamp. KISS guys, it's not rocket science.
Even Loopy has mentioned just using resistors although you only really need the one and perhaps a pull-down.You ask for advice but you seem to ignore it. Personally I've used IRDA in the past with HP calcs but what do I know.
In a few instances, the HP50g is a very handy portable RS232 hardwire interface. IRDA more than likely expects to exchange info in Kermit, which is not low level enough for a BS2.
The HP50g can receive raw data from a BS2 and do the number crunching to either display or to store a data file for later transfer.
In a few instances, the HP50g is a very handy portable RS232 hardwire interface. IRDA more than likely expects to exchange info in Kermit, which is not low level enough for a BS2.
The HP50g can receive raw data from a BS2 and do the number crunching to either display or to store a data file for later transfer.
:frown: First, I apologize for all my shortcomings. I do appreciate all the suggestions given by everyone, and I do listen, I just have a hard head, somtimes.
I do agree with Loopy Byteloose, that the problem is solved. Anyone reading the full thread of this subject should have enough information, just like me, to
begin to build the interface and achieve whatever results they are looking for. The missing peice of the puzzle are the commands of HP, and the working out of the
timing of serial. (less than 9600 baud is recommended, The basic stamp manual indicates that 9600 may have data corruption.) All of the other items needed to
complete an interface will have to be worked out specifically, by the user, in which, is unquie to that person. All of the generic information is here to begin to
build the interface.
I appreciate everyone's input. Alot of people have been waiting for this solution; as indicated throught the web. I know I have.
Learning is what the Parallax Forums are all about. Peter J. is a bit impatient, just because he knows a heck of a lot and sees lots of fun projects that are way beyond you and me.
I admire his knowledge. not so sure about his impatience.
I learned quite a bit by helping out.. it is a two way street. I had not considered having to use Xmodem or Kermit with the HP50g and my Minicom software will do so nicely. I am still waiting for the cable to arrive to do any real tests.
The simple fact is I have had my HP50g for ages and been rather annoyed that it was so hard to read the documentation. I had an HP41cx that was an absolute joy and likely the best of all the calculators HP will ever have made.. but the keyboard wore out.
Calculators are almost becoming artifacts of the past, like long-playing vinyl records. But the HP support for higher maths is wonderful -- especially since it is NOT on a computer spreadsheet.
But the truth is that one might spend a lifetime mastering all the functions on an HP50g. I have a Professional Engineer E.I.T certification, so I do understand what nearly all the maths are supposed to do. But I just about never have a use for them.
And so, the calculator sits around, like a cherished university textbook of course that was very hard, but enjoyable.
++++++++++
The Advanced User Reference has a list of the available Baud rates, 1200 Baud is the slowest. Read Section D-4 on IOPAR
Receiving may be a little more work that sending. XMIT sends, but SRECV requires you first use BUFLEN to know how full the receive buffer is. Otherwise, you have to guess how many characters SRECV should use and the receive buffer might overflow. So there still are some things to smooth out if you have a BS2 sending continuously.
The BS2 rates vary depending on which BasicStamp2 you own. 9600 is the highest rate for all but the BS2px, which will do 19200.
:cool: And with that, The problem is solved. I will complete the total package and post it at a later date, in this
forum. It will be complete with instructions from start to finish, from the HP commands, to timing, the interface, the transducer,
and the program in the stamp. I will have to have an HP program emulator on the computer, to examine other dedicated
programs; revamp them to a generic project. More advanced items than that, graphing, multiple variables, and
Xmodem/Kermit servers, I leave to the more advanced than I. Once again, I do appreciate everybody working on the problem.
:blank: The Journey of a thousand miles begins with one step.........:frown:
scooped up some information about monitoring the serial port information from the stamp, from another related thread; www.serial-port-monitor.com/index.html - serial port analyzer
tried the sparkfun 3.3 v to 5 volt logic converter, from hp calc to stamp; - did not work;
However, I did try an hp 49 to 50 direct serial hookup, with one calculator doing the srecv command, while
the other did the xmit command. They did not communicate. I only used the commands right out of the
command list.( the cat button)
The IOPAR settings on the home directory were identical, and did not conflict.
The calculators did talk via the serial crossover cable, with Xmodem and Kermit protocols, flawlessly.
Based on this, I can not say that the converter was a problem, because the calculators could not talk to
each other, themselves.
I will try to analyze the output of the calculator XMIT command, byteb by byte, or bit by bit.
I wonder if the Srecv command "sees" anything.
Could it be that you are confusing what comes out of the HP50g serial port (ttl 3.3v logic) with what comes out of the other end of an adapter cable (RS232 +V/-V signals that are inverted from the ttl 3.3v logic).
There really is no need to fool around with the ttl 3.3v logic if you have the right cable doing the conversion for you.
And if you really desire to fool with the 3.3v logic and to convert it to 5.0v logic; what are you connecting it to?
In some cases, both the Tx and Rx may require inversion. To get to true RS232 you have to insert a MAX232 or similar chip... just a huge bother when the supplied cable does this for you.
++++++++++
I still haven't gotten the cable I ordered, so I haven't been trying to learn more about the HP50g RS232 port.
tried the sparkfun 3.3 v to 5 volt logic converter, from hp calc to stamp; - did not work;
However, I did try an hp 49 to 50 direct serial hookup, with one calculator doing the srecv command, while
the other did the xmit command. They did not communicate. I only used the commands right out of the
command list.( the cat button)
The IOPAR settings on the home directory were identical, and did not conflict.
The calculators did talk via the serial crossover cable, with Xmodem and Kermit protocols, flawlessly.
Based on this, I can not say that the converter was a problem, because the calculators could not talk to
each other, themselves.
I will try to analyze the output of the calculator XMIT command, byteb by byte, or bit by bit.
I wonder if the Srecv command "sees" anything.
anybody got any ideas?
:cool: I backed up, and tried something the infrared port when using the Xmit and Srecv commands......and it worked! The setting was in the
transfer selection, in the menu part of the calculator. Letters were sent from calculator to calculator, (hp48gii to 50g)
I will try the serial selection, in the transfer menu. I still think the protocol is either kermit or Xmodem. I will try the Y "tap off" deal that
Loopy Byteloose indicated, to see if the stamp "sees" it, or if a protocol software can detect what protocol it is. I must find a program
that forces it to send data in a UART standard, which would be passed through standard computer serial ports.(in the old days)
Otherwise, a Kermit or Xmodem embedded program is probably of the prescription of the Stamp Doctor.
Well, this thread started way back in January. I guess I ordered an HP50 serial cable in early February, though I have a note that says I ordered it Jan 6th.
For what it is worth, it arrived today. So I can now use the HP50 as an RS-232 terminal. There was no way for me to DIY a cable as the plug into the HP50 is nowhere to be gotten in Taiwan.
The main point here is that you can still order the cables from Eric Rechlin in Houston... but you have to be patient. This was put in the mail by him on Mar 22nd.
Time for a loop-back test.. just to make sure all is well.
Well, this thread started way back in January. I guess I ordered an HP50 serial cable in early February, though I have a note that says I ordered it Jan 6th.
For what it is worth, it arrived today. So I can now use the HP50 as an RS-232 terminal. There was no way for me to DIY a cable as the plug into the HP50 is nowhere to be gotten in Taiwan.
The main point here is that you can still order the cables from Eric Rechlin in Houston... but you have to be patient. This was put in the mail by him on Mar 22nd.
Time for a loop-back test.. just to make sure all is well.
Your loop-back test will be successful. Since the thread was started, I have done some more experiments. The winmodem protocol is
unavoidable. I have ordered some winmodem software to make sure the data communication is possible. I have also found some IC's
that communicate in Winmodem, and may allow the calculator to "talk" to many devices, outside the intended range. There may be electronic
kits that are avaliable for this purpose, but I have not found them yet.
Whatever device you untimately interface to, you will need a "front end" from both sides of the interface. Data buffering and packaging seems to be
a prime cause of discontent. I have tried a lot of things, but I know there is an answer!
:cool: And with that, The problem is solved. I will complete the total package and post it at a later date, in this
forum. It will be complete with instructions from start to finish, from the HP commands, to timing, the interface, the transducer,
and the program in the stamp. I will have to have an HP program emulator on the computer, to examine other dedicated
programs; revamp them to a generic project. More advanced items than that, graphing, multiple variables, and
Xmodem/Kermit servers, I leave to the more advanced than I. Once again, I do appreciate everybody working on the problem.
:blank: The Journey of a thousand miles begins with one step.........:frown:
I have had some success withteh Hp serial and basic stamp communication, BUT, it is not dependable to make a viable device that I can depend on. I find myself wasting time
on troubleshooting communication issues (data collisions, timing, ACK, NAK, etc) I decided to chuck that philosophy and go with something totally new. I feel that Parallax has products
to do this, but I had to backtrack to another product, the beagle bone board. It has the power of a laptop, whilst giving the microcontroller hobbiest the options avaliable from the
stamp. There are some bugs, but the modularity is hard to turn down. The have drivers on-board that automatically convert Xmodem (like hyperterminal) to the Ic2, or serial required by
the basic stamps. Beagle boards are not that expensive, but your labor to use it will be. Open source or windows platform, ON THE BOARD, is avaliable. If parallax had something like
this, I would love it! you could use all the power of basic stamps in the parallax well supported enviroment!!!!
I think this should solve my problem, and now I cna proceed to may my ultimate diagnostic tool!! Yay!
status of the project:
playing with a beagleboard to be the interpreter of the project. Beaglebone black is cool, but is
dependent on free drivers and other programs. If you can find them, hope they work. I just need this
working, then I will find a way to port this to the propeller. I can run a terminal program like
(Loopy was saying) to "talk" to the calculator; I will then get the beaglebone to organize the
data and feed it to the stamp. I will have to set up a bash shell run time program to run the
programs in the background to get it to work. The beaglebone can do the job, (maybe),
but requires ALOT of time downloading, testing, and debugging software, that may work. Parallax is definitely more friendly to work with, insofar as putting the
whole system together. :cool:
:nerd: Does anybody know if there is a terminal program written for the propeller? The propeller
must be able to run the terminal program, itself, and gather data. Please advise.
:nerd: Does anybody know if there is a terminal program written for the propeller? The propeller
must be able to run the terminal program, itself, and gather data. Please advise.
To have a terminal program, you will need to have an OS to run it on.
Heater has provided a list
from another thread;
1) CP/M 2
2) CP/M 3
We are working on:
3) MP/M
4) CUBIX
5) One Man Unix (OMU)
6) Flex.
Undoubtly, other subprograms that anyone may need, could be put on these OS's.
I will attempt to acertain the memory requirements of the terminal program; other
subprograms can be evaluated in this way.
Comments
BTW, Peter J is right.
The BS2 will take the +V and the -V, you can use the schematic attached below. Just a few resistors and diodes will protect the BasicStamp or a Propeller and work well. For a BasicStamp2, just connect +5 where the schematic says to connect +3.3v
And even with the 3.3volt logic directly from the HP calculator a connection to the BS is simple. (If only there were a cable for the HP50g that did not bother to convert to RS232 voltage levels). You would just have to avoid the regular serial port and open one on other pins that could accept the inverted signal and provide 3.9K resistors between the two.
++++++
There is some cause to blame HP for never really explaining what the HP50g needs Kermit or Xmodem for. The Hewlett-Packard calculator gnomes have seemed to get longer winded and more cryptic over the years with their documentation.
They love to include lengthy examples of push this key and then that key that make one feel that they are learning from an exotic code, like one would with a chess master.
But after much study of their first two manuals (over 1000 pages of documents) and finally discovering the 3rd manual (another 600 plus page tome). It is all stupidly simple.
A. You turn on the port with OPENIO
B. You send with XMIT
C. You transfer received serial from its 255 byte buffer to the screen with SRECV
Configuration of the Baud rate, parity, and so on is just a simple parameter file that can be edited. Again, that darned Advanced User Reference is very clear about this. But not a word of explaining in the first 1000 pages of stuff that comes with your purchase.
for the last 4 years.
The following information reguards HP communication, command and function reference;
(page 3 - 201) XMIT is usefule for communicating with non-Kermit devices such as RS - 232 printers.
(page 3-169) SRECV - serial recieve Command, reads up to n characters from the serial input buffer and
returns them as a string,along with a digit indicating whether errors occured. - does not use Kermit protocol.
HP does not make this easy. We know that it is accepted by RS - 232 printers, and that is does not use
Kermit protocol. It also is not included in the Xmodem library, to be used in that command set.(inplied?)
The mystery is two fold; find out What the OPENIO, XMIT,CLOSEIO, BUFLEN, SBRK,STIME represent.
Or, decrypt Xmodem command set, and make a interpreter for that. Which is simpler, in ease and
troubleshooting? I will investigate the simplest first.
This serial protocol pertains to a UART in every computer, attached to the serial port.( believe that? hmmm..)
The basic stamp has this protocol imbedded in its code, a virtual UART in the code.
The protocols that I defined previously for the HP calc, is very similar to the ones used for communication
with printers, but primitive.
Simply put, match the voltage levels to/from calculator to Stamp; ensure no corruption of data; and communication should
be possible. Handshaking, signal passing, etc,. should be possible. Find a chip with the speed to match voltages levels
without corrupting data, and you should be home free. The practical would have to be done anyway, for any interface, so
no time is lost doing this basic voltage matchup. Xmodem, anyone? :blank:
And Xmodem is especially provided for Linux projects as HP didn't write anything specifically for Linux to use with the HP50g.
Xmodem is just easier to create a smaller less sophisticated file transfer. If you read the history of it, the developer created it because it was quick and easy.
Kermit is industrial strength modem communications that is still being actively improved.
____________
There is a reason that HP put all this in the Advanced User Reference. That didn't want to explain it all. You are supposed to learn it elsewhere, and to be advanced enough to figure it out for yourself.
I find that a bit unreasonable. So I have ignored the HP50g serial interface for 5 or more years.
+++++++++++++++++
The historical scheme is this.
RS232 asynchronous is accurate until it leaves the computer and enters the wire. Wires and connectors vary in quality and are susceptible to noise.
The first line of defense was originally Parity to check that each and every character was right. But it wasn't very good.
The second line was to add another Stop bit to make the spaces between characters easier to catch, and that wasn't really as good as expected either.
Meanwhile speed was jumping ahead by leaps and bounds. Baud rates that were once 75 Baud, doubled, doubled again, quadrupled, and so on.
Modems went from 300 Baud to 52K Baud in every home.
So people started adding more protective communications software by creating Packets. A Packet could have a Checksum attached and if the Checksum didn't add up, it could be sent again. Of course, that meant that each Packet also required a unique Identifier, so the receiving computer could get everything in proper over.
That is about as far as Xmodem got. All these extras slowed down the actual communications. So people started looking at ways to get faster and faster. So then there was Ymodem, Zmodem, and Kermit. Things got faster, but more complex. Packets got bigger and files management more complex.
=======
All this stuff is rather silly for a lowly BasicStamp2.
The BS2 has only 32 bytes of RAM, so it will never have a file system. Nearly all its reception needs is just 1, 2 or 3 bytes of code to trigger an activity. And it can't keep up with error checking beyond the parity level without a huge slow down.
On the transmission side, the BS2 can send quite a bit if the receiving device can keep up.
But it is just sending real-time data, not files. (It is a MicroController, NOT a MicroComputer -- computers use files, controllers generally don't)
So if you begin to understand the history, a fundamental RS232 port works well with a printer or a dumb terminal.
Xmodem and Kermit works well with file downloads, like HTML files, or E-mail files, whole HP50g program files, modems, and internet connections.
This is all about the scale of the communications as well as the distances. And HP included a USB client to the Kermit and Xmodem would work extremely fast (3Mbaud) with PCs. In fact, with the USB plugged in the HP50g doesn't even need batteries.
Hewlett-Packard likely included the RS232 low level ability to sell calculators to a small group of loyal users that demanded it (government contractors or university researchers), and they are certainly advanced users. You have to consider that this is the calculator you take with you on a NASA Space Shuttle, or to do research in the Antarctic, or to engineer a pipeline through a hostile desert.
And then for the general public, they wrote 1000 pages of Student level text about all-and-everything that you might ever want a math calculator to do. (To sell to the idiots that just want it all.)
I strongly suspect they figured (quite rightly) that 98% of all HP50g owners would never understand even half of what was written. But if the customers thought this was a greater value and would buy, bury them in information.
I certainly felt buried. The Advanced User Reference has been the book I wanted and needed all along.
I want to shout, "Why didn't you say this in the first place?'
That is just the way it is. Enjoy what you have learned, be creative. HP will never produce another product like this.
(signals, chararcter, numbers, etc,.) I will start with the basic stamp, to begin the interpreter code. When I have consumed too much memory, and it starts eating into my
application, then I will gravitate into the propeller, to forge that into a full fledged interpreter. I am sure that by that time, I will have created the "Loopy Stoplight" interpreter, ready for posting.
I think that HP and Texas Instruments will always produce calculators that have this capability. The main use of these calculators are with students in universities, and scientists. This
group uses the serial interface for "talking" to dedicated transducers in the lab. They have the money, the time, and need to produce high technology. The better the tool, the more efficent you are.
The regular person, who is just getting by, will not have a need to purchase an expensive calculator, when their nature pertains to processing the practical.
From this perspective, if used properly, gives a great advantage to we, who are technology geeks. We can reap the benefits of their scientific programs, while actually
impementing (in the real world) the calculated concept they intended, but can not do; to go where no HP/TI has gone before.
This "avatar", would be of great help to projects like the MOON ROVER project, just recently started, here in this forum. The benefits of this project, for the Geek, is
great. Build your own transducer feedback, and troubleshoot any electronic device, or component. The Geek can not only do what takes HP a league of highly paid engineers
to do, but create something a device totally new, and possibly make a hefty profit. To these truths, we hold self - evident. :blank:
Thanks again!
It is all wireless connectivity now. And of course, a touch screen.
http://www.shopping.hp.com/en_US/home-office/-/products/Accessories/Calculators/NW280AA?HP-Prime-Graphing-Calculator
:frown: Well, there's a truth that is self-evident. I stand corrected. :frown: I might as well start working on the USB interface WHILE I am
backtracking in the serial sewer. I guess I will use a USB to serial converter until I work out the kinks. MAN, you can't have nothing
these days........(had a seconds of glory)......:frown: The next thing will happen, is that only Xmodem and/or Kermit protocol is used, because serial is gone.
THEN, I will have to make an interpreter for that. (does anybody sell Xmodem an/or Kermit converters yet? I am dying here...........)
Thanks for the insight.
Right before commiting Hari-Cari, I swept Parallax web site. They sell USB to serial converters! Ha! saved again! for how long, don't know...........
"Hope springs eternal in the human heart."
Xmodem is availabe for Linux.
If you have a need, the stuff is already available.
But I never use this stuff. My Minicom terminal emulator in Linux has XModem and Kermit, and more. It might be handy if I decided to hook up the old modem to the telephone line and do some dial up communications or remote control (to something like a Raspberry Pi connected to a modem at the other end). Not much else.
Saved again! I am back! Thanks again!
from HP 50 to/from basic stamp, $1.99.
Ardenu sells a stamp that processes the USB. What type of communication it uses, I do not know. I feel that
the propeller II will deal with any interfaces needed. Dealing with the protocol is another matter......
I will always love Parallax products. They have been the standard forever, and stable.
Sparkfun voltage changer to make them able to pass data. Does anyone have documentation on more serial
comm on the stamp and HP calculator?
Even Loopy has mentioned just using resistors although you only really need the one and perhaps a pull-down.You ask for advice but you seem to ignore it. Personally I've used IRDA in the past with HP calcs but what do I know.
In a few instances, the HP50g is a very handy portable RS232 hardwire interface. IRDA more than likely expects to exchange info in Kermit, which is not low level enough for a BS2.
The HP50g can receive raw data from a BS2 and do the number crunching to either display or to store a data file for later transfer.
:frown: First, I apologize for all my shortcomings. I do appreciate all the suggestions given by everyone, and I do listen, I just have a hard head, somtimes.
I do agree with Loopy Byteloose, that the problem is solved. Anyone reading the full thread of this subject should have enough information, just like me, to
begin to build the interface and achieve whatever results they are looking for. The missing peice of the puzzle are the commands of HP, and the working out of the
timing of serial. (less than 9600 baud is recommended, The basic stamp manual indicates that 9600 may have data corruption.) All of the other items needed to
complete an interface will have to be worked out specifically, by the user, in which, is unquie to that person. All of the generic information is here to begin to
build the interface.
I appreciate everyone's input. Alot of people have been waiting for this solution; as indicated throught the web. I know I have.
I admire his knowledge. not so sure about his impatience.
I learned quite a bit by helping out.. it is a two way street. I had not considered having to use Xmodem or Kermit with the HP50g and my Minicom software will do so nicely. I am still waiting for the cable to arrive to do any real tests.
The simple fact is I have had my HP50g for ages and been rather annoyed that it was so hard to read the documentation. I had an HP41cx that was an absolute joy and likely the best of all the calculators HP will ever have made.. but the keyboard wore out.
Calculators are almost becoming artifacts of the past, like long-playing vinyl records. But the HP support for higher maths is wonderful -- especially since it is NOT on a computer spreadsheet.
But the truth is that one might spend a lifetime mastering all the functions on an HP50g. I have a Professional Engineer E.I.T certification, so I do understand what nearly all the maths are supposed to do. But I just about never have a use for them.
And so, the calculator sits around, like a cherished university textbook of course that was very hard, but enjoyable.
++++++++++
The Advanced User Reference has a list of the available Baud rates, 1200 Baud is the slowest. Read Section D-4 on IOPAR
Receiving may be a little more work that sending. XMIT sends, but SRECV requires you first use BUFLEN to know how full the receive buffer is. Otherwise, you have to guess how many characters SRECV should use and the receive buffer might overflow. So there still are some things to smooth out if you have a BS2 sending continuously.
The BS2 rates vary depending on which BasicStamp2 you own. 9600 is the highest rate for all but the BS2px, which will do 19200.
forum. It will be complete with instructions from start to finish, from the HP commands, to timing, the interface, the transducer,
and the program in the stamp. I will have to have an HP program emulator on the computer, to examine other dedicated
programs; revamp them to a generic project. More advanced items than that, graphing, multiple variables, and
Xmodem/Kermit servers, I leave to the more advanced than I. Once again, I do appreciate everybody working on the problem.
:blank: The Journey of a thousand miles begins with one step.........:frown:
www.serial-port-monitor.com/index.html - serial port analyzer
to connect the basic stamp to the intenet, try this site, and device;
www.netburner.com/product/se...-ethernet/sb70
a/or
Netburne SB70 device
With this infomation, I am sure a USB client/server is avaliable for the stamp, but where?
tried the sparkfun 3.3 v to 5 volt logic converter, from hp calc to stamp; - did not work;
However, I did try an hp 49 to 50 direct serial hookup, with one calculator doing the srecv command, while
the other did the xmit command. They did not communicate. I only used the commands right out of the
command list.( the cat button)
The IOPAR settings on the home directory were identical, and did not conflict.
The calculators did talk via the serial crossover cable, with Xmodem and Kermit protocols, flawlessly.
Based on this, I can not say that the converter was a problem, because the calculators could not talk to
each other, themselves.
I will try to analyze the output of the calculator XMIT command, byteb by byte, or bit by bit.
I wonder if the Srecv command "sees" anything.
anybody got any ideas?
There really is no need to fool around with the ttl 3.3v logic if you have the right cable doing the conversion for you.
And if you really desire to fool with the 3.3v logic and to convert it to 5.0v logic; what are you connecting it to?
In some cases, both the Tx and Rx may require inversion. To get to true RS232 you have to insert a MAX232 or similar chip... just a huge bother when the supplied cable does this for you.
++++++++++
I still haven't gotten the cable I ordered, so I haven't been trying to learn more about the HP50g RS232 port.
:cool: I backed up, and tried something the infrared port when using the Xmit and Srecv commands......and it worked! The setting was in the
transfer selection, in the menu part of the calculator. Letters were sent from calculator to calculator, (hp48gii to 50g)
I will try the serial selection, in the transfer menu. I still think the protocol is either kermit or Xmodem. I will try the Y "tap off" deal that
Loopy Byteloose indicated, to see if the stamp "sees" it, or if a protocol software can detect what protocol it is. I must find a program
that forces it to send data in a UART standard, which would be passed through standard computer serial ports.(in the old days)
Otherwise, a Kermit or Xmodem embedded program is probably of the prescription of the Stamp Doctor.
For what it is worth, it arrived today. So I can now use the HP50 as an RS-232 terminal. There was no way for me to DIY a cable as the plug into the HP50 is nowhere to be gotten in Taiwan.
The main point here is that you can still order the cables from Eric Rechlin in Houston... but you have to be patient. This was put in the mail by him on Mar 22nd.
Time for a loop-back test.. just to make sure all is well.
Your loop-back test will be successful. Since the thread was started, I have done some more experiments. The winmodem protocol is
unavoidable. I have ordered some winmodem software to make sure the data communication is possible. I have also found some IC's
that communicate in Winmodem, and may allow the calculator to "talk" to many devices, outside the intended range. There may be electronic
kits that are avaliable for this purpose, but I have not found them yet.
a prime cause of discontent. I have tried a lot of things, but I know there is an answer!
I have had some success withteh Hp serial and basic stamp communication, BUT, it is not dependable to make a viable device that I can depend on. I find myself wasting time
on troubleshooting communication issues (data collisions, timing, ACK, NAK, etc) I decided to chuck that philosophy and go with something totally new. I feel that Parallax has products
to do this, but I had to backtrack to another product, the beagle bone board. It has the power of a laptop, whilst giving the microcontroller hobbiest the options avaliable from the
stamp. There are some bugs, but the modularity is hard to turn down. The have drivers on-board that automatically convert Xmodem (like hyperterminal) to the Ic2, or serial required by
the basic stamps. Beagle boards are not that expensive, but your labor to use it will be. Open source or windows platform, ON THE BOARD, is avaliable. If parallax had something like
this, I would love it! you could use all the power of basic stamps in the parallax well supported enviroment!!!!
I think this should solve my problem, and now I cna proceed to may my ultimate diagnostic tool!! Yay!
playing with a beagleboard to be the interpreter of the project. Beaglebone black is cool, but is
dependent on free drivers and other programs. If you can find them, hope they work. I just need this
working, then I will find a way to port this to the propeller. I can run a terminal program like
(Loopy was saying) to "talk" to the calculator; I will then get the beaglebone to organize the
data and feed it to the stamp. I will have to set up a bash shell run time program to run the
programs in the background to get it to work. The beaglebone can do the job, (maybe),
but requires ALOT of time downloading, testing, and debugging software, that
may work. Parallax is definitely more friendly to work with, insofar as putting the
whole system together. :cool:
must be able to run the terminal program, itself, and gather data. Please advise.
Heater has provided a list
from another thread;
1) CP/M 2
2) CP/M 3
We are working on:
3) MP/M
4) CUBIX
5) One Man Unix (OMU)
6) Flex.
Undoubtly, other subprograms that anyone may need, could be put on these OS's.
I will attempt to acertain the memory requirements of the terminal program; other
subprograms can be evaluated in this way.