test1
May 29, 2017, 07:01:41 AM *
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
  Print  
Author Topic: Announcement : ADB Intuos converter v0.1-beta  (Read 4312 times)
tufty
New Poster
*
Posts: 25


View Profile
« on: April 16, 2014, 08:13:25 PM »

Intuos ADB->USB Converter v0.1-beta
===================================

OK, so after a fair amount of digging through obscure documentation, packet dumps,
68k "Classic" Mac driver code, developing tools, and other head-scratchery, it's
finally here.  A (largely) working converter for ADB-equipped Intuos tablets.

https://github.com/tufty/adb-intuos

I wouldn't have got this far if it wasn't for the work done by Bernard Poulin, both
on the waxbee project, and the help he's given me in figuring out what the
packet stream means.

The technical requirements are (apart from an ADB Intuos) identical to those for
Bernard's waxbee converter, even down to the pins used for the ADB connection on
the Teensy.  There's reasons for that, most of which boil down to me "borrowing"
Bernard's ADB codec code.  In any case, if you already have a Teensy wired up for
an Intuos in the vague hope someone would eventually make the damned thing work,
you're good to go.  If you haven't, get one and wire it up.

What does this do?

It converts an ADB intuos tablet into the equivalent sized USB-equipped Intuos 2,
thus enabling the use of stock Wacom drivers (up to v6.20, the last version handling
Intuos 2 tablets; this may preclude being able to use the tablet on Windows Cool
on your computer.

I like the sound of that.  What does it handle?

I *believe* it handles all ADB intuos tablets without any need for configuration.  
It certainly handles the features of my GD-0608-A, including dual tracking, button
bar, standard pen and 4D mouse.

Sounds ace.  What's the catch?

It *certainly* doesn't handle any other tools.  That's because I don't have any of
them, so I can't work out how they work.  Yes, that /is/ a hint.  Please contact me
if you have other Intuos 1 tools you can either lend me (I'm in France) or can
hook up to an ADB intuos and dump the output.

How do I make it work?

  • Get yourself a Teensy 2.0 from pjrc.com
  • Wire it up : https://code.google.com/p/waxbee/wiki/InterfacingADB
  • Get yourself an AVR toolset.  The rest is based on having a command line toolset and some sort of *n*x.  Got a Windows?  I have no idea what you do.
  • Get the code : git clone https://github.com/tufty/adb-intuos.git
  • Go to the 'converter' subdirectory, and type 'make'
  • Load the resulting intuos_converter.hex onto your teensy using pjrc's teensy loader
  • Unplug and replug the teensy, and you're off

I can't attach the resultant .hex file, but if you can't work out the build step above, contact me by mail (my email address can be found in the source) and I'll happily send it to you.

Next post : the full story, and gory technical details on how the adb intuos tablets work, under the hood.
« Last Edit: April 18, 2014, 11:09:03 AM by tufty » Logged
tufty
New Poster
*
Posts: 25


View Profile
« Reply #1 on: April 16, 2014, 09:01:12 PM »

So, I'm going to tell you a story.  Are you sitting comfortably?  Then I'll begin...

A long time ago, in a land far, far away (well, in the year 1999 or so, and on holiday in Paris), I bought myself a Wacom tablet.  An ADB Wacom tablet to go with the Mac IIfx I was using at the time.  Or it might have been the G3 desktop, thinking about it.  Whatever, it was a ripsnortin' fast Mac with several screens attached and an ADB connector.  It was, as I recall, a UD-0608-A, and I bought it on sale from "Surcouf".  And I was mightily happy with it.

That tablet stayed with me for 14 years, but its utility was massively reduced by Wacom "Steving" it when Apple moved to MacOS X.  In fact, it was turned  into a tablet-shaped paperweight. 

At that time, I, amongst many other Wacom users, contacted Wacom to ask if we could please get an OSX driver.  Could we hell.  "OSX can't handle the throughput on ADB", they said.  "It's Apple's fault", they said.  "Buy a USB tablet", they said. 

At the same time, I was running Linux/PPC on my Wallstreet, so I contacted Wacom's developer people, asking if I could get the technical details on how the ADB tablets worked, in order to write a linux driver. Dave Fleck, who was (I believe) responsible for writing much of the Classic Mac code for the ADB tablets, got back to me and explained that:

1 - Can't do that, souper-sekrit eye-pee.
2 - You'll never understand how it works
3 - "XXX can't handle the throughput on ADB"
4 - Buy a USB tablet.

... and that was that for a good few years.  The trusty ultrapad went back into its box, and gathered dust.

Around 2004/2005, I randomly came across a tool for dumping ADB traffic, using 2 classic macs, a butchered serial cable, and some resistors.  Can't remember what I was looking for at the time, but there it was.  The tool I needed to be able to dump ADB traffic to and from the tablet.  I got inspired, and got dumping, 50 packets at a time (if I remember the limits of the tool).  A horrible job, and with no way of actually saving the dump, got writer's cramp.  The result of this, however, was a pretty good understanding of how the UD-xxxx-A series talked. There was nothing "difficult" about it; it was, in fact, pretty much trivial.  So I wrote an OSX 10.2.x driver for it, and it worked.  The first work that cme out of this was an image saying "fuck you wacom!".  Yes, very mature.

10.3 arrived, and buggered things up.  No longer were ADB-equipped Macs supported.

So I wrote, with a fair amount of help, a driver for the iMate ADB converter, which also included a tablet driver (which then got expanded by others to cover not only the ultrapads, but also the Calcomp slates).

It got hammered by, successively, 10.4, 10.5 (which removed ADB entirely), 10.6, etc etc.

The tablet went back into its box.

Bernard contacted me, sometime 2009/2010.  He took my code, with my blessing, and turned it into a part of Waxbee.  I rejoiced, got a couple of teensys, and hooked up my ultrapad.

Then Bernard started asking questions about the intuos tablets.  They were not the same as the ultrapads.  They were - wierd. Random.  My interest was piqued.  So I bought one.  Cheap as chips, obviously, as they no longer fucking work with /anything/.  I looked at the packet stream, and cried.  And put the tablet away again.

Every now and then, I'd pull it out, have a poke, and get discouraged.

Then I had a revelation.  I started dumping packets in binary, rather than hex, and started seeing patterns.  The veil started to lift, ever so slightly.

At this point, Bernard and I knew what happened when you plugged an intuos tablet in (the identification packet was pretty similar to the ultrapad one), and what happened when a pen came into proximity (a pair of messages, the forst of which was obviously tool-specific, and the second of which, again, looked similar-ish to the UD series).  But the rest was gibberish. A constant stream of 3, 6, or 8 bytes at a time, regardless of pen movement, and seemingly random, followed by 2 bytes 0xfe00 as an obvious out-of-proximity marker.

That stream of bytes, however, started to make some sense when dumped in binary.  Move the pen up, and one bit was always set.  Down, and the same bit was always clear.  Left, another bit set.  Right, clear.  Odd, but more or less consistent sets of 4 bits inbetween.  Lean left, another bit.  Lean up, another one.  Press a button, an 8 byte packet happens.  Release it, another one happens.  And so on.

It became clear to me that Wacom were somehow crushing down location data into 5 bit chunks, tilt into 4, probably pressure into another 4.  the encoding was opaque, but the meaning was clear.
Logged
tufty
New Poster
*
Posts: 25


View Profile
« Reply #2 on: April 17, 2014, 08:07:00 AM »

So, I had this stream of data, and I thought I knew what some of it meant.  I got quite excited about that, and contacted Bernard.  We ummed and arred over what the 3 byte and 6 byte packets were all about.

What was obvious was this:  Per 3 bytes, regardless of whether it was a 3 byte or a 6 byte packet, data looked like this ...
00xx xxxy yyyy pppp hhhh vvvv
... where x, y, p, h and v are related to x delta, y delta, pressure delta, horizontal tilt delta and vertical tilt delta.

But what were the 6 byte packets?  And what of the occasional 8-byte packets that weren't triggered by button state changes?  Bernard was of the opinion that the 6 byte packets were simply 2x3 byte packets munged together.  I thought they were, more likely, delta and error correction, and that the 8-byters were "reset" packets of some sort.  Bernard got his o-scope out, and it suddenly became much clearer what was going on.

The intuos marketing material clearly marks the data rate as being /maximum/ 200 samples per second.  I'd initially considered this to be rather ambitious - maybe the USB and serial tablets could hit it, but no way the ADB tablets could go that fast.  Turns out the Wacom engineers were smart enough, and cared enough, to hit that 200 samples per second, pretty much all the time.  Which, in the end, makes sense - the guts of the tablets are identical, it's only the interface and interface firmware that changes between models.  By modifying the ADB polling speed in Waxbee, we could get more, or less, 3-byte, 6-byte and 8-byte packets, and, within reason, we were getting absolutely 200 samples per second. If 3 bytes wasn't fast enough, 2 packets were munged together into a 6-byte packet.  If that wasn't fast enough, lose the tilt information for a packet, and munge 3 packets together into 8 bytes.  Sheer, insane, genius.

The "packaging" of the pen packets sorted out, this only left the content. It was obvious that there was some sort of delta information in there, but testing quickly revealed it wasn't trivial.  Neither simple addition nor "static shift and addition" worked.  Time to start diving into code.

This is where things got hard, and fast.  I didn't have the tools required to even unpack the code resources from the "Classic" mac driver.  So I wrote a resource unpacker in C.  Which eventually netted me a 300K+ chunk of 68k binary.  And, not having the tools to rip that down or even look at the names, I wrote myself a disassembler in scheme.  I used scheme because I could run it from the REPL, and change things on the fly.  A bit of intelligent function prologue matching got me down to a bunch of disassembled functions, and a big bunch of data.  Traps were, with a bit of help from my old MPW discs, decoded, and that enabled me to find the code dealing with talking to ADB tablets, and, from there, the ADB state machine.  Which was hideous.

At this point, I was working from the 4.5.5 driver, which deals with *all* mac-connectable Wacom tablets.  UD, SD, GD, XD series, ADB, serial and USB connections.  And the damn thing is written in C++.  It was too complex to even think about breaking down.  So I went looking for earlier drivers.  Google and wayback failed me, although I now knew what driver I needed.  And eventually, I managed to source one from someone selling a boxed adb intuos on the french equivalent of eBay.

Back to work.  Rinse and repeat what I'd done with the 4.5.5 driver on 4.1.2, get to the ADB state machine, and, eventually, to the handler for "Talk Register 0" commands (the ADB polling mechanism).  And the slow task of picking through the various bits of internal state.  Decoding the structure of the class instances, and the class vtables.  Tedious, mind-numbing code-sifting.

The structure of the r0 handler is horrible.  Cascading branches based on "if this bit set, then this, else this".  But I'd managed to get it labelled up based on the bits being tested, so started manually walking through the code with my packet dumps.  And here's how it works:

When a tool first comes into proximity, there is a 7 byte packet sent containing tool type and tool serial number.  I knew this already; this packet is identified by having it's top nybble set to 100x, where x is the tool index (0 for the first tool, 1 for a second tool in "dual tracking" mode).

When a tool goes out of proximity, there is a 2 byte packet (which may well be part of a "stream" of deltas (i.e. appended after other packets) of the form 0xfe00 | (tool_index << Cool.  I knew that one as well.

After the "in proximity" packet, we get one or more "tool major" packets.  These vary by tool, and contain "raw" sensor data.  The high bit is aways set, and the type of the packet is determined by masking various bits in the top byte.  Size and content vary by packet type, from 6 to 8 bytes each.  At this point, I only had access to standard styli, so I was only seeing "pen major" packets, which encode location, pressure, tilt, orientation and pen button state.  agin, I knew this packet, and had it ripped to bits already.

After the major packets, we get delta packets.  The encoding is different per tool, but these are either 2 or 3 bytes each.  They *all* encode a location delta as described above, the rest varies by tool type.  And, for some tools, there's an alternating sequence of delta packet types.  The 4d mouse, for example, alternates between "location and rotation" and "location and wheel" deltas.

When some state changes that *isn't* encoded in the delta packets, we get a new "tool major" packet of the relevant type.  Button state, for example (and, for obscure reasons, when the 4d mouse wheel goes from +ve to -ve nd vice versa).

The encoded deltas themselves are of the form "sign + magnitude".  For each data element (for example, horizontal tilt), the driver keeps a "shift" value, which is initialised to a "magic" number when we hit a tool major packet.  The delta is calculated by shifting the magnitude left by "shift" number of bits, and this is then added or subtracted from the accumulated value according to the sign bit.  So far, so (relatively) simple.  But then comes the clever bit.  The shift value is manipulated according to the magnitude field.  So, for tilt, if the magnitude is 0b111, we add 2 to the shift value.  0b110, add 1. 0b010 or 0b011, subtract 1. 0b001, subtract 2. 0b000, subtract 3.

It's what I'd describe as "adaptive shift delta encoding".  It's not general, as such - the magic numbers need to be both synchronised between hosts, and probably hand-tuned according to scale and expected delta magnitudes per sensor reading, but it's absolutely brilliant.
Logged
tufty
New Poster
*
Posts: 25


View Profile
« Reply #3 on: April 18, 2014, 11:03:17 AM »

So, how does this "adaptive shift" stuff work, then?

In a naive tablet protocol, for example that of the ultrapads and earlier, we transmit all the data, all the time.  If the stylus has moved from x location 0x1000 to 0x1010, then to 0x1015, we transmit first 0x1000, then 0x1010, then 0x1015.  Wacom could have done this for the intuos tablets, were it not for the combination of ADB's low throughput, and the "required" 200 samples/second thing.

Given that losing samples was presumbly not acceptable, Wacom thus needed to trim down the amount of data being sent per sample. The obvious thing to do is to send deltas where possible.  A simple delta encoding scheme sends a first packet containing the "full" data, and then a number of smaller difference packets.  In the above example, we could imagine 0x1000, 0x10, 0x05, for example.  This works extremely well for messages which are coherent, where each message is likely to be very similar to the preceding one.

There is, however, a catch.  If the difference is too big to fit in the fixed size delta packet, it becomes necessary to send a full-size "reset" packet, which "fattens up" the stream again.  So, in order to be able to deal with a range of differences (for co-ordinates, these can be thought of as velocities), and thus avoid reset packets, the delta packets must be quite large.  And Wacom didn't have the luxury of being able to make the deltas large.  Timing constraints mean that the total size of the delta packets for *all* the relevant sensor outputs for a tool can be, maximum, 3 bytes.

So, another approach is needed.  A commonly used option is to increase or decrease the delta packet size "on the fly" dependent on the data to be encoded, but, again, that pesky fixed packet size kicks in.  So that's out.

Absolute accuracy 100% of the time is not needed, as long as the deltas approximate to, and rapidly converge on, the correct value.  The most important measure is transducer location, and Wacom are measuring these to 1/2540 inch (or, if you prefer, 1/100 mm).  That's pretty damn precise, a little bit of jitter isn't going to hurt that much as long as it converges fast.

So, what wacom have done is change the range of delta measurements on the fly by shifting the delta value to the right, at the cost of reduced accuracy as the range increases (as we lose the lower significance bits).  Let's look at that 5-bit location delta.  Remember, it's 1 sign bit plus 4 bits of magnitude.

shift vMin vMax error (mm)
----- ---- ---- ----------
0     0    15   0
1     0    31   0.001
2     0    63   0.002
3     0    127  0.004
4     0    255  0.008
5     0    511  0.016
6     0    1023 0.032
...

In other words, with a shift value of 4 (which, by chance, is wacom's "starting" value for location delta shifts), it's possible to accommodate a pen velocity of ~ 25 cm / sec, whilst staying within a tolerance of 8/100ths of a mm of the "real" value.  That's pretty good as it stands, and Wacom probably could have got away with leaving it at that, at least for the smaller tablets.

Where the genius comes in, though, is how they've dealt with convergence / divergence.

Effectively, what happens is this:

If the delta magnitude is at the upper end of the scale (15 in the case of location deltas), the driver assumes it has "undershot" the target, and increments the shift.  At the expense of absolute accuracy, this allows the next delta to encompass a larger range, approaching the assumed "far away" target value faster.  If the actual value *was* 15, the next delta can still address it directly.

At the lower end of the range, (say, 1 or 2), the driver decrements the shift, reducing range and thus increasing accuracy, and so converges on the "correct" value faster.

At the *absolute* low end of the range, the driver assumes it has "overshot", and "downshifts" faster, reducing the shift value by 2 or more, allowing the "real" value to catch up.

So, for any given delta magnitude, we "upshift" with maximum value, "downshift" for low-end values, and downshift faster for zeros.  The only tuning needed is to decide where, and by how much, to downshift, and what the initial shift value should be.

Like I said before - it's genius.
« Last Edit: April 18, 2014, 11:05:01 AM by tufty » Logged
Aerendraca
Administrator
Hero Member
*****
Posts: 1057


View Profile
« Reply #4 on: April 19, 2014, 12:07:32 PM »

Wow, and I mean Wow! You have spent some serious time investigating this and it appears to have paid off. I'm sure there will be plenty of people out there that are going to be excited by the work you have done here and it's excellent that should chose to share all your hard work. Simply Brilliant!
Logged
tufty
New Poster
*
Posts: 25


View Profile
« Reply #5 on: April 27, 2014, 08:51:20 AM »

So, latest commits (at git tag "v0.2a-beta") should support the Digitizer II (ultrapad / artZ) tablets, with a couple of caveats:

- Not sure if multi-tool is working on on the UD-1218
- Pressure readings from the pen are definitely fucked, although they kinda work
- I don't think the button bar code is working properly.  Or improperly, to be honest.  It's a bear.

With a bit of luck, I'll be able to re-borrow my old ultrapad and fix the rest this coming week.
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #6 on: February 21, 2016, 05:44:32 AM »

Hello people,

This "Adaptive encoding scheme" really makes me think about "ADPCM". ADPCM is a sound encoding (from 1970 Bell Labs). It encodes a 16 bit sample into 4 bits. My guess is that Wacom borrowed lot of very clever ideas directly from it.

Again, great stuff as usual!  It's been many years. I just now undusted a couple of Waxbee-enabled Wacoms for my kids to play/draw.

Some people are asking about Intuos5 support (I have no clue what happened with that) -- but that didn't occur that much -- maybe it is still possible to install the old driver in Win10? I know I am running it in Win8 right now (even if unsupported).

Maybe it is time for me to get Intuos5 support more stable in WaxBee (for Win10 compatibility). Maybe I could integrate Tufty's work into this? Teensy 2's Flash size is rather limited when you enable everything.

Someone posted a pull request for newer toolchains on GitHub. Maybe I should update that too.

Logged
Aerendraca
Administrator
Hero Member
*****
Posts: 1057


View Profile
« Reply #7 on: February 21, 2016, 11:02:04 AM »

Welcome back Bernard! It's been a long time.
Logged
Ertew
Full Member
***
Posts: 78


View Profile
« Reply #8 on: February 21, 2016, 02:04:47 PM »

Hello Bernard.

In my opinion, You should try two ways for improve WaxBee.
1. Add USB protocol from Tablet-PC digitizers, because many systems have build-in drivers.
2. Reduce size by remove unused parts of code. There should be few different versions of code, like one only for ADB tablets and one for serial only.

Last wish, make WaxBee that can fit into 28kB of Pro Micro's flash (last 4kB was occupied by bootloader).
Logged

Any errors in spelling, tact or fact are transmission errors.

Hi! I'm a signature virus. Copy me into your signature to help me spread.
XDjackieXD
Full Member
***
Posts: 126


*me trying to draw*


View Profile WWW
« Reply #9 on: February 21, 2016, 04:32:31 PM »

Hello Bernard.

In my opinion, You should try two ways for improve WaxBee.
1. Add USB protocol from Tablet-PC digitizers, because many systems have build-in drivers.
2. Reduce size by remove unused parts of code. There should be few different versions of code, like one only for ADB tablets and one for serial only.

Last wish, make WaxBee that can fit into 28kB of Pro Micro's flash (last 4kB was occupied by bootloader).

I started porting the serial tablet to usb part to an atmega8 + v-usb but never came around implementing the usb part (displaying coordinates of the wacom tablet on a LCD connected to the ┬ÁC works perfectly fine ^^). the serial interface code is really small (https://github.com/XDjackieXD/WaxWasp)
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #10 on: February 23, 2016, 04:10:49 PM »

Hello all,  hello Aerendraca!

About 1: I already support Serial TabletPC boards (it's called ISDV4). But I think you meant the USB side?  Yes, we could emulate a USB TabletPC board instead of a Wacom. (well, lot of them were built by Wacom mind you).

About 2: Yeah, I have some debug Strings in there and stuff. One way, like you said, would be to have "multiple builds", then in WaxBee Config you pick the one you need or something like that.  The biggest are the strings but I think it is not enough to bring it down.  Note that 28K must includes the "template" data that the waxbee config appends within the .hex file.  So the target actually varies - the biggest part (by far) of the template are the USB/HID descriptors.

This is of course the reverse of another master plan of being able to autodetect most of the parameters automagically -- but that requires more logic (!!)  For example Serial TabletPC's size could be detected automatically (I print it in debug output but ignore it).

This is built for one specific CPU -- other CPUs are out there too -- now we have inexpensive/small 32 bit/Cortext. I picked PRJC's because it had USB support (with good USB+HID examples), it is small, inexpensive (cost was almost a third of an Arduino at the time) and is a stable/reliable source. (Still there after all theses years!) Point me to another board with the same characteristics...  This was a perfect fit for DIYers.

@XDjackieXD:  very cool stuff! Which tablet?

Logged
XDjackieXD
Full Member
***
Posts: 126


*me trying to draw*


View Profile WWW
« Reply #11 on: February 23, 2016, 07:21:53 PM »

@XDjackieXD:  very cool stuff! Which tablet?
Everything with ISDV4. I tested it using this crappy thing I built before: http://forum.bongofish.co.uk/index.php?topic=2468.0 Tongue
I basically made the WaxBee ISDV4 code work without using the object oriented stuff of c++ with a simple callback when something changes (pressure, coordinates, ...).
By keeping this callback "format" (parameters and such) a bit more generic than needed most of the time it should be easy to make this code modular using a simple definition file or make-config (thus keeping the compiled code-size as low as possible).
« Last Edit: February 23, 2016, 07:24:21 PM by XDjackieXD » Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #12 on: February 24, 2016, 06:55:09 AM »

Yo! Long post. Good candidate for a tl;dr  Cool

ISDV4
ISDV4 is very straightforward -- no special tool ids or weird states like dual track and timings. I believe they built this protocol to be consumed by system integrators because a large business for Wacom was to create those OEM modules for TabletPCs/etc. (There are so many models, it's crazy!). Tongue   Also ISDV4 does not have that dual baud rate speed thingy - you speak directly to a fixed baud rate -- much simpler!  

How fast is your tablet (serial baud rate and position report rate)?

In WaxBee there are so many thing to integrate together (and then to "fan-out" to many other protocols), I tried to have a "common" structure and believe it or not to keep it "relatively" simple and readable, but it went a little bezerk sometimes. It also has all the coordinates transformations - I even thrown a special mode to "extend" beyond the active area! ('accelerate' near the edges with the "anchor" functionality). When matching a LCD, one might need special positioning -- You can often tweak the Wacom driver settings but for a fixed LCD-match you can actually tweak WaxBee coordinates so it becomes "baked in" (next time you reinstall the driver, no need t re-align things). The buffering for USB is also another thing. Stuff like repeating positional packets if passed a certain amount of time else the USB driver thinks the pen is out of proximity, etc. I also had a virtual button system but this was never fully working.

USB TabletPC
I do not remember how the USB tabletPC works but I would assume it is also very straightforward and I suspect it would resemble the serial packets but within a HID packet.  If really the packet matches, the code could be reduced to blind copying of bytes. I would like to add this protocol. I think I have such a USB device somewhere in the basement.

One of the good thing about emulating a TabletPC device is that the drivers contains a screen alignment tool.   Of course TabletPC lacks high-end features found in Intuos tablets so it's a tradeoff.

An alternative approach instead of emulating a Wacom USB tabletPc would be to actually use "standard" HID descriptors -- I believe there is enough in the specification to support most if not all the features of this tablet. No driver required! Now that Photoshop CC 2014 started using Windows Ink (not without issues) having a Wacom product (or WinTab-enabled) is no longer "required" to use Photoshop on Windows.

OOP
I do use the C++ compiler but really, this is not OOP per se. There are no memory allocations (new/malloc); all is defined statically, I am not even sure I have 1 virtual method in there! I liked C++ mostly because of compiler features and syntax like the namespaces.   Calls like console::println()  are actually direct C-like function calls. (the calling convention might be slighty different, but there are no pointer dereferencing through a v-table which is typical of C++ objects). There should be no difference with C under the hood.  Also for objects like Pen::PenEvent penEvent;  It is often declared within the bigger object directly and thus the offset is known. But it is sometimes passed by reference in parameter like (Button::ButtonEvent& buttonEvent) -- this is equivalent to a normal C -> pointer, so that makes 1 pointer dereference.  It was like that to support having multiple events in memory at the same time (but I do not think I have that). It does allow to create a pen event anywhere and to use it as a parameter.

makefile
Yeah, a "make-config" would be nice but it also implies "building" which is something I tried to avoid -- I didn't know how to ship something without asking someone to install the avr-toolchain(!) on any popular OS. Waxbee is a one stop shop for programming the Teensy. One of the main target are DIYers/Tinkerers but not programmers and certainly lots of people on Windows without easy access to tool chains. Smiley  Of course with access to a compiler, you can reduce the output a lot!

What I would like ultimately is allow autodetection of what device you are using. It could download a generic ADB/serial forwarder and the "config tool" would essentially try many things (defined following a configuration) to determine the tablet model. Then it would auto-select the best USB emulation available for this tablet and configure it all.  That would be awesome. Anyway, not going to happen.  Grin Also I had plans to tweak coordinates to align to the screen within the tool but it was too much of a challenge - I had little control over the LCD screen - so I never got to do it.

One annoyance are the "strings" -- if you defined a string I found that it actually allocates both the ram space and rom space (to store the data -- which gets copied to ram on initialization).  That is why I started moving strings directly to rom (Program data) and have a "P" suffix version of my console utilities.  For tiny strings like "*" it takes only 2 bytes so no problem there. My ram usage was overflowing like crazy.
« Last Edit: February 24, 2016, 07:00:30 AM by bernard » Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #13 on: February 24, 2016, 04:15:09 PM »

Quote
By keeping this callback "format" (parameters and such) a bit more generic than needed most of the time it should be easy to make this code modular using a simple definition file or make-config (thus keeping the compiled code-size as low as possible).

Would there be a way I could look at what you have?  Maybe I can borrow some ideas...  Smiley

Logged
XDjackieXD
Full Member
***
Posts: 126


*me trying to draw*


View Profile WWW
« Reply #14 on: February 24, 2016, 05:43:19 PM »

Quote
By keeping this callback "format" (parameters and such) a bit more generic than needed most of the time it should be easy to make this code modular using a simple definition file or make-config (thus keeping the compiled code-size as low as possible).

Would there be a way I could look at what you have?  Maybe I can borrow some ideas...  Smiley
Here is the Code:
https://github.com/XDjackieXD/WaxWasp
Most code is basically your WaxBee ISDV4 code made to work without OOP and very simplified (changing pen event from a class to a struct for example and other things I can't exactly remember Tongue).
The fun part begins with penevent.c which has a method that gets called on pen status changes (the same as in Waxbee).
This is where I wanted to bring V-USB into the game but currently I haven't had time and kinda forgot about the project :3

And it should be possible to minimize waxbee's size by just not linking unused code (when you compile waxbee for isdv4 for example you don't need to link all the other stuff about adb and such).
The problem is that you would need the avr toolchain to customize waxbee then... (not a huge deal on Linux but annoying on Windows).

Oh and while I'm at it: What License does WaxBee have? I haven't found anything and felt kinda bad for just using GPL2 (as needed when using V-USB) without knowing the original License... (I hope it is ok :3)
« Last Edit: February 24, 2016, 05:49:11 PM by XDjackieXD » Logged
Pages: [1] 2
  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!