Serial port problem

[amiga_amigo]

Hello all,
i can't seem to get my serial connection with WinUAE 4.4.0 to work as it should - maybe someone can give me hint.
I need to send data to a piece of hardware using the following settings: baudrate 31250, 1 start bit, 8 data bits, parity even, 1 stop bit, no handshaking (not supported by hardware).
Everything works fine on windows but i can't get it to work from within WinUAE.
For debugging i've set up com0com (com1 <=> com2).

WinUAE IO-port settings:
com0com (com1) selected in Serial Port dropdown
Shared - unticked
RTS/CTS - unticked
Direct - unticked
uaeserial.device - unticked

WB serial preferences:
baudrate: 31250
input buffer size: 8192
Handshaking: none
Parity: even
Bits/char: 8
Stop Bits: 1
Applied "Use" and "Save"

echo "hello" >ser:

gives the following ascii output in a terminal on windows connected to com2:

A9,
68='h',
A8,
65='e',
A8,
6C='l',
A8,
6C='l',
A8,
6F='o',
A8,
0A='\n'

Tried various settings, none worked except if i switch to parity 'None'. Unfortunately this is not an option, since this setting is not supported by my hardware ('even', 'odd', 'mark', 'space' - all supported, but 'none' isn't).
What am i doing wrong? Is parity not supported / buggy? Any alternatives? I need to send data to the serial port from within the amiga shell...
Any help appreciated.

Michael

[duga]

What odd hardware are you using that doesn't support parity = none?

[Toni Wilen]

uaeserial.device supports parity. (But probably was never tested..)

Paula serial port emulation can't because Paula serial port parity is Amiga-side serial.device software feature so there is no way for emulator to know if data written to SERDAT is actually 8/9 bits or 7/8+parity bit.

[amiga_amigo]

Thanks Toni,

so if i understand correctly, then sending data with parity is impossible from within WinUAE using serial.device due to this Paula thing?
Maybe using uaeserial.device? I read somewhere, that it's directly connected to PC-side comports (unit == portnumber).
Is it possible to use uaeserial.device from the shell (classic WBs 1.3 ... 3.1)? Is there a "compatible" handler to mount it e.g. as aux or whatever?
I'd like to use shell scripts to compile code and send the ouput via serial to the connected hardware.

Googled quite a bit for uaeserial.device but there's not much information...

Michael

[Toni Wilen]

uaeserial.device unit 0 is first PC port, 1 second and so on. Otherwise it works just like normal serial.device.

But I am not sure if all PC serial ports support 8 + 1 parity bit mode. 7+1 would have worked even with emulated serial.device because there is no hardware level difference between 7+1 and 8+0.

I think there was some way to customize serial device name and unit to AUX handler via extra mount list entries but I don't remember it now. Or just hex edit l:aux-handler

[Rock'n Roll]

I want control the onboard LED on an Arduino over the WinUAE serial port.
But there is anything wrong.

I have the settings 9600,8N1,Handshaking none.
The output from WinUAE to a terminal is ok.

I send
1 or 0 for "1-LED on" and "0-LED off"
I can control the led on or off over the terminal.

But from WinUAE only the 0 "LED off" works.
By the command 1 the LED flashes but remains off.

This are the commands:
>echo >ser:"1"
>echo >ser:"0"
(also possible: echo >ser:"aawedew1ds" any 1 or 0 in this data)

Maybe anyone can check this?

(Test with Arduino Uno and Mega2560 with 9600 or 19200 and com0com)

[Rock'n Roll]

I made some further tests and it works, when I make following:
In my case I have to COM-Ports
COM7: Arduino Mega 2560 (USB to USB)
COM8: USB Serial Port (its an USB to serial TTL cable with open pins)

If I write the serial commands direct to COM7 - there is any problem.
But if I take COM8 with the USB to serial cable and connected it
direct to the pins RXD,TxD and GND on the Arduino board then it works.

I tested with the commands:
SYS:>echo >ser: 0 for LED off
SYS:>echo >ser: 1 for LED on

In my Arduino code I write back the serial data.
if (Serial1.available() > 0) {
incomingByte = Serial1.read();
Serial.println(incomingByte);
...

And in the terminal I get following response for:
SYS:>echo >ser: 0
hex: 0x34, 0x39, 0x0D, 0x0A, 0x31, 0x30, 0x0D, 0x0A
and for
SYS:>echo >ser: 0 noline
hex: 0x34, 0x39, 0x0D, 0x0A, 0x30, 0x0D, 0x0A

Is there a DOS-command for only:
hex: 0x34, 0x39, 0x0D, 0x0A (or only hex: 0x34, 0x39) ?

[Toni Wilen]

I guess it is "echo" that adds the linefeed. (Not that this has anything to do with emulation or OPs problem..). Try for example copying properly formatted text file to SER: instead of using echo.

OP: If you really can't find any other solution, I can add config file option that forces Paula serial port emulation to always use specified parity and number of bits.

[lesta_smsc]

@Toni Wilen - is there anyway to have an LED status for the serial port both Tx/Rx? Just so I know what to expect and can see if I send a command whether it even receives it on the emulation and vice versa?

[amiga_amigo]

Hello Toni,
thanks for coming back to this.

First of all: 'echo' indeed adds a linefeed at the end.
But you can do
echo "Hello" NOLINE >ser:

Back to my problem - i've experimented a bit:
First i checked if uaeserial.device can work with the port settings i need.
I selected 'none' in WinUAE io ports dropdown and ticked 'uaeserial.device'.
Using Term4.8 from Aminet i managed to open the port with correct parameters (verified with the trial version of 'virtual serial ports' from Eltima: It displays the parameters used to open a virtual serial port used in the virtual 0-modem).
Characters are transmitted correctly without errors using uaeserial.device, unit 1. I didn't manage to transmit a binary file though.
Term4.8 uses a Zmodem protocol for 'upload binary file' and using 'upload ascii file' transmits some extra 0x20 characters every now and then - might be some control character replacement.
Nevertheless i think uaeserial.device is able to do what i need.
So i followed your advice and looked at the aux-handler and port-handler in a hex editor.
Both have a reference to serial.device in a string. Changing these strings to 'uaeserial.device' is problematic: the binary file size changes since the new string is 3 chars longer.
I changed the hunk sizes also, but sending data using these "patched" handlers throws error messages. I must have broken something.
Now i googled again and found: you can also specify the device and unit when mounting your own serial port.
I used this mountfile:

uaeser:
EHandler = L: port-handler (without the space after L)
Priority = 5
StackSize = 1000
Device = uaeserial.device
Unit = 1
Flags = 0
Control = "8E1"
Baud = 31250

Mounting this device with 'mount uaeser:' works fine. Transmitting characters works only sort-of:

echo "Hello" >uaeser: gives

"Hello\nHello\n"

It's transmitted twice? - but not each character is repeated but the whole sequence(?)
I also tried to copy a binary file:

copy test.bin to uaeser:

The file is transmitted but transmission aborts after a few (e.g. 49) characters. These few characters are correct though.
I think it's a buffer problem. The port-handler is buffered io. Therfore i tried the same with the aux-handler (unbuffered io). Doesn't work at all.
It seems you can't specify device and unit when mounting your own aux.
Gave up here.
Maybe i need to dig into coding a small utility using the uaeserial.device myself.
I found an example for communicating with a (serial-) device here: https://wiki.amigaos.net/wiki/Serial_Device
Compiling the Simple_Serial.c example gave compiling errors (used a preset gcc setup i found, havn't tried more yet)
Never coded for amiga, so this may take some time...

Adding a configuration option would be awesome. One could use serial.device with settings other than '8N1' then - at least as long as the wb-presets and the configuration on the pc-side match.

Michael

[Tomislav]

You have enabled echo option somewhere...

[amiga_amigo]

Good tip about the echo option, Tomislav!
If i do

set echo OFF
echo "Hello" >uaeser:

i get:
"Hello\n"

:-)
But only sometimes...
:-(
The first three or so invocations of echo are transmitted as should. Then "Hello\n" is again transmitted twice, then occasionally not at all, then only once,...
Again, i think it's a buffer / buffer flush thing.

Also - this doesn't help at all when copying binary data to uaeser:
It's 14 bytes of my testfile that get transmitted, then transmission ends (not hanging - just as if the file ended)

transmitted bytes:
01 12 02 12 0A 01 20 31 02 A9 09 85 0A A9
next bytes would be
01 85 ...

[amiga_amigo]

Ha - Big UPDATE!

got it working.
I compiled my own little tool - my first Amiga C-program - to communicate directly with uaeserial.device.
The example i found earlier was for OS4+ (should have read more carefully).
My tool now works with my hardware, i just need to make it configurable. Parsing argc and argv should be doable though.

I also have an idea why the port-handler didn't work with uaeserial.device and aborted transmission after 14 bytes.
since i had the same phenomenon with my own code:

First, i tried to read the whole file to be transmitted into an allocated buffer (unsigned char*) and then did:

SerialIO->IOSer.io_Command = CMD_WRITE;
SerialIO->IOSer.io_Length = buffersize;
SerialIO->IOSer.io_Data = buffer;

Same result - 14 bytes then end of transmission.
Now i read one byte at a time from file and transmit it:

SerialIO->IOSer.io_Command = CMD_WRITE;
SerialIO->IOSer.io_Length = 1;
SerialIO->IOSer.io_Data = &byte;

works - but certainly slower than reading whole file into a buffer first.

[Toni Wilen]

Does it also hang if there is nothing connected to serial port? (and no handshaking enabled)

[amiga_amigo]

It didn't hang - transmission just stopped and my program ended.
Same with the port-handler. The shell immediately displayed a new line prompt.
So i don't know what to expect if nothing is connected. I could measure execution time to see if more than 14 bytes are transmitted to nirvana?
Haven't checked IOSer.io_Error with my code yet.
Handshaking was always disabled - it's not supported by my hardware.
I will revert my code and do some more testing...

[amiga_amigo]

Something is really odd...

According to serial.h, io_Length is of type ULONG (4 bytes)
And "serial.doc" says:

serial.device/CMD_WRITE

NAME
Write -- send output to serial port

FUNCTION
This command causes a stream of characters to be written out
the serial port. The number of characters is specified in
io_Length, unless -1 is used, in which case output is sent until
a null(0x00) is encountered.

I had io_Length = -1 in the beginning when i tried to send a simple string "Hello World" (which i thought was null-terminated).
What i got was not only my string, but all kind of strings: Message texts from workbench, etc. The transmission simply didn't end.
I thought it was a problem with my string not being properly terminated.
But now, if i use io_Length = -1 for sending my binary data, the program also keeps sending data forever... more bytes than the buffer length... lots of 0x00 also... until Windows crashes hard.
Had to press the power button 4 secs (poor harddisk).
If i use any positive number 1..14 for io_Length, everything is ok.
Any number >14 -> program ends after 14 bytes.
I tried different baudrates and parities, same result.
Added a WaitIO after the write command. I don't know if the write is asynchronous and i don't want to free the buffer memory before data is sent.
Didn't help either - 14 bytes max.
I guess it's time to check uaeserial.device for how it handles io_Length?

[Toni Wilen]

-1 is not handled (I don't know why, I do know that -1 means until zero so I guess I simply forgot when I implemented it..) Will be implemented..

You sure it isn't the device having 14-16 byte hardware buffer and it isn't fast enough to handle more bytes without some extra delays?

uaeserial.device does not have any size limits (It will splits larger than about 4000 byte transfers in smaller pieces but it is only internal feature, caller does not see anything different).

DoIO() is never asynchronous (it waits internally). SendIO() can be async (usually it is) and requites waiting.

Sounds like you have crap serial driver (or USB driver?) that does not like too large transfers if whole system crashed

[amiga_amigo]

Well, should have been more careful with my wording.
It didn't crash with a bluescreen or something.
On a very poor notebook (2 Core Intel Pentium, 4GB Ram, Win10 Home) i had this setup:
WinUAE (A4000, JIT, OS3.1) <=> Com0Com <=> Win10 HTerm
When transmission didn't want to end, WinUAE window first went blank and didn't respond to middlemouse or F12. So i had no windows mousepointer anymore.
Same time windows started swapping ram to HD since traffic went up (notebook HD-LED continuously on).
Couldn't bring up the task manager to kill WinUAE also - usually this means CPU at 100% and/or system too busy with HD.
Waited half a minute then held the power button for hard reset...

Good to hear about the io_Length = -1 issue. Then all this might (at least) help improving this great piece of emulation software a little bit further.
About the 14-16 byte buffer: i actually didn't try with real (FTDI usb serial) port, only com0com and eltima virtual serial ports. Will do...

Meanwhile i added possibility to configure my transmission tool with unit, baudrate and parity.
I must be doing something wrong still. Parity N, E and O work as should. M and S don't. They are set differently (io_ExtFlags instead of io_SerFlags).
There are no errors reported back when sending SDCMD_SETPARAMS, but the port opens at 9600,8N1 always.
Baudrate, databits and stopbits settings are completely ignored as soon as i choose parity S or M...
I know it's possible to use Mark and Space with uaeserial.device - Term4.8 can do it.

[amiga_amigo]

As always - tried 100 things but obviously the wrong ones.
The number of bytes transmitted does indeed change with baudrate.
I always tried baurates <=62500 and had 14 of 13760 bytes transmitted.
With a real comport, transmission seemed to take longer than i'd expect for transferring 14 bytes - different buffer size?
So i tried again using the virtual comports.
Going up with baudrate makes it "better": at 500000 baud (yes you can set this using virtual comports) it's already 799 bytes transmitted - yay!
Extrapolating... i'll need a baudrate of ~8.4 MBaud to transfer my complete 13.4 Kb testfile.
Imagine how fast a serial transfer that will be!
Anyway - as always: Toni is correct. It's a hardware/software buffer overflowing. The higher the rate it gets emptied, the longer it takes to overflow.

Guess, i can live with transferring each byte individually then.

Now i just need to find out, why parity mark and space don't work.
Would it help, if i upload source and binary for someone - with a little more experience in coding for amiga than me - to have a look?

[amiga_amigo]

Ooohh - Forget everything i said about parity mark and space.
I guess it's not supported by uaeserial.device?
Even Term4.8 cannot set it. It claims to do so, but checking with Eltima virtual serial ports it's the same result i get: 9600,8N1
Although it seems, the baudrate set depends on whether you choose settings first and then change to uaeserial.device or the other way round.
Sometimes i get 31250,8N1, sometimes 9600,8N1 (trying to set 31250,8S1).

It's living without mark and space then, until...

EDIT:
It's definitely not supported by uaeserial.device. Just checked the source.
Now i wonder why in my buffer transfer, io_Actual was always zero - looking at the source of "void uaeser_signal (...)" shouldn't it count up?
If only i could get WinUAE to compile from source...
Dreaming...