The BS2 has 32 bytes of actual RAM. The Propeller has 32K in Hubram
The BS2 has half-duplex serial only. The Propeller can do both half and full duplex serial.
Baud rates can be much higher with the Propeller. The Propeller is likely the only choice that will handle HP calculator transmissions and receptions if the protocol is packets and not
character-by-character ASCII.
The BS2 has 32 bytes of actual RAM. The Propeller has 32K in Hubram
The BS2 has half-duplex serial only. The Propeller can do both half and full duplex serial.
Baud rates can be much higher with the Propeller. The Propeller is likely the only choice that will handle HP calculator transmissions and receptions if the protocol is packets and not
character-by-character ASCII.
If the odds are favored with the propeller, then I will use that for the translater. I have already made a substantial investment in the 40 pin stamps. I plan to
use the propeller as the interpreter, to take data from/to calculator, then spoon feed the slave stamps. I would like a quick response time from slave stamps to
calculator. In the real world, delays are inevitable. It is just a matter of delays of system Vs. Field demands.
Nothing will really get done without some good information. I mentioned using a Y-cable and RealTerm to capture what is really going on between the HP50 and a Windows computer.
The link below refers to my idea of a Y-cable as a T-plus. They provide a schematic to build one yourself, or you can order (a bit expensive) from them.
This device just snoops the RX line from one device... nothing else is connected.
My idea of a Y-cable was to have all the lines availabe for monitoring. Not sure which is a better idea.
Download the .zip file with the FREE HP50 Advanced User Reference.
And go to the section on OPENIO to start reading.
You will also need to read several other entries. BUFLEN, CLOSEIO, SBRK, SRECV, STIME, XMIT
With these, you just might be able to send one character at a time. What you receive seems to go into a buffer and you have to move it to the display to read.
Download the .zip file with the FREE HP50 Advanced User Reference.
And go to the section on OPENIO to start reading.
You will also need to read several other entries. BUFLEN, CLOSEIO, SBRK, SRECV, STIME, XMIT
With these, you just might be able to send one character at a time. What you receive seems to go into a buffer and you have to move it to the display to read.
No doubt, you are the authority! I appreciate your help. Looks like it is research time! :frown: I have just tried to use the file I/O in the tools section, to
get something going. I will visit those sites for the information to begin programming. Thanks!
Reading the HP50 Advanced User Reference was quite helpful.
It seems there are 3 modes - Generic serial, Kermit, and Xmodem.
To get to Generic, you start the serial port with OPENIO. At that point, it will receive up to 255 characters that go into a buffer to be unloaded or redirected as the user sees fit. And you can enter characters from the keyboard and send them with an XMIT.
If the baud rate and other settings are not right, the PARIO file needs to be revised to what you want.
I tried an OPENIO and sending a few ASCII characters via XMIT. It seemed to work, but I don't have a cable to set up a destination. A DB9 connector with Pin 2 connected to Pin 3 would allow you to loopback to the HP50 and verify what you send is arriving in the buffer.
There are choices to turn on and off XON/XOFF flow control. I'd keep these off.
I still am not sure how to send 'special Ascii characters', maybe by shifting to a hexadecimal format. For Forth you need the <cr> and <lf>
You could set up a BasicStamp2 to turn on an LED when an 'A' is sent and to turn it off when a 'B' is sent. Then test with the HP50g. If the BasicStamp is sending a Prompt to the receive buffer, it shouldn't matter -- unless you want to make communications conditional on receiving the right Prompt character.
Kermit and Xmodem will take packets, and maybe character-by-character that also allows for special embedded codes. If you want to use these, you will have to learn them.
If you don't want to learn Kermit and Xmodem, use OPENIO. It really is that simple.
Reading the HP50 Advanced User Reference was quite helpful.
It seems there are 3 modes - Generic serial, Kermit, and Xmodem.
To get to Generic, you start the serial port with OPENIO. At that point, it will receive up to 255 characters that go into a buffer to be unloaded or redirected as the user sees fit. And you can enter characters from the keyboard and send them with an XMIT.
If the baud rate and other settings are not right, the PARIO file needs to be revised to what you want.
I tried an OPENIO and sending a few ASCII characters via XMIT. It seemed to work, but I don't have a cable to set up a destination. A DB9 connector with Pin 2 connected to Pin 3 would allow you to loopback to the HP50 and verify what you send is arriving in the buffer.
There are choices to turn on and off XON/XOFF flow control. I'd keep these off.
I still am not sure how to send 'special Ascii characters', maybe by shifting to a hexadecimal format. For Forth you need the <cr> and <lf>
You could set up a BasicStamp2 to turn on an LED when an 'A' is sent and to turn it off when a 'B' is sent. Then test with the HP50g. If the BasicStamp is sending a Prompt to the receive buffer, it shouldn't matter -- unless you want to make communications conditional on receiving the right Prompt character.
Kermit and Xmodem will take packets, and maybe character-by-character that also allows for special embedded codes. If you want to use these, you will have to learn them.
If you don't want to learn Kermit and Xmodem, use OPENIO. It really is that simple.
I was checking out the serial info on the stamp. Timing of the communication will be critical, because replies are looked for in a specific cycle, or
chaos ensues. Looking at the issue, at this time, it seems that the propeller is the solution. When the data transmission gets involved in a dedicated
program that requires timing stability, the propeller can give each device a response to "keep it in the loop", or give it information in the format that
it can handle, and in the amount of data that it can handle. This frees up each device to perform it dedicated function, (calculatior(brain) and bs2p stamp(slave))
gives greater memory to use in brain and slave, and will not impede the brain and slave's dedicated function of the program they are running at the time.
Will allow communication problems to be solved in one device, not split up to consume time in troubleshooting in brain and slave. Thanks again.
Looking at the propeller I and II, both look awesome! The propeller II looks like a ready - made application to go!
The propeller II looks like the device to use, but I don't want to tie it up wth communication chaos. Thanks again!
A. The Propeller 1 is both cheap and available now. The Propeller 2 has not yet been released.
B. I have not seen anyone develop Kermit or Xmodem protocol for the Propeller. So you will either be using generic serial with the HP50g or have to develop one of these.
C. If everything is to be done in real time serial, PropForth or Tachyon Forth both offer multiple serial ports within a Forth interactive environment.
:cool: Thanks! Looks like the propeller I is the device to use. I just tried using the serial and mini-usb from the hp49g to/from hp50g, and
it did not work.:frown: If these devices will not talk to each other, (only through infrared), then I hope programming them directly will "force"
them to talk. And when they do talk, I hope it is consistant. I found a link you indicated, and that site sold infrared to serial adapters.
This might be a generic way to "snoop" on the calculators! Using your y cable techniquie, and the infrared interface from both calculators,
I should be able to capture the true protocol used by the calculators. In case the designers put something "extra" in their calculators program for
job security, I can detect that too.(he, he!) However, when sending data via serial port, will this resemble the "snooped" data?
Thanks again!
:cool: Thanks! Looks like the propeller I is the device to use. I just tried using the serial and mini-usb from the hp49g to/from hp50g, and
it did not work.:frown: If these devices will not talk to each other, (only through infrared), then I hope programming them directly will "force"
them to talk. And when they do talk, I hope it is consistant. I found a link you indicated, and that site sold infrared to serial adapters.
This might be a generic way to "snoop" on the calculators! Using your y cable techniquie, and the infrared interface from both calculators,
I should be able to capture the true protocol used by the calculators. In case the designers put something "extra" in their calculators program for
job security, I can detect that too.(he, he!) However, when sending data via serial port, will this resemble the "snooped" data?
Thanks again!
The reason I would use the infrared, is because I have seen this port work. I hooked up the 50g to my computer with the companies
software, and it did not work. I used their cable, their method, and still did not work. The only data that I can prove works, is clean, and
has correct handshaking/timing, is the infrared. Eventually, I will have to get the serial or usb port to work, but I need a practical base
to build upon. If you have any ideas about port functionality, please advise. Thanks again.
A. The Propeller 1 is both cheap and available now. The Propeller 2 has not yet been released.
B. I have not seen anyone develop Kermit or Xmodem protocol for the Propeller. So you will either be using generic serial with the HP50g or have to develop one of these.
C. If everything is to be done in real time serial, PropForth or Tachyon Forth both offer multiple serial ports within a Forth interactive environment.
:cool:
right on! In reguards to the serial cable, I probably should have used a crossover cable! But, then why didn't the usb cable work? No one ever needs a cross over
cable for the usb. (?) The mini-usb to computer usb, and mini-serial to serial to computer did not work.(?) will try a serial cross over cable to both calculators directly,
and see if that works. Someone on the web had indicated that they tried this, and the serial port blew! (?) micro fuse in-between?
Regarding your USB probem....
The HP50g is NOT a USB Host; it is a USB Client. Your PC has USB Host ports... lots of them. The HP50g was designed to connect to your PC, so it has a USB Client chip inside.
There are two different USB devices with very different requirements( a USB Host and a USB Client), not like RS232 (where both ends can use the same chips)
USB to RS232 adapters require a USB Host.
Regarding your HP50g RS232 to computer problem...
The role of the crossover cable is quite simple - Rx is connected to Tx, and Tx is connected to Rx. If these are Rx to Rx and Tx to Tx; no communication. DIY a crossover, and be sure to include a shared ground Pin 2 to Pin 3, Pin 3 to Pin 2, and Pin 5 to Pin 5.
A 'crossover cable' is also called a null modem... read the link.
Other stuff may cause damage as the USB ports provide +5 and the HP50g serial port provides +6 power with 3.3v logic - one input/one output. Lots of combinations will cause damage if you don't know exactly what you are doing. I'd avoid making my own adapters unless I had an oscilloscope and a good multimeter to research exactly what each line does.
Regarding your USB probem....
The HP50g is NOT a USB Host; it is a USB Client. Your PC has USB Host ports... lots of them. The HP50g was designed to connect to your PC, so it has a USB Client chip inside.
There are two different USB devices with very different requirements( a USB Host and a USB Client), not like RS232 (where both ends can use the same chips)
USB to RS232 adapters require a USB Host.
Regarding your HP50g RS232 to computer problem...
The role of the crossover cable is quite simple - Rx is connected to Tx, and Tx is connected to Rx. If these are Rx to Rx and Tx to Tx; no communication. DIY a crossover, and be sure to include a shared ground Pin 2 to Pin 3, Pin 3 to Pin 2, and Pin 5 to Pin 5.
A 'crossover cable' is also called a null modem... read the link.
Other stuff may cause damage as the USB ports provide +5 and the HP50g serial port provides +6 power with 3.3v logic - one input/one output. Lots of combinations will cause damage if you don't know exactly what you are doing. I'd avoid making my own adapters unless I had an oscilloscope and a good multimeter to research exactly what each line does.
:cool: Awesome info! I did not have a clue about the internals of the usb client and host! I will have to read up on this! Thanks. I will try the serial crossover cable with a 1K resistor, just for
peace of mind. If that impeads, I will reduce the resistance until results (or explosion!) occurs. I can then "snoop", on the data! Save it to my pc- oscilloscope, make sure the data is clean,
and voila! clean data for analyzing! I could take the "snooped" data and feed it into my computer, where I can make a C program to begin pattern - protocol matching. If I can feed it to
a stamp, and clean it up a little bit, maybe that will work. but, still, will need propeller interpreter. Thanks again.
The HP50g has three serial choices --- [a] OPENIO, Kermit, and [c] Xmodem
Kermit and Xmodem are really for connecting to the PC by either the USB, the IR link, or even the RS232 cable. They are not much use with the Propeller and the BS2. They are intended for loading files to the HP50g or sending files to your PC.
Usually, the Propeller or the BS2 doesn't have a file sysem that is compatible with Kermit or Xmodem (maybe someday, but not now).
So focus on learning to use OPENIO.
Once you start OPENIO, you send with XMIT, and recieve with SRECV. Since the RS232 is only a Tx and Rx pair, no extra control lines it is pretty simple.
The HP50g has three serial choices --- [a] OPENIO, Kermit, and [c] Xmodem
Kermit and Xmodem are really for connecting to the PC by either the USB, the IR link, or even the RS232 cable. They are not much use with the Propeller and the BS2. They are intended for loading files to the HP50g or sending files to your PC.
Usually, the Propeller or the BS2 doesn't have a file sysem that is compatible with Kermit or Xmodem (maybe someday, but not now).
So focus on learning to use OPENIO.
Once you start OPENIO, you send with XMIT, and recieve with SRECV. Since the RS232 is only a Tx and Rx pair, no extra control lines it is pretty simple.
:cool: Building upon what you have said, OPENIO seems to be pure rs-232 data protocol, right? That would be a dream come true, because the data train may not be complex.
This will cut down on complexity, and speed up the comm. I was reading some of the HPCalc programs, and there might be help in there for the dedicated serial communication,
visa vi, example programs that actually work. I can use exerpts from those programs, for the calculator, to communicate with the stamp(s). I will still need a propeller, because of
the processing power/resource. an embedded interpreter in the main stamp program will be problematic. I could use a stamp that I have to START an interpreter program, but
will have to modify when I get the propeller. Appreciate your help, You need to change your name to Captain Awesome !
The HP50g has three serial choices --- [a] OPENIO, Kermit, and [c] Xmodem
Kermit and Xmodem are really for connecting to the PC by either the USB, the IR link, or even the RS232 cable. They are not much use with the Propeller and the BS2. They are intended for loading files to the HP50g or sending files to your PC.
Usually, the Propeller or the BS2 doesn't have a file sysem that is compatible with Kermit or Xmodem (maybe someday, but not now).
So focus on learning to use OPENIO.
Once you start OPENIO, you send with XMIT, and recieve with SRECV. Since the RS232 is only a Tx and Rx pair, no extra control lines it is pretty simple.
\
:nerd: I will try this. If I can get the stamp to communicate on a basic level (?), I will sen you and attachment. I am not to shabby on C++ programming. Assembly language, I
do not like. I will not program it with a fox, I will not program it in a box. (do I have too?:frown:) This could be a HP/stamp "sub" language that you and I can create! I appreciate your
help.
Well, there are really two seperate modes of serial tranfer ---- Character by character, and a Block of characters by Block of characters.
I suspect the IR in the HP calculator is IRDA. And that is intended to transfer blocks of data, often with file names. On the other hand, the BasicStamp is very much a character by character device.
Linux has an IRDA project that might help, but it is a lot more complex to do IRDA than it is to do either simple IR remote control or character-by-character transfers. The use of Kermit supports block-by-block data transfers.
If you are developing your own code, starting with character-by-character transfers is best. Later you can learn about blocks as these require more computer resources. I am not sure that anyone has developed IRDA software for the Propeller. It won't work on the BasicStamp.
:cool: We could call the interpreter code, The "Byteloose Stoplight" code! The interpreter will act like a traffic cop, controlling the data "traffic" between the calculator and the Stamp/Propeller.
It has to acknowledge both devices in times when either is in "waiting" mode, keeping them on hold until the other device is freed up to continue traffic. It has to provide data character/files as
each device accepts, via internal design. Thanks.
:cool: Awesome info! I did not have a clue about the internals of the usb client and host! I will have to read up on this! Thanks. I will try the serial crossover cable with a 1K resistor, just for
peace of mind. If that impeads, I will reduce the resistance until results (or explosion!) occurs. I can then "snoop", on the data! Save it to my pc- oscilloscope, make sure the data is clean,
and voila! clean data for analyzing! I could take the "snooped" data and feed it into my computer, where I can make a C program to begin pattern - protocol matching. If I can feed it to
a stamp, and clean it up a little bit, maybe that will work. but, still, will need propeller interpreter. Thanks again.
Good News, Good News! I made a crossover cable, and it works!! It let transfer of information from hp49gii to hp50g from the serial port! Awesome! Now, I need to "snoop" on the
transfer info. Too fast for my pc - oscope. Will have to use the computer with a C program to intercept the data transmission. Will have to amplify, then clip the signal, then feed it
into a line driver or non-inverting chip to go into the computer's serial port. I will have to do this for both coming and going lines. I could send an identical file 2 times, one
to one calc sending, and then one calc recieving. sent in both Kermit and Xmodem, both worked. Will have to try to use OPENIO to see what protocol that is; test against
the recieving calc; recieve in Kermit or Xmodem; if either one is rejected, or both, the protocol of the OPENIO is a standard protocol used, and may be intercepted by a
basic stamp. The file transfer will be limited, but the interpreter overhead will (may) be eliminated. HAPPY DAY! What do you think, Loopy Byteloose?
Good News, Good News! I made a crossover cable, and it works!! It let transfer of information from hp49gii to hp50g from the serial port! Awesome! Now, I need to "snoop" on the
transfer info. Too fast for my pc - oscope. Will have to use the computer with a C program to intercept the data transmission. Will have to amplify, then clip the signal, then feed it
into a line driver or non-inverting chip to go into the computer's serial port. I will have to do this for both coming and going lines. I could send an identical file 2 times, one
to one calc sending, and then one calc recieving. sent in both Kermit and Xmodem, both worked. Will have to try to use OPENIO to see what protocol that is; test against
the recieving calc; recieve in Kermit or Xmodem; if either one is rejected, or both, the protocol of the OPENIO is a standard protocol used, and may be intercepted by a
basic stamp. The file transfer will be limited, but the interpreter overhead will (may) be eliminated. HAPPY DAY! What do you think, Loopy Byteloose?
Well, it seems that you can get the BS2 or the Propeller up and running quite soon. I am happy this turned out so well.
:frown: Finding the protocol, and then the data control is going to be a nightmare. This will be time consuming. I have come up with a problem soving motto;
If there is a pattern, there is a sequence; If there is a sequence, thers is a formula; If there is a formula, there is a family of solutions;
If there is a family of solutions, there exists a singular answer from begining to end, throughout the problem.
Well, it seems that you can get the BS2 or the Propeller up and running quite soon. I am happy this turned out so well.
:cool: info for the RS - 232;
It seems to ba standard byte by byte transmission, with signals sent being defined as start or stop bits -defned as signal bits. If the HP calculator communicates
via some commands by RS-232, then there is hope. In the OPENIO theory, if the calculator is forced to send a byte or bit at the time, the logical assumption is
that the bytes or bit will be sent in that format, irregardless of the Kermit or Xmodem protocol. The forced sent bits or bytes will resemble RS-232, whether the stamp
realizes it or not. Any comments?
Hewlett-Packard seems to like Kermit for managing the HP50g, but it is the most complicated of the 3. It usually uses packets and file transfers. So you need a device with an actual file system (which the BS2 can't have, and the Propeller often doesn't have).
The main use is the USB to PC with provided software for Windows and Apple. And I am guessing that the IRDA link wants to default to Kermit as well. I don't use IRDA much as the distances that it works at are small and many IRDA devices are not well documented (like IRDA on a cellular phone).
Xmodem sends packets of 128 bytes, with markers and a checksum to verify good data. It might be handy with some older devices that demand Xmodem and can't use Kermit. But that is about all. Xmodem might be handy with Linux computers.
If you want or need Xmodem or Kermit, you will just have to study them from the internet. I don't know enough to teach you. With Kermit, you might have to buy a big textbook for the current version 9.0.
~~~~
All of them send 'strings' of 8 bit characters as their usual configuration.
OPENIO doesn't directly support file transfers, packets, or verification.
Historically ASCII started with 7 bits and there may be a way to fudge the HP into receiving and sending 7 bit if you must. BUT, these days almost everything has gone over to 8N1, which is 8 bits, No parity, and 1 stop bit. Stay with that unless you have a reason to use something else. Life will be simpler.
The HP50g has 1200 baud as its slowest rate, so anything slower won't work.
++++++++++
The main thing about OPENIO is there is NO packet, it just send bursts of bytes as long as the message you create. It doesn't include a verification (a checksum), and it doesn't ask to resend packets that failed the verification.
In some cases, you might use special ASCII codes to mark the end of a string. For Forth, it is common to use <CR> and/or <LF>. These don't have a key on the calculator, so you have to enter via their binary code.
<CR> equals decimal 10
<LF> equals decimal 13.
It can be done, but you will have to learn how in the HP50g. If you can use those codes, you can use any ASCII codes and there are a lot of other ones -- all 8 bits long, and actually you can adapt them to 7 bits as they are in the low end of 255 ASCII codes.
But it is really up to you to figure out your own communications scheme. And much depends on how flexible the RS232 device is that you connect to.
If you make odd complicated schemes for your own amusement, you will have to maintain them.
Hewlett-Packard seems to like Kermit for managing the HP50g, but it is the most complicated of the 3. It usually uses packets and file transfers. So you need a device with an actual file system (which the BS2 can't have, and the Propeller often doesn't have).
The main use is the USB to PC with provided software for Windows and Apple. And I am guessing that the IRDA link wants to default to Kermit as well. I don't use IRDA much as the distances that it works at are small and many IRDA devices are not well documented (like IRDA on a cellular phone).
Xmodem sends packets of 128 bytes, with markers and a checksum to verify good data. It might be handy with some older devices that demand Xmodem and can't use Kermit. But that is about all. Xmodem might be handy with Linux computers.
If you want or need Xmodem or Kermit, you will just have to study them from the internet. I don't know enough to teach you. With Kermit, you might have to buy a big textbook for the current version 9.0.
~~~~
All of them send 'strings' of 8 bit characters as their usual configuration.
OPENIO doesn't directly support file transfers, packets, or verification.
Historically ASCII started with 7 bits and there may be a way to fudge the HP into receiving and sending 7 bit if you must. BUT, these days almost everything has gone over to 8N1, which is 8 bits, No parity, and 1 stop bit. Stay with that unless you have a reason to use something else. Life will be simpler.
The HP50g has 1200 baud as its slowest rate, so anything slower won't work.
++++++++++
The main thing about OPENIO is there is NO packet, it just send bursts of bytes as long as the message you create. It doesn't include a verification (a checksum), and it doesn't ask to resend packets that failed the verification.
In some cases, you might use special ASCII codes to mark the end of a string. For Forth, it is common to use <CR> and/or <LF>. These don't have a key on the calculator, so you have to enter via their binary code.
<CR> equals decimal 10
<LF> equals decimal 13.
It can be done, but you will have to learn how in the HP50g. If you can use those codes, you can use any ASCII codes and there are a lot of other ones -- all 8 bits long, and actually you can adapt them to 7 bits as they are in the low end of 255 ASCII codes.
But it is really up to you to figure out your own communications scheme. And much depends on how flexible the RS232 device is that you connect to.
If you make odd complicated schemes for your own amusement, you will have to maintain them.
Affermative. I have looked into the Hp book you suggested, about the protocols. The "true" RS - 232 data, as defined by HP, was made for printers. A protocol is still followed, and
it seems to be Xmodem. All commands used with association of OPENIO are NON- kermit protocols, as defined by the manual. Basic DTE/DCE communication. "Real" numbers and
"real " characters can be sent. Since xmodem is the oldest, with most bugs worked out, and most versitile(because of age), I will attempt to match this to the OPENIO commands.
There may be more info, and less complexity for Xmodem commands. There appears to be a need for an interpreter, no matter what system to use. The interpreter memory
overhead is what I am trying to minimize. I appreciate your help.:nerd:
Affermative. I have looked into the Hp book you suggested, about the protocols. The "true" RS - 232 data, as defined by HP, was made for printers. A protocol is still followed, and
it seems to be Xmodem. All commands used with association of OPENIO are NON- kermit protocols, as defined by the manual. Basic DTE/DCE communication. "Real" numbers and
"real " characters can be sent. Since xmodem is the oldest, with most bugs worked out, and most versitile(because of age), I will attempt to match this to the OPENIO commands.
There may be more info, and less complexity for Xmodem commands. There appears to be a need for an interpreter, no matter what system to use. The interpreter memory
overhead is what I am trying to minimize. I appreciate your help.:nerd:
:cool: The benefits of using Xmodem; interface to any Hp calc, any standard RS - 232 device (printers, accessories, etc,.) and possible other small devices that use the Xmodem
protocol. IF (and I mean IF) Xmodem is the "True" RS - 232, or "The Holy Grail of RS - 232", then the investment in time to write the interpreter in stamp/propeller "ease" is worth it. I will try to
find out shortly, if I can. Any data sent has to have a protocol, or chaos insues. Even if you manage to write your dedicated code, it will be difficult to follow and troubleshoot. Errors may
come up, with garbage data; It may corrupt the application you are trying to develop. This destroys and backs up precious system time, from app to assembly. :frown:
:cool: The benefits of using Xmodem; interface to any Hp calc, any standard RS - 232 device (printers, accessories, etc,.) and possible other small devices that use the Xmodem
protocol. IF (and I mean IF) Xmodem is the "True" RS - 232, or "The Holy Grail of RS - 232", then the investment in time to write the interpreter in stamp/propeller "ease" is worth it. I will try to
find out shortly, if I can. Any data sent has to have a protocol, or chaos insues. Even if you manage to write your dedicated code, it will be difficult to follow and troubleshoot. Errors may
come up, with garbage data; It may corrupt the application you are trying to develop. This destroys and backs up precious system time, from app to assembly. :frown:
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.
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.
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.
I think that there are a lot of misperceptions of what RS232 is that evolved out of its role in history.
It indeed may have been a harward standard and only that, but it was 'the One' for asynchronous serial that tied together teletype machines. ASCII may have started out with 7 bits and Baud rates that were at a snail pace, and control lines to hand shake with devices that were equally slow and somewhat prone to making things harder -- but the Byte-by-Byte format of asychronous transmission has pretty much settled in.
RS485 and RS422 were serious improvements over the RS232 electrical standard on two fronts. First, you didn't need to provide power for +12 and -12; and secondly, noise immunity and distances were vastly improved.
But the PC came along and printers migrated from a teletype era to a computer era with the RS232, not a 'coordinated upgrade' to RS422/RS485. Heck, we all got stuck at some time with a cumbersom Centronics printer cable that had all the wires in parallel. And that was even a worse dinosaur.
By the RS232 ports lingered with modems and dumb terminals. And they are still lingering.
I am very PRO RS422 as I just hate the MAX232 chip with all the extra pins and capacitors when compared to a nice tidy MAX485 or related devices.
And so here we are. HP provided a state of the art calculator with a USB port, an IRDA serial port, and a 3.3v ttl asychronous serial port. But the only cables one seems able to buy are RS232, none are RS422. In fact, HP didn't seem to want to support the ttl asychronous serial port at all. No cable came with the calculator. A few people have gone in and out a business providing cables for it.
++++
But RS232 lingers on and on as being the most visible asynchronous serial to anyone new to electronics. We it seems that regardless of RS422 being far superior in every way, mentors and teachers have to start with RS232 and then try to offer the more enlighted RS422 and RS485.
That is just the way it is.... messy. ... Like most things of this world.
Comments
The BS2 has 32 bytes of actual RAM. The Propeller has 32K in Hubram
The BS2 has half-duplex serial only. The Propeller can do both half and full duplex serial.
Baud rates can be much higher with the Propeller. The Propeller is likely the only choice that will handle HP calculator transmissions and receptions if the protocol is packets and not
character-by-character ASCII.
use the propeller as the interpreter, to take data from/to calculator, then spoon feed the slave stamps. I would like a quick response time from slave stamps to
calculator. In the real world, delays are inevitable. It is just a matter of delays of system Vs. Field demands.
The link below refers to my idea of a Y-cable as a T-plus. They provide a schematic to build one yourself, or you can order (a bit expensive) from them.
This device just snoops the RX line from one device... nothing else is connected.
My idea of a Y-cable was to have all the lines availabe for monitoring. Not sure which is a better idea.
http://airborn.com.au/serial/rs232.html
I also found that while the HP-48 and HP-49 seemed to have had a built in loopback test, the HP-50 does not.
Download the .zip file with the FREE HP50 Advanced User Reference.
And go to the section on OPENIO to start reading.
You will also need to read several other entries. BUFLEN, CLOSEIO, SBRK, SRECV, STIME, XMIT
With these, you just might be able to send one character at a time. What you receive seems to go into a buffer and you have to move it to the display to read.
get something going. I will visit those sites for the information to begin programming. Thanks!
http://h30499.www3.hp.com/t5/Calculators/Using-the-Serial-Port-on-the-HP-50g-Graphing-Calculator/td-p/6040283
Start with the second post and then the google groups link further down the page.
Who knows what was on (or in) the minds of the people that designed that serial port.
The port on the 48sx is quite normal.
Rick
It seems there are 3 modes - Generic serial, Kermit, and Xmodem.
To get to Generic, you start the serial port with OPENIO. At that point, it will receive up to 255 characters that go into a buffer to be unloaded or redirected as the user sees fit. And you can enter characters from the keyboard and send them with an XMIT.
If the baud rate and other settings are not right, the PARIO file needs to be revised to what you want.
I tried an OPENIO and sending a few ASCII characters via XMIT. It seemed to work, but I don't have a cable to set up a destination. A DB9 connector with Pin 2 connected to Pin 3 would allow you to loopback to the HP50 and verify what you send is arriving in the buffer.
There are choices to turn on and off XON/XOFF flow control. I'd keep these off.
I still am not sure how to send 'special Ascii characters', maybe by shifting to a hexadecimal format. For Forth you need the <cr> and <lf>
You could set up a BasicStamp2 to turn on an LED when an 'A' is sent and to turn it off when a 'B' is sent. Then test with the HP50g. If the BasicStamp is sending a Prompt to the receive buffer, it shouldn't matter -- unless you want to make communications conditional on receiving the right Prompt character.
Kermit and Xmodem will take packets, and maybe character-by-character that also allows for special embedded codes. If you want to use these, you will have to learn them.
If you don't want to learn Kermit and Xmodem, use OPENIO. It really is that simple.
I was checking out the serial info on the stamp. Timing of the communication will be critical, because replies are looked for in a specific cycle, or
chaos ensues. Looking at the issue, at this time, it seems that the propeller is the solution. When the data transmission gets involved in a dedicated
program that requires timing stability, the propeller can give each device a response to "keep it in the loop", or give it information in the format that
it can handle, and in the amount of data that it can handle. This frees up each device to perform it dedicated function, (calculatior(brain) and bs2p stamp(slave))
gives greater memory to use in brain and slave, and will not impede the brain and slave's dedicated function of the program they are running at the time.
Will allow communication problems to be solved in one device, not split up to consume time in troubleshooting in brain and slave. Thanks again.
The propeller II looks like the device to use, but I don't want to tie it up wth communication chaos. Thanks again!
A. The Propeller 1 is both cheap and available now. The Propeller 2 has not yet been released.
B. I have not seen anyone develop Kermit or Xmodem protocol for the Propeller. So you will either be using generic serial with the HP50g or have to develop one of these.
C. If everything is to be done in real time serial, PropForth or Tachyon Forth both offer multiple serial ports within a Forth interactive environment.
it did not work.:frown: If these devices will not talk to each other, (only through infrared), then I hope programming them directly will "force"
them to talk. And when they do talk, I hope it is consistant. I found a link you indicated, and that site sold infrared to serial adapters.
This might be a generic way to "snoop" on the calculators! Using your y cable techniquie, and the infrared interface from both calculators,
I should be able to capture the true protocol used by the calculators. In case the designers put something "extra" in their calculators program for
job security, I can detect that too.(he, he!)
Thanks again!
The reason I would use the infrared, is because I have seen this port work. I hooked up the 50g to my computer with the companies
software, and it did not work. I used their cable, their method, and still did not work. The only data that I can prove works, is clean, and
has correct handshaking/timing, is the infrared. Eventually, I will have to get the serial or usb port to work, but I need a practical base
to build upon. If you have any ideas about port functionality, please advise. Thanks again.
:cool:
right on! In reguards to the serial cable, I probably should have used a crossover cable! But, then why didn't the usb cable work? No one ever needs a cross over
cable for the usb. (?) The mini-usb to computer usb, and mini-serial to serial to computer did not work.(?) will try a serial cross over cable to both calculators directly,
and see if that works. Someone on the web had indicated that they tried this, and the serial port blew! (?) micro fuse in-between?
The HP50g is NOT a USB Host; it is a USB Client. Your PC has USB Host ports... lots of them. The HP50g was designed to connect to your PC, so it has a USB Client chip inside.
There are two different USB devices with very different requirements( a USB Host and a USB Client), not like RS232 (where both ends can use the same chips)
USB to RS232 adapters require a USB Host.
Regarding your HP50g RS232 to computer problem...
The role of the crossover cable is quite simple - Rx is connected to Tx, and Tx is connected to Rx. If these are Rx to Rx and Tx to Tx; no communication. DIY a crossover, and be sure to include a shared ground Pin 2 to Pin 3, Pin 3 to Pin 2, and Pin 5 to Pin 5.
A 'crossover cable' is also called a null modem... read the link.
http://www.lammertbies.nl/comm/cable/RS-232.html
Other stuff may cause damage as the USB ports provide +5 and the HP50g serial port provides +6 power with 3.3v logic - one input/one output. Lots of combinations will cause damage if you don't know exactly what you are doing. I'd avoid making my own adapters unless I had an oscilloscope and a good multimeter to research exactly what each line does.
peace of mind. If that impeads, I will reduce the resistance until results (or explosion!) occurs. I can then "snoop", on the data! Save it to my pc- oscilloscope, make sure the data is clean,
and voila! clean data for analyzing! I could take the "snooped" data and feed it into my computer, where I can make a C program to begin pattern - protocol matching. If I can feed it to
a stamp, and clean it up a little bit, maybe that will work. but, still, will need propeller interpreter.
The HP50g has three serial choices --- [a] OPENIO, Kermit, and [c] Xmodem
Kermit and Xmodem are really for connecting to the PC by either the USB, the IR link, or even the RS232 cable. They are not much use with the Propeller and the BS2. They are intended for loading files to the HP50g or sending files to your PC.
Usually, the Propeller or the BS2 doesn't have a file sysem that is compatible with Kermit or Xmodem (maybe someday, but not now).
So focus on learning to use OPENIO.
Once you start OPENIO, you send with XMIT, and recieve with SRECV. Since the RS232 is only a Tx and Rx pair, no extra control lines it is pretty simple.
:cool: Building upon what you have said, OPENIO seems to be pure rs-232 data protocol, right? That would be a dream come true, because the data train may not be complex.
This will cut down on complexity, and speed up the comm. I was reading some of the HPCalc programs, and there might be help in there for the dedicated serial communication,
visa vi, example programs that actually work. I can use exerpts from those programs, for the calculator, to communicate with the stamp(s). I will still need a propeller, because of
the processing power/resource. an embedded interpreter in the main stamp program will be problematic. I could use a stamp that I have to START an interpreter program, but
will have to modify when I get the propeller. Appreciate your help, You need to change your name to Captain Awesome !
:nerd: I will try this. If I can get the stamp to communicate on a basic level (?), I will sen you and attachment. I am not to shabby on C++ programming. Assembly language, I
do not like. I will not program it with a fox, I will not program it in a box. (do I have too?:frown:) This could be a HP/stamp "sub" language that you and I can create! I appreciate your
help.
:cool: We could call the interpreter code, The "Byteloose Stoplight" code! The interpreter will act like a traffic cop, controlling the data "traffic" between the calculator and the Stamp/Propeller.
It has to acknowledge both devices in times when either is in "waiting" mode, keeping them on hold until the other device is freed up to continue traffic. It has to provide data character/files as
each device accepts, via internal design. Thanks.
transfer info. Too fast for my pc - oscope. Will have to use the computer with a C program to intercept the data transmission. Will have to amplify, then clip the signal, then feed it
into a line driver or non-inverting chip to go into the computer's serial port. I will have to do this for both coming and going lines. I could send an identical file 2 times, one
to one calc sending, and then one calc recieving. sent in both Kermit and Xmodem, both worked. Will have to try to use OPENIO to see what protocol that is; test against
the recieving calc; recieve in Kermit or Xmodem; if either one is rejected, or both, the protocol of the OPENIO is a standard protocol used, and may be intercepted by a
basic stamp. The file transfer will be limited, but the interpreter overhead will (may) be eliminated. HAPPY DAY!
Well, it seems that you can get the BS2 or the Propeller up and running quite soon. I am happy this turned out so well.
If there is a pattern, there is a sequence; If there is a sequence, thers is a formula; If there is a formula, there is a family of solutions;
If there is a family of solutions, there exists a singular answer from begining to end, throughout the problem.
:cool: info for the RS - 232;
It seems to ba standard byte by byte transmission, with signals sent being defined as start or stop bits -defned as signal bits. If the HP calculator communicates
via some commands by RS-232, then there is hope. In the OPENIO theory, if the calculator is forced to send a byte or bit at the time, the logical assumption is
that the bytes or bit will be sent in that format, irregardless of the Kermit or Xmodem protocol. The forced sent bits or bytes will resemble RS-232, whether the stamp
realizes it or not. Any comments?
A. OPENIO
B. Xmodem
C. Kermit.
Hewlett-Packard seems to like Kermit for managing the HP50g, but it is the most complicated of the 3. It usually uses packets and file transfers. So you need a device with an actual file system (which the BS2 can't have, and the Propeller often doesn't have).
The main use is the USB to PC with provided software for Windows and Apple. And I am guessing that the IRDA link wants to default to Kermit as well. I don't use IRDA much as the distances that it works at are small and many IRDA devices are not well documented (like IRDA on a cellular phone).
Xmodem sends packets of 128 bytes, with markers and a checksum to verify good data. It might be handy with some older devices that demand Xmodem and can't use Kermit. But that is about all. Xmodem might be handy with Linux computers.
If you want or need Xmodem or Kermit, you will just have to study them from the internet. I don't know enough to teach you. With Kermit, you might have to buy a big textbook for the current version 9.0.
~~~~
All of them send 'strings' of 8 bit characters as their usual configuration.
OPENIO doesn't directly support file transfers, packets, or verification.
Historically ASCII started with 7 bits and there may be a way to fudge the HP into receiving and sending 7 bit if you must. BUT, these days almost everything has gone over to 8N1, which is 8 bits, No parity, and 1 stop bit. Stay with that unless you have a reason to use something else. Life will be simpler.
The HP50g has 1200 baud as its slowest rate, so anything slower won't work.
++++++++++
The main thing about OPENIO is there is NO packet, it just send bursts of bytes as long as the message you create. It doesn't include a verification (a checksum), and it doesn't ask to resend packets that failed the verification.
In some cases, you might use special ASCII codes to mark the end of a string. For Forth, it is common to use <CR> and/or <LF>. These don't have a key on the calculator, so you have to enter via their binary code.
<CR> equals decimal 10
<LF> equals decimal 13.
It can be done, but you will have to learn how in the HP50g. If you can use those codes, you can use any ASCII codes and there are a lot of other ones -- all 8 bits long, and actually you can adapt them to 7 bits as they are in the low end of 255 ASCII codes.
But it is really up to you to figure out your own communications scheme. And much depends on how flexible the RS232 device is that you connect to.
If you make odd complicated schemes for your own amusement, you will have to maintain them.
it seems to be Xmodem. All commands used with association of OPENIO are NON- kermit protocols, as defined by the manual. Basic DTE/DCE communication. "Real" numbers and
"real " characters can be sent. Since xmodem is the oldest, with most bugs worked out, and most versitile(because of age), I will attempt to match this to the OPENIO commands.
There may be more info, and less complexity for Xmodem commands. There appears to be a need for an interpreter, no matter what system to use. The interpreter memory
overhead is what I am trying to minimize. I appreciate your help.:nerd:
:cool: The benefits of using Xmodem; interface to any Hp calc, any standard RS - 232 device (printers, accessories, etc,.) and possible other small devices that use the Xmodem
protocol. IF (and I mean IF) Xmodem is the "True" RS - 232, or "The Holy Grail of RS - 232", then the investment in time to write the interpreter in stamp/propeller "ease" is worth it. I will try to
find out shortly, if I can. Any data sent has to have a protocol, or chaos insues. Even if you manage to write your dedicated code, it will be difficult to follow and troubleshoot. Errors may
come up, with garbage data; It may corrupt the application you are trying to develop. This destroys and backs up precious system time, from app to assembly. :frown:
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.
It indeed may have been a harward standard and only that, but it was 'the One' for asynchronous serial that tied together teletype machines. ASCII may have started out with 7 bits and Baud rates that were at a snail pace, and control lines to hand shake with devices that were equally slow and somewhat prone to making things harder -- but the Byte-by-Byte format of asychronous transmission has pretty much settled in.
RS485 and RS422 were serious improvements over the RS232 electrical standard on two fronts. First, you didn't need to provide power for +12 and -12; and secondly, noise immunity and distances were vastly improved.
But the PC came along and printers migrated from a teletype era to a computer era with the RS232, not a 'coordinated upgrade' to RS422/RS485. Heck, we all got stuck at some time with a cumbersom Centronics printer cable that had all the wires in parallel. And that was even a worse dinosaur.
By the RS232 ports lingered with modems and dumb terminals. And they are still lingering.
I am very PRO RS422 as I just hate the MAX232 chip with all the extra pins and capacitors when compared to a nice tidy MAX485 or related devices.
And so here we are. HP provided a state of the art calculator with a USB port, an IRDA serial port, and a 3.3v ttl asychronous serial port. But the only cables one seems able to buy are RS232, none are RS422. In fact, HP didn't seem to want to support the ttl asychronous serial port at all. No cable came with the calculator. A few people have gone in and out a business providing cables for it.
++++
But RS232 lingers on and on as being the most visible asynchronous serial to anyone new to electronics. We it seems that regardless of RS422 being far superior in every way, mentors and teachers have to start with RS232 and then try to offer the more enlighted RS422 and RS485.
That is just the way it is.... messy. ... Like most things of this world.