How do I write to the USB port directly? That is, how can I transfer data byte by byte along the USB port using assembly, or, if possible, C? I do not want to use Get/GetCalc but am open to using Send (because the calculator will be sending, not receiving, data). This is a Plus CE so it has no I/O port. Also, what is the baud rate of the CE?

The concept of baud rate makes 0 sense with usb. You can't just transfer a byte here and there either. You must send data as specified in the usb 2.0 echi protocol specification. Figure out if the calculator is acting as a host or a device first. There is no way to do this *simply*.

I want to connect it to an Arduino so it should probably be the host since the arduino is normally a device, right?

No, the Arduino would be the host.

So would I need a driver?

Yes, you would call that the CE USB device driver. Which has not been completed yet

Generally using the CE as a usb device is much simpler than trying to use it as a host. In terms of code that is.

Why is that? Is it because the CE is normally a device when connected to a computer? Also, do the two sides of the included mini USB cable have anything to do with host and device?

The CE is easier because it already acts as a host when communicating with other CE's. The Arduino has never interfaced with a CE and know little about the I/O. What Mateo is saying, is that it would be easier to treat the CE as the host because it acts like one sometimes. (Correct me if I am wrong, Mateo)

EDIT: I stand corrected.

What are you talking about LAX18 A host is most definitely *not* easier to do.

The usb specification dictates that a usb device must interface as either a "host" or "device" (These are different then what you may think). A device is simply easier to do on the CE because it requires less assembly code and knowledge of the inner workings of the usb protocol because a lot of it already exists in bootcode. Using the CE as a host requires you to write host drivers for all connected "devices". That's all I am saying.

The usb cable has nothing to do with what is a host and what is a device in terms of the usb protocol.

What if I only want binary data. That is, what if I want the arduino to know if the CE is sending anything to it at all or not?

You can't just transfer a byte here and there either. You must send data as specified in the usb 2.0 echi protocol specification.

That's not what I mean. I mean that I don't care if the data is interpreted. Basically, I will not be sending integers or strings, just one signal.

You're asking something similar to how to speak without knowing how to control your vocal chords and without knowing a spoken language.

I'm just trying to say that is not how usb works. When a device connects to a host, the host queries the device for a list of description information, interfaces, and other such items. It then uses setup packets to establish the protocol between the connected devices. Once all this is complete, you usually begin by requesting bulk packets, and transferring them between the device and the host. If you fail to do things this way, the usb controller will lock up and usually freeze either the device or host.

Like I said before, there is no concept of "sending" anything. It all boils down to how the usb 2.0 echi specification works.

