Sending non-printable ascii characters via serial port

[Jay Hennessy]

Hi all,

Maybe someone can help me with this problem.

I want to send a string to a serial port to control a TMS machine during an EEG experiment. I already know how to send strings using Serial.Write

The problem is that the standards for the TMS machine require the last character of the string to be a check bit. You calculate it by first adding up the hexadecimal equivalents of the other characters then taking the inverse. This is now your check bit or check character added to the end of the string.

example: if i want to send @050

ascii      hex

@     =    40

0       =    30

5       =     35

0       =     30

40+30+35+30 = D5

so the inverse is = 2A

and 2A in hex is * in ascii

so I would send the string @050* and everything should work.

The problem is that if my check bit becomes a non-printable ascii character, how should I send it?

for example my check bit might be 1C in hex which is 'file seperator' in ascii. This isn't a character I can send using Serial.Write in Eprime (at least that I know of).

Can anyone think of a way around this problem?

I might be able to send bits instead of a string. Is sending bits something Serial.Write can do? can eprime convert things to bits?

Any help would be appreciated.

Thanks

jay

[Paul Groot]

Jay,

You can use the WriteBytes function for this:

Dim arrData(4) As Integer

arrData(0) = 40

arrData(1) = 30

arrData(2) = 35

arrData(3) = 30

arrData(4) = &H2A

Serial.WriteBytes arrData

With some additional code you could make a nice function out of this that automatically calculates and adds the checksum value.

Best,

Paul

--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+u...@googlegroups.com.
To post to this group, send email to e-p...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/fb97098b-509e-403b-96a7-909c09c9ef67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jay Hennessy]

Ok thanks Paul,

I had never seen the use of &H to convert from ascii to hexadecimal.

that makes things pretty clear.

J

[Jay Hennessy]

Paul,

So this method would send the binary equivalent of those hex values which represent ascii characters.

Do you know if/how Serial.WriteBytes is different from Serial.Write?

I would assume that either way the information is going to be sent in the form of bytes through the port. Is the protocol for how e-prime sends bytes different for one method vs. the other.

Or is WriteBytes the same as Write except one takes hexadecimal values and one the other takes string values then converts them to bytes?

Any wisdom you could pass on would be much appreciated once again.

Cheers,

J

On Saturday, June 28, 2014 6:54:17 AM UTC-4, Paul Groot wrote:

[Paul Groot]

Well, I'm not sure about the SerialDevice.Write function because that one is not documented (does it really exist?) But you're right, at the end of the story all data is exchanged as sequence of bytes; one byte at the time. (Together with the configured start-, stop and parity bits, but that is completely transparent to the programmer once the device is open for use.) So, PST added a few useful wrapper functions to do the conversion to and from bytes automatically for a few frequently used data types. Those functions make it possible to send and receive text strings, 2 byte integers and 4 byte integers, by calling one of the wrapper functions. On the lower level, this conversion is pretty straightforward because the internal (in-memory) representation of this data is already a sequence of bytes. However, things become confusing for most people when ASCII characters have to be translated to their numerical representation, and vice versa. Especially when the text contains numbers. But that is something you already figured out. (I'm just ignoring multi-byte character sets for the moment, because that's even more challenging.)

A similar thing is true for the way numerical data is represented in E-Basic. A numerical value can be represented by E-Basic in several ways: decimal, hexadecimal, ... It's just the textual presentation in the script that is different; once the value is stored in memory their is no difference in the byte values. The &Hxx syntax is mainly available for our convenience; to make life easier when dealing with binary data. In theory it would have been possible to add support for a binary representation in E-Basic, but unfortunately that is not available. But no matter what the textual representation is, at the end it is just another byte in memory. Regarding this point, you might also have a look at the Asc() and Chr() functions. These functions will convert characters type to numerical type (and back), without changing the value in-memory. This allows you to write Asc("@") instead of &H40 or 64.

Hope this helps to understand the (seemingly) subtle, but important differences.

Paul

To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/36c2a30d-db0a-48b1-8e64-187a18b92292%40googlegroups.com.