 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: NetherlandsPosts: 3509 |
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 PicomiteVGA PETSCII ROBOTS |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3839 |
Thanks Volhout, 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 Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8576 |
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 KingdomPosts: 3839 |
Thanks Peter, Which is what I am in the process of doing for MMB4L alpha 3. Good point, and a lot simpler than my suggestion  .Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3013 |
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. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3839 |
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. 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 Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
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 KingdomPosts: 3839 |
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 Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
PhilHornby Newbie  Joined: 28/11/2021 Location: United KingdomPosts: 2 |
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 ZealandPosts: 2285 |
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 ZealandPosts: 2285 |
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 KingdomPosts: 3839 |
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 Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Page 2 of 2 |
|||||
 Print this page |
