Jump to content
IGNORED

TIPI - TI-99/4A to Raspberry PI interface development


Recommended Posts

On 11/9/2022 at 2:56 PM, RickyDean said:

 

I don't think the legacy 'wiringPi' c library works with this translation layer, as I believe it programs to the bmc memory addresses directly.

 

But this tool and library might make an update toward portability much easier. I'll check it out. 

 

Last week I started writing a tipi_gpio kernel module that exposes a few character devices in linux /dev/tipi_control  /dev/tipi_data, that implement my funky communication model using the linux/gpio.h kernel support. This will allow me to make it so the 'tipi' user can access these, and the python c library (that abstracts the websock vs gpio) can delegate to these character devices for reading and writing to the various tipi mailbox's/registers...  

 

Layers do tend to slow things down. But a pin mapping layer shouldn't be too slow. I am a little skeptical of libgpiod though, because from what I've heard and read it seems to be limited to ~70khz gpio manipulation.  

  • Like 1
Link to comment
Share on other sites

Hey Matt,

 

Just wanted you to know I finally got things figured out with MyArt on the Geneve working with the TIPI Mouse.  Geneve users will see the Myart/TIPI Mouse update on the next release of MDOS.

 

Somewhere along my initial code changes from a bus mouse to the tipi mouse, I must have modified a line of code causing the TIPI XOP opcode for the mouse response, to not  be interpreted correctly with the rest of the MyArt code.  When i went back and started over with what I was trying to do, I then got mouse movement working.

 

I finally got the appropriate button response after resolving another separate issue.  The Geneve has three buttons, two of which are tied to the 9938.  The third button status is grabbed from bit 24 with a TB test.  In MyArt, this button was being scanned in a separate loop from the mouse position code or other button status calls.  However, in the TIPI mouse protocol, screen position and button status is all returned in one call.  That is not a problem, however the way MyArt was written, each call to the TIPI to get either position or either of the two button status responses, resulted in a report of delta X and delta Y for each call being ignored for two of the three calls.  Thus, the mouse moved slower by over 1/3rd of what it should have been.

 

There is so limited use of the mouse in other software, this probably does not matter.  However, I thought if someone were to try to modify some other Geneve mouse code, I would point this out here.

 

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

@jedimatt42

 

Matt, I am looking at the UDP protocol I copied from your wiki page.  I am looking at adding the UDP protocol to the MDOS TIPI XOP.

 

My first question, and it more for just understanding, is why the message string length is "message length - 1" and not "message length" ?  Just seemed a bit odd.  I want to confirm there was no typo, etc.

 

My second question deals with the 0x04 Read command.  I highlighted I think is a typo, with a 2K message length of 0x08 0x00 for the length instead of 0x02 0x00.  

 

Finally, do you or does anyone else know of somewhere I can open/read/write/close a UDP socket so I can test my routines?

 

Thanks.

 

=================================

 

UDP Extension

Represent socket access from Raw extensions. This is registered as 0x23 in RawExtensions.py

Usage

Client Socket Commands

command Message format Errors
open 0x23 + handle-byte + 0x01 + "hostname:port" 0 : failed to connect
close 0x23 + handle-byte + 0x02 n/a
write 0x23 + handle-byte + 0x03 + [ data array ] 0 : failed to write
read 0x23 + handle-byte + 0x04 + size-msb + size-lsb n/a

Send a message starting with 0x23 as the first byte. The second byte should be socket handle number to use. The third byte is the command to process, followed by command specific arguments.

Client Sockets

Socket handle numbers are a single byte 0-255, assigned arbitrarily by the TI code when it passes the value in the open command.

For command 0x01 open / follow with string in the form of "hostname:port". Tipi will return a message of 255 if connected or 0 if failed to connect. The string will be assumed to be the message length - 1. To connect as handle 0x00 to server.com port 9999 the message bytes could be:

0x23 0x00 0x01 's' 'e' 'r' 'v' 'e' 'r' '.' 'c' 'o' 'm' ':' '9' '9' '9' '9'

 

