Screen Tablet malarky => Tablet Conversion to USB => Topic started by: bernard on May 11, 2016, 04:32:54 AM

Title: WaxBee Feature Requests
Post by: bernard on May 11, 2016, 04:32:54 AM
Ertew was throwing ideas for some features for WaxBee. So here's a dump of our conversation to everybody's benefit. So I named it "feature request" so anybody can chime in to try to influence the direction of this project.  ;D

Quote from: Ertew
Hoooray. Good to know that new firmware version will fit into Pro Micros and clones with stock bootloader. Please keep going.

If You making changes, I have few ideas:

- Can You split templates to two independent flies: 'input' and 'output'?
By input I mean everything digitizer related, like ADB/ISDv4/serial IV protocol, resolution, tilt, maybe hardware buttons.
By output I mean everything USB emulation related, mainly type of tablet that was emulated (Intuos2, Intuos5, Graphite, Bamboo and different sizes of that tablets).
That change will allow users to build firmware from blocks and make easier to add new templates for new hardware.

- Actually CPU run at 16Mhz or half of it, while USB always run at 48Mhz (16Mhz quartz * PLL factor).
Can You add option to select 8Mhz Quartz speed? This option need to modify PLL settings, nothing more.

Last thing, that I forgot to mention in tutorial. AVRs have 5 different types of memory.
Flash, RAM and EEPROM are pretty obvious. Last two are fusebits and lockbits.
Fusebits are like jumpers on motherboard. If uC working, do not play with that. Wrong settings can disable crystal oscillator. Repairing that was quite funny.
Last thing are the lockbits. They can protect flash from being overwritten. If You have good settings here, writing more than 28k via bootloader will fail at 28k. Wrong settings results a broken bootloader = You need to buy/build an programmer and rewrite bootloader before next use.
If You take care about programming lockbits and not touch fusebuts, You should be able to recover broken Pro Micro.

Title: Re: WaxBee Feature Requests
Post by: bernard on May 11, 2016, 04:34:04 AM
I am done with my changes... but I can do more.  ;D

Split templates to two independent files
Ah! I understand! to mix & match any input / output tablets instead of having to create all combinations upfront?  Sounds like a great idea! Hum...  What about doing a more generic "partial templates" concept? Like a "partial template" would only modify a "portion" of the values? We could create arbitrary grouping of data for any kind of feature and simply "apply" it.  Let me digest this concept a little to see how it could work out "easily" in the UI...

8Mhz Quartz
Are there 8Mhz Quartz AtMega32U4 systems out there? Can it be done all at runtime or do I need to recompile with a different F_CPU value (which could be problematic)?

Memory Types
I am not sure what you are asking here?  What can WaxBee do to help out?  Is it that easy to brick a Pro Micro ?! Like, you get it delivered (Pro Micro chinese clone), you flash *any* 29K size .hex using avrdude and you're toast?

I will be testing on a Pro Micro clone (will be a few weeks before I get it). Looking at the datasheet I just realized that the "Led" configuration is different than the Teensy 2.0. Well, actually *each* Atmega32u4 boards have their LEDs hooked to a different pin it seems. So I might add a "Led" setting to control where to lit up the Led.  And if I ever do that "partial template" thingy, I might have a series of template to "match" boards. (like the LED configuration and 8Mhz Quartz settings).  

Anyways, still sorting this out in my little head...

Title: Re: WaxBee Feature Requests
Post by: bernard on May 11, 2016, 04:38:32 AM
Quote from: Ertew date=1462920708
Split templates to two independent files
Yes, You have very nice idea. Even better than I expected.
I have zero knowledge about Java (small about C and quite big about electronics) so please think about it without my support.

