Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 07:35 22 Jan 2022 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : PicoMite: serial I/O (from MMB4L)

     Page 2 of 2    
Author Message
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 1044
Posted: 08:15am 06 Jan 2022
Copy link to clipboard 
Print this post

Hi Tom,

Serial port is one of the most ancient communication ports. The parity bits are historically checked in the UART itself (hardware) as it can check other faults.
The UARTS have a status register and interrupt flag register for these faults.

So in essense it is up to the software to service these. The detection happens, but if it is polled, generates an interrupt, and if the interrupt is followed up with action (error message, or NACK back to sender) is under software implementation.

This is different in software UARTS (that we sometimes transparently like to use).
There, the detection may not even happen. The parity bit may simply be seen as a 9'th bit, and discarded.

Peter pointed out he did not implement paritiy checking in picomite.
But you are implementing serial in Linux, and the underlying linux serial port software may throw you an event. And you will have to stub that or expand MMBasic with new functionality (that up to now never has been used...nobody missed it)

Regards,

Volhout
If nothing goes right ... turn left
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 2077
Posted: 09:51am 06 Jan 2022
Copy link to clipboard 
Print this post

Thanks Volhout,

  Volhout said  But you are implementing serial in Linux, and the underlying linux serial port software may throw you an event. And you will have to stub that or expand MMBasic with new functionality (that up to now never has been used...nobody missed it)


It looks like a "standard" mechanism on Linux for where parity checking is enabled (you can include parity bits without checking) is for a byte with a parity error to be received as 3 bytes, 0xFF, 0x00, n, where 'n' is the byte as received (an actual 0xFF is received as 0xFF 0xFF). I think it is also possible to query the device for how many parity errors have occurred, c.f. "checking the status register".

For alpha 3, and going forward until there is someone who actually requests it I will probably leave the parity bit unchecked if that is the existing 'mite "standard". How can I even test it, is is possible to bit bang serial from a 'mite and thus deliberately introduce parity errors?

For the moment I have the PicoMite serial flags implemented: 7BIT, ODD, EVEN, S2, and am now starting to look at adding the receive buffer and interrupt. I'll also include my "best guess" at hardware flow control support, as far as software goes I *think* it's just another flag. XON/XOFF can wait until someone actually needs them and can help me test.

I think I've got a slab of time on Sunday so hopefully I'll be almost there by next week.

Best wishes,

Tom
CMM2 Welcome Tape, Creaky old text adventures
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 5688
Posted: 09:54am 06 Jan 2022
Copy link to clipboard 
Print this post

  Quote  How can I even test it, is is possible to bit bang serial from a 'mite and thus deliberately introduce parity errors?


The PicoMite (and other mites) correctly generate parity on output as specified in the OPEN command. They do no check parity on incoming data. To test your code just set the opposite parity on the PicoMite to that expected by your code - easy  
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 2077
Posted: 10:07am 06 Jan 2022
Copy link to clipboard 
Print this post

Thanks Peter,

  matherp said  The PicoMite (and other mites) correctly generate parity on output as specified in the OPEN command. They do no check parity on incoming data.


Which is what I am in the process of doing for MMB4L alpha 3.

  Quote  To test your code just set the opposite parity on the PicoMite to that expected by your code - easy  


Good point, and a lot simpler than my suggestion .

Best wishes,

Tom
CMM2 Welcome Tape, Creaky old text adventures
 
lizby
Guru

Joined: 17/05/2016
Location: United States
Posts: 1856
Posted: 02:19pm 06 Jan 2022
Copy link to clipboard 
Print this post

  thwill said  XON/XOFF can wait until someone actually needs them and can help me test.


Can't say that I have ever used it in any other circumstance, but trying to refute an assertion that the CMM2 serial was fatally flawed without hardware handshaking, I successfully tested XON/XOFF with a 10 megabyte serial transmission to the CMM2 here.

I think everything you would need to test incoming serial to MMB4L is in that post. Glad to test if that would help.

With a potential multi-gigabyte serial buffer on many possible MMB4L implementations, a real use-case need might never come up.
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 2077
Posted: 02:30pm 06 Jan 2022
Copy link to clipboard 
Print this post

  lizby said  I think everything you would need to test incoming serial to MMB4L is in that post. Glad to test if that would help.


Thanks Lance, at the moment I keep telling myself I need to keep my head down and push alpha 3 out of the door with a "minimal" implementation before running off to hide under the bed.

  Quote  With a potential multi-gigabyte serial buffer on many possible MMB4L implementations, a real use-case need might never come up.


I'll probably need to remove the hard-coded 1 MB "Heap" and 0.5 MB "Program size" limits from MMB4L then - always the plan, just haven't found it necessary yet.

Best wishes,

Tom
Edited 2022-01-07 00:30 by thwill
CMM2 Welcome Tape, Creaky old text adventures
 
Turbo46

Guru

Joined: 24/12/2017
Location: Australia
Posts: 905
Posted: 10:59pm 06 Jan 2022
Copy link to clipboard 
Print this post

