Bongofish
October 16, 2018, 02:09:53 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: You may have to login twice the first time,  but we don't know why - Erm I mean it's a security thing yeah that's it - security.
 
   Home   Help Search Login Register  
Pages: [1] 2 3 ... 10
  Print  
Author Topic: Playing with the tx2000 Tablet-PC digitizer (SU5R-12W12AU-01X)  (Read 76345 times)
Trashie
Full Member
***
Posts: 120


View Profile
« on: April 02, 2011, 01:30:10 AM »

Hello! In this thread i'll post the progress i (hopefully) make investigating the tx2000 tablet-PC digitizer.

- Objective:
Being able to use the tx2000 screen as a cintiq, with minimal modifications.

- The problem
Translating the digitizer signal to something the Wacom USB drivers are able to recognize and handle.

- Tools
The Wacom digitizer can be found in pc-hub for around 6$.
The cable connecting the digitizer to the mainboard of the tx2000 (so we dont have to make our own), can be found for 2$.
Arduino nano for handling the digitizer input and (hopefully) sending it to the USB port in the PC.
Breadboard, multimeter, etc.

This thread is started to avoid cluttering bernard's thread about his great advances on this topic (see http://forum.bongofish.co.uk/index.php?topic=1738.0) for ADB tablets

Following the conversation there, i "chose" Arduino for it was a platform that had me intrigued for some time, aaand..because was inmediately available from my local store, and wanted to know the platform before the digitizers arrive.
I got the Nano 3.0  because it was the only Arduino on stock :-P, but looks fairly simple.

About the virtual serial port .. yes, that came to my mind inmediately when i connected the board to the PC..But i guess it'd be possible to use other digital outputs for sending the USB data, and leave that serial interface for debugging,
or for another idea i've in mind.Yes, i hope to start from your code, and the linux drivers, but until i get the digitizers and gather information (if any...) about the pinout...
One thing that worries me are the cables i've ordered.From the photos, looks like there are unused spaces between them, so i guess there are no cables for some pins, and, following the hypothesis that there may be pins for usb interfacing
(first thing to test), maybe there are no cables for those pins.

Until i get the digitizers, my plan is to start playing with a Graphire 4 tablet i have around.Sacrificing 2 usb cables, i will try to "pass-thru" packets from the tablet to the arduino, and from it to the pc,while debugging to the serial console,
to begin to understand the underlying protocol.


The reason for wondering about using 2 digitizers at the same time, is : being those digitizers so cheap in comparison with a wacom intuos, would it be possible use those digitizers instead an intuos for the "traditional" (intuos+monitor) designs?
Problem, of course, is those digitizers are small (for 12.1 screens).Would it be possible to duplicate that working area laying 2 digitizers together, so they form a single, double-size working area?
Of course, there must be some sort of coordinate translation, and the joint would be a problem too,but if the two i've ordered survive my "handling", i'll try to test that.
 
« Last Edit: April 02, 2011, 01:32:28 AM by Trashie » Logged
bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #1 on: April 02, 2011, 01:37:17 AM »

Nice journey!

Oohh -- it is a Nano -- not an Uno (I problably misread)? 

I certainly do not want to discourage you, but here's a couple of reality checks here:

I might be wrong, but I think you cannot "big-bang" pins to emulate a USB ports with this type of processor: You just do not have enough of 16Mhz to do so on the Nano 3.0.  For the low-end chips, you need one with a dedicated USB port (there are plenty of those these days) -- the raw USB protocol is quite complex, not your simple RS-232 port.  You can take a look at the USB specification to get a feel of what's involved.