For command 0x02 close / no parameters. Tipi will return 255. To close socket with handle 0x00:

0x23 0x00 0x02

 

For command 0x03 write / follow with bytes to write to socket. Tipi will return after bytes are written with 255 or 0 if failed to write. To write "HELLO" to socket with handle 0x00:

0x23 0x00 0x03 'H' 'E' 'L' 'L' 'O'

 

For 0x04 read / follow with max size to read as int (two bytes, [msb,lsb]). Tipi will return message of read socket data no greater than max size. It may read from 0 to max size. This depends on the available bytes in the socket buffer on the Raspberry PI's TCP stack. Reading 0 bytes does not indicate that the there is no more data, just that it hasn't been buffered yet. Use higher-level protocols to determine completeness. TIPI returns a 0 length array if the socket is not open. To request reading up to 2k from the socket with handle 0x00:

0x23 0x00 0x04 0x02 0x00  Should this be 0x08 0x00 ?

Link to comment
Share on other sites

2 hours ago, 9640News said:

OK, got a question about the UDP extension.  When sending a string, is just a few bytes (< 10) the common thing, or would it be necessary to send a string much longer due to the application?

 

Beery

UDP is usually good for self contained small packets of data. Small isn't a problem, bigger than an Ethernet packet is a problem.  Less than 10 bytes should be fine.

Link to comment
Share on other sites

14 hours ago, jedimatt42 said:

UDP is usually good for self contained small packets of data. Small isn't a problem, bigger than an Ethernet packet is a problem.  Less than 10 bytes should be fine.

My concern here is with something that may be fragments passing that are too small.

 

I had an issue with the TCP socket telnet protocol sending the ANSI UP/DOWN/LEFT/RIGHT/PG-UP/PG-DN sequence a byte at a time.  If in the messaging system, I sent a byte at a time, the BBS I was sending them too did not understand the sequence.  Rather, if I sent the sequence as a whole block with one call of the message system, then there was no issue.

 

And since I was implementing UDP in the TIPI XOP, I was concerned if a fragmented block for a potential midi device may suffer similarly.

 

Beery

 

  • Like 1
Link to comment
Share on other sites

1 hour ago, jedimatt42 said:

With UDP, you should not fragment the data. You should send a unit of data that can be received and processed independently. 

 

For midi, with mt32-pi, this must be a complete midi event - you will not get away with patching rs232 software by sending 1 byte at a time. 

Ok. Thanks for the feedback. I have begun writing  code to handle an 8K block unless you think a larger block is required. 

  • Like 1
Link to comment
Share on other sites

  • 1 month later...
On 11/9/2022 at 2:56 PM, RickyDean said:

I've looked at the technology being used here, and have dug in to write a kernel module that uses a device-tree overlay to designate the gpiochip and pins to use. The kernel-module should be compatible ( at least compile compatible ) with most SBC linux kernels since 4.8 ( so anything newer than a few years ago LOL ) and all that is needed to work on different boards is loading a different device-tree overlay file. I've got this working, as a base, on raspbian-bullseye. With a little time off this weekend, I should be able to give it a go on the Le Potato / Armbian or Ubuntu-Server builds that are available. 

 

This isn't TIPI working yet, but the tipi python native C library can send and receive bytes from the 2 character devices via file io that and should maintain pretty good speed. The kernel module is still sending bits at about 1.3Mhz, where the libgpiod would have slowed that down to 50Khz from what I've read. That's bit transfer rate. Byte transfer rate looks like it is 60Khz, and then the tipi protocol of mailboxes requires 3 byte transfers per data byte, so a theoretical rate of 20K bytes a second. Hopefully when connected to the entire TIPI python suite, I'll still be getting the 7K bytes a second transfer rate we currently enjoy.

 

I will also be able to set the permissions on the character devices created by the kernel module, so that the python library can continue to run as the 'tipi' user without needing some privilege escalation. 

 

