test1
September 24, 2017, 11:13:02 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] 4 5
  Print  
Author Topic: Converting Wacom GD-1218-R from Serial to USB  (Read 31825 times)
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #30 on: December 16, 2011, 04:09:50 AM »

Quote
So my question is now: does it work when you set the normal speed to 9600 bauds?

Yeah, it works at 9600.  That's what I meant when I said "Yes, the standard Teensy firmware works with the Wacom driver when set to 9600 baud but not 19200 or 38400."

The menu does seem to work but I didn't test it carefully.  I noticed that when I move the mouse over the menu area the mouse changes to the little grey "1", "3", etc shape, but when I click the menu I didn't see anything happen.  Also, I couldn't get the "2" to appear when hovering over menu number 2.  So I'll have to do more testing.

I don't see anything on the back that indicates the firmware version but maybe the -R00 at the end of the serial number indicates something...  I've attached a picture of the label.


* IMG_20111215_190125.jpg (484.79 KB. 2592x1952 - viewed 440 times.)

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


pato mania


View Profile
« Reply #31 on: December 16, 2011, 04:21:22 AM »

On Ultrapads, you had a sticker on the EEPROM chip on the PCB that had the firmware version.  Anyways. I think there is none in more recent models.
Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #32 on: December 16, 2011, 04:50:16 AM »

I tested that all the menu buttons work when pressed in the center of the button.  Woot!  The only weird thing I noticed is with the grey rectangle icons I mentioned.  I can't get the grey rectangle with the "2" in it to appear no matter where I place the pen, but clicking menu 2 still works.  The grey rectangle with the "1" only appears when the pen is held at least 3/5ths of the way across the menu from the right edge of the area and about 1/10th up from the bottom, yet the 1 menu activates when the pen is clicked at least 1mm from the right of the menu area.  Menu 3 and 4 show the grey "3" and "4" starting at the exact edges of the menu (actually, the area might be offset to the left by under 1mm).  Menus 5 and above seem to show they grey numbers at the appropriate edges, but I didn't test them extensively.

As for the firmware, there is something that looks kinda eprom-ish with a white sticker that says "0130003" but who knows what that means (Jan 30 2003?).  There's a picture of my whole PCB in the first post if you want to look at it.
Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #33 on: December 16, 2011, 05:05:44 AM »

Two other glitches:

The Intuos 1 mouse is not recognized at all.  It doesn't even show up as a tool in the Wacom control panel.  I think you mentioned in another thread this wasn't implemented because you don't know the tool ID for the Intuos 2 mouse...  Damn.  I think you also mentioned that the linux drivers list the Intuos 2 mouse tool id, but only part of it.  I was thinking that maybe that part of it is always the same and the rest of the number varies by the individual tool for use in distinguishing different tools of the same type?  Like how it recognizes two different but identical model number pens.

EDIT: That made me think of testing a second Intuos1 pen with the tablet.  It is not recognized as a second pen and behaves exactly like the first pen.  So you aren't passing through the unique part of the pen ids through the driver.

If you have the Wacom control panel open and you unplug the tablet and plug it back in, the Tool and Applications rows go blank and if you click things the control panel tends to crash.  Like I had the "Functions" dialog open when that happened and when I closed the Functions dialog, it crashed.  Not really a big deal but figured you should know.
« Last Edit: December 16, 2011, 05:10:27 AM by Dragon » Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #34 on: December 16, 2011, 07:41:32 AM »

Is the mouse really that important?  Did you ever used a mouse with a wacom product before? I had a Graphire3 with a mouse.  The problem is that you have to move your mouse following the X axis of the tablet to move the mouse horizontally.  If my hand is in diagonal and I move the mouse sideways, the mouse will go in diagonal on the screen!!  Simply impossible to use.  In other words, it does not look at the "rotation" of the mouse -- where it is pointing at and do the "math" to compensate. (maybe this is different with the GD because the tablet knows about the mouse Z-rotation?) -- From my limited mouse experience, it just makes the mouse totally unusable!!!   So I am not bothering too much with it -- unless someone tells me it would be really interesting and they really use it.

The list of tool ids (or full serial number) -- is quite large. (just look at the linux driver)

One thing I tried doing in the code is to simply make the mouse act appear as a stylus -- but I am not sure if this is broken or not currently. I guess this is broken (?).  The issue with this is that you could not configure the mouse differently than the pen in the control panel and supporting all the buttons on the mouse might not work either. (since a stylus only has 2 side switches).

