Some technical information on ADB tablets.

[tufty]

Hi.  I'm new here, but I have a little experience with ADB tablets.  Bernard emailed me today, so I thought I'd register and post what I know.

As you are all no doubt aware, ADB tablets are dirt cheap on fleabay and the like.  This is because nobody can use them, so nobody wants them.  Nobody can use them, because they have a completely proprietary interface, the ports for which haven't been included on an actual shipping computer since 1998 or so (and even then, they were only ever on Macs).

Now, I'm one of those people who hoard old tech, and who feel bitter and twisted when that old tech no longer works.  Especially when that old tech cost an arm and a leg a mere couple of months before Wacom decided they weren't gonna ship drivers for that "old" tech under Apple's new OS.  Yeah, I've got an ADB tablet.

So I went out of my way to start developing a driver for OSX (based on some work I did years back on developing a driver for Linux, but that's a whole 'nother story), the result of which was the imate-osx project (which can be found at the google code site).  This allows some machines with very specific versions of OSX and specific pieces of the Griffin iMate hardware to talk to specific ADB tablets.  Yeah, it's a bit flakey, but nobody seems interested in helping out and I've been - erm - busy.  Yep, that's right.  "busy".  Certainly not "slacking off", or "lazy", just "busy".

Anyroadup, here's some ADB tablet "general" info.

• The ADB tablets do not use the same logic boards as the serial ones.  You can't just hook up a serial cable and expect it to work, at least not without some considerable software work
• Some of the larger (high end) ADB tablets had swappable driver boards, and could run ADB or serial, depending on which board was installed.  Wacom offered a "low price" board swap for these tablets as a sop to the community when they announced they weren't going to support ADB any more.  If you could find a supply of those boards, you'd be a hero, although It probably wouldn't help with the tablets smaller than 12x12
• The messages sent across ADB are not the same as those sent across the serial connection, although they do appear to be similar, so you can't just do a level conversion, either

So where does that leave those with ADB tablets?

Frankly, the phrase "in the shit" springs to mind, but there are options.

Firstly, one could get hold of an ADB-USB adaptor (the only one that works properly is Griffin's "iMate", now discontinued), and write a driver for one's favoured OS.  It's a fair amount of work, but the imate-osx project is there.  As the iMate appears as an ADB controller, you have to write a whole ADB stack, not just a driver for the tablet.

Secondly, you could get hold of a microcontroller and hook it up to ADB, with some firmware to make it handle the ADB side of things, and look either like a serial tablet or a generic HID tablet.  That's what Bernard wants to do; I think he's probably right.  If nothing else, it makes the resulting device platform independent.

Or you could say "cobblers to it", chuck the tablet in the bin and buy a USB model.  Yeah, right.

In any case, you need to know a few things.  Let's look at ADB itself.

ADB is a single-wire protocol handling one master and up to 15 slaves, and it's not very fast.  There's full documentation of the underlying protocol (how devices talk to the controller, timings and so on) in "About Macintosh", and also in the technical documentation for the Apple IIgs.  Both of these are available online.

An ADB device has a bus address (defaulted by the device, but possibly changed to avoid collisions on ADB startup) and what's knwon as a "handler number".  The handler number is very important for ADB tablets, as they start up, by default,  behaving as though they are a standard one-button ADB mouse.  The driver for the tablet needs to tell it to move to the proper handler before the firmware will start sending absolute location, pressure, tilt, and all that other good tablet stuff.

The proper handler number is model specific.  Which is to say, a UD-0608A 6x8 ADB tablet will have a different handler number to a GD-1212A, and so on.  That's a bugger, and the only way to find out what the correct handler number is for a specific model of tablet, is to hook up the tablet to an old mac running OS9 or below, with the proper Wacom drivers installed, and then look to see what handler is assigned using an app named "ADB Parser".

ADB treats each device as having a number of registers, which store up to 8 bytes of data each.  Wacom tablets use all the registers.

ADB is a polled bus.  The controller will ask each device in turn if it has new data.  Combined with the speed of the bus, this effectively limits the ADB tablets to a maximum sample rate.  It's not very high.  You are *not* going to get a polling speed of over 100Hz.

The data that is sent over the bus is similar to, but not the same as, the serial protocol.  Here's what I found:

Code:

Extracted from an ArtPad II, model UD-0608-A using ADB Analyzer, a 9500, a Powerbook G3, one dead ADB mouse, a Newton
keyboard, 4x2.2K resistors, 1 1K in line resistor pack, a bit of solderless breadboard, and some wire.  Not pretty.

By default, this tablet appears at handler 0x3a, and gets moved to handler 0x68 by the Wacom driver.  That's where we
want to put it, I think.  Is it by chance that 0x68 is a truncation of 0608?  Would a 1212 be moved to 0xcc?  I think
it likely.  Need to get someone to try, I guess.

DEVICE INFORMATION
==================

Static device information is coded in register 1 and Register 3.  Reg 3 is, as usual, the handler id.

ADB Register 1 holds 8 bytes, and appears to encode the following:
?? ?? xx xx yy yy ?? ??

Resolution of my tablet is 2450 dpi (0x5000 / 2450 = 8, 0x3e00 / 2450 = 6) or 0.01mm

xxxx : maximum x co-ordinate
yyyy : maximum y co-ordinate

items referred to as ?? I haven't figured out yet.

All but the second byte appear to be static data.  Second byte is random, but seems to be fixed per setting of R3, although its value
doesn't seem to be related to r3 value in any way.

RESET PROCESSING
================

Packets sent after address resolution is finished

Talk R1 38 20 50 00 3c 00 06 17 // Talk register 1, presumably to determine if this is actually a wacom tablet
Talk R0 a6 bc 0b 4b 00 80 1f 19 // Talk register 0, doesn't always do this.  Possibly irrelevant, may be triggered
// by normal ADB polling?
Talk R3 6e 3a // Talk register 3, find out what handler it's set to.
Talk R1 38 20 50 00 3c 00 06 17 // Talk register 1, Always an identical result to the previous talk

Listen R3 6f 68 // Listen register 3, set handler to 68
Talk R3 6x 68 // Talk register 3, did it take?

Listen R1 67 68 // Listen register 1, do what?  First byte changes, seems irrelevant.
Talk R1 38 03 50 00 3c 00 06 17 // After the listen, byte 2 has changed, but there seems to be no reason to it.

Talk R0 // No data in this case, will repeat if there is any, this is probably a normal poll
Talk R3 61 68 // Appears to be normal MacOS ADB init handling, probably not required

POLLING
=======

Despite Dave Fleck's assurances to the contrary, there appears to be nothing over-onerous in the protocol.  Each
poll interval can result in 8 bytes being sent, with the command byte that makes 9 bytes per packet, at 100Hz, or 8100bit/s.
Even USB 1.1 devices should be able to handle 12Mbit/s, so we're not even close to throttling USB. It has to be said, it is
pretty close to thrashing  ADB, which could be an issue for OSX, but to be frank, I think Wacom have been talking crap
since day 1.  Anyway, back to matters in hand.

The tablet polls just like any other device, with a talk R0 command, which returns an 8 byte packet if there's anything to
report.

In short, it looks like this:

Talk R0 ss xx xx yy yy pp tx ty

ss   : status
xxxx : x coordinate
yyyy : y coordinate
pp   : pressure,
tx   : X tilt, +-127, -ve to the left
ty   : Y tilt, +-127, -ve away from user


The status byte is similar to, but not the same as, that used by the Wacom IV binary protocol:

Bit Comment
7 Always 1
6 Pointer in proximity indicator
5 Stylus : 1, Cursor : 0
4 Button Depressed (click)
3 B3
2 B2
1 B2
0 B0


Button encoding, as given by the nybble defined by B0..B3 depends on the tool in use.  Nothing like a standard
approach, after all, and this is nothing like one.

If it's a puck:
Button = 1 - Front centre
Button = 2 - Left
Button = 3 - back centre
button = 4 - right

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.


Back to the rest of the packet:

Following the status byte, there are 2 bytes of X coordinate, and 2 bytes of Y coordinate, both of which
are clipped to the maximum dimension as specified in the register 1 packet, then one byte of signed pressure, with -128 being the minimum / off tablet reading, and 127 being the highest, and a signed byte each for x tilt and y tilt.  X tilt is negative to the left, y is negative *away* from the user.

For a puck, pp, tx and ty will be zero


OUT OF PROXIMITY
================

When the tool moves out of proximity, you will get a packet with a status of '80' or 'A0' (depending on tool),
with last received data in the rest of the packet.  The status byte will look like this, even if a button was
pressed as the tool went out of prox.

ss = %10x00000

MACRO BUTTONS
=============

Macro buttons are indicated by a single "out of proximity" message, but with the button depressed flag set, as follows:

Talk R0 %10x1xxxx 00 bb 00 00 00 00 00

bb is the button number, and the x's in the status byte change depending on tool and button used.  All other data is zero.


OTHER STUFF
===========

The Stylus seems to need occasional R2 packets as well, not sure what this is for, there seems no rhyme or reason
to when they are requested, and what they contain seems random.  8 bytes of random.  They are requested *directly*
after an Talk R0 event (i.e. not polled), and followed, again immediately, immediately by an talk R0.
They appear to be applied to device address ^ 0x08, which is unused (by chance?) but that could be my stupid
analyzer setup playing up.  I have no idea what these are, anyway, but the R0 data seems to be enough to be going
on with for the moment.


R2 Data (without driver installed)
==================================

Further analysis needed on this
R2 appears to always return data, it could be polled without requiring a kernel extension at all, but we'd have to deal with
(i.e. block) the R0 data being picked up by the mouse handler.  Not sure what the format of the status byte in R2 is, the rest
seems consistent with R0 and the handler having been changed.


DEVICE INFORMATION
==================

Device Original              New Register 1 Who
Handler              Handler
UD-0608-A 0x3a 0x68 38 20 50 00 3c 00 06 17 Me
UD-0608-A 0x3a 0x68 38 79 50 00 3C 00 06 17 Adam Ladds (aladds@gmail.com)
GD-0912-A 0x6a 0x6a 04 12 77 10 5d fc 00 07 Bernhardt (tabletmagic forum) (confirms scaling at 2450dpi)

ADB Parser from Griffin links 3a to "ArtZ" models, 6a to "Intuos", which might well make sense.  Were there any other families with ADB interfaces?

[/size]

[bernard]

Well, well, well, I got that chap hooked up pretty good! Seriously, this is great info.   Warm welcome Tufty!

Note to the reader, Tufty also emailed me **lots** of ADB related files.

Note: I also contacted another chap -- "Osgeld" on the arduino.cc forum which also played with ADB in the past.  Here's the thread - http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1283648312/12#12

[bernard]

Ok, I did a few analysis of the ADB signaling.  From the little I have seen, it look like it matches the specs (but a little detail about the stop bit after a data packet).



This is from a Wacom UD-0608-A. It's connected to an iMate (but I do not have the good combination of drivers to make it work in tablet mode. The Wacom emulates a mouse (relative mode, no pressure sensitivity, etc.) 

[bernard]

more analysis -- that is a data packet from a mouse (an ADB Wacom in HID mouse mode through the iMate)



The specification from Apple are supposed to be:

Value	Min	Max	unit
Bit time	70	130	us
0 low time	60	70	% of bit time
1 low time	30	40	% of bit time
Attention	560	1040	us
Sync	60	70	us
Stop-to-start	140	260	us

Start is essentially a 1, Stop is a 0.

and here's a few packets one after the other:

[bernard]

The Journey
In the hopes that this project will "hold" up to its end (if more people has interest in this, the more it will push it).  Watch out this is a huge post. So here's what I have in mind:

Like Tufty already mentioned, the goal here is to build an hardware device that would act as a "Wacom-ADB to Wacom-Serial" bridge. This would be the first "step": after that, I would attempt a "Wacom-ADB to Wacom-USB" bridge. While doing that, I might be able to also do a "Wacom-Serial to Wacom-USB" (connect the dots!)  Doing the USB part will probably be a rough ride (more on that further down). The Serial version would normally be through the USB (virtual serial port) -- but I might actually have an option to use an onboard UART so one could connect directly to a hardware serial port (if that could be of any help).

EDIT:  I dropped the idea of doing the ADB to Serial -- I will go directly to do the USB version. That is, ADB to USB and then Serial to USB.

EDIT (June 2011): this project is named "WaxBee" and is now in good shape. http://code.google.com/p/waxbee/  (more info in this very long thread) It emulates a Graphire3 or Intuos2 and can hook to ADB tablets and few serial tablets (including TabletPC penenabled sensor) -- all to varying degree of implementation. The tablet power always comes from the USB (throught the teensy). The configuration software is advanced enough to be "usable". At this point, a few folks are starting to order teensy boards  -- I am confident that it will work fine for them (with a little help from me).

Enter the Teensy
I looked for the cheapest solution I could find that would be "DIYers-compatible" (e.g. no soldering of super-high-density components). For that I picked the "Teensy" (An Arduino-like board that is not only very cheap, but seems to be perfect for the job: voltage is right (5v), milliAmps (I think) is ok, ports can emulate OpenCollector-style of the ADB bus).  I picked the 18$US+5$ [slow] shipping "Teensy 2.0" board. The idea would be to solder 3 wires from a S-Video cable (mini-din) to connect to the ADB tablet (yes it would connect "backwards", but male connectors are much easier to find than female ones and it works perfectly) OR bypass that and solder the 3 wires directly bypassing the connectors. For a DIY electronics project, this can't get simpler/cheaper I think.

This may look like a remake of the Griffin iMate, but it isn't. First it is not generic, but focused at driving a single Wacom ADB board (not a whole ADB bus with up to 15 devices on it). I mean, if you have 2 ADB Wacom board to connect, just get two Teensy. Second, it really "converts" to something else; not just "tunneling" the ADB packets through USB up to the Mac. For the Mouse and Keyboard, the Griffin iMate is actually converting to their USB HID equivalent but for anything else, you are stuck building drivers on the Mac.

I am still waiting on the Teensy to arrive. They said it was shipped. 

In the meantime, I did a bit of progress as I was able to get my UD-0608-A to work correctly on a Mac Classic II (Performa 200) running System 7.0.1 with the Wacom drivers. (Thanks to Tufty for the drivers -- they are no longer available on Wacom it seems -- I would never been able to do it without his help).  That means that I can make it run in Tablet mode. (as opposed to not HID Mouse "relative positions and no pressure, etc.").  The ADB packets are bigger now and correspond to what I need to interface with. Here's a quick snap of such a packet.


Report rate
If you carefully count, you'll see 64 bits in the data portion of the packet. Which means 8 bytes (the maximum ADB packet size). It takes roughly 10ms to transfer the whole packet -- 10ms would normally mean a report rate of 100 per second. (100Hz)  That's theorical and actually matches what the manual says about the report rate for that model, (I did not measure it yet).  A lot of other (old) wacom tablets (serial & USB) are rated at 200 per second.  I might be able to shave off and gain a few Hz if the internals of the tablets permits it, but nothing that would make a significant difference.  My Graphire3 USB report rate is also 100 per second (according to its manual) and it is not really a problem for me. On the Mac the ADB host had to "poll" all the devices all the time and the OS had to keep the pace (while doing other stuff like photoshop redrawing) so the 100Hz was a theorical limit.

To Arduino or not to Arduino?
The Teensy is essentially a single CPU with --- well nothing else(!) (other than the USB connector, a crystal, a led, a reset button, few capacitors and resistors). All the magic is happening within that ATmega32U4 chip. This is a 8bit core named "AVR" -- very popular architecture for its low cost and low power. I worked a lot with Microchip "PICs" in the past and I now begin to think that one is a ripoff of the other (but I have no proof) -- The resemblance is just striking!  EDIT: I just checked and first AVR = 1995 vs. first PIC = 1975 (yeah, that's 20 years difference) and I think it pays off: the architecture is slightly better.
For development, you have many choices but really two main options are there: Arduino or avr-gcc-based tools. The Teensy guy (paul) created a plugin for the Arduino platform and eases the pain often associated with these type of projects.  On the downside, Arduino and their "sketches" seemed a bit limiting and not that effective (performance-wise) so I opted to go with the free Atmel's AVR Studio coupled with avr-gcc (installed by WinAVR). So I would do my stuff in straight C.  EDIT: I actually changed to using Eclipse (see following posts).

Programming Approach for the ADB Bus
While waiting for the Teensy, I started reading the specification of the ATmega32U4 and see what approach I might go with. The ATmega32U4 has what they call an "input capture" and "output compare" functionality. Simply put this is a way to use on-board "timers" to either measure (input) or "generate" a "pulse" size without going into a "polling loop" of checking if the signal is up or down.  The chip is clocked at 16Mhz on the Teensy, and based on the documentation (and my rough understanding of all the parameters) -- I should be able to handle a "change" of signal on the ADB bus easily under 3us and with a potential precision of about ~0.1us (if the stuff is carefully done).  The smallest pulse is a bit over 30us -- that's ten times bigger -- so that means it is really perfect for the job.

Learning about the ADB Wacom protocol
I have to interface the bus signals. When that is done, I will immediately have to decode and encode the packets to make the tablet live to its full potential. This is not documented anywhere I can find. Tufty already did quite a good job of decoding the stuff -- enough to make a working driver! That info will kickstart my learning quite a lot I think. But in order to learn and also "test" that my stuff is OK, I need a solution to "analyze/debug" the ADB bus.
Tufty stated in his imateosx project wiki page (and also a bit more to me as I am asking questions) a bit how to go about running Apple's "ADB Analyzer" tool. You essentially need to have 2 Classic Mac, one that runs the Wacom driver and the tablet, the other that runs the "ADB Analyzer".  I do not have 2 Classic Mac and can't seem to find any (for 0$). In my case, since I do have a little "scope" (which allow me to see the bus signals to the nanosecond and take screenshots) and I have the intention of decoding the ADB bus signals anyway, I might actually simply run a second board that would essentially only "listen" to the adb bus and "dump" what it sees to a software running on the PC. In other words, roll my own ADB analyzer for my own purpose.

Learning about the Serial Wacom protocol
The serial protocol is well documented and many had implemented it -- the Linux driver, TabletMagic and the Microsoft DDK drivers Wacom examples comes to mind.

Learning about the USB Wacom protocol
This has been done before -- at least from a Linux driver standpoint. I believe this is an HID device and can be a bit complex to get a hang of all this. One thing here is that I would have to re-use the IDs from existing Wacom tablets for the Wacom drivers to work correctly. Reporting the coordinates, pressure, button, etc. is one thing, but the configuration side of it might not be as easy to "match" to the ADB tablet. (Probably some Wacom configuration options will be ignored).  I only possess a Graphire3 USB tablet and it is not in the same family as the Intuoses (I think there is no Tilt for example) -- I might have to get my hands on other USB tablets that would have enough features to match against the professional UltraPads).

EDIT: I now have two Intuos2 12x18 - both a USB and a serial version. Thanks to titus1972 for selling it to me at a low price for this project. It came without any pens so I will focus on Graphire3 until I find one.

I will need to eventually get my hands on a USB analyzer of some sort.

Software on the Host
True that the Teensy is meant to run without any special driver on the Host machine (PC/Mac/Linux) (other than the standard Wacom ones). I will still require special configuration options, like selecting the "right" tablet (if not automatic) or tweaking a few options here and there. For that I thought of using the excellent libusb project and its libusb-win32 along with javalibusb and simply build the software with Java -- this would allow it to run anywhere (Windows/Mac/Linux) without much problem (in theory at least).  libusb works with most popular OSes -- including Windows 7, 64 bits (their driver is now officially "signed" so you can install it on 64bit OS -- yay!).

EDIT: I am now debating between: Java, Adobe AIR (extended desktop mode) or PyGTK.
EDIT2: I picked Java -- main reason is that I totally know the ins and outs of the java language - including going JNI (dll) interfacing.

[AmbiDextrose]

Bernard,

With regards to using TabletPC digitizers, this is probably the correct approach. Basically, use the microcontroller board to translate packets from ISDV4 (from a TabletPC's digitizer) to ProtocolV4 (used by older WACOM tablets). In this way, you can still use "regular" serial I/O between the digitizer and the CPU. It should relatively be straight-forward to translate ISDV4 to ProtocolV4 because ISDV4 is a subset of ProtocolV4. One advantage this approach offers is that you will be able to use regular WACOM drivers for their older serial products (i.e., no custom driver development) because the microcontroller will make the TabletPC digitizer act like a regular WACOM serial digitizer. Furthermore, it should be easier to use a regular USB-to-Serial adapter to attach the TabletPC digitizer to a CPU.

In order for this to work properly, the microcontroller board should be able to:

1. translate ISDV4 packets into ProtocolV4 packets (digitizer -> CPU)
2. translate ProtocolV4 control commands into ISDV4 (CPU -> digitizer)
3. provide the proper response (i.e., similar to a regular serial WACOM tablet) to PnP inquiries over the serial port

There won't be a one-to-one mapping between the control commands from ProtocolV4 to ISDV4 so the microcontroller would have to provide "dummy" or "canned" responses to these inquires (from the WACOM driver).

If someone is feeling rather adventurous, you could even attempt ISDV4-to-ProtocolV5 (i.e., Intuos and Cintiq) translation with the microcontroller.

[bernard]

Well, hello AmbiDextrose!!   glad to read you    Thanks for reading that (huge) post.

You seem to know a lot about all those protocols!  Yeah, I did not follow everything you said in details, but I will have to at some point.  So you say the TabletPC and older serial (like Ultrapads) are not using the same protocol?  Quite interesting.  Do you know which protocol my Graphire3 uses?

There are PnP inquiries over the serial port?

Do you have more information and pointers about all these things?  The more info I gather the better. 

"normal" Serial port drivers are nice but not the panacea -- it is difficult to make them work with more recent Windows OSes -- thinking about Windows 7  64 bits -- that is why I want to (as a second step of course) try to make it act as a USB Wacom.

[bernard]

I just received my Teensy! Wow! This is so freakin' small!!!

It is the size of my thumb!  I should have ordered more than one.

[AmbiDextrose]

Hey Bernard,


The Graphire probably uses ProtocolV4 as the only devices that I know of that use ProtocolV5 are the Intuos and Cintiq lines (e.g., support for the slide strips, for example). I don't know which protocol the newer Bamboo tablets support but it should be noted that even ProtocolV4 supports touch. All the details on how the packets for ISDV4, ProtocolV4, and ProtocolV5 are in the Linux driver source code . I'm t work so I can't post the relevant code fragments but I'll send you what I have when I get home later.

And yes, there are PnP inquiries even over the serial port. The following document has more to say about this:
http://www.osdever.net/documents/PNP-ExternalSerial-v1.00.pdf

[bernard]

Little progress: I finished building the setup for the ADB bridge. As expected, this is extremely simple:  Half of an unused S-Video cable from which 3 wires (out of four) are connected directly to the unaltered Teensy board (Vcc, Gnd and PC7). I tried connecting my UD-0608-A tablet and it was powering on normally! pfew! (When doing these things, you always get to a point where you fear smoke at the last moment before connecting it).

Of course there is no software yet on the Teensy to do anything useful, but all seems connecting correctly (so far).


The Teensy board is really small !


I took the other half of that same S-Video cable to build another setup:  Just the Data and Ground without the 5v+ power (Vcc).  This will allow me to build the "ADB Sniffer" using another board (I really should have ordered 2 Teensy) -- but I have an Arduino UNO that should arrive soon, so I'll use the UNO to do the ADB sniffing. I think I will be able to share the same ADB bus signal decoding code.

At the same time, I got myself a working Eclipse-based setup hooked to the Teensy (I really love working with the Eclipse environment). AVR Studio really does not cut it for C development. I do not have any source-level debugging facility (this would require some expensive JTAG-style gear I believe). If I can find an inexpensive device to enable putting breakpoints and debugging, I might go for it (on the UNO and/or the Teensy).

[Osgeld]

hey there, looks like your making good progress!

To Arduino or not to Arduino?

I just jumped in here to add that the question you bring up is one of the reasons why I like arduino, the software for it is just a extra layer on top of avrgcc to make it more friendly, but because of this you can write avrgcc code or even asm code in an arduino sketch for when you need speed, and use simple arduino functions for stuff that is not critical, which can be a time saver in prototype stages

anyway best of luck!

[bernard]

Hello Osgeld!  Thanks for joining!

You have a good point for the Arduino platform!  Of course, I already know C quite well and the Eclipse IDE: that is why I felt immediately comfortable with this environment (once I got it to work). Some people seem to hate Sketches and others are passionate about it. I do not wish to turn this thread into a Arduino flame war. Suffice to say that they are targeted at different task and/or people. Arduino filled a niche and it caught up brilliantly -- it seems very popular!   

On that note, I just received my Arduino UNO.  This board has the best marketing material I have ever seen -- it feels like you are opening an Apple product!  No kidding! I do recognize the Italian spirit here.  (I ordered a FT232R breakout board at the same time, so here you can see the relative size of these things)

[Osgeld]

Yea Im not here to "twist your arm" but as a C-tarded person its been a great way for my to slip into avrgcc stuff at my leisure while still having the arduino crutch around hehe

glad your happy with the uno, I have no plans to buy one, course I never do (just got done making my own custom board anyway) but from what I hear its pretty nice, there may be a couple kinks to work out in it but nothing massive or major, even if the worst happens you have another board which can re-flash the arduino avr 

[bernard]

I must confess I already like the Teensy *way* better.

[Osgeld]

yea its probably going to be next on my shopping list