The other alternative is to use a software USB trace software on the host machine to analyse the "high-level" packets bytes.  (but that won't give you the physical signaling layer).
 
But the Arduino board can always be useful for all sorts of things, I used mine to sniff the Apple "ADB" bus for analyzing and debugging purposes.

You can effectively connect two penenabled/TabletPC sensors side-to-side. Mapping the coordinates is the easy part. The first issue, I think, will be the "seam" between the tablets -- maybe you can overlap them and reduce that seam. You will have to "deal" with "strokes" crossing sensors and merge into a single stroke. I would also imagine you might get interference between the two sensors -- each sensor emits and receives RF/magnetic energy.

We never saw a TabletPC sensor working using its "USB" connection. I know there are some that should work this way since the linux driver appears to be supporting them.  This might be an interesting avenue to investigate -- you might get lucky and connect it directly to the PC. Smiley

This is from a tx2000? According to our wiki, the model would be close to be a: SU5R-12W12AU-01X -- I see "12" in there, so that kinda match the 12.1 size you are refering to.
http://wiki.bongofish.co.uk/doku.php?id=bongofish:penenabled

If this is a 14 pins connector, then I would start with the pinout we came up on the wiki. I assume you have a multimeter?
« Last Edit: April 02, 2011, 03:08:53 AM by bernard » Logged
Trashie
Full Member
***
Posts: 120


View Profile
« Reply #2 on: April 02, 2011, 02:43:04 PM »

Hi, bernard, just a quick update..I'm trying to get working the v-usb library for arduino boards.It has an implementation of USB 1.1, supporting the 16Mhz processor in the 328 (Nano 3.0).I guess 1.1 is enough for the wacom, do you have any info on that?
Also, it comes with schematics to add the usb port to the board, and make the 5v to 3.3v conversion from the digital outputs to D+,D-.I know that's added complexity, but, while i get the digitizers, all this stuff is helpful to begin working with microcontroller programming.
Problem is, the Arduino IDE is acting wierd when compiling the library, so i have to switch to AVR Studio, which, in the end, i think it's the way to go.
When the boards arrive, first thing is investigating that usb output(if any),and see what's happening there (yes, i've the multimeter).If not, well, i hope i've a working USB port :-P
And, yes, the seam is the hard part...But well, if i get a single board working, it wouldnt hurt to measure those interference levels and see whats doable

[EDIT]: Usb library compiled and usb circuit in place..maybe are nonsenses, with my little (almost "no") experience in electronics and microcontrollers, quite happy! :-D
[EDIT2] Btw, another thing to test is that driver that  supposedly allows tablets to work from an usb-serial interface..As long as i can tell, only one person tested it, with a particular board..

« Last Edit: April 03, 2011, 08:21:36 AM by Trashie » Logged
bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #3 on: April 03, 2011, 02:39:54 PM »

Oh!  Good finding!!  That is good news!! Smiley

I think that v-usb thingy must be running at the slower speed (1,5Mbits/s) of USB -- that is probably why they say usb 1.1 -- which it sounds the chip might be fast enough for this.  Older Wacoms are typically 100Hz packets (100 packets per seconds) -- packets are from ~7 to 10 bytes depending on the protocol. Doing the math for the worst case : 10 bytes * 8 bits * 100Hz = 8000 bits per second or 8Kbits/s -- sounds good enough!  Smiley   Usb 1.1 also allows for 12Mbps which, again, I would doubt you can drive with a chip running at 16Mhz.

Logged
bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #4 on: April 03, 2011, 02:53:01 PM »

About your Graphire4, could you do something for me?  Run the usbview utility (as depicted in this post) and post the resulting USB descriptors for the Graphire4. 

http://forum.bongofish.co.uk/index.php?topic=1738.msg12401#msg12401

I would like to know how different it is from my Graphire3 and other wacom boards.
Logged
Trashie
Full Member
***
Posts: 120


View Profile
« Reply #5 on: April 03, 2011, 11:19:00 PM »

Here's the output from usbview:

Code:
Device Descriptor:
bcdUSB:             0x0101
bDeviceClass:         0x00
bDeviceSubClass:      0x00
bDeviceProtocol:      0x00
bMaxPacketSize0:      0x08 (8)
idVendor:           0x056A (WACOM Co., Ltd.)
idProduct:          0x0016
bcdDevice:          0x0403
iManufacturer:        0x01
0x0409: "WACOM"
iProduct:             0x05
0x0409: "CTE-640-U V4.0-3"
iSerialNumber:        0x00
bNumConfigurations:   0x01

ConnectionStatus: DeviceConnected
Current Config Value: 0x01
Device Bus Speed:     Low
Device Address:       0x01
Open Pipes:              1

