RS232 port state settings

[Ralfo]

Hello gents,
I would like send a datastream with 250 kbaud, 8 databits and 2 stopbits to a serial port COMyx via a common usb-to- RS232 converter in dongle version. Modern computers don´t have COM-ports, you know.
The following port-state-setting function is changing properly only the Baudrate to 250 kBaud. The other parameters are not changed, when I try to change it to another state.
It could be a bug in the comm.ppl???

func term_config
struct(dcb$, DCB);
GetCommState(p$, &dcb$);
dcb.BaudRate$ = term_dcb.BaudRate$;
dcb.ByteSize$ = term_dcb.ByteSize$;
dcb.Parity$ = term_dcb.Parity$;
dcb.StopBits$ = term_dcb.StopBits$;
dcb.fAbortOnError$ = term_dcb.fAbortOnError$;
SetCommState(p$, &dcb$);
return(false);
end;
For that, has anybody tested in own programs the parameter StopBit, ByteSize, Parity?
Maybe with a scope? I am awaiting for response.

[bmanske]

Ralfo,

I take it that "term_dcb" is a global and you have examined the contents to verify the values are all correct? Are you making a second call to GetCommState to compare the resulting values with the originals? Which version of PPL do you have?

Give me a little more info on what you are doing and I will try it out.

Brad

[Ralfo]

Hello Brad,
I have attached a simple test program as zip.
Additionally a *.png schematic with the desired dataformat:
1- 250 KBaud ( change is possible )
2- 8 DataBits ( no change )
3- 2 StopBits ( no change )
4- No Parity. ( no change )
I resume - that I can not change with this program the COMx states 2- 4 (see above) properly with the PPL to PC compilation ( just no test with the PC *.exe ).
I have tested it with diferent PC´s.
The PPL to PPC compilation (for Pockets) is not running correct, too.

A other question is, just I don´t know how I can put out the Break and Mark Sequenz in PPL. In the past I have programmed this for a embedded MCU in C language and it was possible to set the BREAK and MARK states so like as in a assembler language. Maybe give my a tip for that.
Many thanks in advance.
[br]1202851831_746_FT8953_rs232-test-mainprogram.zip

[Ralfo]

Hello Brad and David,
just I have tested the uploaded RS232*.zip program from yesterday in PPC-WM5 format as a RS232-test.exe on the PDA directly with a scope. It is the same as the PC version. No changing from COM port states - only the Baudrate is changeable. In the past I have only changed the baudrates and no states, that the reason why I have not recognized this mistake. I think this is a old bug, nobody has tested it in reality.
I have changed the line number from the Baudrate 1 line below and the Stopbits line at first in the source, too - for the case the port is not ready to accept the next or is hang up. No effect.

The problems with the BREAK-MARK sequenz - I have a idea, maybe I have solved it.

[bmanske]

Very interesting. I never looked at it with a scope because I always use 8-N-1 and I had no reason to believe that it wasn't behaving as specified. I'll look into this.

The problem with BREAK-MARK is interesting also. I thought that since the Hardware Abstraction Layer (HAL) was sitting between the app and the hardware, you couldn't control it directly. I'm also assuming that BREAK-MARK is what I know is MARK-SPACE. Maybe I don't really know what you are trying to do. Could you give me a few more details?

Brad

[Ralfo]

Brad,
I give you right, normally a user needs only the 8-N-1 format. But for special features it is important to have a other format for example 8-N-2 in my case. Before I have posted the apps timing diagram as a *.png file included in the RS232*.zip. It is the USITT-DMX-1990 protocol for contolling lighting and stage applications.
Trifles I will post later.

The HALayer is a problem for BREAK-MARK and you can´t solve that directly with the standard WIN-API features. But in my apps I will try to change the Baudrate to 1000 Baud and send a Byte with 00hex ( I have a "BREAK == LOW" from 10 ms "+" a delay "MARK == HIGH" from 1 ms in the PPL program), then I change the Baudrate to my desired normal Baudrate from 250 kBaud and then I send my data stream. This will cause the effect as I need in detours but it will work. Just theory - but tomorrow I will try it.
What are you thinking about that?

If you need further input, don´t hesitate to ask.

[Ralfo]

Hello Brad,
quote
I take it that "term_dcb" is a global and you have examined the contents to verify the values are all correct? Are you making a second call to GetCommState to compare the resulting values with the originals? Which version of PPL do you have?
Give me a little more info on what you are doing and I will try it out.
Brad
unquote

When you are right with the global, why then the Baudrate is changeable?
I´m using PPL1.42.

[David Chua]

Hi Ralfo,

I've check my term program and found that it works fine anyway, I've modify the program to allow 250000 baud. By the way, you can run the same program on PC as well as PDA or pocketPC and, you should be able to communicate with this test program.

[Ralfo]

Many thanks David,
I have no problems with the baudrates changes in your term program.
It works on PC and on PPC without complaints.
My problem is, I can´t change the 1 stopbit to 2 stopbits.
Under normal circumstances, you can see it with a scope ONLY.
Please check this also, if you have the possibility.

[Ralfo]

Hello Brad,
I have tested the BREAK-MARK sequenz - see above in this thread - it works satisfactory.
Only the time after MARK to put out the first databyte is quite long with about 120 ms in the PIDE interpreter mode. But my standard receiver device is understanding this well nevertheless.
When I have time, I will test it in the .exe version, too.