test1
March 24, 2017, 11:17:34 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: You can attach photos hosted by the forum rather than using an external image hosting site, this means they will stay forever and not disappear after a year or two.
 
   Home   Help Search Login Register  
Pages: [1] 2 3 ... 13
  Print  
Author Topic: WaxBee project  (Read 54511 times)
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« on: September 06, 2011, 05:09:11 AM »

The WaxBee project is the magic touch that makes serial/ADB tablets act as 'native' USB tablets.  It's the software that runs on the Teensy (or equivalent).

Project is open source and located here : http://code.google.com/p/waxbee/

(Huge) thread where it all started : http://forum.bongofish.co.uk/index.php?topic=1738.msg12302#msg12302
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #1 on: September 06, 2011, 05:10:21 AM »

New version 0.10 adds support to program the Teensy within WaxBee from 32 bits Windows environment.
Logged
tufty
New Poster
*
Posts: 25


View Profile
« Reply #2 on: September 29, 2011, 07:54:31 PM »

Bloody hell, I missed this.  Bernard, that's fantastic work.

simon
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #3 on: September 30, 2011, 12:26:33 AM »

Hello simon, your help to jumpstart this whole thing was invaluable. Now it is used by quite a few folks. I have converted not only ADB but Serial-based ones as well (including penenabled (TabletPC) serial-based wacom sensors).
Logged
tufty
New Poster
*
Posts: 25


View Profile
« Reply #4 on: September 30, 2011, 07:18:16 AM »

I'm really glad someone's gone up and running with the info I managed to glean, to be honest.  I was about to start coding up something equivalent for a little ARM dev board I have lying about here, but I'm shelving that for now...

Quick question, though.  What's the running memory (i.e. RAM) footprint of the AVR code for ADB?  I'm having trouble sourcing an actual teensy over here, but there's a bunch of "more or less equivalent" dev boards out there, but they have half the memory (ATmega32U2 rather than U4, 1K vs 2K RAM).  I'm guessing I can get away with that, but not sure.
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #5 on: September 30, 2011, 08:40:47 AM »

The info you gleaned, keeping the Wacom ADB-related drivers as well as other ADB stuff around was an invaluable step for me to be able to do all that ADB stuff. I am not sure if I would have been able to do anything without it frankly.

---------