In the below image, I'm using 'cat /dev/tipi_data' and the mailbox in the CPLD is set to hold the 'Z' character ( 0x5A ) so that if they have bit problems, it's stand out on the screen. There are 10 clocks for every byte, the first coincides with latching the data into the shift-register, and then I shift out 8 data bits and a parity bit. Then there is a gap while we are back in the 'cat' program as it displays a byte, and then returns to get the next one.

 

Tipi-DSO-LE-CLK-read.thumb.png.6126cd3a4ee30d28a640a6ce1f0998d9.png

 

Anyway, @RickyDean this was a very useful tip. Thanks!

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

  • 3 weeks later...
On 12/29/2022 at 9:22 PM, jedimatt42 said:

I've looked at the technology being used here, and have dug in to write a kernel module that uses a device-tree overlay to designate the gpiochip and pins to use. The kernel-module should be compatible ( at least compile compatible ) with most SBC linux kernels since 4.8 ( so anything newer than a few years ago LOL ) and all that is needed to work on different boards is loading a different device-tree overlay file. I've got this working, as a base, on raspbian-bullseye. With a little time off this weekend, I should be able to give it a go on the Le Potato / Armbian or Ubuntu-Server builds that are available. 

 

This isn't TIPI working yet, but the tipi python native C library can send and receive bytes from the 2 character devices via file io that and should maintain pretty good speed. The kernel module is still sending bits at about 1.3Mhz, where the libgpiod would have slowed that down to 50Khz from what I've read. That's bit transfer rate. Byte transfer rate looks like it is 60Khz, and then the tipi protocol of mailboxes requires 3 byte transfers per data byte, so a theoretical rate of 20K bytes a second. Hopefully when connected to the entire TIPI python suite, I'll still be getting the 7K bytes a second transfer rate we currently enjoy.

 

I will also be able to set the permissions on the character devices created by the kernel module, so that the python library can continue to run as the 'tipi' user without needing some privilege escalation. 

 

In the below image, I'm using 'cat /dev/tipi_data' and the mailbox in the CPLD is set to hold the 'Z' character ( 0x5A ) so that if they have bit problems, it's stand out on the screen. There are 10 clocks for every byte, the first coincides with latching the data into the shift-register, and then I shift out 8 data bits and a parity bit. Then there is a gap while we are back in the 'cat' program as it displays a byte, and then returns to get the next one.

 

Tipi-DSO-LE-CLK-read.thumb.png.6126cd3a4ee30d28a640a6ce1f0998d9.png

 

Anyway, @RickyDean this was a very useful tip. Thanks!

Bumping this.  I'm hoping this works out, since pi stuff is unobtainium.

Link to comment
Share on other sites

My goal is to release something after the unobtainable status of the PIs is no longer relevant. (Just kidding 😂)

 

I have it fully working on a Raspberry PI 3b+ with Raspberry PI OS - Bullseye edition. So no more dependency on the defunct WiringPI library. Feels like the mouse has more lag than I remember, but I plan to make an SD image for bullseye soon and release it as TIPI 3.0 (beta)... There will be no automated upgrade from TIPI 2.x to 3.0. It'll be back up yer stuff, and restore it on a fresh sd card image.

 

I'm struggling with the Libre Computers Le Potato adaption. But I've been out of town for a week, and busy getting ready to go out of town the week before, and last weekend was recovering from being out of town for a week. I think I have a device tree file that is testable. I think that if I install that file as well as the PI device tree file with their compatibility statements, then only the correct one will be active during boot. And then maybe their little pi OS conversion tool will do all the correct things. 

 

We'll see... eventually, when I have time to focus.

  • Like 4
Link to comment
Share on other sites

Here is a Raspberry PI OS Bullseye SD image : https://jedimatt42.com/downloads/tipi-sdimage-bullseye-3.0.zip

 

I consider this 'beta', but I make it available here if anyone else wants to try it out. 

 

Not much in the TIPI services have changed. 

 

The base OS is different, along with it, the version of python is 3.9.x. 