Second pen?  What do you mean?  The dual-tracking feature? AFAIK, GD boards do not support dual-track (two devices simultaneously being moved on the tablet). I think only Intuos2 boards does that.  (Intuos3 and 4 does not do it either).  Either way, the tool id would be the same if you have twice the same pen model.  Internally it is some sort of "parallel channel". I do not support simultaneously dual-tracking pens. (simply because this is yet another feature that is not popular -- even Wacom dropped it).  The Eraser has a different tool id (you know that the eraser is actually a separate, independent pen that is just at the other end of your pen -- with its own coil and circuit).  (at least this was true for the Ultrapads, it was two separate boards). They still appear as different devices.

Having two different pens with different serial numbers (a black one and a grey one for example) I think would allow for different settings for each (pressure, relative/absolute, button assignments, etc.)  So you know that when you use the black one, it is configured to do xyz stuff which would be different with the "grey" one.

The tool id in the linux driver is a shortened portion of the serial number (I think it takes a couple of sections of the bigger number). Yeah, maybe there is a variable part to that serial number (but I doubt it).  I think the linux driver did this to come up with unique values that fits in an integral type easily "switch-able" in the source code (for speed).

You can see the serial number in the diagnostic panel. If anyone has a real USB intuos2 with a tool, he could just go to that About -> Diagnostic panel, put the tool on the tablet and copy the serial number appearing there.  It would be awesome.
Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #35 on: December 16, 2011, 07:55:55 AM »

I don't use the mouse either, although I used to WANT to use it with 3D Studio Max because it has five buttons and I wanted to map the extra buttons to rotate and zoom the 3d model...  except the Wacom drivers were so limited in how you could configure those buttons that it wouldn't work.  I asked them to add some simple thing like the ability to make the button hold down control or alt and they never did it.  So I ended up writing a 3ds max plugin that made it work, but it was kind of glitchy.

Anyway, the main reason I want mouse support is so when I sell the tablet I can say it works like a stock USB Intuos 1 and since I'm selling it with the mouse, it only makes sense to make it support the mouse.  But maybe I'll work on adding that functionality myself when I have time.  And no, the mouse does not work at all with Waxbee.  It doesn't move the cursor or show up as a tool or recognize button clicks.

What I mean with using multiple pens is not to use them at the same time, but to have them show up as multiple tools in the Wacom control panel, and each tool remembers separate settings.  Each pen has its own internal ID unique among all pens Wacom produced and normally each pen will show up as a separate tool in the Wacom control panel.  Then you can do things like set one pen to be a brush in Photoshop, another to be an airbrush, and so on... at least I think you can do that.  Again, not a feature I personally use (although it sounds like something I might use if I were doing serious art), but something that would be good when claiming to have the same functionality as a standard USB tablet.

I do have two Intuos1 pens and two Intuos1 mice so if there's a way to get their serial through Waxbee we could see if there's a variable part to the serial.
« Last Edit: December 16, 2011, 07:58:02 AM by Dragon » Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #36 on: December 16, 2011, 08:28:59 AM »

Flash the debug template, run HID Listen and see what it outputs, it is supposed to output a "tool id" that is close to the Linux driver.  What numbers you see appear? This serial number is sent when the pen/mouse comes "in proximity".

Code:
uint16_t toolid = (((uint16_t)buffer[1] & 0x7f) << 5) |
(((uint16_t)buffer[2] & 0x7c) >> 2);

/*
uint32_t serial = (((uint32_t)buffer[2] & 0x03) << 30) |
(((uint32_t)buffer[3] & 0x7f) << 23) |
(((uint32_t)buffer[4] & 0x7f) << 16) |
(((uint32_t)buffer[5] & 0x7f) <<  9) |
(((uint32_t)buffer[6] & 0x7f) <<  2) |
(((uint32_t)buffer[7] & 0x60) >>  5);
*/
console::printHex(toolid, 8);

eraser_mode = 0;

