Serial communications

[cakeisalie5 Profile Website]

Hi! So I've been trying to communicate with my Graph 35+USB using Util Pocket's USB to serial cable and libp7 on GNU/Linux, and writing succeeds, but reading just takes a while (Cable type on the calculator was of course set to 3pin), so I was wondering:
- is the protocol used by the calculator on serial the same as on USB (Protocol 7)? I've been through some legacy docs recently, and in the old protocol(s), the receiving had to be done first...
- the second version of fxReverse's project documentation stipulates that the default speed is 9600 bauds/s, but what are the default number of stop bits (1 or 2) and the default parity (none, odd or even)?

Thanks in advance!

[SimonLothar]

The OSes use no parity and two stop bits.
I use one stop bit, when communicating, because the probability of line faults is very low.
The "no parity"-setting is mandatory.
After I sent the first check packet successfully with 9600 baud I switch over to 115 kBaud.

The protocol with USB and serial is the same.

[cakeisalie5 Profile Website]

Hm, it seems that even with those settings, I can't communicate with the calculator. (it's writing ok, but it is not reading, so I assume what I wrote just disappeared)
Is there other settings to set before being able to do this? (I assume you have been using GetCommState/SetCommState)

[SimonLothar]

Hm, it seems that even with those settings, I can't communicate with the calculator. (it's writing ok, but it is not reading, so I assume what I wrote just disappeared)

Do you have a serial monitor to verify, what you are sending arrives properly? A receiving add-in would do.

Is there other settings to se t before being able to do this? (I assume you have been using GetCommState/SetCommState)

Yes, I use Get-/SetCommState.

[cakeisalie5 Profile Website]

Do you have a serial monitor to verify, what you are sending arrives properly? A receiving add-in would do.

I always forget about the fact that I can use an add-in as a test receiver! I'll be using Serial Monitor. But for what I've seen, bytes do not seem to be written...

Yes, I use Get-/SetCommState.

But do you use special properties in the DCB? Here is my configuration (speed can be P7_B9600 or P7_B19200, parity can be zero or an odd/even number, stop bits can be 1 or 2):

Code: Select all

/* get communication properties */
DCB dcb = {0};
if (!GetCommState(cookie->_handle, &dcb)) {
   logr_warn("Failed getting communication settings, nevermind.");
   return (0);
}

/* set DCB thingies */
dcb.DCBlength = sizeof(dcb);
dcb.BaudRate = (speed == P7_B9600) ? CBR_9600 : CBR_19200;
dcb.fParity = !!parity;
dcb.Parity = !parity ? NOPARITY :
   (parity % 2) ? ODDPARITY : EVENPARITY;
dcb.StopBits = (stopbits == 1) ? ONESTOPBIT : TWOSTOPBITS;

/* save new state */
DWORD wsuccess = SetCommState(cookie->_handle, &dcb);
#if LOGLEVEL <= ll_info
if (!wsuccess)
   logr_warn("Failed setting communication settings, nevermind.");
#endif

(I haven't tested that yet, I'll be doing this when I can)

[SimonLothar]

I use

SetupComm( Handle, $8000, 0 );

SetCommState( Handle, DCB );
with DCB (0x1C, 0x2580, 0x1011, 0, 0x4000, 0x1000, 8, 0, 2, 17, 19, 0, 0, 0, 0) or (0x1C, 0x2580, 0x1011, 0, 0x4000, 0x1000, 8, 0, 0, 17, 19, 0, 0, 0, 0)

SetCommTimeOuts( Handle, CTO );
with CTO (0xFFFFFFFF, 0, 0, 0, 0)

as preparing steps.

[cakeisalie5 Profile Website]

So this is what I've deduced:

Code: Select all

/* set the DCB thingies */
dcb = (DCB){
   .DCBlength = sizeof(dcb),
   .BaudRate = speed,
   .fBinary = 1,
   .fParity = !!parity,
   .fDtrControl = DTR_CONTROL_ENABLE,
   .fRtsControl = RTS_CONTROL_ENABLE,
   .XonLim = 0x4000,
   .XoffLim = 0x1000,
   .ByteSize = 8,
   .Parity = !parity ? NOPARITY : (parity % 2) ? ODDPARITY : EVENPARITY,
   .StopBits = (stopbits == 1) ? ONESTOPBIT : TWOSTOPBITS,
   .XonChar = 17, /* DC1, Device Control 1 */
   .XoffChar = 19, /* DC3, Device Control 3 */
};

(at the end of initialization, before sending the initial packet, this will be called with P7_B900, P7_PARITY_NONE and P7_TWOSTOPBITS)

I'll be trying this in a short amount of time! (EDIT: well in fact, it looks like my calculator's serial port has a problem >< I'll investigate)

[cakeisalie5 Profile Website]

So for some reasons, it worked under Linux (I didn't use the DTR or what), I haven't tested yet under MS-Windows (I'll do this afterwards).
So I'm trying out command 0x01 in a simple communication :
- 0x05 - ACK
- Command 0x01 (get device info) - EACK
- Command 0x02 (set link settings) - ACK
- 0x18 - ACK

Here is my command 0x02 packet (as you can see, I'm just setting the defaults again):

Code: Select all

[libp7 info]  0130 3231 3030 3231 3030 3030 3030 3030 .021002100000000
[libp7 info]  3030 3030 3034 3034 3031 3030 3030 3030 0000040401000000
[libp7 info]  3936 3030 4E4F 4E45 3246 30             9600NONE2F0

The thing is, I have no answer to the final terminate packet, and the calculator stays in Receive mode. So my main questions are:
- should the changes be applied before or after receiving the ACK to command 0x02? (it should logically be afterwards, but with CASIO engineers...)
- is there something special I should do before closing communication? (in order to get a damn answer to this terminate packet)

Thanks in advance!

EDIT: It feels like any next packet after receiving the ACK to the set link command won't receive an answer... :/

[SimonLothar]

After the calculator receives the "set link settings" command it needs some time to open the serial interface again.
I use a delay of 100 ms, after I received the "set link settings" command's ACK-response.

[cakeisalie5 Profile Website]

Inserting the delay works really well, thanks!
Also, fun fact, the calculator resets its serial interface even when the parameters are invalid and it sends a generic error (0x04).

I'll wander about to check what speeds work :p

EDIT: The following speeds seem supported by the calculator: 9600, 19200, 38400, 57600, 115200
And they now are supported by libp7