There are at least 4 different platforms with AtMega32U4:
- Teensy 2.0
- Arduino Leonardo (useless, too big to implement)
- Arduino Micro by Arduino (
- Pro Micro by Sparkfun (
Note size difference between A. Micro and P. Micro. There are available clones for both versions, but bigger board = higher price.

There are difference on LEDs:
 - Pro Micro have same RX/TX LEDs as Leonardo but and lack of User LED and some I/O pins.
 - Arduino Micro have same User LED as Leonardo. It also have same pins for RX/TX LEDs but logic for that LEDs are reversed!
So in my opinion, LEDs for Arduino & clones can be ignored at this moment. There are a lot of more important things to improve.

8Mhz Quartz & 3v3
AtMega32U4 should run at 8Mhz on lower voltage. As I see, Teensy have jumper to switch voltage, quartz should be divided at software level.
Arduino products are designed to be simply, 5V and 16Mhz for everyone. WaxBee can run at 8Mhz on Arduino. 5V only might cause a problem for digitizer, but We can talk about it later.
Sparkfun are a black sheep here. No jumpers, just two independent products: Pro Micro - 5V/16MHz ( and Pro Micro - 3.3V/8MHz (
Why It's so important for me? Because Pro Micro 8Mhz have very cheap clones with 3v3 LDO on board. That would be super easy for peoples to start.
What should be changed in code? As far as I know, code should be compiled as for 8Mhz on 16Mhz quartz, but prescaler for CPU and for PLL should be turned OFF. I'm searching for
PLL_CONFIG(); // config PLL
but can't found it.

Memory Types
Sorry about my poor language and putting messy there. If anything is unclear, please ask, I'll try to find example over network and send link.
The rules of fusebits & lockbits are:
1. Fusebits can be changed only via ISP with fusebits specified command. If board worked before, do not touch this. There You can brick board.
2. Lockbits can't brick the board, just block reading/overwriting of flash&eeprom.
3. To set lockbits You need specified fusebits command via ISP. Only way to clear lockbits are 'full chip erase' that wipes out flash.
4. Programming flash (burning bootloader) via ISP programmer always use 'full chip erase' command so after programming that way You should set lockbits manually.

Why I'm writing that? Because Teensy, Arduino, Pro Micro and some good clones have right settings for lockbits. That mean that bootloader can't overwrite itself and will crash exactly at 28k. Reset and bootloader works again.
Bad clones doesn't have right settings for lockbits. Bootloader can overwrite itself and brick itself. That happens to me with one board (rest wasn't tested yet).
As You can read on forum (, I use old programmer to fix that. You probably need to build Your own by flashing 'ISP programmer sketch' ( into working clone or into one of Teensy boards.

Title: Re: WaxBee Feature Requests
Post by: bernard on May 11, 2016, 04:56:02 AM
Well I could easily drive the User Led, shutdown driving any Led or drive any other "signal" (if ones want to hook a led somewhere else).  Yes, not the most important thing (unless the led pin I am driving is not causing electrical issues when running in these other boards)

The Sparkfun pro micro does have a jumper (it's in the corner of the board and also appear in the schematic with a note about the voltage).

8Mhz Crystal
I do not know if the Crystal on the 3.3V version of the board is a 8Mhz crystal or 16Mhz? Sparkfun is totally dry of any details in that regards, the schematics are the same (says 16Mhz crystal) - you see a difference between the board photos: the jumper is soldered on one of them. The 3.3v LDO part appear to be present on both boards..?  Similarly, does the Pro Micro 3.3v really has a 8Mhz crystal?  Any other board with 8Mhz crystal?

So... what can WaxBee do to help not brick those clones?  Issue a big red warning when generating a .hex over 28K?

Partial templates
We could have "board" configuration templates on top of picking the input/output tablets

Title: Re: WaxBee Feature Requests
Post by: Ertew on May 15, 2016, 12:45:02 PM
I checked schematics for Teensy and Pro Micro and must note. These boards are incompatible at some cases.

8Mhz crystal
Yes, Pro Micro have 8Mhz version with 8Mhz crystal on board. I bought 3v3 8Mhz version clone and it comes with 8Mhz crystal. Photo attached.
Also every source over the network (except Sparkfun's official schematics) approve this. So I assume that there's a mistype on schematic.

*All my knowledge is based on Pro Micro clones. I assume that clones are 100% functional equal to Sparkfun's board, but I can't check and 100% approve this information.  

Power supply voltage
All Arduino boards are deigned to work at 5V level. Voltage may come from external supply higher than 6V (hence raw input pin, voltage pass through 5V LDO) or 5V from USB (bypassing LDO, because cheap LDO required at least 0.5V drop).
Teensy have voltage selector: 5V from USB or 3V3 from LDO. There's no raw input for supplying 6-12V from battery pack.
Pro Micro 5V are Arduino compatible. Jumper need to be closed to bypass LDO while powering from USB (I tested it, with jumper open, LDO have significant drop). LDO work only for external input.
Pro Micro 3v3 have open jumper so supply current always flow through LDO, no matter board supply. Both USB 5V and external supply are stabilized to 3v3. Unfortunately, board is incompatible with other equipment because have 8Mhz quartz.

In my opinion, jumper shouldn't be changed bu user. It's designed to reduce manufacturing cost. Difference between 5V 16Mhz version and 3V3 8Mhz version are: Quartz value, LDO value and some tin on jumper pads. Board layout persist the same so they can order big lot of same PCBs instead of two smaller with different layouts.

By your suggestion I think that Pro Micro 3v3 may be compatible with Teensy 2.0. If no raw input, supply voltage may be:
  • default 3v3 from LDO (jumper open),
  • 5V from USB (user close jumper).

Because of that, Pro Micro 5V 16Mhz may be used instead of Teensy as long as everything can work at 5V level (wrong choice, You need 3v3 LDO for Wacom digitizer). Pro Micro 3v3 8Mhz have integrated 3v3 LDO for digitizer but required different clock settings for USB PLL.

Every good product (all original boards) cannot make self destruct. Problem with broken bootloader persist only for cheap clones. So warning
Flash size above 28KB cannot be written via Arduino compatible bootloader. You may destroy bootloader. Please use Teensy board or external ISP programmer.
should be enough.

IMO that's all suggestions I have to say. Maybe next ideas appear later.

Title: Re: WaxBee Feature Requests
Post by: bernard on May 16, 2016, 06:57:49 AM
Yeah I am afraid of the 8Mhz crystal case. Sparkfun appear to insist on the user to make sure they select the right voltage. They never talk about "converting" a board to the other voltage. That tells me some parts are different (like the crystal), if it was only a jumper, they might have explained how to convert.

Nevertheless, even if Sparkfun's 3v3 board is 16Mhz, the fact that the clone version is 8Mhz is enough to attempt to support it. It's a viable alternative.

(wrong choice, You need 3v3 LDO for Wacom digitizer).

AFAIK, only for ISDV4 you need 3.3v -- All the Wacom tablets I have seen (ADB & Serial, Graphire, Ultrapads & variants, Intuos, Intuos2) -- ALL are running 5V internally.  The only 3.3v I have seen so far are the OEM ISDV4 boards.

Title: Re: WaxBee Feature Requests
Post by: Ertew on May 20, 2016, 04:08:23 PM
Yes. My 3v3 postulate is for serial digitizers and laptop/tablet screens with that digitizers.

I know nothing about stand-alone tablets, but latest serial devices might be produced in 3v3 era.
For RS232 interface only visible difference is the converter chip, usually MAX232 (5V) vs MAX3232 (3V3).

Title: Re: WaxBee Feature Requests
Post by: bernard on May 23, 2016, 04:16:04 AM
ALL the Serial "Wacom"s I have seen (and that I believe include the latest serial ones) were running 5 Volts internally. I mean, the main supply power was down-converted to 5 Volts all the time and fed to all the "logic/digital" components. I think they simply kept the same circuitry even if 3v3 was starting to be popular.  (like for the Intuos2)

All OEM Wacoms (for Tablet PCs) that I have seen were running on 3v3 Volts internally. (I say internaly because lots of them had a non-installed zener diode (ZD) (which we suspect was to drop a 5Volt supply) but that was never used AFAICT.

Title: Re: WaxBee Feature Requests
Post by: Pesho on June 11, 2016, 11:52:35 AM
A suggestion i thought of - bernard, do you think it's possible to have a Waxbee template that emulates the Cintiq protocol? I'm not sure how much it differs from the Intuos5 one... It would allow folks to use the regular Cintiq driver on Windows for some specific buttons like the "switch mapping between main and secondary monitor" function.

Title: Re: WaxBee Feature Requests
Post by: bernard on July 13, 2016, 01:17:20 AM
It is indeed possible and like you said very desirable to get the screen mapping utilities for free.

I "just" need to have someone with the model you want to "sniff" the USB packets so we know how to emulate it. If you can find such person that would be willing to run a USB sniffer tool (it can be tricky sometimes to do this, but certainly doable).

Unfortunately, Wacom drivers are extremely picky. As soon as something is not "as expected" it just stops working. It never was able to "guess". The only other hint I could have is to look in the Linux driver source code to see how the packets are handled for Cintiqs. But typically you cannot infer enough info just with the linux driver source code.  The first and foremost thing that is required are the USB and HID "descriptors". (a long series of bytes describing the USB "interface").

Title: Re: WaxBee Feature Requests
Post by: Pesho on July 13, 2016, 02:55:55 PM
I have a 12WX so it's not a problem - just say what you need me to do. It works very well with the Linux driver (probably better than the real one) and maps itself automatically. There are 5 buttons (ABCDE) and a ribbon controller on each side, all of them connect to the tablet's mainboard internally and are handled by it (i've looked). The ribbon controllers dont seem to report actual values, but track input as only "upper half" and "lower half" and get mapped to + and - on photoshop for zooming in accordingly.

Title: Re: WaxBee Feature Requests
Post by: Ertew on November 11, 2017, 09:35:38 PM
I just found a problem in intuos5 template. There may be bug in template, WaxBee firmware or drivers itself. Full story below.

I migrated my WaxBee tablet from intuos2 to intuos5. To do this I chose right template, set "serial input" same as on my working intuos2 template, upload firmware and have great surprise.
Only upper-left quater of tablet working. Right half and bottom half sends cursor to the edge of screen. Very strange.
Next I chose diagnostic option build in Wacom drivers. This shows me that screen respond perfectly in mm but drivers scaling data, actually doubling input value. More funny I can actually fix this by option "chose area of tablet". But clicking on edges gives me one marker at edge of active area of the tablet and next 3 markers far beyond tablet. Pretty funny.
Solution: set exactly half values in "USB tablet max coordinates" in WaxBee configuration editor. But why these values doesn't match?
Wacom driver version 6.1.7-3

Working template attached.

Title: Re: WaxBee Feature Requests
Post by: bernard on January 13, 2018, 05:52:11 PM
you forgot to tell us what is you tablet model OR is it in the file name? T5010 ISDV4 ?   What is the hardware resolution of that tablet?

EDIT:  after digging in your other posts, I found this:

I use standard template, Penenabled ISDV4 to Intuos2 12x18
For my digitizer, max X = 28811, max Y = 18083.

which does not match your template:

The SLAVE tablet max x / y should normally match your digitizer. You can try this :

...And YES, it would be nice that WaxBee's ISDV4 to internally prompt automatically for MAX X/Y SLAVE TABLET on boot (a feature of ISDV4). Maybe have a special "0" value. But I figured that if you got that far as connecting an ISDV4 to WaxBee you probably have that info and it will never change in a specific build. So until I get "peer pressure" to implement this (including troubleshooting this issue often like this post), I won't invest time.