FYI: Regardless of whether you opt for a "proper" MAX232 or not I thought I'd like to share some measurements I have been taking of RS232 signal levels and what does work.
I can definitely tell you that 2V signals at 115.2K baud works into MAX232s etc. Dropping down to 1.8V looks like a threshold here so 3V levels are plenty fine. The same goes for PC serial ports since they have the same "RS232 compliancy" just like the MAX232.
Also take into account that practically nobody tries to run RS232 anymore than a few metres. Anyway the logic level outputs have far lower impedance than the RS232 drivers so they are able to overcome cable capacitance better and are also more immune to noise due to their low impedance drive, not that noise has ever been a problem on RS232 links.
I have ordered both MAX232 and MAX3232 (Added the latter becouse Mike Green told me it wouldnt work, and couldnt cancel the first...)
Mike G:
Thank you for the code, even though my code worked just fine both with the Printer, and also with the serial terminal on the PC (via demoboards USB interface)
DR_Acula:
I do have access to 5v since im hooking this up on my demoboard. And once more, thanks for clarify the pins
Peter:
By this, youre telling me im not experiencing any problem with the voltage levels on using a MAX232 and not MAX3232?
Do you think that the theory about the voltagelevels on the iPaq makes this problem?
(it measures 5-6v on the comm pins)
Firstly this isn't really about MAX232 vs MAX3232 but more about ANY232 vs reality. There is nothing magical about an ANY232 chip plus they are not really compliant anyway. A truly compliant receiver would only switch on + and - thresholds unlike the gamut of "compliant" receivers on the market which switch at the +1.8V threshold only.
But it's not about compliance either.
Right from the early PC days and even before the receivers were this way especially with the once ubiquitous 1488 & 1489 combo, the receiver in these chips was essentially a transistor inverter with the switching threshold around 1.5V and a turn-off threshold of around 1V, yes, 500mv or so of hysteresis, that's all.
I can do that easily with a current limit resistor running straight into a Prop pin with a switching threshold of around 1.5V!!!!! Why, why, why, would I be beguiled by marketing hype when I can do my own calculations. The PC's receivers are all based on these thresholds. Except for the distant early days of PCs and prior nobody wants to make a serial port that doesn't work because a GPS or PDA that just used 0-5V might be plugged in. Whose fault is it if it doesn't work?. It just looks bad and RS232 is not essential or required per se, it's simple asynchronous communications that is essential and required. The small amount of noise immunity of the proper RS232 was lost when receiver thresholds were silently downgraded decades ago. There are much better ways of achieving noise immunity and speed and RS232 will never even be considered for this.
So when it comes to the transmitter side why would I even bother generating a negative voltage which is and proven to be redundant or a higher voltage which is also redundant. It's a case of engineering design (or engineers) gone awry.
I have been over this so many times before and up against the same irrational thinking from people who should know better. I think I will setup a webpage to totally debunk and demystify RS232 and the like. It's not rocket science or black magic and it shouldn't be considered this either. It's not like I don't know what I'm talking about, I can speak with lots of hard and commercial experience on this matter.
Firstly this isn't really about MAX232 vs MAX3232 but more about ANY232 vs reality. There is nothing magical about an ANY232 chip plus they are not really compliant anyway. A truly compliant receiver would only switch on + and - thresholds unlike the gamut of "compliant" receivers on the market which switch at the +1.8V threshold only.
But it's not about compliance either.
Right from the early PC days and even before the receivers were this way especially with the once ubiquitous 1488 & 1489 combo, the receiver in these chips was essentially a transistor inverter with the switching threshold around 1.5V and a turn-off threshold of around 1V, yes, 500mv or so of hysteresis, that's all.
I can do that easily with a current limit resistor running straight into a Prop pin with a switching threshold of around 1.5V!!!!! Why, why, why, would I be beguiled by marketing hype when I can do my own calculations. The PC's receivers are all based on these thresholds. Except for the distant early days of PCs and prior nobody wants to make a serial port that doesn't work because a GPS or PDA that just used 0-5V might be plugged in. Whose fault is it if it doesn't work?. It just looks bad and RS232 is not essential or required per se, it's simple asynchronous communications that is essential and required. The small amount of noise immunity of the proper RS232 was lost when receiver thresholds were silently downgraded decades ago. There are much better ways of achieving noise immunity and speed and RS232 will never even be considered for this.
So when it comes to the transmitter side why would I even bother generating a negative voltage which is and proven to be redundant or a higher voltage which is also redundant. It's a case of engineering design (or engineers) gone awry.
I have been over this so many times before and up against the same irrational thinking from people who should know better. I think I will setup a webpage to totally debunk and demystify RS232 and the like. It's not rocket science or black magic and it shouldn't be considered this either. It's not like I don't know what I'm talking about, I can speak with lots of hard and commercial experience on this matter.
Peter,
Firstly i must say i dont kno who im going to listen to, everyone troughout this thread do tell me different things, and there is really no information out there on wich voltage level the iPaq require. So the only way i can go is to try to make the prop as much as a PC voltagevise, and the pc doesnt base the serialport on 3.3v right?
And since my symptoms are like this:
Loop TXRX on the iPaq it recieves its own communications just fine, this mean that it is ready to recieve.
The code on the prop is not the problem, since it works with both the rs232 printer and also to the parallax serial terminal.
I have tried back and forth with every mode configuration there is, with the same vage result.
I'm trying to work out what you have working and what is not working.
I think you have a loopback test working (just take a female D9 and join pins 2 and 3).
I presume you have a terminal program that works and can test this?
Can you program a propeller chip? If yes, then all your hardware should be ok, and you should not need any max232 or any other chip.
I'm trying to find some code that can do a minimum test. See attached - this is KyeDOS and it is designed for a VGA display but it sends the startup message to a VGA display, to a serial port (and even to a 20x4 LCD). It does expect a SD card, but it will still print an error message if no card is found.
Baud rate is 38400 so set your terminal for that, or change the baud rate in the file KyeDOS.Spin
You know that your Prop code and the iPac loop back works. The only thing left is the interface between the devices. This is where a scope comes in handy.
Load some thing like the code below in the prop and view the output on a scope.
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
DAT
message byte "Hello World",0
OBJ
serial : "FullDuplexSerial"
PUB main
serial.Start(31, 5, 0, 57600)
Toggle(16)
waitcnt(cnt+clkfreq/8)
repeat
serial.tx(1)
Toggle(16)
PUB Toggle(pin)
dira[pin]~~
repeat 2
!outa[pin]
waitcnt(cnt + 5_000)
Run the loop back test using the same Rx/Tx data as above and view the signal on a scope. Take note of the differences. Your interface circuit will need to translate the delta.
Test the different nodes of your circuit to verify the nodes are functioning as expected.
If you do not have a scope, at least your know your code is working. Then it's a matter of tweaking the interface until you get a signal on the iPac. Oh, and replace the Tx data (1) with a character like "A" (0x65). The "1" is for viewing with a scope.
Comments
I can definitely tell you that 2V signals at 115.2K baud works into MAX232s etc. Dropping down to 1.8V looks like a threshold here so 3V levels are plenty fine. The same goes for PC serial ports since they have the same "RS232 compliancy" just like the MAX232.
Also take into account that practically nobody tries to run RS232 anymore than a few metres. Anyway the logic level outputs have far lower impedance than the RS232 drivers so they are able to overcome cable capacitance better and are also more immune to noise due to their low impedance drive, not that noise has ever been a problem on RS232 links.
Thanks very much for all your help.
I have ordered both MAX232 and MAX3232 (Added the latter becouse Mike Green told me it wouldnt work, and couldnt cancel the first...)
Mike G:
Thank you for the code, even though my code worked just fine both with the Printer, and also with the serial terminal on the PC (via demoboards USB interface)
DR_Acula:
I do have access to 5v since im hooking this up on my demoboard. And once more, thanks for clarify the pins
Peter:
By this, youre telling me im not experiencing any problem with the voltage levels on using a MAX232 and not MAX3232?
Do you think that the theory about the voltagelevels on the iPaq makes this problem?
(it measures 5-6v on the comm pins)
But it's not about compliance either.
Right from the early PC days and even before the receivers were this way especially with the once ubiquitous 1488 & 1489 combo, the receiver in these chips was essentially a transistor inverter with the switching threshold around 1.5V and a turn-off threshold of around 1V, yes, 500mv or so of hysteresis, that's all.
I can do that easily with a current limit resistor running straight into a Prop pin with a switching threshold of around 1.5V!!!!! Why, why, why, would I be beguiled by marketing hype when I can do my own calculations. The PC's receivers are all based on these thresholds. Except for the distant early days of PCs and prior nobody wants to make a serial port that doesn't work because a GPS or PDA that just used 0-5V might be plugged in. Whose fault is it if it doesn't work?. It just looks bad and RS232 is not essential or required per se, it's simple asynchronous communications that is essential and required. The small amount of noise immunity of the proper RS232 was lost when receiver thresholds were silently downgraded decades ago. There are much better ways of achieving noise immunity and speed and RS232 will never even be considered for this.
So when it comes to the transmitter side why would I even bother generating a negative voltage which is and proven to be redundant or a higher voltage which is also redundant. It's a case of engineering design (or engineers) gone awry.
I have been over this so many times before and up against the same irrational thinking from people who should know better. I think I will setup a webpage to totally debunk and demystify RS232 and the like. It's not rocket science or black magic and it shouldn't be considered this either. It's not like I don't know what I'm talking about, I can speak with lots of hard and commercial experience on this matter.
Peter,
Firstly i must say i dont kno who im going to listen to, everyone troughout this thread do tell me different things, and there is really no information out there on wich voltage level the iPaq require. So the only way i can go is to try to make the prop as much as a PC voltagevise, and the pc doesnt base the serialport on 3.3v right?
And since my symptoms are like this:
Loop TXRX on the iPaq it recieves its own communications just fine, this mean that it is ready to recieve.
The code on the prop is not the problem, since it works with both the rs232 printer and also to the parallax serial terminal.
I have tried back and forth with every mode configuration there is, with the same vage result.
Were would you put your money on for the fault?
I think you have a loopback test working (just take a female D9 and join pins 2 and 3).
I presume you have a terminal program that works and can test this?
Can you program a propeller chip? If yes, then all your hardware should be ok, and you should not need any max232 or any other chip.
I'm trying to find some code that can do a minimum test. See attached - this is KyeDOS and it is designed for a VGA display but it sends the startup message to a VGA display, to a serial port (and even to a 20x4 LCD). It does expect a SD card, but it will still print an error message if no card is found.
Baud rate is 38400 so set your terminal for that, or change the baud rate in the file KyeDOS.Spin
This sends bytes back up the same programming cable lines, so it will at least test that you can send bytes from the propeller to the PC.
Can you post some photos and code?
Load some thing like the code below in the prop and view the output on a scope.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 DAT message byte "Hello World",0 OBJ serial : "FullDuplexSerial" PUB main serial.Start(31, 5, 0, 57600) Toggle(16) waitcnt(cnt+clkfreq/8) repeat serial.tx(1) Toggle(16) PUB Toggle(pin) dira[pin]~~ repeat 2 !outa[pin] waitcnt(cnt + 5_000)Run the loop back test using the same Rx/Tx data as above and view the signal on a scope. Take note of the differences. Your interface circuit will need to translate the delta.
Test the different nodes of your circuit to verify the nodes are functioning as expected.
If you do not have a scope, at least your know your code is working. Then it's a matter of tweaking the interface until you get a signal on the iPac. Oh, and replace the Tx data (1) with a character like "A" (0x65). The "1" is for viewing with a scope.