Is it possible to connect a TI-84 to a Raspberry Pi via the exposed ground, ring, and tip wires so that I can get it recognized by TiLP2? I believe in this thread https://www.cemetech.net/forum/viewtopic.php?p=231487 somebody tried to do something similar.
If the set of GPIO you're targeting can't be configured as a valid UART exposed as such by the OS (which then ought to work with the serial cable, as long as the user running TILP has the appropriate access rights, as usual), the way to get it handled by libticables would be to add a RPi GPIO cable, inspired by the serial cable implementation.
In order to have a more generic cable implementation, there needs to be a way to pass information about the GPIO pins used for the current session, but libticables is currently not very suitable for such use cases. Using ticables_cable_set_device() to pass information about the pins would be an abuse, so for best results, there's probably some new API (which would also be useful for the never implemented TCP cables, anyway) to be invented...
Lionel Debroux wrote:
If the set of GPIO you're targeting can't be configured as a valid UART exposed as such by the OS (which then ought to work with the serial cable, as long as the user running TILP has the appropriate access rights, as usual), the way to get it handled by libticables would be to add a RPi GPIO cable, inspired by the serial cable implementation.
In order to have a more generic cable implementation, there needs to be a way to pass information about the GPIO pins used for the current session, but libticables is currently not very suitable for such use cases. Using ticables_cable_set_device() to pass information about the pins would be an abuse, so for best results, there's probably some new API (which would also be useful for the never implemented TCP cables, anyway) to be invented...


Hello Lionel! I appreciate your reply. Would you know how I would be able to get the GPIO pins I want to be configured that way? I'm not too sure about this. I am currently using a Raspberry Pi Zero W and I did add enable_uart=1 to my OS config.txt as I thought pins 8 and 10 would be the proper pins
Quote:
Would you know how I would be able to get the GPIO pins I want to be configured that way?

I'm afraid not, documentation on the Internet will more helpful than I can be Smile
However, there are some people on this forum who have already used RPis for various purposes.

A couple ideas:
* what is the device name of the UART you're trying to use ? Out of the box, libticables uses /dev/ttyS*, and while libticables supports setting the device using the ticables_cable_set_device() function I mentioned previously, TILP provides no user interface for doing so...
As a workaround, I expect creating a symbolic link (# ln -s <the target device> /dev/ttyS0) to do the job, which is one of the reasons why TILP provides no UI.

* do you use a distro package which defines the udev rules for you, or did you create them manually if you're compiling libti*/gfm/tilp yourself (which I can only recommend) ? Without such rules, your SilverLink cable or direct USB cable won't be usable as an unprivileged user, and running GUI applications as root is usually advised against.
Based on the output of tilp, it says that /dev/ttyS0 is available which is GPIO pins 14 and 15 and where I have the ring/tip cables connected.


Code:
ticables-INFO: 23:40:37.939: Check for tty support:
ticables-INFO: 23:40:37.941:     tty support: available.
ticables-INFO: 23:40:37.946: Check for tty usability:
ticables-INFO: 23:40:37.947:     node /dev/ttyS0: exists
ticables-INFO: 23:40:37.957:     node /dev/ttyS0: accessible
ticables-INFO: 23:40:37.958:     is useable: yes


Despite this there is no output so I'm trying to experiment with some different things. I built everything manually by downloading it from GitHub and using the automatic script.
From a software POV, it sounds like /dev/ttyS0 could work, indeed.

Quote:
I built everything manually by downloading it from GitHub and using the automatic script.

Good, but you didn't specify whether you created the udev rules file according to the information in the CONFIG file mentioned by the script Wink


Code:
cat << 'EOF' > /etc/udev/rules.d/69-libticables.rules
ACTION!="add", GOTO="libticables_end"

# serial device (assume TI calculator)
KERNEL=="ttyS[0-3]", ENV{ID_PDA}="1"
# parallel device (assume TI calculator)
SUBSYSTEM=="ppdev", ENV{ID_PDA}="1"
# SilverLink
SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="e001", ENV{ID_PDA}="1"
# TI-84+ DirectLink
SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="e003", ENV{ID_PDA}="1"
# TI-89 Titanium DirectLink
SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="e004", ENV{ID_PDA}="1"
# TI-84+ SE DirectLink
SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="e008", ENV{ID_PDA}="1"
# TI-Nspire DirectLink
SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="e012", ENV{ID_PDA}="1"
# Lab Cradle / Datatracker Cradle
SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="e01c", ENV{ID_PDA}="1"
# TI-Nspire CX II
SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="e022", ENV{ID_PDA}="1"

LABEL="libticables_end"
EOF
Sorry for the delay in writing back. I added those rules to a file in /etc/udev/rules.d/ with 69-libticables.rules and restarted the Pi, but I have still not had any luck unfortunately.

So far I've done the following:
- Linked /dev/ttyAMA0 to /dev/ttyS1 (ln -s /dev/ttyAMA0 /dev/ttyS1)
- Linked /dev/ttyserial0 to /dev/ttyS2 (ln -s /dev/ttyserial0 /dev/ttyS2)
- Added root to the groups dialout and plugdev

Notes:
-Enabled UART via the enable_uart=1 flag in the Pi's configuration file
- I disabled the serial console (sudo systemctl disable serial-getty@ttyS0.service)
- Plugging in a calculator through the standard mini USB works, but serial does not.
- Output of dmesg | grep tty

Code:

[    0.000000] Kernel command line: coherent_pool=1M bcm2708_fb.fbwidth=1184 bcm2708_fb.fbheight=624 bcm2708_fb.fbswap=1 smsc95xx.macaddr=B8:27:EB:3B:15:AD vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  console=tty1 root=PARTUUID=d9b3f436-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[    0.000294] console [tty1] enabled
[    0.742840] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81, base_baud = 0) is a PL011 rev2
[    2.648244] systemd[1]: Created slice system-getty.slice.