Really, it would be better to use the same CPU -- there is an equivalent breakout board from Adafruit. The "Atmega32u4 Breakout Board+". The only real difference is the bootloader (which is not a problem really). Some suppliers are in europe. Try to source that if you cannot get a Teensy (how come you can't get it from paul btw??).

http://www.robotshop.com/eu/adafruit-atmega32u4-breakout-board.html
http://www.eztronics.nl/webshop/catalog/product_info.php/products_id/412 
http://www.robot-italy.com/product_info.php?products_id=2026

Some other AVR CPU have different "USB" characteristics (like buffer maximum sizes for endpoints for example). There might be other differences I am not aware that might be annoying to fix. If you use the same CPU, it will also ease each time WaxBee gets to a new version. I already did many revisions of the software.

For the current program space foot print I do not remember at all. You can try to download the latest WaxBee and run -- in theory this application should run on Mac OSX -- Run it up to the point of generating a .Hex file.  I think the software shows the total bytes. If not, then try to run the "Program device" (it will fail for Mac OS since I did not compile a native library for it yet), but it should show the size of the firmware in the window "behind" the error message box. (The total foot print size is the original firmware code + "injected parameters" which varies in size depending on what you configure).

The other variable to consider is the free "RAM" space. That won't show in WaxBee. This is only when I compile it that I see it. If you still want to know, I will load and check it out from a build in my Eclipse IDE. I recently did a big change to put as much "Strings" in Program space as possible. (in C/CPP, each string, even if immutable, take program space and RAM space). So that change alone reduced my RAM footprint  (it was something like 85% if I remember correctly). But I could do better (if I ever need more space) -- I declare a lot of structures as straight global variables. For example, Wacom Protocol 4 and Wacom Protocol 5 have their own separate stuff -- both eating RAM space -- and only one protocol is used at any one time.
« Last Edit: September 30, 2011, 08:45:29 AM by bernard » Logged
tufty
New Poster
*
Posts: 25


View Profile
« Reply #6 on: September 30, 2011, 12:30:24 PM »

(how come you can't get it from paul btw??).
It was more a question of shipping costs, which are quite significant, but I've actually got another couple of projects on the go (iPaq "stowaway" keyboard -> USB, for example) which might be able to use a teensy, so maybe I'll just bite the bullet and order a few at once.  The adafruit board works out more expensive than the teensy anyway, even with shipping included, so hey.

I was looking through your code, I *think* your menu strip handler is b0rked.  From my UD0806A, ISTR that a menu strip event looks like this:

Bx 00 yy 00 00 00 00 00 : Stylus menu strip event, x is stylus button encoding as per a "normal" button event, yy is the menu strip button entry
9x 00 yy 00 00 00 00 00 : Puck menu strip event, x and y as above.

I may well be misreading your code, though.
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #7 on: September 30, 2011, 04:40:57 PM »

Wow! someone looking at the code!  Grin  All the menu strip logic is not really finished and is thus in "limbo".  The idea is to have internal button events that would work from different sources (tablet menu strip, teensy GPIO pins, dedicated tablet zones) and be able to map them to the target USB device menu strip, buttons and whatnot. I've started putting the architecture to support this, thus I am not surprised that something is wrong (I am not following exactly what, can you point to a specific line in the code?) -- and you are saying that using the Puck gives out a different message than with the pen? yipes. In more recent wacom tablet models (XD series for instance), the menu strip is not implemented in the tablet. The active area is simply extended to include the menu strip area and the wacom driver software does the mapping. Actually for some older series (UD or GD can't remember) the smaller tablets tend have the mapping done in the driver whereas the bigger tablets have it done within the tablet itself (I assume that is to simplify support of "custom drivers" in each applications -- A practice that was common in the days of DOS).

I do not really support the puck either BTW (unless it is the same thing) -- I never felt the puck to be useful and nobody asked for it. But you may prove it differently. Smiley

Do I infer that you are trying to convert it to USB? I thought you had it working already with the iMate and your Mac OSX driver, etc?

BTW, the Teensy is physically smaller than the Adafruit one, this is really nice for embedding and hiding inside cases. The Arduino is a rather small board that fits in one palm's hand but it looks huge when put next to a Teensy!! Smiley

« Last Edit: September 30, 2011, 04:43:14 PM by bernard » Logged
tufty
New Poster
*
Posts: 25


View Profile
« Reply #8 on: September 30, 2011, 08:00:02 PM »

Wow! someone looking at the code!  Grin  All the menu strip logic is not really finished and is thus in "limbo".  The idea is to have internal button events that would work from different sources (tablet menu strip, teensy GPIO pins, dedicated tablet zones) and be able to map them to the target USB device menu strip, buttons and whatnot. I've started putting the architecture to support this, thus I am not surprised that something is wrong (I am not following exactly what, can you point to a specific line in the code?)
Ah, that figures.

The code I was looking at was pen_button_handler.cpp, which, unless I'm misreading totally, appears to only be looking for ADB packets starting with 0xB0.  As far as I can recall, those only happen when you let go of all buttons when hovering over the menu strip - you don't get proximity messages for the menu strip, only actual button state changes.  I think.  Can't find my analyzer logs now.

and you are saying that using the Puck gives out a different message than with the pen? yipes.
The only difference is the pen / puck bit (bit 5 of the first byte) and the fact that button encoding for the puck is sane.

I do not really support the puck either BTW (unless it is the same thing) -- I never felt the puck to be useful and nobody asked for it. But you may prove it differently. Smiley

Do I infer that you are trying to convert it to USB? I thought you had it working already with the iMate and your Mac OSX driver, etc?
Most people don't have pucks...  I have one, and it can be *enormously* useful for tracing drawings and other delicate work.  Don't use it much, but when I do, nothing else will do the job.

And yeah, I'm gonna go USB.  The driver's getting to be a bugger to maintain.  Can't get it to work *at all* on 10.6, which means the tablet's hooked up to the second mac rather than my main one.
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #9 on: September 30, 2011, 11:17:19 PM »

yes, the menu strip outputs a button packet. But that is different from tablet to tablet. In general the more recent, the less likely it reports button packets. And in some case, the size of the tablet appears to make a difference on that regard.

oh that hex string 0xB0 x1x1 y1y1 x2x2 y2y2 btnNo  is a configuration parameter to configure a "zone button" area. (feature not working yet). Nothing to do with the ADB packets!

When you say the "puck" you really mean that mouse-like device with a clear plastic piece with a "cross" to precisely position it?  In my case, I was talking about a "plain mouse". (no cross)

For ADB, the decoding of bits is done by overlaying a bitfield structure (adb_codec.h and adb_tablet_defs.h) over the received bytes. This is governed by an ADB state machine (adb_controller.cpp). The ADB signal decoding logic is in adb_codec.cpp

BTW, it is very well possible that the ADB puck works - just that it will be reported as a pen. Not all the puck buttons might be mapped (how many buttons do you have on your puck?). If you want to use the puck then we can try to fix it (if we ever found what a puck "tool id" looks like?). The best would be to find someone with a similar Intuos2 device and make him run a USB Trace to see the packets.
« Last Edit: September 30, 2011, 11:33:40 PM by bernard » Logged
tufty
New Poster
*
Posts: 25


View Profile
« Reply #10 on: October 01, 2011, 09:17:57 AM »

For ADB, the decoding of bits is done by overlaying a bitfield structure ...
Ah, so I was misreading.  Fair enough.

BTW, it is very well possible that the ADB puck works - just that it will be reported as a pen. Not all the puck buttons might be mapped (how many buttons do you have on your puck?).
Puck button encoding (on the adb side) is different to pen button encoding.  Because the pen button encoding is insane.  Here's how it works:

For a puck : the "button" nybble encodes the button number on the puck as follows (at least for my 4 button puck, the intuos lens cursor and so on have at least 5 buttons) :

1 - Front Centre
2 - Left
3 - Back centre
4 - Right

Note - this doesn't allow for detection of multiple buttons at once.  It seems to pick up the first button pressed.  I do not believe there is any difference between the packets sent by the "lens" puck and a non-lens variant, except where the samples are centred. 

I'd guess you have pen button encoding handled properly, but just in case:

For the stylus (ultrapen eraser), it's all a bit arse arse as the number is a bitmap of the "tip pressed" and button
Button = 1 - nib pressed
Button = 2 - side button 1 pressed
Button = 3 - nib pressed and side button 1 pressed
button = 4 - side button 2 pressed in proximity *or* eraser in proximity
Button = 5 - Eraser pressed *or* side button 2 pressed and tip pressed
Button = 6 - Eraser in proximity with side button 1 pressed
Button = 7 - can't do this, I don't think.

A little explanation from the wacom docs...
# When the eraser is in proximity of the tablet, or the second side switch is pressed while the pen is
# in proximity, then the tablet will transmit a switch number of 4. When the eraser tip is pressed
# against the tablet, or the second side switch is pressed while the pen tip is pressed against the
# tablet, then the tablet will transmit a switch state of 5.
#
# Note that the tablet cannot detect the difference between an eraser in proximity and a pen tip with
# the 2nd side switch pressed in proximity (switch state 4), and it cannot detect the difference
# between an eraser pressed against the tablet and a tip pressed against the tablet while the 2nd side
# switch is pressed (switch state 5).
#
# Note: The WACOM drivers differentiate between the eraser function and the second side switch
# function by analyzing the first switch state transmitted after the pen enters proximity: if the initial
# switch state is 4, the driver assumes that an eraser is now in proximity, and if the initial switch
# state is 0 and changes later to 4 or 5, then the driver assumes that the pen tip is in proximity and
# that the 2nd side switch was pressed at the later moment.

If you want to use the puck then we can try to fix it (if we ever found what a puck "tool id" looks like?). The best would be to find someone with a similar Intuos2 device and make him run a USB Trace to see the packets.

http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/input-wacom;a=blob;f=2.6.36/wacom_wac.h;h=a4399a41f8d3ee658f1651d44cbdd965e9128dba;hb=HEAD suggests that the HID report identifier should probably be 0x06, but I'm not certain if it sends a different packet.  Would need to trawl through the Linux code again, I think.

Code:
/* device IDs */
#define STYLUS_DEVICE_ID        0x02
#define TOUCH_DEVICE_ID         0x03
#define CURSOR_DEVICE_ID        0x06
#define ERASER_DEVICE_ID        0x0A
#define PAD_DEVICE_ID           0x0F
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #11 on: October 01, 2011, 03:54:17 PM »

For the stylus it works marvel already. Thanks to your ADB discoveries (and lots of experimentation on top). Most of the old analog wacom tablets (e.g. UD) have this special eraser thingy, but the digital ones (e.g. XD) work differently and have a tool long serial number. The eraser has a separate serial number than the pen. That is the tool id I am talking about. The linux driver only lists a "portion" of the serial number. Which is why it is difficult to guess what is the full serial number of the tool. This is the general problem with the linux code: it only looks at a portion of the packets and thus, the "rest" contains bits that maybe the Wacom driver looks at, but we cannot "know" their values unless we see one in action or we put random numbers until it "appear" to work.

But until we find a intuos2 puck device (I might have one, have to check), the linux driver is the best source of info to guess at the encoding for the Intuos2 emulation.

I am not sure what the report id #6 is for exactly, I never saw anything "special" happening in there.

Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #12 on: December 05, 2011, 04:14:00 AM »

This is an awesome project.

I've got an Intuos GD-1218-R I'm considering converting to USB but it looks like I'll lose access to the menu strip, correct?  If I were to delve into the source code, do you have any vague ballpark estimate of how long it might take to figure out what's what and get the menu strip working?  I work with C++ for a living so understanding it at that level won't be a problem.
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #13 on: December 05, 2011, 05:37:58 AM »

GD-1218-R?  wow, that's a huge intuos1!  For intuos2, the menu strip works fine since we directly relay the same data. It's the same tablet.  For Intuos1 (GD), there might be some work involved indeed.

A couple of questions: What is your operating system? Windows, linux or Mac OSX?  (I ask that because *I think* the menu strip support is not equal across all OSes).
Do you use the menu strip a lot?  I believe Wacom dropped the support for those in newer tablets, I was wondering if anybody in 2011 was actually using them?  It always felt cumbersome to move the pen away and start looking directly on the tablet to find the buttons.

A lot of work is already done to achieve this but some stuff remains to do. How many buttons do you have in your model? (higher-end models tends to have more buttons).

Another member is currently talking to me about a similar topic but for his UD-1212-R. I do not have much time on my hands right now, but I am willing to help out.
Logged
Sergio
New Poster
*
Posts: 5


View Profile
« Reply #14 on: December 12, 2011, 04:23:52 PM »

Hi guys,

I just found out about waxbee, that looks like a really cool project! I happen to have a old ADB Wacom digitizer (A5 artpad) lying around, and could buy a bigger, serial-based one (ultrapad, 12*12) at a very low price. Would both work? Where can I find a diagram for serial and ADB wiring?
BR,

Serge
Logged
Pages: [1] 2 3 ... 13
  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!