For what it's worth, I have had a fair bit of experience with SCADA in my working life. Modern day RTUs (remote terminal units) communicate serially with protection relays, control equipment and other devices to gather data and to control devices.

Of course electro-mechanical relays are still used to control devices such as circuit breakers and digital inputs for alarms and device status indications.

The interfaces were always either full RS232 or RS485. I never came across a device that used 7 bit ASCII or odd or even parity bits. Always 8N1 and always CRCs were used for security.

Various handshake signals were used by various devices but they can easily be taken care of in software and/or cable connections.

I would initially only worry about 8N1 inverted or not and one or two stop bits and worry about the rest later.

I sure someone will now come along and say "But I want to communicate with... and it uses..."

As I said FWIW

Bill
Keep safe. Live long and prosper.
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 2077
Posted: 04:18pm 09 Jan 2022
Copy link to clipboard 
Print this post

Hi folks,

No MMB4L in the following example.

It feels like I've been chasing ghosts all afternoon, but perhaps there is a real issue here.

I've got the PicoMite COM1 hooked up via an FT232 adapter to /dev/ttyUSB0 on Linux - but please don't immediately dismiss it as a Linux problem, is there anyone who can easily test on Windows ?

I'm running this on the PicoMite:
Option Base 0
Option Default None
Option Explicit On

Const MESSAGE$ = "Hello World" + Chr$(152)

transmit()
transmit()

Print "DONE"
End

Sub transmit()
 Print "TRANSMIT to COM1:9600"
 SetPin GP1, GP0, COM1
 Open "COM1:9600" As #1
 Print #1, MESSAGE$
 Print #1, MESSAGE$
 Pause 5000
 Close #1
End Sub


And I'm monitoring what is received on /dev/ttyUSB0.

This is what I'm consistently getting:

00000000  48 65 6c 6c 6f 20 57 6f  72 6c 64 98 0d 0a 48 65  |Hello World...He|
00000010  6c 6c 6f 20 57 6f 72 6c  64 98 0d 0a f8 48 65 6c  |llo World....Hel|
                                               ^^
00000020  6c 6f 20 57 6f 72 6c 64  98 0d 0a 48 65 6c 6c 6f  |lo World...Hello|
00000030  20 57 6f 72 6c 64 98 0d  0a 00                    | World....|
0000003a


"Hello World" + Chr$(152) accounts for 12 bytes:

48 65 6c 6c 6f 20 57 6f 72 6c 64 98


And that is then followed by the two bytes 0d 0a which is carriage-return, line-feed.

So we get that twice and then we get an f8 !!!

And then we get it all again, as expected, and with no f8.

Can anyone explain what the f8 is, and where it it coming from ?

Best wishes,

Tom
Edited 2022-01-10 02:19 by thwill
CMM2 Welcome Tape, Creaky old text adventures
 
PhilHornby

Newbie

Joined: 28/11/2021
Location: United Kingdom
Posts: 1
Posted: 04:48pm 09 Jan 2022
Copy link to clipboard 
Print this post

I'm new to the *mite world - (I'm a Picaxe user, eyeing the Picomite with considerable interest...)

Isn't the 'f8' caused by the "Close #1" statement? (Misinterpreted character caused by the change of line polarity)
 
robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 1891
Posted: 05:12pm 09 Jan 2022
Copy link to clipboard 
Print this post

well, 0xF8 is 11111000, ie a simple pulse. i'm picking that when the comm port is closed a glitch is occurring that just happens to correspond to 0xF8.

aside from monitoring with an oscilloscope, run up GFXterm from a terminal window, and once connected select 'diagnostics' -> 'Rx data to console'. in the console window you will then see the arriving bytes with timestamps. my guess is you'll see the 0xF8 happening 5 seconds after the two print #1... statements. you might like to add a pause 1000 after the close #1 just to make things clearer.


when you close a serial port, the TxD and RxD pins will float. try adding a pullup resistor and see what effect, if any, this has. perhaps when a serial port is closed, the pico should leave a weak pullup in place?


cheers,
rob   :-)
Edited 2022-01-10 03:13 by robert.rozee
 
robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 1891
Posted: 05:15pm 09 Jan 2022
Copy link to clipboard 
Print this post

phil posted his message while i was (slowly!) typing mine. he makes a good point    


cheers,
rob   :-)
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 2077
Posted: 09:52am 10 Jan 2022
Copy link to clipboard 
Print this post

Thanks for the responses, another demonstration that I know little about hardware.

The fact that I first noticed it when receiving data from the PicoMite into MMB4L (but not the other way around) suggests I'm not correctly/completely flushing the buffers when making a new connection on Linux - now that I know it is a real thing and not a figment of my imagination I'll investigate further; it's not simply enough to ignore characters until I read something I'm expecting because the new connection might use 7, 8 or 9 bit characters.

Note that if opening/closing ports multiple times with different parameters seems contrived then it is, it's the result of a test program that tries various combinations of serial speeds and flags.

Thanks again,

Tom
CMM2 Welcome Tape, Creaky old text adventures
 
     Page 2 of 2    
Print this page


To reply to this topic, you need to log in.

© JAQ Software 2022