Endpoint Descriptor:
bEndpointAddress:     0x81  IN
Transfer Type:   Interrupt
wMaxPacketSize:     0x0008 (8)
bInterval:            0x0A

Configuration Descriptor:
wTotalLength:       0x0022
bNumInterfaces:       0x01
bConfigurationValue:  0x01
iConfiguration:       0x00
bmAttributes:         0x80 (Bus Powered )
MaxPower:             0x14 (40 Ma)

Interface Descriptor:
bInterfaceNumber:     0x00
bAlternateSetting:    0x00
bNumEndpoints:        0x01
bInterfaceClass:      0x03 (HID)
bInterfaceSubClass:   0x01
bInterfaceProtocol:   0x02
iInterface:           0x00

HID Descriptor:
bcdHID:             0x0100
bCountryCode:         0x00
bNumDescriptors:      0x01
bDescriptorType:      0x22
wDescriptorLength:  0x0062

Endpoint Descriptor:
bEndpointAddress:     0x81  IN
Transfer Type:   Interrupt
wMaxPacketSize:     0x0008 (8)
bInterval:            0x0A

The USB device simulated in the Arduino board is a mouse that executes a certain movement pattern.My next step is to execute that same pattern, but identifying the device as this Graphire 4.

Have you tried this usb / serial sniffer? http://www.hhdsoftware.com/ It has a trial version for 14 days, and looks pretty useful
Logged
bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #6 on: April 04, 2011, 01:40:46 AM »

I tried many ones, and probably that one two. Actually I waited for one to finish the eval to start installing another to "extend" my USB monitoring (until I finally bought one in the end).

You will need to set exactly the same descriptors as the graphire4 (or very close) for this to work correctly.
Logged
bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #7 on: April 04, 2011, 03:44:04 AM »

That is pretty cool! 

Watch out! long post coming up (I like writing long posts, sorry about that).

BTW, I am using Eclipse CDT combined with the WinAVR (which is based off gcc -- same stuff Arduino and a lot of people are using). I never tried Atmel AVR Studio. It is certainly easier to setup with respec to AVR products.  I am used to Eclipse already and all the IDE niceties that goes with it [I do java programming for a living].  I also created an ArduinoCore eclipse project so I could re-used the core arduino library.  (which I later abandonned, but it was great for a start). I still have those around if you need something.  The one thing that I do not have is a debugger but that requires me to buy some extra hardware and connect it somehow. So my debugging went from the flashing LED (boy did I looked at that built-in led), sending pulses of different widths on a GPIO pin to be read by the oscilloscope to using a serial port and also a special high-speed "hid-based" debugging console (written by Paul, the Teensy guy).

Oh!  I just saw the following:  Device Bus Speed:     Low    -- that is the 1.5Mbps speed I believe.

Few notes from my past experience with this USB business:
You will also have to get the full HID descriptor (I think usbview does not give it all out) of your Graphire4 and replicate that (I assume the Graphire4 is the one you will emulate -- at least to start with). Also in those descriptors there is a endpoint number and size that you have to match with your v-usb setup.  The USB strings ID 01 and ID 05 (iManufacturer and iSerialNumber) do not need to be implemented -- but you should not return "an error" either.  Actually you can make the USB String Ids point to nothing I believe (with a number like 0x00, have to re-read that USB specification to be sure). The wacom driver does not care about them for sure. The wacom driver cares about the idVendor and idProduct first, but then the interface descriptors and even the HID descriptor. (I tried to sneak a debug port in parallel but really, nothing worked out, the HID descriptor had to match perfectly else I would get weird errors -- I tried many, many things to sneak out debug data).

I hope you are successful. Let me tell you that this is a great learning exercice!  For both the AVR & Arduino platform and the world of USB and HID in particular (which is a world on its own). (It had my Win7 64-bit blue screen quite a few times, but, nothing fatal).  HID is great since you essentially do not need to write a USB driver when implementing a new device!  Your application can directly listen to your device -- and actually any other HID-based device for that matter.

I am looking forward to look at your code and maybe we could merge the projects -- or integrate pieces of it somehow. Having the Arduino Nano 3 as an option to host my project sounds interesting. I will follow you closely. Already awaiting your next post. Smiley

Now I just hope the Nano can handle 2 software serial port and 1 software USB port at the same time!  Maybe you could give it a break and re-allocate the hardware serial port to one of the tablet(??).

Good luck!


EDIT:  I just went peeking at the v-usb project and code -- They are more crazy than me!!   I would never even attempted to do this, they carefully crafted the code to fit precise crystal speeds (approx. from 12 to 16Mhz).  BTW, that made me thinking:  most likely the tabletpc wacom sensor is expected to run at 3.3v.  AVR chips at 3.3v tend to not support 16Mhz and you have to reduce the core speed to 8Mhz (something that can be done by playing with the CPU prescaler setting without touching the hardware). Well... unless you overclock it. It had been reported to me that the AVR appears to work at 16MHz @ 3.3v -- So that might be your best bet, you gonna need all the chip can offer! The AVR spec says: 4.5v minimum supply for running the core at 16Mhz.

Mode of operation of v-usb:  There is an "edge" interrupt that wake up and all the code runs under interruption, no other interruption is allowed to jump in else it will break the timings. All the "timings" and "pulses" are done with "instruction delays". That means that when that interrupt is running, nothing else on the AVR can run -- typical of big-banging algorithm.  I am still wondering what is the "worst case" time that the interrupt can be held? and what is the fastest time an v-usb interrupt could occur? I am thinking maybe the software serial port could be done using input capture timers so even if your are stuck in the v-usb interrupt, the timer would kick-off right away (in hardware) and you could read the timer value when you finally get into your input capture interruption to know where you are in the serial bits timings.

The slower the serial ports baud rate, the easier it will be to handle the load. The typical baud rate speeds of wacom boards are 9600, 19200 and 38400 bauds. Some wacom boards can have their speed modified (for example, to run at 9600 or 38400).  If you want, I can potentially try to reduce it to 9600 on the tabletPC I have here to see if that's possible.  The Linux driver lists a few commands, but it is not clear to which tablet these apply exactly.  The TabletPC boards typically speak "ISDV4" so that is a hint.

« Last Edit: April 04, 2011, 04:36:42 AM by bernard » Logged
bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #8 on: April 04, 2011, 04:49:26 AM »

btw, I adapted the rawhid utility from paul (prjc.com) to bind to the first Wacom device it founds on the system (i.e. VendorId == 0x056A). It should work with your Graphire4. It should output all "HID report" packets coming out of the Graphire4 if that can be of any help.

http://sites.google.com/site/bernardpublicstuff/wacom_rawhid_dump.zip

I have other versions which interprets the bytes. I have a Win64 system, I am not sure if it works on Win32. (what OS do you have?)
Logged
Trashie
Full Member
***
Posts: 120


View Profile
« Reply #9 on: April 04, 2011, 06:26:52 AM »

Updates:
Got the board recognized as a Graphire 4 :-D. I got the full HID, and right now i'm sending the same message all the time.I got the message from that usb sniffer, but have already looked around the linux driver, and looks (mostly) simple.
So, it makes my pointer jump to a fixed position.After that, i can move the mouse freely, even if the tablet is sending the same event.I guess the Wacom driver is discarding those duplicated events (same as if you'd left the pen over the tablet, and then use your mouse). But the OS (Windows 7 32 bits) is launching the on-screen keyboard and usbview reports everything ok.

About the linux driver..Have you noticed there are 2 specific defines for tablet PC's?
WACOM_REPORT_TPC1FG , with 6 bytes-len reports, and WACOM_REPORT_TPC2FG with 13-bytes len reports.
I guess those 13 bytes are for multitouch input or something like that..And the 6 bytes len reports are for older tablets (like mine).Just supposing, i havent still looked at that code.
What might be interesting, is (in case no direct connection is possible and all this Arduino thing is actually needed) even if the packets come in a WACOM_REPORT_TPC1FG format, still impersonate a graphire to add buttons managed by the Arduino board, and send their state along with the position..

If i get time after work, i'll try to actually encode messages doing something meaningful :-P
« Last Edit: April 04, 2011, 06:33:19 AM by Trashie » Logged
bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #10 on: April 04, 2011, 01:24:37 PM »

yay!! progress! 
Logged
Trashie
Full Member
***
Posts: 120


View Profile
« Reply #11 on: April 04, 2011, 08:27:25 PM »

Update :
Got positioning + pressure working :-D
Sending commands from the Arduino board, it draw a gradient in photoshop (varying x, y and pressure).
I've to test changing the tool , and pen buttons, but looks like i'm beginning to need those digitizers here soon! :-D

Some images:
Schematic for the USB port i'm currently using (note that this setup makes the board get VCC=3.6V aprox).Maybe a better solution would be use 2 diodes in D+ and D-? Or maybe this setup is sucking less power from the USB host so the digitizer can get enough power to run?

* with-series-diodes.jpg (21.36 KB. 227x434 - viewed 730 times.)


This is my *cough* "system" *cough*

* 20110404_002b.jpg (70.98 KB. 519x394 - viewed 739 times.)


There you can see  the output in photoshop.If you're noticing something like a "moire effect" is because some horizontal lines were not drawn (just was lazy and didnt adjust graphire x/y to monitor x/y)

* 20110404_001b.jpg (71.93 KB. 519x394 - viewed 751 times.)

 

« Last Edit: April 04, 2011, 10:58:26 PM by Trashie » Logged
Trashie
Full Member
***
Posts: 120


View Profile
« Reply #12 on: April 04, 2011, 11:34:07 PM »

Btw, i find interesting this two images.Those are the images i'm rendering, one with black background and a 1px white airbrush 100% opacity, 100% flow, normal mode.The driver is at "standard" settings (lol, i'm not able to change them if i connect the board, as it "pulls" the mouse).

The second one,  green background, 1px white airbrush.
Those images are generated increasing the pressure sent (supposedly) by a Graphire 4:
My impression is there's no lineal increase at all :-P

* blackwhitegradient.png (14.67 KB. 403x236 - viewed 618 times.)

If you look at the b/w picture, you'll see there are "blocks" of color.In fact, the "darkest" gray i'm getting, is RGB =(14,14,14).This is, under a certain pressure (cant tell right now which value), the "real" pressure applied is...0. (no color change).One level of pressure more, and you get 14,14,14. Woha..Intriguing..

In the second image, you see this same problem .. Under the "1", there should be quite a few color values more..
Under the "2", you can see how slowly the color increases..This same effect can be seen in the b/w image.
There's a certain pressure value that makes the color "jump" to a quite higher level (higher in the sense we have(?) 512 pressure levels, to map in a space of 0-255 values per RGB...So there 2 different pressure levels for each RGB..why the blocking then?
And, under the "3", you can see a funny thing..There's a peak in the color value, this is, there's a point having a *less green* value in its left,and a *more green* value in its right.

* greenwhitegradient.png (0.9 KB. 433x53 - viewed 546 times.)