According to my understanding, the USB protocol is not like the serial port on the monochrome calculators. With that serial port, the calculator's processor can more directly power or depower the port to send 1s and 0s. With USB, the cable state cannot be directly accessed as a USB controller is between the processor and the USB port. This controller does not provide everything that is needed to send data between two devices, however. An additional software driver is needed to turn data into packets and make communication work with the protocol Mateo mentioned above. TI's Send( command does this, however it has not been reverse-engineered, probably because it would be easier to write a custom driver than to do so.

This topic is somewhat hilarious to me, because all of these questions were questions I asked a few days ago in relation to my project.

***Pieman7373 wonders who MMMMMMMMMMMMM is

There's a lot of misinformation here, so let me set everything straight:


You cannot transmit things over usb byte by byte. Instead, you create data buffers in ram and then schedule transactions that use them with the usb chip so that it can transfer them asynchronously according to the usb protocol. The CE, having a usb 2.0 chip, can have the standard usb baud rates of 1.5, 12, or 480 Mb/s, but of course the usb protocol eats up some of this bandwidth and then the CE processor would actually have to be able to generate/process the data at that rate.


Since you can connect an arduino to a computer it can act as a device. However, since you can also plug mice and keyboards into an arduino it can also act as a host. Which way you use it is entirely up to you and/or the libraries/drivers you want/have to use.
Edit: Looking through some arduino docs, it appears that it only allows access to the usb port through a conversion chip/separate processor. If this is the case, then you have no choice but to use only the protocol(s) it lets you use, which means implementing a driver for said protocol(s) on the calculator. Not to mention that, assuming my eyes don't decieve me, the ones I looked at all have a standard type B port, which, as per below, means it can only operate as a usb device and not a usb host.


If you don't want to have to use the low-level hardware interface yourself, then you would need a usb host driver to make the CE act as a host or a usb device driver to make the CE act as a device, neither of which exist yet for the CE.


The reason it is easier to act as a device than a host is only because usb is an extremely asymmetrical protocol where the host does almost all of the work, including scheduling and managing every single transaction, regardless of type and direction, and the device simply responds to host-initiated transactions. This is reflected in the low level hardware interface, where the device interface is arguably simpler than the host interface. Whether something functions as a host or a device is usually entirely based on whether it has a usb type A/host/upstream port or a usb type B/device/downstream port. The one exception to this is usb otg type AB ports where the initial host is determined by which side of the cable is plugged in to the port, and both sides can negotiate to swap roles if they are both type AB ports and the user plugged the cable in backwards.



As a usb device, you can do literally nothing in the way of sending data until the host configures you and requests data. As a host, you would have to manage and configure the device connections so that the usb host controller knows how to talk to them, and then schedule and manage all the transactions as mentioned above.

In general, in order to successfully use usb at all you need to understand certain parts of the usb 2.0 spec. The usb 2.0 ehci spec is only necessary for interfacing directly with the usb host controller, which is only needed on the host side of the connection, if there isn't a usb host driver doing it for you.

I have absolutely no idea what any of you are talking about, or know anything about coding on a to 84. But, I have a to 84 plus ce, will have an Arduino MKR1000 WiFi, and my goal is to create an assembly program that reads current position from gps through the Arduino, then go/move to that position on the included map(s). I would rather the map(s) be auto mattically detected based on a naming scheme. I will not have but 7-8 different stretches of road for proof of concept. As afore mentioned, I have absolutely no idea what to do, how do I do this (or who do I pay for this 😆). 😳

Please don't hijack an existing topic for your own project. The most appropriate procedure would be to go to the Your Projects subforum and start a new topic. Thanks!

While it is true that you should use USB this way in order to achieve the best performance, it also should be possible to write directly to the USB port and directly power and depower the ports with 1s and 0s, and effectively send data over USB in the same way you would over the link port.

The reason I think it should be possible because it is possible on the TI-84+, TI-84+SE, and the TI-84+CSE. However, this requires writing to specific ports using the "in" and "out" instructions, which cannot be done on the TI-84+CE, as these instructions are blocked.

Instead, ports are mapped to certain memory addresses, and you have to manipulate the data stored in those memory addresses to read and write from ports.

You can only directly write to the D- line and read from the D+ line. This means if you wanted to communicate over USB by manipulating these lines directly, you'd need a 1-bit data protocol that can send and receive data over a single wire, and then you'd send data upstream on the D- line and receive data downstream on the D+ line.

This is quite trivial on the TI-84+, SE, and CSE due to the great documentation on the Wiki for ports, but the documentation for the CE is very incomplete.

On the TI-84+, SE, and CSE, reading and writing directly to the USB port can be done like this (just read the Wiki if you want more of an explanation on all of this):


Code:


That's the gist of how you'd do it on the TI-84+, TI-84+SE, and TI-84+CSE.

This is a pretty slow way to use USB, since you'd be basically be writing your own protocol from scratch rather than just using USB protocol that the hardware is designed for. On the TI-84+, I've only gotten speeds of about 3-4 bytes a second doing it this way (this is 3-4 bytes upstream and downstream that can be maintained simultaneously). It could potentially be faster on the CE but if you want good speed you should actually use USB as its intended and not control the lines directly.

However, it does have the benefit of actually being quite simple to send and receive data with, which was a nice feature of the link port, and if you are just sending and receiving commands rather than entire programs, 3-4 bytes a second is plenty enough speed.

My assumption is that there should be a very similar way to achieve this on the CE, by manipulating the ports through memory mapped addresses.

While it does suck to the the I/O link port removed since it was so easy to directly control, there may be a way to achieve this via USB on the CE.