Unfortunately not, as the CE does not have the I/O port that is used to make this work. If you can find out a way to use the USB port on the CE though, you might be able to get it to work.
In the same vane as deuteriumoxide's previous post, can someone help me with the Arduino code to send a simple integer (0 to 1023 from an analog read) to my TI-83?
Specifically, how do I format the header and body of the onSendAsCBL2 routine to send a single integer (value 0-1023) when I issue a get( command by my TI-83+?
jam lam wrote:
Specifically, how do I format the header and body of the onSendAsCBL2 routine to send a single integer (value 0-1023) when I issue a get( command by my TI-83+?
Oh man, so sorry that it took this long to get an answer to you! You would want something like this.
Code:
#include "CBL2.h"
#include "TIVar.h"
#define MAXDATALEN 255
uint8_t header[16];
uint8_t data[MAXDATALEN];
CBL2 cbl;
const int lineRed = DEFAULT_TIP;
const int lineWhite = DEFAULT_RING;
// Forward declaration of onRequest() and onReceived() functions
int onReceived(uint8_t type, enum Endpoint model, int datalen);
int onRequest(uint8_t type, enum Endpoint model, int* headerlen,
int* datalen, data_callback* data_callback);
void setup() {
Serial.begin(9600);
cbl.setLines(lineRed, lineWhite);
cbl.resetLines();
//cbl.setVerbosity(true, &Serial); // Comment this in for message information
cbl.setupCallbacks(header, data, MAXDATALEN, onReceived, onRequest);
}
void loop() {
cbl.eventLoopTick();
}
int onReceived(uint8_t type, enum Endpoint model, int datalen) {
// do nothing
return 0;
}
int onRequest(uint8_t type, enum Endpoint model, int* headerlen,
int* datalen, data_callback* data_callback)
{
if (type != VarTypes82::VarReal) {
Serial.println("Received request for invalid data type");
return -1; // Can only return a real
}
int val = analogRead(0);
*datalen = TIVar::longToReal8x((long long int)val, data, model);
memset(header, 0, sizeof(header));
TIVar::intToSizeWord(*datalen, header);
header[2] = VarTypes82::VarReal; // Variable type
header[3] = 'A'; // variable A
header[4] = 0x00; // pointless zero termination
*headerlen = 13;
return 0;
}
In fact, you sufficiently inspired me that I just created a new ReadAnalogSingle example showing exactly this.
So, Tuesday night I spent more hours than I was planning to get to the end of a number of issues and pull requests that were pending on ArTICL, succeeding in doing the following:
Let me know if you run into any issues or have questions!
- PR #14: Finally, after a two-year delay, accepted this PR from GitHub user ajcord. I held off in order to test it (and did indeed find some problems, which I later fixed in PR #17 and other commits). It adds a new example, Hello World, which demonstrates how to transfer strings to and from the calculators.
- Patched Interpretation of Variable Headers: The CBL protocol is shockingly inconsistent, especially about how variable headers are formatted. A set of functions has been added to try to standardize headers somewhat, simplifying what sketch writers need to do to interact with ArTICL.
- Closed PR #9: geekboy1011 had an even longer-suffering PR, from October 2015, adding the Whack-a-Mole sketch. Since the sketch had already been added, I incorporated changes I had suggested in that discussion and closed it without merging it.
- Closed several issues: Closed as resolved, stale, or wontfix issues #8, #11, and #12.
- Added ReadAnalogSingle example: See previous post.
Let me know if you run into any issues or have questions!
I have been experimenting with ArTICL and sending key presses to some calculators. I have found problems with the TI-84+SE.
In the Typeletter example, if you change the line in the setup part ' ticl->setVerbosity(true, &Serial);' and set verbosity to false, then the program is massively slowed down. It will only type one single M when no delay is set (the act of continued 'key-presses' keeps it from processing one entirely), and will type one M per second (it's fastest) when the delay of 500ms is still set.
To be clear the TI-84+SE, when verbosity is set to True, seems to be capable of 3 characters to be entered per second, when there is no delay set in the example program.
Why would changing the verbosity affect the speed of the key inputs on a TI-84+SE (TI-83+ is the same) so much?
EDIT: I have been testing this again, and when one of the calcs is operating slow, as described, the serial port is reporting "ERR_READ_ENTER_TIMEOUT = -6" and if I press the next key too quickly "ERR_WRITE_TIMEOUT = -2," errors. It only seems to be affecting the TI-84S +SE now, even the TI-83+ is allowing faster entry.
Is there a way to avoid the -6 error I am getting?
2nd EDIT. It was the cause of all problems on TI-84's. Mathprint! Changing it to Classic instead has sorted it out and things are working at a good speed now.
So that just leaves this part:
The TI-84+CSE allows much faster entry and isn't slowed down by the serial verbosity being false. It takes a very long time though, to give the user control again, when moving the cursor over characters with the up arrow, CLEARing a line, deleting a character or when enter is pressed. Is there any way to avoid that? It turns out that these actions are also reporting "Get returned -6" in the serial debugger. Any ideas on how to make that error less likely to occur?
Is it just that those operations take a little longer? It does seem like they take much longer when pressed by the arduino, than when typed directly into the calculator. Could ArTICL be communicating further with the Calculator after a Get returned -6 error, causing the calculator to take longer than usual to give the user back control?
In the Typeletter example, if you change the line in the setup part ' ticl->setVerbosity(true, &Serial);' and set verbosity to false, then the program is massively slowed down. It will only type one single M when no delay is set (the act of continued 'key-presses' keeps it from processing one entirely), and will type one M per second (it's fastest) when the delay of 500ms is still set.
To be clear the TI-84+SE, when verbosity is set to True, seems to be capable of 3 characters to be entered per second, when there is no delay set in the example program.
Why would changing the verbosity affect the speed of the key inputs on a TI-84+SE (TI-83+ is the same) so much?
EDIT: I have been testing this again, and when one of the calcs is operating slow, as described, the serial port is reporting "ERR_READ_ENTER_TIMEOUT = -6" and if I press the next key too quickly "ERR_WRITE_TIMEOUT = -2," errors. It only seems to be affecting the TI-84S +SE now, even the TI-83+ is allowing faster entry.
Is there a way to avoid the -6 error I am getting?
2nd EDIT. It was the cause of all problems on TI-84's. Mathprint! Changing it to Classic instead has sorted it out and things are working at a good speed now.
So that just leaves this part:
The TI-84+CSE allows much faster entry and isn't slowed down by the serial verbosity being false. It takes a very long time though, to give the user control again, when moving the cursor over characters with the up arrow, CLEARing a line, deleting a character or when enter is pressed. Is there any way to avoid that? It turns out that these actions are also reporting "Get returned -6" in the serial debugger. Any ideas on how to make that error less likely to occur?
Is it just that those operations take a little longer? It does seem like they take much longer when pressed by the arduino, than when typed directly into the calculator. Could ArTICL be communicating further with the Calculator after a Get returned -6 error, causing the calculator to take longer than usual to give the user back control?
You could see the problem behaviour for your self if you use your example Typeletter, and change the letter M 0xA6, to the Enter command 0x05. The constant errors will show in the Serial terminal. This will show on any TI-83 +or 84+, up to CSE.
It sounds like it's not releasing the data lines when it's idle, which could be making the calculator think there are incoming messages to be constantly processed. What does your example program do when no key is being pressed, or are you using the TypeLetter example directly as-is? I expect that it'll error whenever it tries to send an ENTER but the calculator is busy doing something else.
KermMartian wrote:
It sounds like it's not releasing the data lines when it's idle, which could be making the calculator think there are incoming messages to be constantly processed. What does your example program do when no key is being pressed, or are you using the TypeLetter example directly as-is? I expect that it'll error whenever it tries to send an ENTER but the calculator is busy doing something else.
I'm using the typeletter example so that it will be recreatable for anyone.
There is a particular error code -2 that I receive when I try to press a key when the calc is busy.
The error I am getting is -6 though, and this is when the calc is not busy.
Every time enter is pressed when the calc is not busy there is a -6 error. Adjusting typeletter only to use 05 instead of A6 and making the delay 5 seconds will show this. Enter is indeed processed by the calc, but a roughly one second delay in the ability to accept the next calculator means that inout by this method is forced to be much slower that typing on the calc.
This is what the serial monitor shows, it just repeats.
EDIT:
Okay, it seems that something is happening too quickly or soon for the calculator. When I have the typeletter example adjusted to this:
Code:
/*************************************************
* TypeLetter.ino *
* Example from the ArTICL library *
* Created by Christopher Mitchell, *
* 2011-2015, all rights reserved. *
* *
* This demo communicates use the silent- *
* linking commands to type the letter M on a *
* connected calculator. *
*************************************************/
#include "TICL.h"
TICL* ticl;
int lineRed = 2;
int lineWhite = 4;
void setup() {
Serial.begin(9600);
ticl = new TICL(lineRed, lineWhite);
ticl->resetLines();
ticl->setVerbosity(true, &Serial);
}
void loop() {
int rlen = 0;
int rval = 0;
uint8_t header[4] = {COMP83P, KEY, 0x05, 0x00};
rval = ticl->send(header, NULL, 0); // Send KEY message
if (rval != 0) {
Serial.print("Send returned ");
Serial.println(rval);
} else {
// delay(100);
rval = ticl->get(header, NULL, &rlen, 0); // Get ACK
if (rval != 0) {
Serial.print("Get returned ");
Serial.println(rval);
} else {
delay(50);
rval = ticl->get(header, NULL, &rlen, 0); // Get key process notification
if (rval != 0) {
Serial.print("Get returned ");
Serial.println(rval);
}
}
}
delay(5000); // 2 'M's per second
}
Then it works fine and no error is returned, and the user can immediately use the calculator again after the result is displayed. However, if I change verbosity to false (which speeds up all of the inputs to the calculator, or at least the time between sends and gets) then again, it is returning error -6 on the serial monitor.
Verbosity itself is not the answer though, because if I set verbosity to true and change the serial speed to 203400 instead of 9600, then the error persists, again a sign that something is a bit to fast or soon for the calculator.
Does this suggest that there may not be a way to ensure input as fast as on calc typing from a remote source? Is there a way to use a calculator to remotely input to another to test how fast I should expect remote typing to work?
Further EDIT: Using https://www.ticalc.org/archives/files/fileinfo/223/22377.html a remote calculator to calculator, I can see that fast typing, using ENTER, or Scrolling should be possible from a remote source. Does that mean that there is something not exactly right about the way ArTICL communicates remote control data, or rather, the typeletter example?
The asm program I linked to is incredibly simple, obviously it is using calls:
Code:
#include ti83plus.inc
.org usermem-2
.db $BB,$6D
loop
bcall(_getkey)
push af
ld a,$83
bcall(_sendabyte)
ld a,$87
bcall(_sendabyte)
pop af
bcall(_sendabyte)
xor a
bcall(_sendabyte)
ld hl,flags+onflags
bit oninterrupt,(hl)
jr z,loop
res oninterrupt,(hl)
ret
.end
Can that possibly make it clearer how remote control can properly be achieved?
Is it possible to send more than 1 number at a time via ArTICL? I believe SEND() can send a list, could ArTICL send a list out from the calculator?
Yes, ArTICL supports lists. Take a look at the onSendAsCBL2 method in CalcCam.ino example, which responds to a Get(L1) call from the calculator. There's also the parallel onGetAsCBL2 in there for the opposite direction.
- doge
- Newbie (Posts: 1)
- whats the bare minimum needed to send/recieve strings
- 02 Jan 2024 11:19:04 pm
I dont understand how to use the articl library cause im not that experienced with arduino programming
and just c in general, im using a ti 89 titainium.
im trying to use a PIC16LF18425 to decode the ti link protocol and convert it to spi which is gonna
communicate to a seed studio RFM95 to talk 2 another 1 of these units for texting over lora
can i have 2 callbacks, 1 for when the calculator requests data and another for when it sends data.
the only parameters i would need would be 1 for the target variable and another for the string itself if
the calculator and finally just sum simple way to send a string back to the calculator on the request data
callback
pls thx
and just c in general, im using a ti 89 titainium.
im trying to use a PIC16LF18425 to decode the ti link protocol and convert it to spi which is gonna
communicate to a seed studio RFM95 to talk 2 another 1 of these units for texting over lora
can i have 2 callbacks, 1 for when the calculator requests data and another for when it sends data.
the only parameters i would need would be 1 for the target variable and another for the string itself if
the calculator and finally just sum simple way to send a string back to the calculator on the request data
callback
pls thx
Hello guys, anybody here?
I wanted to setup communication between TI-92+/Voyage 200 and Arduino, but I am not succesfull. TypeLetter example is working (except the letter written on LCD is not M, but some weird character), but HelloWorld example don't work. When I type Get(str1) in Voyage 200 or 92+, I got "Error: Link transmission" on calc and "Received request for invalid data type" in Serial monitor.
I read code in TICL.h, CBL2.h, TIVar.h and see that some parts are not finished for TI-92, but it is over my very basic knowledge. Can somebody help me what to change to get it working? Is that even possible?
I wanted to setup communication between TI-92+/Voyage 200 and Arduino, but I am not succesfull. TypeLetter example is working (except the letter written on LCD is not M, but some weird character), but HelloWorld example don't work. When I type Get(str1) in Voyage 200 or 92+, I got "Error: Link transmission" on calc and "Received request for invalid data type" in Serial monitor.
I read code in TICL.h, CBL2.h, TIVar.h and see that some parts are not finished for TI-92, but it is over my very basic knowledge. Can somebody help me what to change to get it working? Is that even possible?
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
» Go to Registration page
» Go to Registration page
» Goto page Previous 1, 2, 3, 4, 5
» View previous topic :: View next topic
» View previous topic :: View next topic
Page 5 of 5
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement