Re: [Pharo-project] Mark and space parity
Tony, I *almost* understand that, and greatly appreciate your reply. Compiling a new vm is getting to be routine, mostly because I find its diagnostic output to be far less than I typically want when sorting out a problem. Certainly the Windows vm goes out of its way to fail on valid settings and should be changed to allow parity values 3 and 4; the Linux vm might also benefit from relaxing its checks. The interesting part is that I don't need to send to the device, only read from it. If my notes are correct, it is 7S2. Gary, re programming by barcode, are you thinking that I might be able to get the scanner to use different settings? I wondered about that last night. There is a fairly extensive book full of barcodes that I believe are for changing the scanner's behavior. In your experience, are such changes stored in persistent store (flash, eprom, etc.), or are they transient such that they typically have to be restored each time the scanner loses power? If I can get it to use something friendly to the vm and stay that way, that might be a good solution. Bill ________________________________________ From: Tony Garnock-Jones [tonyg@lshift.net] Sent: Saturday, September 11, 2010 1:44 PM To: The general-purpose Squeak developers list Cc: Schwab,Wilhelm K; vm-dev@lists.squeakfoundation.org; Pharo-project@lists.gforge.inria.fr Subject: Re: [squeak-dev] Mark and space parity Hi Bill, Based on http://www.lothosoft.ch/thomas/libmip/markspaceparity.php, it looks like you're set if you need 7S1. If you need 8S1, however, the options for linux are - flip between 8N1 and 8E1 depending on the byte to send, or - use the undocumented CMSPAR flag. Given that the SerialPort class in Squeak uses 0, 1, 2 for no, even and odd parity respectively, and the sqUnixSerial.c driver doesn't support any other kinds of parity specification (see the table parityTypeDecode), ruling out the use of CMSPAR, your only option (aside from modifying the SerialPlugin or writing your own) is to flip between 8N1 and 8E1 for each byte. Unfortunately it doesn't look like there's a way to get at tcsetattr without also doing an open, so there goes that idea as well. In summary: 7S1 ought to be OK (use 8N1 with a cleared 8th bit), but I suspect that 8S1 is out of reach without changes to the SerialPlugin. Regards, Tony On 11/09/2010 09:42, Schwab,Wilhelm K wrote:
I ran across a device (barcode scanner) that uses space parity and dug into vm code to see if it was indeed going to be a problem. This is not a debate on whether or not the designers of the device could have chosen something else: clearly they should have. The question is whether our vms should be able to communicate with it, and they should where possible.
It is not clear whether Linux even supports space parity, though there are hints that recent kernels do so. Windows certainly does support it. Have any of you made the required changes and had success with it? On which operating system(s)?
Bill
Generally, settings are stored in flash and changes should be permanent. Though we have had the odd Datalogic unit that tends to suffer from amnesia! Regards, Gary Sent from my iPad On 11 Sep 2010, at 19:25, "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> wrote:
Tony, I *almost* understand that, and greatly appreciate your reply. Compiling a new vm is getting to be routine, mostly because I find its diagnostic output to be far less than I typically want when sorting out a problem. Certainly the Windows vm goes out of its way to fail on valid settings and should be changed to allow parity values 3 and 4; the Linux vm might also benefit from relaxing its checks.
The interesting part is that I don't need to send to the device, only read from it. If my notes are correct, it is 7S2.
Gary, re programming by barcode, are you thinking that I might be able to get the scanner to use different settings? I wondered about that last night. There is a fairly extensive book full of barcodes that I believe are for changing the scanner's behavior. In your experience, are such changes stored in persistent store (flash, eprom, etc.), or are they transient such that they typically have to be restored each time the scanner loses power? If I can get it to use something friendly to the vm and stay that way, that might be a good solution.
Bill
________________________________________ From: Tony Garnock-Jones [tonyg@lshift.net] Sent: Saturday, September 11, 2010 1:44 PM To: The general-purpose Squeak developers list Cc: Schwab,Wilhelm K; vm-dev@lists.squeakfoundation.org; Pharo-project@lists.gforge.inria.fr Subject: Re: [squeak-dev] Mark and space parity
Hi Bill,
Based on http://www.lothosoft.ch/thomas/libmip/markspaceparity.php, it looks like you're set if you need 7S1. If you need 8S1, however, the options for linux are
- flip between 8N1 and 8E1 depending on the byte to send, or - use the undocumented CMSPAR flag.
Given that the SerialPort class in Squeak uses 0, 1, 2 for no, even and odd parity respectively, and the sqUnixSerial.c driver doesn't support any other kinds of parity specification (see the table parityTypeDecode), ruling out the use of CMSPAR, your only option (aside from modifying the SerialPlugin or writing your own) is to flip between 8N1 and 8E1 for each byte. Unfortunately it doesn't look like there's a way to get at tcsetattr without also doing an open, so there goes that idea as well.
In summary: 7S1 ought to be OK (use 8N1 with a cleared 8th bit), but I suspect that 8S1 is out of reach without changes to the SerialPlugin.
Regards, Tony
On 11/09/2010 09:42, Schwab,Wilhelm K wrote:
I ran across a device (barcode scanner) that uses space parity and dug into vm code to see if it was indeed going to be a problem. This is not a debate on whether or not the designers of the device could have chosen something else: clearly they should have. The question is whether our vms should be able to communicate with it, and they should where possible.
It is not clear whether Linux even supports space parity, though there are hints that recent kernels do so. Windows certainly does support it. Have any of you made the required changes and had success with it? On which operating system(s)?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks to all who replied. I will try reprogramming the reader to 8n1 and see if that sticks. I still think there is room for the vm to be less aggressive in failing over valid parity values, certainly on Windows now and perhaps on Linux either now or in the future (once support for mark and space becomes wide spread, which I suspect will eventually happen). If Microsoft figured out how to deal with something, we should be able to do at least as well :) Bill
participants (2)
-
Gary Chambers -
Schwab,Wilhelm K