|
|
| (9 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| − | == This is just to move the TOC up ==
| + | This page was split since it was getting large; see also the [[Talk:83Plus:OS:84_Plus_USB_Information/1|second page]]. |
| − | | + | |
| − | I read the bit about device PIDs and theorized that the 89T was the 000F that it rejected... I hooked it up to my computer and it reported PID=E004, which isn't even an option from what he said. Also, in #wikiti: ''<+Kalimero> exactly, and 84P has pid E008'', which makes me think that it drops the E for OnTheGo transfers.. That explains that, but not what the other devices are. I think it'd be safe to theorize that the ViewScreen adapter would be "allowed", but... Didn't it come out after the calculators, so it would have a higher PID? Hold on, I just had another idea in #wikiti: ''<Andy_J> looking at the PIDs, it would seem that the 84+SE might be 0003, then the 89T would be 0004, then some mysteries, and the 84+ being 0008... maybe they originally planed to just have the 84+SE?'' So if that were the case, what are 0005 through 0007? Just some random ideas to throw out there. --[[User:AndyJ|AndyJ]] 08:11, 27 May 2005 (PDT)
| + | |
| − | : I'm doing my testing on an 84PSE, by the way. I assume everything about the regular 84P is the same, but I don't have one to check. The CBL2 has to fit in there somewhere. I have one in Ann Arbor, so when I go back there I'll check the PID. This code (that looks for 0008, etc) isn't necessarily the total "allowed" list either, as the code that checks for Vernier devices is elsewhere, it's just some random code that I stumbled upon and thought I'd mention, even though I wasn't planning on checking into the details at the moment. --[[User:Dan Englender|Dan Englender]] 11:32, 27 May 2005 (PDT)
| + | |
| − | ::Alright, throw that theory out the window. :D --[[User:AndyJ|AndyJ]] 12:02, 27 May 2005 (PDT)
| + | |
| − | :By the way, the 0008 vs E008 has a simple explanation: I was typing up the page at 6 AM and my brain wasn't working very well. I meant E008, E00F, and E003. Oops :) --[[User:Dan Englender|Dan Englender]] 12:39, 27 May 2005 (PDT)
| + | |
| − | :In the course of doing some other research, I found that Andy was (almost) right. E008 is the 84P SE, E003 is the 84P regular. Still don't know what E00F is.
| + | |
| − | ::From what you've written, it sounds like E00F is almost certainly the presentation link, given that (A) connecting the presentation link presumably requires the screen to be refreshed, and (B) having the presentation link connected prevents any other (software driven) USB devices from being used. From which I suppose we can infer that TI has no plans to support hubs :) [[User:FloppusMaximus|FloppusMaximus]] 10:00, 15 Jun 2005 (PDT)
| + | |
| − | More info on those PIDs:
| + | |
| − | On Ti-89 Titanium, the only PIDs which seem to be accepted are E004 (Titanium) and E00E (???). Also Romain Liévin pointed out to me a few months ago that Texas Instruments's Win32 driver supports this list of PIDs:
| + | |
| − | | + | |
| − | %DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E003 => TI84+
| + | |
| − | %DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E004 => Titanium
| + | |
| − | %DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E008 => TI84+SE
| + | |
| − | %DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E009
| + | |
| − | %DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E00A
| + | |
| − | %DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E00B
| + | |
| − | %DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E00C
| + | |
| − | %DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E00D
| + | |
| − | --[[User:ExtendeD|ExtendeD]] 16:16, 29 Jun 2005 (PDT)
| + | |
| − | :Ok, I speculate that E00F is the 84+ ViewScreen adapter and E00E is the 89T ViewScreen. We won't know for sure until we get our hands on one of each. --[[User:AndyJ|AndyJ]] 17:57, 29 Jun 2005 (PDT)
| + | |
| − | ::I agree that that seems likely. Also, the CBR2 can connect somehow to the 84 via USB. I'm not sure whether it will have a TI or a Vernier ID though. I don't really want to drop the dough for that one to find out. I may buy the Vernier EasyLink when it comes out though. --[[User:Dan Englender|Dan Englender]] 19:07, 29 Jun 2005 (PDT)
| + | |
| − | | + | |
| − | == Source ==
| + | |
| − | | + | |
| − | >> Source code will be going on SourceForge sometime in the near future.
| + | |
| − | | + | |
| − | What's the project name, or do you not have it made yet? --[[User:AndyJ|AndyJ]] 14:55, 28 Jun 2005 (PDT)
| + | |
| − | :Haven't made it yet. I hate the overhead of having to use SourceForge, so I'm avoiding it as long as possible. --[[User:Dan Englender|Dan Englender]] 15:16, 28 Jun 2005 (PDT)
| + | |
| − | | + | |
| − | == Ports ==
| + | |
| − | | + | |
| − | Dan: did you notice, as on Titanium, that 0 was written to port 2E instead of port 8E, in the routine handling device requests, before sending an "ACK without data phase", to select endpoint 0? For the other types of acknowledgement (NAK and "ACK with data phase"), its 8E, as you have written. --[[User:ExtendeD|ExtendeD]] 13:43, 30 Jun 2005 (PDT)
| + | |
| − | :This isn't the case on the 84P. Regardless of whether there's a data phase, a value of 0 is sent out port 8E. (Port 2E isn't a USB port on the 84P either.) As for the command ports though, I still haven't quite figured out port 94 vs port 91 yet though. It seems like 94 is used for interrupt transfer, and 91 is used for both control and bulk, but I can't see why that makes sense. --[[User:Dan Englender|Dan Englender]] 21:42, 30 Jun 2005 (PDT)
| + | |
| − | :This may sound silly, but could it be that the port 2E on the titanium is a typo? Because if endpoint 0 was currently selected by a previous command (which it probably was if you're doing standard device requests), you could probably leave out the setting of port 8E altogether. I only ask because I've found a few very silly typos in the 84P USB code which only happen to work by "luck". --[[User:Dan Englender|Dan Englender]] 21:47, 30 Jun 2005 (PDT)
| + | |
| − | ::By the way here are the ports used in the USB code of the Titanium, that you haven't yet mentionned:
| + | |
| − | | + | |
| − | ::22, 24, 26, 27, 29, 2E, 2F, 31, 32, 34, 39, 4A, 54, 56, 57, 5A, 67, 81, 89, 8B, 92, 95, 96, 98, 99, 9A
| + | |
| − | | + | |
| − | :::The ports used for output on the 84P are: 39, 3A, 4A, 4B, 4C, 4F, 50, 54, 57, 5B, 80, 81, 87, 89, 8B, 8E, 8F, 90, 91, 92, 93, 94, 95, 98, 9A, 9B. I haven't made a completele list of the input ports yet, but it's something like 39, 3A, 4C, 4D, 4F, 57, 81, 82, 84, 86, 87, 89, 8B, 8C, 8E, 8F, 90, 91, 93, 94, 98, 9A. So it looks like your 80s and 90s might be mapped the same as the 84P, but maybe the other ports aren't? --[[User:Dan Englender|Dan Englender]] 12:13, 1 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | ::About port 94: the only bit I have figured out is bit 5: setting it stalls the OUT bulk endpoint (this is what is done when SET FEATURE is sent for feature ENDPOINT_HALT). To unstall the endpoint, 34:7 is set and 34:5 is cleared.
| + | |
| − | | + | |
| − | ::Note that the ports and bits are different for the IN bulk endpoint: 31:4 is set to stall it, 91:6 is set and 91:4 is cleared to unstall it.--[[User:ExtendeD|ExtendeD]] 11:20, 1 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | :::Yes, this seems very similar to what's going on on the 84P, but instead of using 31/91, just 91 is used, and instead of 34/94, just 94 is used. But the bits to stall and clear the stall are the same. --[[User:Dan Englender|Dan Englender]] 23:29, 1 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | ::Could it be that the 2x ports on the Titanium are 8x ports on the 84+ and the 3x ports are 9x ports? That would make the numbers nicely match up. Maybe the Titanium separates input and output ports that way, whereas the 84+ mixes them? -- Kevin Kofler 17:04, 6 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | :::Actually AMS sometimes uses 2x ports, sometimes 8x ports, and this is the same for ports 3x/9x. There doesn't seem to be any logic in the choice (actually for some ports there is, and for others there isn't). Maybe there are some mirrors in the 7100xx range, and TI is using the possible addresses indifferently (perhaps for debugging purposes, using data breakpoints!). I have asked Romain Liévin to check this on a real Titanium. --[[User:ExtendeD|ExtendeD]] 02:30, 7 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | I've had a thought that may be nonsense, but also might not be. I'll need to verify it later. It seems like most, if not all, of the ports in the 9X range have two versions: one for incoming pipes and one for outgoing pipes. For example, 90 and 93, 92 and 95, 98 and 9A all seem very similar both based on when they're called, and the values set. It also may be that more than just A0, A1, and A2 can be used for data. Using ports 98 or 9A it might be able to set up other pipes. --[[User:Dan Englender|Dan Englender]] 00:18, 1 Jul 2005 (PDT)
| + | |
| − | :I agree that these ports are similar. I would also add 99 and 9B (bInterval), and 87 and 89 (???).--[[User:ExtendeD|ExtendeD]] 11:22, 1 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | Dan, there is something I don't understand in Titanium's code, perhaps you can help me: only 2 routines write to port A0. The first one writes a packet, reading from a buffer in RAM. The second one that I don't understand) sends a packet formatted like this: 0 | something (seems to be 3 or 6) | address.lower | address.upper | endpoint.lower | endpoint.upper | something (seems to always be 0) | something (seems to always be 0). I am quite sure "address" and "endpoint" represent a device address and an endpoint, but I really can't figure out when this would be sent. Do you have something similar on 84P? --[[User:ExtendeD|ExtendeD]] 16:30, 1 Jul 2005 (PDT)
| + | |
| − | :I don't think there's anything like that on the 84P. The closest I see is that during USB device initialization for calc<->calc, a Set Feature of 3 and 4 are sent (00 03 03 and 00 03 04, with the rest of the packet 00). The receiving calculator plays with a couple of memory addresses when it gets these, but doesn't seem to do anything meaningful. What do you mean by address.upper and endpoint.upper, as these aren't 16-bit values. Just a 0? I, also, am not sure what it could be. Do you know if the code is ever actually called in the course of normal calculator operation? I ask because there seems to be some leftover unused code in the 84P operating system that might have been debug code or something like that. --[[User:Dan Englender|Dan Englender]] 21:16, 1 Jul 2005 (PDT)
| + | |
| − | ::Ok, I have found out, I was completely wrong. The routine sends a setup packet (the "setup stage" of a control transfer). What helped is the Titanium's equivalent of your "5290 BCALL" I have located (by the way I am ok with what you have written about the max size of 8 bytes for the first request). --[[User:ExtendeD|ExtendeD]] 03:25, 2 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | ----
| + | |
| − | | + | |
| − | Hi guys. I'm leaving tomorrow for a week on vacation. I wont have internet access, so I wont be able to post any updates. I'll take along a laptop and will hopefully get some work done, though, so I'll have updates to post when I get back. I'll try to have another cool demo to show :) --[[User:Dan Englender|Dan Englender]] 22:07, 1 Jul 2005 (PDT)
| + | |
| − | :I'm back. Unfortunately I forgot to bring with me some of the files I needed, so I didn't get much done. Oh well. --[[User:Dan Englender|Dan Englender]] 16:01, 9 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | ----
| + | |
| − | | + | |
| − | Dan, I agree with your thoughts on ports 9A and AX. Port 9A is used to configure the type of an endpoint. BTW the USB controller supports 3 endpoints, (either as a device or host), 2 of which (at the most) can be in endpoints (IN means "from you to me", ie not in the USB-sense where the host is taken as reference). I don't know if this limit of 2 inendpoints is only a soft one, or a real limit of the USB controller. --[[User:ExtendeD|ExtendeD]] 12:21, 2 Jul 2005 (PDT)
| + | |
| − | :Quoting Dan from #WikiTI via his cell phone:
| + | |
| − | [15:38:45] <Dan_E> I See What Extended Is Saying About The Three end points from looking at port data
| + | |
| − | [15:41:02] <Dan_E> but the whole ax range seems to be mapped as oppossed to the bx range so maybe its an init thing
| + | |
| − | [15:42:04] <Dan_E> can someone post that to the wiki. thanks.
| + | |
| − | :--[[User:AndyJ|AndyJ]] 16:26, 2 Jul 2005 (PDT)
| + | |
| − | ::[Thanks AndyJ]. So perhaps this limit is only a software one. Anyway the Titanium's OS won't go further than A3. --[[User:ExtendeD|ExtendeD]] 01:26, 3 Jul 2005 (PDT)
| + | |
| − | :::The 84P OS doesn't use anything past A2. What does the titanium use A3 for? --[[User:Dan Englender|Dan Englender]] 16:01, 9 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | ----
| + | |
| − | New stuff of the day which may help you:
| + | |
| − | | + | |
| − | - I agree that 8F:2 set means 'calculator-as-host'.
| + | |
| − | | + | |
| − | - The features set by 'set feature' device requests which seem to be not standard ones are actually On-The-Go features. These features are not really interesting, except the "Host an Negociation Protocol" enabling which may be used during calc-to-calc transfers (controlled by port 8F:1). Here is a copy/paste of a part of the corresponding structure of Titanium's OS :
| + | |
| − | ...
| + | |
| − | int f_remote_wakeup : 1; // PERIPH - feature #1 (DEVICE_REMOTE_WAKEUP, USB specs). If set, the Titanium has remote wakeup enabled and can wake the host up during suspend. Read/Write. Doesn't seem to do anything.
| + | |
| − | int f_b_hnp_enable : 1; // PERIPH - feature #3 (UOTG_B_HNP_ENABLE, OTG specs). Only written. The only feature which may be set by AMS when the Titanium is acting as host. Cannot be cleared. 8F:1 set to enable HNP.
| + | |
| − | int f_a_hnp_support : 1; // PERIPH - feature #4 (UOTG_A_HNP_SUPPORT, OTG specs). Only written. Doesn't seem to do anything. Cannot be cleared.
| + | |
| − | int f_a_alt_hnp_support : 1; // PERIPH - feature #5 (UOTG_A_ALT_HNP_SUPPORT, OTG specs). Only written. Doesn't seem to do anything. Cannot be cleared.
| + | |
| − | ...
| + | |
| − | - I have started a documention on some ports you have not talked about, or are not yet really detailed. You can integrate this to the Wiki if it also corresponds to the 84P's USB hardware and seems to be correct. http://membres.lycos.fr/extended/usb/titanium_usb_hw.txt . Also can you check what you have written on port 87? I am quite sure of its functioning on Titanium, but it does not appear to follow what is in the Wiki. --[[User:ExtendeD|ExtendeD]] 09:06, 4 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | I have now quite a good view on control transfers from the host point of view. For port 91, ''"42 - Done reading data on port A0. (Send an ack?) (host)"'' should be ''"Send an OUT token"'' (see 8.5.3.1 of the USB 2.0 specs). --[[User:ExtendeD|ExtendeD]] 10:56, 4 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | Dan, for your USB project, are you planning to "hook" the OS (I do not know anything of Ti-83/84+ programming and how this can be done), or to rewrite the whole USB stack? For your mouse demo, did you use any hooks? I am personally thinking of rewriting the stack, but I am still not sure whether some part of the Titanium's OS can be easily reused without confliting with files transfers. BTW I will soon need a real Titanium, I am ready to buy a secondhand one at a reasonable price, if somebody needs to get rid of one... --[[User:ExtendeD|ExtendeD]] 12:39, 6 Jul 2005 (PDT)
| + | |
| − | : So far I've written the initialization and set-up completely by hand, but managed to "hook" part of the OS interrupt routine for the purposes of retrieving USB interrupt data (e.g. the mouse demo). I had some problems on my preliminary tests trying to get this method to work with bulk data. So, I may have to use my own interrupt routine do everything without any OS help. --[[User:Dan Englender|Dan Englender]] 16:13, 9 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | ''"The presentation link (...) appears to request 16 byte packets?"'' On Titanium, device E00E has a max packet size of 32 (max_packet_size >> 3 is written to port 90). --[[User:ExtendeD|ExtendeD]] 14:06, 9 Jul 2005 (PDT)
| + | |
| − | : I will check this again on the 84P --[[User:Dan Englender|Dan Englender]] 16:13, 9 Jul 2005 (PDT)
| + | |
| − | :: I checked again and the E00F does in fact use a max packet size of 16 bytes. I guess there's the bigger screen to contend with on the 89t, but I don't really see why TI didn't just make them both the same. *shrug* --[[User:Dan Englender|Dan Englender]] 18:33, 9 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | == 89T information txt file ==
| + | |
| − | In regards to your (ExtendeD's) text file:
| + | |
| − | * Port 22/82: I'm not completely sure I agree with your explanation, at least for how it functions on the 84P. From what I see it looks like it may represent whether the last packet (or command) was successfully sent, as you say, but each bit I think may specifically represent a different pipe. Bit 0 for port A0, bit 1 for port A1, bit 2 for port A2. Probably the higher bits are for the higher Ax ports, but these aren't used on the 84P.
| + | |
| − | :This looks possible, you are probably right (I have currently no Titanium to test, and AMS uses of course only bit 0 and 1). --[[User:ExtendeD|ExtendeD]] 02:44, 10 Jul 2005 (PDT)
| + | |
| − | * Port 24/84: I agree with your description.
| + | |
| − | * Port 87: The only thing the 84P does to this port is output FF, 7F, 00, or set bit 0. I can't see how this would correspond to the description you've given it, so perhaps the 84P and 89t differ in this respect. The output value of 00 appears to happen once: during the setup procedure for the E00F device.
| + | |
| − | ** I'm still rather confused about what 87 and 89 are doing on the 84P. I'll try to provide some more detail of what's going on, and maybe you can see how this matches with what happens on the 89t. The "normal" state of port 87 seems to be FF. I guess this could be reconciled by saying that it just keeps all the pipes enabled at all times. For E00F initialization it sets the value to 00, but I'm not worried about E00F yet. The odd thing is that right before the address is set, when the calc is a device and gets a set address request, it changes the value to 7F. I can't imagine it would want to do anything with pipe A7, so I don't know what it could be for. --[[User:Dan Englender|Dan Englender]] 12:31, 10 Jul 2005 (PDT)
| + | |
| − | ***''"right before the address is set"'': you mean at the end of the status stage, before the address is written to port 80? On Titanium, the device is moved to the address state: among other things, 1 is written to port 87, and 0 is written to port 89. I really don't understand what's going on with your ports 87 and 89. Titanium's behavior with them is consistent. Each configured endpoint has an associated configuration structure, with a field I have called ''enabling_mask''. Its value is ''1 << buffer_index'' (buffer_index is 1 for A1 for example). To enable the outgoing flow of the pipe, I have a (in C) ''wio(87, rio(87) | enabling_mask);'' (wio/rio are C macros). To disable it, I have a ''wio(87,~config->enabling_mask & rio(87));'', and so on. --[[User:ExtendeD|ExtendeD]] 13:16, 10 Jul 2005 (PDT)
| + | |
| − | **** I meant right after it reads and parses the set address request, before it actually outputs to port 80. It seems way too strange to have everything else be exactly the same and the behavior of these two ports be completely different between the two calculators. I'll have to think about it further and see if I can make any sense out of I guess --[[User:Dan Englender|Dan Englender]] 13:25, 10 Jul 2005 (PDT)
| + | |
| − | * Port 89: I have to look in more detail to see what port 89 is doing on the 84P
| + | |
| − | ** The "normal" state of port 89 seems to be 0E. I guess bit 0 is reset because the control port is treated like an outgoing port. Why bits 1-3 are set is odd though, because probably only one of them should be used for incoming, and port A3 is never used at all. When a Vernier device is connected, the value is set to 02. This makes sense: A1 is used as the interrupt in pipe for this device. However, in the code which, I think, is the bulk recieve for linking and/or silent linking, the port value is set to FF until all packets are received, and then reset to 0E. During E00F set-up the port is set to 0 (but I'm not worrying about that, because E00F seems to behave different altogether). But the FF and 0E stuff is a little confusing. --[[User:Dan Englender|Dan Englender]] 12:31, 10 Jul 2005 (PDT)
| + | |
| − | * Port 8F: Your description seems to be accurate for the 84P as well. The 84P also reads the value of bit 7, though. I haven't determined what this is for yet. Does the titanium check this bit?
| + | |
| − | ** No, only bit 0, 1 and 2 are used... --[[User:ExtendeD|ExtendeD]] 02:44, 10 Jul 2005 (PDT)
| + | |
| − | *** I believe bit 0 might be to enable HNP from the host side. --[[User:Dan Englender|Dan Englender]] 12:46, 10 Jul 2005 (PDT) ---- Changed my mind. It has something to do with HNP, but I haven't figured out what yet.
| + | |
| − | **** On Titanium, this bit is set to enable HNP on the device side (after a set_feature request by the host). Strangely, it is also set by the device... during HNP! The OTG spec requires to check if a set_feature has been sent by the host before continuing HNP, but AMS as device seems to enable it by itself... BTW I am currently working on HNP handling routines. This is so complicated, I have been on this for hours. This will hopefully demystify the role of many ports. I am trying to cross-check AMS's routines and OTG spec's state diagrams, but I am far from having anything useful for the moment. I think we will soon have to switch our vocabulary from ''"as host"'' to ''"a B-device acting as host"'' for example, else we'll soon be confused when detailing HNP and SRP. This would be great if you could find 84P's equivalent routines, to cross-check the 2 implementations. I can try to give you hints for this if you want. --[[User:ExtendeD|ExtendeD]] 13:54, 10 Jul 2005 (PDT)
| + | |
| − | ***** I believe I've found the HNP handling routines as well, and was mapping them out, but got sidetracked by the strange things I found with port 3A. I'll get back to the HNP stuff later tonight. Let me know what you find out and I'll see how it matches up to what I see on the 84P. --[[User:Dan Englender|Dan Englender]] 14:05, 10 Jul 2005 (PDT)
| + | |
| − | *** On the 84P only bits 0, 2, and 7 are used. It seems like bits 0 is set if the USB has activated at all. Bit 1 always seems to be 0, so far as I can tell. Bit 2 is set if the device is acting as host. Bit 3 seems to be the same as bit 2. Bit 4 always seems to be the negation of bit 2. Bit 5 seems to always be 0. Bit 6 seems to be the same as bit 2. Bit 7 seems to be 1 is b-cable is connected or 0 if a-cable is connected. --[[User:Dan Englender|Dan Englender]] 23:51, 10 Jul 2005 (PDT)
| + | |
| − | * Port 96: I agree with your description. The 84P doesn't use port 97. But it also doesn't transfer packets larger than 256 bytes.
| + | |
| − | * ''"Is this distinction always necessary for port 91?"'' - On the 84P, sometimes the values are output without regard for the current port value, and sometimes the values are read in first, bits set, then the value output. I assume sometime similar is going on the titanium, and promped your question. I am also not sure why this is done.
| + | |
| − | * In general: I think, what we're calling "endpoints" when we're talking about Ax ports, we should be calling "pipes" to be in line with the USB spec.
| + | |
| − | * I expect hubs could be supported if you were willing to do the extra programming to write a driver for it.
| + | |
| − | * I'm going to make another complete guess: The ports that seem to have each bit mapped to a different endpoint/pipe, for example ports 82 (in my model), 84, 87 (in your model), and 89 (in your model) all have another port directly after them that is never used anywhere in the operating system (on the 84P at least). I'm going to guess that the total number of available pipes is 16 (A0 through AF) and that the first of the ports, the ones that we've written about, controls A0 through A7, and the second one, that the OS never touches, controls A8 through AF. --[[User:Dan Englender|Dan Englender]] 22:51, 9 Jul 2005 (PDT)
| + | |
| − | :This looks good. The only thing which annoys me is that ports '87' and '89' are odd addresses, I would expect even ones. --[[User:ExtendeD|ExtendeD]] 02:44, 10 Jul 2005 (PDT)
| + | |
| − | --[[User:Dan Englender|Dan Englender]] 16:58, 9 Jul 2005 (PDT)
| + | |
| − | | + | |
| − | Dan, I had forgotten to upload the latest version of the file. Here is a diff [http://membres.lycos.fr/extended/usb/titanium_usb_hw.diff.20050710.txt] of it for the few missing additions you have not read. --[[User:ExtendeD|ExtendeD]] 03:09, 10 Jul 2005 (PDT)
| + | |
| − | ----
| + | |
| − | Dan, Olivier, I really appreciate the work you're doing on the USB ports. I'm looking forward to USB support in TiEmu, at least for TiEmu-TiEmu virtual linking. Maybe I'll implement it once you get the documentation done. Is anything similar being done for the RTC ports? --[[User:Kevin Kofler|Kevin Kofler]] 19:34, 9 Jul 2005 (PDT)
| + | |
| − | :Glad to be of service :) As for the RTC ports, I haven't the faintest idea how they work on the 89t, but on the 84P, they work as follows: Ports 45 through 48 (MSB) hold the current value of the clock, as seconds since January 1st 1997 12 AM. Bit 0 of port 40 is set if the clock is enabled, and reset if not. To set a new value of the clock load the value you want to ports 41 through 44, and then set port 40 to 01 then 03 in succession. --[[User:Dan Englender|Dan Englender]] 21:59, 9 Jul 2005 (PDT)
| + | |
| − | ::Noted. I'll check out if it matches what the Titanium OS does about a week from now, unless Olivier (ExtendeD) beats me to the punch. --[[User:Kevin Kofler|Kevin Kofler]] 00:54, 10 Jul 2005 (PDT)
| + | |
| − | :::<<Ports 45 through 48 (MSB) hold the current value of the clock, as seconds since January 1st 1997 12 AM>> I can confirm this. While I was working on clock support for TiLP, I had to understand how the clock was encoded in the packet. It's encoded like you mentionned: a 32-bits value which holds the current value of the clock, as seconds since January 1st 1997 12 AM. But, I will add this: it is assumed there are _always_ 365 days in a year (no 1996, 2000, specific years). --[[User:roms|Romain Liévin]] 23:14, 11 Jul 2005
| + | |
| − | ::::So no leap years? That's silly. Does the OS simply not allow one to set a February 29 in years mod 4 = 0 (plus those other restrictions)? --[[User:AndyJ|AndyJ]] 14:46, 11 Jul 2005 (PDT)
| + | |
| − | :I have thought about this for a while, it would be really helpful to debug any USB-related software written. The problem is that nothing has been tested yet on a real Titanium (Romain Liévin was to bring his calc to me during his weekend in Paris, but it seems we have missed each other). There are also many other ports we have not yet thought about. Perhaps you should wait for more information and for the current details to be stabilized.<br>
| + | |
| − | :About the RTC, I think we have everything needed to implement it in my titanium-info.txt (in Titarom's package). --[[User:ExtendeD|ExtendeD]] 02:44, 10 Jul 2005 (PDT)
| + | |
| | | | |
| | == Currently unresearched ports == | | == Currently unresearched ports == |
| Line 155: |
Line 25: |
| | * 57: I/O port. No clue. | | * 57: I/O port. No clue. |
| | * 5A: A value of 1 is sent to this port during E00F setup. | | * 5A: A value of 1 is sent to this port during E00F setup. |
| − | **Same on Titanium but for device E00E. Some pieces of code check if this port has a value of 1: trap #4 (the hardware trap to shutdown the calc), the high-level function called "USBCheckReceived" by Kevin Kolfer used during file transfers (it quits if it is 1: no transfers if we are configured to used the adapter), the ROM Call EV_getc (which calls a routine that checks if the device has been unplugged, with 56:5), and the USB interrupt, which calls the same routine as EV_getc instead of the standard handler. | + | **Same on Titanium but for device E00E. Some pieces of code check if this port has a value of 1: trap #4 (the hardware trap to shutdown the calc), the high-level function called "USBCheckReceived" by Kevin Kofler used during file transfers (it quits if it is 1: no transfers if we are configured to used the adapter), the ROM Call EV_getc (which calls a routine that checks if the device has been unplugged, with 56:5), and the USB interrupt, which calls the same routine as EV_getc instead of the standard handler. |
| | | | |
| | ...These lower ports are especially odd because many of them are used very few times, or just once, in the OS. Does the 89T have anything that might resemble these? --[[User:Dan Englender|Dan Englender]] 00:52, 10 Jul 2005 (PDT) | | ...These lower ports are especially odd because many of them are used very few times, or just once, in the OS. Does the 89T have anything that might resemble these? --[[User:Dan Englender|Dan Englender]] 00:52, 10 Jul 2005 (PDT) |
| Line 184: |
Line 54: |
| | | | |
| | The state diagram is very nice. Unfortunately I wasn't able to map what I read in the diagram to what I saw going on on the 84P. So instead I took a little break from the research stuff and worked some more on the driver today. I got bulk I/O working, and wrote another demo: this time with the silverlink. In case anyone had been sitting up at night wondering, using the standard TI serial routines, the calculator can transmit data to itself at ~2.3 KB/s. --[[User:Dan Englender|Dan Englender]] 23:25, 11 Jul 2005 (PDT) | | The state diagram is very nice. Unfortunately I wasn't able to map what I read in the diagram to what I saw going on on the 84P. So instead I took a little break from the research stuff and worked some more on the driver today. I got bulk I/O working, and wrote another demo: this time with the silverlink. In case anyone had been sitting up at night wondering, using the standard TI serial routines, the calculator can transmit data to itself at ~2.3 KB/s. --[[User:Dan Englender|Dan Englender]] 23:25, 11 Jul 2005 (PDT) |
| | + | |
| | + | == Meta == |
| | + | Um... Dan, did you intend to revert a bunch of earlier changes [http://wikiti.denglend.net/index.php?title=83Plus:OS:84_Plus_USB_Information&curid=1525&diff=1790&oldid=1789&rcid=2571 here] ? --[[User:FloppusMaximus|FloppusMaximus]] 17:40, 13 Jul 2005 (PDT) |
| | + | :No, I didn't. I've been having a lot of caching problems (I keep getting old copies of pages) and I have no idea why. I guess that was an example. I'll change them back soon --[[User:Dan Englender|Dan Englender]] 19:05, 13 Jul 2005 (PDT) ----- Fixed. Thanks for pointing that out. --[[User:Dan Englender|Dan Englender]] 19:25, 13 Jul 2005 (PDT) |
| | + | |
| | + | |
| | + | == 0.09 Updates == |
| | + | I've been working on version 0.09 of usb8x. The version in the CVS is relatively stable, but I'll be posting an official release sometime soon. A couple things to mention: |
| | + | * In case anyone was wondering, the hardware allows you to setup the same pipe/endpoint number for both IN and OUT transfer. |
| | + | * The issue with a lot of flash drives not working (i.e. sandisk cruzer) was a bug in usb8x caused by #1. It's been fixed. |
| | + | * The new version includes a compile-time option for logging lots of internal state data to one of the extra RAM pages. Hopefully this will be useful for debugging new drivers. |
| | + | --[[User:Dan Englender|Dan Englender]] 00:41, 3 June 2006 (PDT) |
There are some ports whose function which we haven't yet agreed on, but I thought I'd compile a list of ports that neither of us have touched yet:
Then there are the lower ports on the 84P, which I don't know, but am guessing are different on the 89t, since I haven't heard anything about them:
...These lower ports are especially odd because many of them are used very few times, or just once, in the OS. Does the 89T have anything that might resemble these? --Dan Englender 00:52, 10 Jul 2005 (PDT)
I suspect some missing initializations on Titanium that do exist on 84P to be due to a different interpretation of the USB controller's datasheet by the 2 teams of developpers. --ExtendeD 03:56, 10 Jul 2005 (PDT)
Before a transmission between 2 Titaniums, the sending calculator first tries to become host: it tests if it is a A-device or B-device according to the plug inserted. If it is a B-device, it tries to become host with HNP. If it is a A-device, it tries to configure itself as a host (and perhaps many other things, the state diagram is as complicated as the one for a B-device). I don't know exactly what the receiving calculator do, but it also calls the routine for a A-device. I suspect the calculators both to try to become host: the first calculator to achieve this will be the host. Then come the bulk transfers.
In the 2 state diagrams (for a A-device and a B-device), there are ports modifications and tests everywhere as actions and transitions. Also some timers and loops are used (loops for 1 to 3 ms waitings, timers for 100ms to 1s timeouts). I am using the state diagrams at the end of the OTG spec, and this Powerpoint presentation by a guy from Cypress that details these complicated diagrams [2].
It's past midnight in France, and I am tired... Perhaps I will convert tomorrow my paper diagrams to Visio ones, it will be easier to work with this as a reference for the Titanium's workflow. --ExtendeD 15:20, 10 Jul 2005 (PDT)
I've been working on version 0.09 of usb8x. The version in the CVS is relatively stable, but I'll be posting an official release sometime soon. A couple things to mention:
![[4]](http://membres.lycos.fr/extended/usb/b_device_hnp.png){kind=link}