switch (toolid)
{
case 0x007: // 2D Mouse
case 0x09C: // ?? Mouse
case 0x094: // 4D Mouse
case 0x096: // Lens cursor
penEvent.is_mouse = 1;
break;

case 0x812: // Intuos2 ink pen XP-110-00A
case 0x012: // Inking pen
case 0x822: // Intuos Pen GP-300E-01H
case 0x852: // Intuos2 Grip Pen XP-501E-00A
case 0x842: // added from Cheng
case 0x022:
case 0x832: // Intuos2 stroke pen XP-120-00A
case 0x032: // Stroke pen

case 0x112: // Airbrush
default: // Unknown tool
penEvent.is_mouse = 0;
break;

case 0x82a:
case 0x85a:
case 0x91a:
case 0x0fa: // Eraser
eraser_mode = 1;
break;
}
Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #37 on: December 16, 2011, 09:01:06 PM »

I've attached a log of all my tools.  I first touched a pen in the center of the tablet, then a different pen, then a mouse, then a different mouse.

I see two locations for the 0822 pen tool type:

Serial Tablet - GD-1218-R00,V1.2-7
Intuos
¬
*C2A41080010 0C7F03000
0822

*A0)29%2508A41838000000
[USB Packet - In Range packet, eraser=0]


*E0)29!21(28@40h6804y7907

and

¬
*C2A41
0A1311014   09`6000
0822

*A0*2AT5407p70h68000000
[USB Packet - In Range packet, eraser=0]


*E0*2AR5207q710300407y79

I'm guessing that the number immediately before the tool type is the unique id, but I should have placed the two pens down again to see which number stayed the same...

The mice are seen as tool type 0094:

¬
*C204R52232`60017370000
0094
®
*A8/2F-2Dh68v76x78000000


*AA/2F-2Dh68v76x78000000

®
*A8/2F434h68v76030000000


and


¬
*C204R52232 2003~7E`6000
0094
®
*A8+2B/2F   09@40x78000000


*AA+2B/2F   09@40x78000000

®
*A8+2B535)29A41h68000000

PS, waxbee also works fine with the Wacom driver on Win7 64bit.  =)

* toolids.txt (11 KB - downloaded 299 times.)
« Last Edit: December 16, 2011, 10:33:50 PM by Dragon » Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #38 on: December 16, 2011, 11:16:27 PM »

I see in the traces that the mouse does not have a "USB Packet Range eraser=0" message  which means not much is being sent.

I suspect that the following line serial_protocol5.cpp is the culprit, but not sure.  We would need to carefully look at the mouse-generated packets.   I see a lot of A0 for the pen and AA/A8 for the mouse which might be why it is not even behaving like a mouse.


else if (((buffer[0] & 0xB8) == 0xA0) || ((buffer[0] & 0xBE) == 0xB4))


The tool id -- btw-- is for both intuos1 and intuos2.  That makes me think that *maybe* that serial number is compatible ?  Maybe I could just send the original serial number across up to the USB???
Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #39 on: December 17, 2011, 02:37:54 AM »

Wouldn't hurt to try passing the unique ID through.  The idea is just to identify each pen, not necessarily to send through a serial that would actually belong to an Intuos2 pen.  As long as the serials are the same length, I doubt it matters what value you send as long as each pen has a unique value.

It looks like the mouse packets are totally different than pen packets.  From http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37/plain/drivers/input/tablet/wacom_wac.c:

/* 4D mouse, 2D mouse, marker pen rotation, tilt mouse, or Lens cursor packets */
   if ((data[1] & 0xbc) == 0xa8 || (data[1] & 0xbe) == 0xb0 || (data[1] & 0xbc) == 0xac) {

      if (data[1] & 0x02) {
         /* Rotation packet */
         if (features->type >= INTUOS3S) {
            /* I3 marker pen rotation */
            t = (data[6] << 3) | ((data[7] >> 5) & 7);
            t = (data[7] & 0x20) ? ((t > 900) ? ((t-1) / 2 - 1350) :
               ((t-1) / 2 + 450)) : (450 - t / 2) ;
            input_report_abs(input, ABS_Z, t);
         } else {
            /* 4D mouse rotation packet */
            t = (data[6] << 3) | ((data[7] >> 5) & 7);
            input_report_abs(input, ABS_RZ, (data[7] & 0x20) ?
               ((t - 1) / 2) : -t / 2);
         }

      } else if (!(data[1] & 0x10) && features->type < INTUOS3S) {
         /* 4D mouse packet */
         input_report_key(input, BTN_LEFT,   data[8] & 0x01);
         input_report_key(input, BTN_MIDDLE, data[8] & 0x02);
         input_report_key(input, BTN_RIGHT,  data[8] & 0x04);

         input_report_key(input, BTN_SIDE,   data[8] & 0x20);
         input_report_key(input, BTN_EXTRA,  data[8] & 0x10);
         t = (data[6] << 2) | ((data[7] >> 6) & 3);
         input_report_abs(input, ABS_THROTTLE, (data[8] & 0x08) ? -t : t);

      } else if (wacom->tool[idx] == BTN_TOOL_MOUSE) {
         /* I4 mouse */
         if (features->type >= INTUOS4S && features->type <= INTUOS4L) {
            input_report_key(input, BTN_LEFT,   data[6] & 0x01);
            input_report_key(input, BTN_MIDDLE, data[6] & 0x02);
            input_report_key(input, BTN_RIGHT,  data[6] & 0x04);
            input_report_rel(input, REL_WHEEL, ((data[7] & 0x80) >> 7)
                   - ((data[7] & 0x40) >> 6));
            input_report_key(input, BTN_SIDE,   data[6] & 0x08);
            input_report_key(input, BTN_EXTRA,  data[6] & 0x10);

            input_report_abs(input, ABS_TILT_X,
               ((data[7] << 1) & 0x7e) | (data[8] >> 7));
            input_report_abs(input, ABS_TILT_Y, data[8] & 0x7f);
         } else {
            /* 2D mouse packet */
            input_report_key(input, BTN_LEFT,   data[8] & 0x04);
            input_report_key(input, BTN_MIDDLE, data[8] & 0x08);
            input_report_key(input, BTN_RIGHT,  data[8] & 0x10);
            input_report_rel(input, REL_WHEEL, (data[8] & 0x01)
                   - ((data[8] & 0x02) >> 1));

            /* I3 2D mouse side buttons */
            if (features->type >= INTUOS3S && features->type <= INTUOS3L) {
               input_report_key(input, BTN_SIDE,   data[8] & 0x40);
               input_report_key(input, BTN_EXTRA,  data[8] & 0x20);
            }
         }
      } else if ((features->type < INTUOS3S || features->type == INTUOS3L ||
            features->type == INTUOS4L) &&
            wacom->tool[idx] == BTN_TOOL_LENS) {
         /* Lens cursor packets */
         input_report_key(input, BTN_LEFT,   data[8] & 0x01);
         input_report_key(input, BTN_MIDDLE, data[8] & 0x02);
         input_report_key(input, BTN_RIGHT,  data[8] & 0x04);
         input_report_key(input, BTN_SIDE,   data[8] & 0x10);
         input_report_key(input, BTN_EXTRA,  data[8] & 0x08);
      }


They also handle extra info relating to airbrush:

   /* airbrush second packet */
   if ((data[1] & 0xbc) == 0xb4) {
      input_report_abs(input, ABS_WHEEL,
            (data[6] << 2) | ((data[7] >> 6) & 3));
      input_report_abs(input, ABS_TILT_X,
            ((data[7] << 1) & 0x7e) | (data[8] >> 7));
      input_report_abs(input, ABS_TILT_Y, data[8] & 0x7f);
   }
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #40 on: December 17, 2011, 04:00:18 AM »

The code you are showing is the USB packets parsing or the serial packet parsing? I think it is the USB one (but not sure).

Passing down the entire unique ID will work in terms of unicity. I have a TODO in the code to do just that actually.  But I think it still has to be recognized by the Wacom driver to enable the specific tool-related features, no?  Would need to try it out actually. To pass down the serial id, we have to introduce the concept of a serial/tool id in the centralized "pen_event" structure and pen_event "sequence". Since this is centralized, we need to make it work for all combinations of tablets. Lots of tablets (like the ultrapads, ISDV4 penenabled and Topaz) do not have such concepts. And BTW, because of that, I always "loose" the first packet with coordinates with UltraPads (because I use the first packet "event" to send the tool id instead of sending the first coordinates). In older tablets, the first packet contains coordinates.

I do not have the list of IDs for neither tablets (what will happen when we emulate a Bamboo, an intuos4 or a Cintiq eventually?) the best would be to "map" valid numbers from the old series to the newer series.  So potentially we could have some sort of internal "tool ids" (+ keep the original serial number around if any) and depending on the tablets either generate a generic serial id for mapping the internal tool id or, if that works, pass on the original id.

Most of the people I have encountered only have the stylus and for those that have a mouse, it was just collecting dust. Nobody had an airbrush and one had a "lens cursor" I think (on an Ultrapad), which works like a pen in that case (if I recall correctly).

So, yeah, WaxBee is certainly not complete and misses a lot of features (that is why the version number does not start with "1" yet) Smiley. Especially when talking about stuff that only a few people use (like airbrushes). There is a huge difference between making software "functional" vs. completing it. It's the 80/20 rule: it takes 80% of the time to do the last 20% of the work.

But you can help by finding a working serial id for your mouse, and there is a way to try it out using the "debug" field at the bottom of the configuration.

First, this is my "own" spec that I use for talking like an intuos2. The red packet are the ones containing the serial id. Do you think you could come up with a packet for a mouse?

Code:
// USB Protocol V (5)
//
// Data gleaned for the Intuos2
// Button 0 = side switch near the tip (not working with eraser)
// Button 1 = side switch away from the tip (not working with eraser)
//
// [color=red]02 C2 85 20 16 00 2C D0 00 00[/color]   In Range: NORMAL PEN
// [color=red]02 C2 85 A0 16 00 2C D0 00 00[/color]   In Range: ERASER (PEN)
//
// 02 A0 91 06 66 9F 00 20 40 B8   Pen Data (see below)
// ...
// ...
//
// 02 80 00 00 00 00 00 00 00 00   Out of range
//
//
// Pen Data: 02 A0 91 06 66 9F 00 20 40 B8
//
// [0] 02  HID report identifier (02)
// [1] A0  1 1 p 0  0 b c i   p = prox, b = button1, c = button0, i = index
// [2] 91  x x x x  x x x x   x pos
// [3] 06  x x x x  x x x x
// [4] 66  y y y y  y y y y   y pos
// [5] 9F  y y y y  y y y y
// [6] 00  p p p p  p p p p   pressure (1024)
// [7] 20  p p t t  t t t t   t = tiltx - 0 = -60 degrees, 40 = 0, 7F = +60 degrees
// [8] 40  t u u u  u u u u   u = tilty - 0 = -60 degrees, 40 = 0, 7F = +60 degrees
// [9] B8  d d d d  d 0 0 0   d = sensor z distance 0x26..0x0D
//
// touch = pressure > 10
//


BTW, the "debug" data can be used to try out things. You essentially encode the USB HID reports yourself and and dump it there. Not that difficult actually. Probably 3 packets would be enough (or duplicate packet blocks to make the tool stay in proximity for a longer time. This is to see if the wacom driver recognizes it (using the About->Diagnostic panel  -- you see the serial number in there btw).

Check out the template that has a  "+ playback" in the name. I copied the relevant piece here:


# Multi-purpose internal debug data. To be left empty for normal operation.#
DEBUG_DATA = @[
0x1,      # debug type = 1 (USB endpoint packets playback)
0x1,      # trig on "1=Prox out" (0=powerup)
0x1,      # endpoint 1
0xa,      # 10 seconds to wait before starting
0x3,      # repeat sequence 3 times
0xa,      # 10 ms between packets (in 10 ms increments)
0xa,      # packet size (data of that size follows, up to the end of the binary field)
0x2,0xc2,0x85,0x20,0x16,0x0,0x2c,0xd0,0x0,0x0,      #
0x2,0xe0,0x1c,0x2d,0x48,0x29,0x0,0x27,0x43,0x68,      #
0x2,0xe0,0x1c,0x54,0x48,0x20,0x0,0x27,0x43,0x68,      #
0x2,0xe0,0x1c,0x7e,0x48,0x23,0x0,0x27,0x42,0x68,      #
0x2,0xe0,0x1c,0xab,0x48,0x2b,0x6,0x27,0xc3,0x68,      #
0x2,0xe0,0x1c,0xab,0x48,0x42,0x9,0x28,0x43,0x68,      #
0x2,0xe0,0x1c,0x9f,0x48,0x58,0x8,0x28,0x43,0x68,      #
0x2,0xe0,0x1c,0x75,0x48,0x50,0x34,0x28,0x43,0x68,      #
0x2,0xe0,0x1c,0x53,0x48,0x4b,0xb8,0xaa,0x43,0x68      #
0x2,0x80,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0      #   // tool out of proximity
« Last Edit: December 17, 2011, 04:20:05 AM by bernard » Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #41 on: December 17, 2011, 04:46:47 AM »

I was thinking about doing some development on waxbee myself, but based on this post it sounds like you've got a complicated development environment that you don't remember how to replicate...

Have you ever used VirtualBox?  If you're willing, you could make a Clonezilla copy of your development machine, use Clonezilla again to extract the cloned drive to a VirtualBox machine, and then in the virtual machine, delete/uninstall any personal information/programs you've got and send the virtual machine to whoever you want to use as a development environment.  Once space is freed up, I could shrink the hard drive of the virtual machine or send you instructions on how to do that too.  Send me an email if you're interested in details of all this.
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #42 on: December 17, 2011, 05:23:35 AM »

I am sorry but this cloning thing appears to be too much work for the little time I have. My "development machine" is really big and full of other stuff. Besides it is not *that* complicated. Also you do not need to use the same tools as well!!  I use Eclipse CDT running on top of the AVR GNU tool chain -- the tool chain was "installed" for me by the WinAVR installer. Someone already made the bridge with Eclipse CDT. The "complex" part was to tweak the Eclipse so it works the way *I* like it. Really, you do not need that. Actually you do not need Eclipse at all. Just use WinAVR (like a lot of people are using) -- I am just more comfortable with all the little features built-in Eclipse and have my java project (WaxBee) within the same IDE.

If you want to go down the Eclipse path, then I can duplicate the relevant subdirectories. (Eclipse is just an exploded "zipped" file, there is no such thing as an Eclipse install program so there is nothing stored in the Windows registry or other external hacks like that. I can have 20 Eclipse installations side by side and they will not even know about each other).

Really, WinAVR (and its install program) is the tool that do all the hard work (setting up the AVR GNU Tool Chain).  I would suggest that try to make it work. I have the gcc/g++/linker command line options that I use. Also you do not need to build all the little tools and the build the native dlls (but you could as well to support Linux!). You essentially probably only need to build the AVR project and potentially the Java WaxBee tool(s).

Don't get the wrong message, I am very positive about this and helping you out. If you make it work with WinAVR or with some other way, well this is a very good thing for the project and to attract developers to give a hand. "Streamlining" a development environment was on the TODO list like any other feature. It needs to be done. I had to pick my battles. Last time I seriously worked on WaxBee was to create a "button system" (which is not finished btw). Once you have something working, we can commit the supporting files and document the procedure in the wiki or in a text file. Smiley

« Last Edit: December 18, 2011, 05:04:57 AM by bernard » Logged
Dragon
Full Member
***
Posts: 121



View Profile WWW
« Reply #43 on: December 17, 2011, 11:52:28 PM »

On the checkout page it says to type this:
svn checkout http://waxbee.googlecode.com/svn/trunk/ waxbee-read-only

but that results in an error: "svn: URL 'http://waxbee.googlecode.com/svn/trunk' doesn't exist"

This works:
svn checkout http://waxbee.googlecode.com/svn/ waxbee-read-only

So what's next?  I assume I want to compile \waxbee-read-only\WaxB_Adb2Usb but there's no makefile.  I see .project and .cproject files for Eclipse and .cproject has a wide variety of gcc and g++ command lines embedded in it... but which to use?
Logged
bernard
Administrator
Hero Member
*****
Posts: 2584


pato mania


View Profile
« Reply #44 on: December 18, 2011, 04:29:11 AM »

yes, you would want to generate .hex file out of the WaxB_Adb2Usb project.

Options for the different tools:

avg-g++ : (for .cpp files)
  
-Wall -O3 -fpack-struct -fshort-enums -funsigned-char -funsigned-bitfields -fno-exceptions -mmcu=atmega32u4 -DF_CPU=16000000UL
  
avr-gcc : (for .c files)
  
-Wall -O3 -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega32u4 -DF_CPU=16000000UL

The "linker" options (-Wl,x,x,x,x)

-Wl,-Map,WaxB_Adb2Usb.map,--cref -mmcu=atmega32u4

...
Then the resulting .hex file must be in a directory which is on the java classpath when running the WaxBee config java tool. (or replace the .hex file at the same location in the most recent binary waxbee-xx.jar distribution file).
« Last Edit: December 18, 2011, 04:36:12 AM by bernard » Logged
Pages: 1 2 [3] 4 5
  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!