So I setup my AVR32 (UC3A0256) in host mode and can read the FTDI USB descriptors (on the 635) . The USB host on the AVR32 supports Full Speed (fyi, I'm learning the USB protocol as I develop this..)
I have this spit out on my terminal display:
"Device connected
VID=403, Product ID=FC0D
Number of Endpoints 2
Pipe Number = 1, Interrupt Period =0, End Point Addr =1, Type =2 (bulk), In/Out=1, Size =64
Pipe Number = 2, Interrupt Period =0, End Point Addr =2, Type =2(bulk), In/Out=0, Size =64
Device enumerated" -> I set up the FTDI USB device to be address 4.
When the FTDI USB device is enumerated the default display comes up on the LCD (Crystalfontz CFA-635 etc). It didn't do this until it was enumerated..
I poll the Display and get I continuously read "0x01 0x60" regardless of what I send it (or buttons I push).
Looking at the documentation for the display
TTcc cccc
|||| ||||--Command, response, error or report code 0-63
||---------Type:
00 = normal command from host to XES635BK
01 = normal response from XES635BK to host
10 = normal report from XES635BK to host (not in
direct response to a command from the host)
11 = error response from XES635BK to host (a packet
with valid structure but illegal content
was received by the XES635BK)
-- I'm not sure what to make of this response..
I put a usb sniffer on my PC and hooked up the display and I see the same thing, but I can send commands to it using the 635_Wintest_1_0 app. See below..
-----------------------------------------------------------------------------------------------
857730: Bulk or Interrupt Transfer (UP), 24.09.2010 11:30:15.058 +0.015. Status: 0x00000000
Pipe Handle: 0x9a072dc8 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
01 60 .`
857732: Bulk or Interrupt Transfer (DOWN), 24.09.2010 11:30:15.074 +0.015
Pipe Handle: 0x9a072df8 (Endpoint Address: 0x2)
Send 0x1a bytes to the device
1F 16 00 00 20 20 20 20 20 20 20 20 20 20 20 20 ....
20 20 20 20 20 20 20 20 51 85 Q…
857734: Bulk or Interrupt Transfer (UP), 24.09.2010 11:30:15.074 +0.0. Status: 0x00000000
Pipe Handle: 0x9a072dc8 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
01 60 .`
857736: Bulk or Interrupt Transfer (DOWN), 24.09.2010 11:30:15.074 +0.0
Pipe Handle: 0x9a072df8 (Endpoint Address: 0x2)
Send 0x1a bytes to the device
1F 16 00 01 53 70 65 65 64 20 20 20 20 20 20 20 ....Speed
20 20 20 00 02 04 06 20 77 5A .... wZ
------------------------------------------------------------------------------------------------------
Is the 0x01 0x60 part of the FTDI driver interface? and am I missing the Corresponding command to send to the driver before it will send data to the display? I've been digging through FTDI examples but everything seems to have a PC OS associated with it and I'm not sure what I'm looking for.. The "0x1F" command is what I'm trying to send to it (I calculated the 0x5A77 crc value just like last packet above).
I'm not sure where to look at this point as don't have the ability to monitor the traffic between the AVR32 and display.. I'm hoping the "0x01 0x60" leads me to the key that I'm looking for..
Any help is most appreciated.
ef.
I have this spit out on my terminal display:
"Device connected
VID=403, Product ID=FC0D
Number of Endpoints 2
Pipe Number = 1, Interrupt Period =0, End Point Addr =1, Type =2 (bulk), In/Out=1, Size =64
Pipe Number = 2, Interrupt Period =0, End Point Addr =2, Type =2(bulk), In/Out=0, Size =64
Device enumerated" -> I set up the FTDI USB device to be address 4.
When the FTDI USB device is enumerated the default display comes up on the LCD (Crystalfontz CFA-635 etc). It didn't do this until it was enumerated..
I poll the Display and get I continuously read "0x01 0x60" regardless of what I send it (or buttons I push).
Looking at the documentation for the display
TTcc cccc
|||| ||||--Command, response, error or report code 0-63
||---------Type:
00 = normal command from host to XES635BK
01 = normal response from XES635BK to host
10 = normal report from XES635BK to host (not in
direct response to a command from the host)
11 = error response from XES635BK to host (a packet
with valid structure but illegal content
was received by the XES635BK)
-- I'm not sure what to make of this response..
I put a usb sniffer on my PC and hooked up the display and I see the same thing, but I can send commands to it using the 635_Wintest_1_0 app. See below..
-----------------------------------------------------------------------------------------------
857730: Bulk or Interrupt Transfer (UP), 24.09.2010 11:30:15.058 +0.015. Status: 0x00000000
Pipe Handle: 0x9a072dc8 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
01 60 .`
857732: Bulk or Interrupt Transfer (DOWN), 24.09.2010 11:30:15.074 +0.015
Pipe Handle: 0x9a072df8 (Endpoint Address: 0x2)
Send 0x1a bytes to the device
1F 16 00 00 20 20 20 20 20 20 20 20 20 20 20 20 ....
20 20 20 20 20 20 20 20 51 85 Q…
857734: Bulk or Interrupt Transfer (UP), 24.09.2010 11:30:15.074 +0.0. Status: 0x00000000
Pipe Handle: 0x9a072dc8 (Endpoint Address: 0x81)
Get 0x2 bytes from the device
01 60 .`
857736: Bulk or Interrupt Transfer (DOWN), 24.09.2010 11:30:15.074 +0.0
Pipe Handle: 0x9a072df8 (Endpoint Address: 0x2)
Send 0x1a bytes to the device
1F 16 00 01 53 70 65 65 64 20 20 20 20 20 20 20 ....Speed
20 20 20 00 02 04 06 20 77 5A .... wZ
------------------------------------------------------------------------------------------------------
Is the 0x01 0x60 part of the FTDI driver interface? and am I missing the Corresponding command to send to the driver before it will send data to the display? I've been digging through FTDI examples but everything seems to have a PC OS associated with it and I'm not sure what I'm looking for.. The "0x1F" command is what I'm trying to send to it (I calculated the 0x5A77 crc value just like last packet above).
I'm not sure where to look at this point as don't have the ability to monitor the traffic between the AVR32 and display.. I'm hoping the "0x01 0x60" leads me to the key that I'm looking for..
Any help is most appreciated.
ef.
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.