The libtipi_gpio library has been replaced with libtipi_chardev which communicates via my kernel module : https://github.com/jedimatt42/tipi_kernel_module

Tiny change to the web UI, due to upstream dependency changes. 

Small tweak to the polling loops in libtipi to reduce cpu load when idle.

 

I still plan to do a lot of testing. 

 

OH, per Bullseye standards, there is no longer a 'pi' user. Just the 'tipi' user...

 

 

  • Like 3
Link to comment
Share on other sites

20 hours ago, jedimatt42 said:

Here is a Raspberry PI OS Bullseye SD image : https://jedimatt42.com/downloads/tipi-sdimage-bullseye-3.0.zip

 

Does not work with PI Zero W -- hopefully I just have to tweak the device tree overlay to declare compatibility with that chip.

I would not expect it to work on a PI4 either then... until I fix the compatibility statements.

 

Link to comment
Share on other sites

44 minutes ago, jedimatt42 said:

 

Does not work with PI Zero W -- hopefully I just have to tweak the device tree overlay to declare compatibility with that chip.

I would not expect it to work on a PI4 either then... until I fix the compatibility statements.

 

Ok, after simply re-compiling the kernel module and re-installing it, it works on the PI-Zero-W ... the device tree compatibility flags for the PIZeroW and the PI3 are the same, but it looks like the actual kernel used on boot differs based on the board detected.

 

I guess I'll have to figure out how to rebuild on boot if necessary. ( and/or DKMS if the kernel updates ) 

  • Like 1
Link to comment
Share on other sites

1 hour ago, WhataKowinkydink said:

Will any Pi do for the TIPI, or is there a 'best one' for the job?

https://github.com/jedimatt42/tipi/wiki/Which-PI

 

The TIPI software does not require many resources from the PI. The CPU is mostly idle. Everything is designed for asynchronous timing. The PI controls the clock when sending or fetching data from the TIPI board. 

 

However, most upgrade problems that have been reported to me come from the slower PI's like the PI Zero W ( before the 2W ) when paired with poor network connections failing while fetching upstream resources mid update. 

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

On 1/22/2023 at 3:44 PM, jedimatt42 said:

Ok, after simply re-compiling the kernel module and re-installing it, it works on the PI-Zero-W ... the device tree compatibility flags for the PIZeroW and the PI3 are the same, but it looks like the actual kernel used on boot differs based on the board detected.

 

I guess I'll have to figure out how to rebuild on boot if necessary. ( and/or DKMS if the kernel updates ) 

I opted to let my tipiboot.service rebuild install and load the kernel module if it wasn't already loaded at boot. 

 

So now I've tested TIPI 3.0 on PI Zero W, PI Zero 2(W), PI 3B+, and PI 4B. 

 

Tomorrow's plan will be to update and replace that TIPI 3.0 image I shared. And then back to trying to get the Le Potato to co-operate

  • Like 2
Link to comment
Share on other sites

Ok, this image should fix itself on boot for the Raspberry PI it is being run on. https://jedimatt42.com/downloads/tipi-sdimage-bullseye-3.1.zip

 

I have not taken down the 'buster' image yet. I'll leave that 'buster' image up for a while under the 'old' section of my downloads page in case this blows up in my face. 

 

 

  • Like 2
Link to comment
Share on other sites

Woot... The Le Potato almost works... I can load and save files... the PHP Tidbit bits work, the web ui works... xbas99 text to PROGRAM image conversion works. 

 

What doesn't work :

- (EDIT - fixed) print to pdf PI.PIO - The 3rd party code doesn't compile on the 64bit raspberry/debian hybrid that is the Le Potato environment. 

- the reset signal - I expose this in the kernel module as /sys/devices/platform/tipi_gpio/tipi-reset, but it either doesn't support interrupts on edge detection, or I have to explicitly ask for it and it was free on the RPI. IDK... 

- (EDIT) usbmount also doesn't work. 

 

But very close... 

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...