After connecting an Arduino Pro Mini to the same UART lines and running the following Python script, I am able to at least confirm that the UART ports are set up correctly as the script reads what the Arduino sends through Serial.write()


Code:
import serial
neo = serial.Serial(
    port='/dev/ttyUSB0',
    baudrate=9600,
    parity=serial.PARITY_NONE,
    stopbits=serial.STOPBITS_ONE,
    bytesize=serial.EIGHTBITS,
    timeout=1
)
print("connected to: " + neo.portstr)

while True:
    dataline = neo.readline();
    print dataline


Would the Python code above be able to pick up anything if the calculator is connected to the ports and I were running the following TI-Basic program?

Code:

"123"->Str1
Send(Str1)

That doesn't seem to do anything

Theoretically, would I be able to connect through the I/O port with an FTDI breakout and have the calculator recognized on TI Connect on Windows? because that does not work either.
Oh, you're trying to connect the calculator directly, without an adapter (BlackLink / $4 cable).
I didn't make it explicit above in "which then ought to work with the serial cable", sorry... but nope, that's not going to work. The Python script confirmed that your UART is set up correctly, which is good, but it won't pick up anything from the calculator.

On the PHY layer, TI graphing calculators don't use RS232 TTL (5V for the TI-Z80 series, 3.3V for the TI-68k series, and they're interoperable), but their own half-duplex protocol instead. It's described at e.g.
https://raw.githubusercontent.com/debrouxl/tiemu/master/tiemu/trunk/docs/ti_hw/misc/J89hw.txt , which is mirrored at http://tict.ticalc.org/docs/J89hw.txt .

Above the PHY layer, TI is using a specific protocol, for which https://github.com/debrouxl/tilibs/blob/experimental2/libticalcs/trunk/src/dbus_pkt.cc serves as the main modern public implementation.
No worries! I'll try to pick up a Graph Link cable and hopefully it'll work after using that. Just want to say that I'm really grateful for all your help! Smile
BlackLinks are not necessarily cheap, so since you have access to soldering equipment, you might want to build your own "$4 cable", https://www.ticalc.org/hardware/cables/serial.html Smile
That uses far more than three pins, though. Maybe a GreyLink would be better for you, if that uses three pins, and the RPi GPIO doesn't expose all RS232 TTL pins ?

TI's protocol requires direct access to the wires' state, which is why the BlackLink / $4 cable don't work with a number of RS232 (TTL) / USB adapters, and also why a Windows driver - which doesn't work anymore on modern Windows versions - was used. I never integrated Jonimus' code partially because I wasn't able to test it, and in fact, by that time, few other people were.

Back in the day, my BlackLink broke after several years of usage; I then used a $5 cable for several years, before switching to the SilverLink, more usable on modern computers Smile
I'll get all of the parts and give that $4 cable a shot. I guess in the end it doesn't matter what I use as long as it works. Thank you again!
Actually, now that I've looked at the RPi's documentation ( https://www.raspberrypi.org/documentation/usage/gpio/ ), I'm not convinced that either the BlackLink, or even the GreyLink, can work for your purposes...
The GreyLink uses more than three pins as well: https://wiki.tiplanet.org/TI-GraphLink mentions DTR, CTS, RTS, DSR, and some of those are used for powering the GreyLink.

https://www.raspberrypi.org/forums/viewtopic.php?t=160016 seems to indicate that there's no DTR, which is used by both cables.

libticables definitely uses more than 2 bits in the serial I/O code, e.g. https://github.com/debrouxl/tilibs/blob/experimental/libticables/trunk/src/linux/link_ser.c .

So... back to bit-banging on TX / RX, I guess ?
Oh okay. Perhaps I'll just have to figure out a different approach to this.
A SilverLink plugged into the RPI's native USB ports is always an option, but it's quite expensive for such a limited piece of equipment... There's been work on making a SilverLink-compatible Arduino FW, it works but I remember that the transfer rates are lower.

Based on today's research, I now think that as I wrote in my first post, for your purposes, libticables would need a RPi GPIO backend, based on bit-banging GPIOs. Libraries such as pigpio ( http://abyz.me.uk/rpi/pigpio/index.html , https://raspberrypi.stackexchange.com/questions/27488/pigpio-library-example-for-bit-banging-a-uart ) could be valuable information sources for implementing TI's active-low, half-duplex protocol.
  
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
Page 1 of 1
» All times are GMT - 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

 

Advertisement