Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Justin

  • Rank
  • Birthday 10/09/1973

Profile Information

  • Gender
  • Location
    South Africa
  1. Ok, I found the problem... The UBW board requires set_bit(rcon, IPEN) This enables the low priority interrupts (i think?) And the Endpoint0 addresses must not be offset +0x000800, ie: #define USB_EP0_OUT_SIZE 8 #define USB_EP0_OUT_ADDR 0x0500 #define USB_EP0_IN_SIZE 8 #define USB_EP0_IN_ADDR 0x0508 #define USB_EP1_IN_SIZE 8 #define USB_EP1_IN_ADDR 0x0510 is correct. Device enumerates correctly. Now to writing some code to make it useful. regards Justin PS Big thanks to Ian Harris for your PicPack! Taken me about 3 days to get a device to enumerate... would've taken me 3 years. (I find the Microchip stack too generic (one size fits all) and therefore extremely difficult to step through and understand...)
  2. Hello everyone, I have a Sparkfun 18F2553 USB Bit Wacker (UBW) which has a bootloader loaded at 0x000000-0x0007ff. I have stripped down the PicPack usb_joy_mouse demo to the basics which should enumerate on winxp. I have added the linker option -rb 0x000800 to place the code at the right place. I have Sourceboost IDE 6.97, compiling and linking using BoostC++ (since I don't have a license for BoostC, and the lite ver runs out of ram i think...) The device is programmed using the PICDEM FUSB tool. This works fine, using the boards current config data (ie the bootloaders config?). But after reset, winxp reports the device is "not recognized". I thought it may be that Endpoint0 addresses may not be offset correctly (from 0x500 to 0xD00?). Tried #define USB_EP0_OUT_SIZE 8 #define USB_EP0_OUT_ADDR 0x0D00 #define USB_EP0_IN_SIZE 8 #define USB_EP0_IN_ADDR 0x0D08 #define USB_EP1_IN_SIZE 8 #define USB_EP1_IN_ADDR 0x0D10 Also, modifed in pic_usb.c usb_handle_reset() { ... bd0out.addr = USB_EP0_OUT_ADDR; ... bd0in.addr = USB_EP0_IN_ADDR; ... } as mentioned in another post elsewhere. Still does not enumerate though. Any ideas anyone? Any help will be much appreciated! regards Justin
  3. Hi Pavel, I think it's most useful with structs embedded within a union, in my case specifically to allow easy EEPROM read/write. Not sure how often this would arise, but consider the following hypothetical situation (my actual situation is similar but has more levels embedded): typedef union tagOBJECT { struct { char Data1; char Data2; } Data; //<<==Undesirable declaration char AsChar[2]; } OBJECT; typedef union tagPAIR { struct { OBJECT Left; OBJECT Right; } Objects; //<<==Undesirable declaration char AsChar[4]; } PAIR; PAIR MyPair; MyPair.Objects.Left.Data.Data1 = 0x01; //Allowed MyPair.Left.Data1 = 0x01; //Not allowed Regards Justin
  4. Nameless embedded structures - A nice feature supported by Visual C++ - see excerpt below from Visual C++ reference: struct s { float y; struct { int a, b, c; }; char str[10]; } *p_s; . . . p_s->b = 100; /* A reference to a field in the s structure */ Justin
  • Create New...