I really dont know if this is intentional or not ( i mean, maybe they've found this kind of setup is a "more natural" setup instead a simply linear one, but , in any case...

Logged
Trashie
Full Member
***
Posts: 120


View Profile
« Reply #13 on: April 05, 2011, 01:45:28 AM »

Btw, bernard, i hadnt noticed your comments about the power issues.As states the post above, i'm right now using diodes between the USB 5V and the 3.3V input in the Arduino board.But, when powered by 5V, the arduino has that 3.3 pin active, so there's a source for 3.3V.
In the vusb tarball, there's a "circuits" folder with different setups.I just used this one because i did have those diodes, and had not to walk to the store.I see other alternatives, but i'm just a newbie in electronics.
Would it be possible to get the same result if the diodes are moved to the D+ and D- lines?
Would it be possible to use the 5V from the digital outputs of the arduino board to control 2 transistors having in the emitter the 3.3V source? (Maybe some math needed to calculate resistor values).

About usb/serial synchronization...I really need some help here..Im not familiar with interrupt-driven programming, and the concepts related to this kind of programming are mixed with USB concepts in the documentation, so this is even harder :-P
Relevant parts in the doc (well, usbdrv.h :-P )

Code:
The device MUST be clocked at exactly 12 MHz, 15 MHz, 16 MHz or 20 MHz
or at 12.8 MHz resp. 16.5 MHz +/- 1%. See usbconfig-prototype.h for details.
Does this mean the Arduino is not working at 8Mhz with my current setup?

When you say the AVR "That means that when that interrupt is running, nothing else on the AVR can run", you mean "another interrupt", right?
Is the USART still working and getting serial data?


Trying to understand all the interrupt-related stuff..For now, the usbdrv.h mentions:

Code:
Please note that the USB standard forbids bulk endpoints for low speed devices!
Most operating systems allow them anyway, but the AVR will spend 90% of the CPU
time in the USB interrupt polling for bulk data.
I dont know what are "bulk endpoints", but i guess if the USB standard forbids them, Wacom will not be using it

Code:
Interrupt latency:
The application must ensure that the USB interrupt is not disabled for more
than 25 cycles (this is for 12 MHz, faster clocks allow longer latency).
This implies that all interrupt routines must either have the "ISR_NOBLOCK"
attribute set (see "avr/interrupt.h") or be written in assembler with "sei"
as the first instruction.

Maximum interrupt duration / CPU cycle consumption:
The driver handles all USB communication during the interrupt service
routine. The routine will not return before an entire USB message is received
and the reply is sent. This may be up to ca. 1200 cycles @ 12 MHz (= 100us) if
the host conforms to the standard. The driver will consume CPU cycles for all
USB messages, even if they address another (low-speed) device on the same bus.

Any comment on those?


Logged
bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #14 on: April 05, 2011, 03:28:17 AM »

Quote
When you say the AVR "That means that when that interrupt is running, nothing else on the AVR can run", you mean "another interrupt", right?
Is the USART still working and getting serial data?

Nothing else in terms of "code" (e.g. Another interrupt or normal not-under-interrupt code) -- all the hardware-based stuff will continue to work (timers, USART, whatever).  For the v-USB code to run successfully it has to "steal" the CPU to provide the exact timings (nothing must interrupt it or it will create unwanted delays and break the USB connection).  I was wondering about the worst case time the v-usb will do its thing -- it appears that this is about 100us (according to the text you found). 

So that essentially means that other processing can be halted for 100us. My concern here is doing a software serial port in parallel. The normal hardware USART will function -- it has a buffer (not sure how big though -- have to check the datasheet) and it will fill that buffer until you can respond to the serial receive interrupt and empty the buffer.

We have to do the math.  The tablet baud rate is important to know -- I think all ISDV4 boards runs at 38400 (sadly for you, the fastest speed).  Let's use that for doing the math.  We also need the USART  port receive buffer size.  -- according to the 12mb datasheet ( http://www.atmel.com/dyn/resources/prod_documents/doc8271.pdf ) -- this datasheet is your master reference btw.  The receive buffer contains a whopping ... 2 bytes  Roll Eyes (on top of the "shifting register" I think.  Ooooookay, so 2 bytes at 38400 baud.  38400 baud is close to 3840 bytes/secs -- that is about 1/3840 seconds or ~260us between bytes.   So 2 bytes is 520us of waiting.  That sounds like it can work with the hardware USART.

Bulk:  No, you are not using Bulk mode, you are using Interrupt mode. -- If I recall correctly, Bulk is for stuff like mass storage (USB key or hard drive).   Each endpoint can have a mode of operation. (Interrupt, Bulk, Isochronous) -- Interrupt is for an ad-hoc, immediate event (not a lot of data typically), bulk is to send massive amount of data "when the bus is free to do so", and Isochronous is for real-time streaming of data (a time slot is allocated for your device -- this is to do stuff like an audio stream for a microphone or speaker that cannot tolerate waiting).    I believe HID devices cannot do Isochronous but is allowed Interrupt or Bulk.

(The "AVR or CPU interrupts" has nothing to do with the USB endpoint modes -- do not confuse the two -- same word, different meaning)
« Last Edit: April 05, 2011, 03:30:50 AM by bernard » Logged
Pages: [1] 2 3 ... 10
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!