Can't get unit_test to work with PIC18F4550

[nyholku]

Hi,

I added the following to usb_hal.h:

#elif _18F4550
#define BD_ADDR 0x0400
#define BUFFER_ADDR 0x500
#else
#error "CPU not supported yet"

and this to main.c

#elif _18F4550
//__code char __at 0x300000 CONFIG1L = 0x20; // USBDIV=1, CPUDIV=00, PLLDIV = 000
//__code char __at 0x300001 CONFIG1H = 0x0E; // IESO=0, FCMEN=0, FOSC = 1110
#pragma config USBDIV   = 2 
#pragma config CPUDIV   = OSC1_PLL2
#pragma config PLLDIV   = 1
#pragma config FOSC     = HSPLL_HS
#pragma config IESO = 1
#pragma config FCMEN = 0

#else
    #error "Config flags for your device not defined"

(The commented out lines are from own ACM CDC stack I used as reference to ensure that the configs are right for my hardware (4 MHz XTAL) and I verified from the .hex file that they are indeed ok.)

The code compiles and runs but on Mac OS X Mountain Lion the device does not get enumerated. (The board is self powered but that should not make a difference?)

Before I dig deeper I thought I'd pop in here and ask for advice…?

[signal11]

Does it enumerate on other OS hosts? Where does it fail in the enumeration? Are there any logs? What do they say? Plug it into a Linux box and see what the log messages say. Are you getting any USB interrupts? Which demo are you trying to run?

You shouldn't need to change any more than you already have, and those addresses look right.

Also, the 4550 is both an ancient and expensive chip. There's no reason for doing a new design with it. You're much better off with a PIC18 that has a J or K in the part number like the 18f25k50. The new J and K parts are better in every way and a lot less money.

[nyholku]

On 20/06/2014 16:40, Alan Ott wrote:

Does it enumerate on other OS hosts? Where does it fail in the enumeration? Are there any logs? What do they say? Plug it into a Linux box and see what the log messages say. Are you getting any USB interrupts? Which demo are you trying to run?

You shouldn't need to change any more than you already have, and those addresses look right.

Also, the 4550 is both an ancient and expensive chip. There's no reason for doing a new design with it. You're much better off with a PIC18 that has a J or K in the part number like the 18f25k50. The new J and K parts are better in every way and a lot less money.

---

Reply to this email directly or view it on GitHub:
#4 (comment)

I've not yet tested on any other OS, will do in due course and report here.

Thanks for confirming that the changes I made look correct, hmm have
to check if the other config values (that I do not set) could have
a detrimental effect.

As to 4550, this an existing design, see here:

http://www.sparetimelabs.com/eazycnc/toad4/toad4.php

and I'm toying/playing with the idea of moving away from USB CDC ACM to
HID to get rid of the driver installation nuisance on Windows plus
to get away from stream of bytes type protocol to a packet based one.

Thanks for pointing out 18f25k50, looks interesting.

br Kusti

[signal11]

Instead of HID, I'd recommend going with just a straight vendor-defined USB device with a couple of bulk endpoints. On Linux/Mac/Windows, you can use libusb to communicate with it. Windows Libusb uses WinUSB under the hood, and in Win7, you can do this without a driver or INF file (xp requires an INF file). See the apps/bootloader for an example.

[nyholku]

On 20/06/2014 16:55, Alan Ott wrote:

Instead of HID, I'd recommend going with just a straight vendor-defined USB device with a couple of bulk endpoints. On Linux/Mac/Windows, you can use libusb to communicate with it. Windows Libusb uses WinUSB under the hood, and in Win7, you can do this without a driver or INF file (xp requires an INF file). See the apps/bootloader for an example.

---

Reply to this email directly or view it on GitHub:
#4 (comment)
I know, but I don't want use libusb (at least not yet) as I don't want
to add an other dependency to my project, especially C-stuff as I know
from experience it will create work both initially in the support phase.

Besides I still support WinXP and IIRC WindUSB is not available there
and I shun away from anything that needs drivers if at all possible,
it is simply amazing how much trouble driver installation can cause.

I'm accessing USB from Java and I have reasonable 100% Pure Java
implementation of HIDAPI so I'm going see if I can make that work
for me.

br Kusti

[nyholku]

BTW

M-stack seems to be about 7.5 kB when compiled with the MPLABX Free version, do you have access to the Pro version and what is the size then?

My CDC stuff takes about 2.5 kB (IIRC) and I'm a bit (haha) short of space atm.

br Kusti

[signal11]

The XC8 compiler in free mode is atrocious, and on the PIC18, it's a major regression from the older C18 compiler in this respect, unfortunately. I don't have the pro mode, but when you build with the free one it will tell you what it the PRO mode will do. Here's what mine says for the HID Mouse example (pic18f46j50):

Memory Summary:
Program space used 1FD7h ( 8151) of FFF8h bytes ( 12.4%)
...
The MPLAB XC8 PRO compiler output for this code could be
4936 bytes smaller and run 4 times faster.

Also unfortunately, I don't currently support C18 with M-Stack. C18 would create some technical challenges as there are two classes of pointer in C18 (RAM and ROM), but with XC8 (and the GCC-based XC16 and XC32), I can address whatever I need to with one type of pointer. This is why the Microchip code has duplicate functions, one for RAM pointers and one for ROM pointers. It is of course doable; I just haven't done it.

I'm also not opposed to supporting SDCC, but last time I checked, SDCC was unable to use the linear addressing mode. Maybe that was just on PIC16F though, as that was my target at the time. I see that your code uses SDCC, so maybe that's something we could work on together if you're interested.

[nyholku]

On 20/06/2014 17:38, Alan Ott wrote:

The XC8 compiler in free mode is atrocious, and on the PIC18, it's a major regression from the older C18 compiler in this respect, unfortunately. I don't have the pro mode, but when you build with the free one it will tell you what it the PRO mode will do. Here's what mine says for the HID Mouse example (pic18f46j50):

Memory Summary:
Program space used 1FD7h ( 8151) of FFF8h bytes ( 12.4%)
...
The MPLAB XC8 PRO compiler output for this code could be
4936 bytes smaller and run 4 times faster.

Also unfortunately, I don't currently support C18 with M-Stack. C18 would create some technical challenges as there are two classes of pointer in C18 (RAM and ROM), but with XC8 (and the GCC-based XC16 and XC32), I can address whatever I need to with one type of pointer. This is why the Microchip code has duplicate functions, one for RAM pointers and one for ROM pointers. It is of course doable; I just haven't done it.

I'm also not opposed to supporting SDCC, but last time I checked, SDCC was unable to use the linear addressing mode. Maybe that was just on PIC16F though, as that was my target at the time. I see that your code uses SDCC, so maybe that's something we could work on together if you're interested.

---

Reply to this email directly or view it on GitHub:
#4 (comment)

So about half size with Pro, okey, that is not too bad size. My CDC code
has been hand tuned for SDCC and pruned to the border of compliance
and functionality disregarding maintainability and readability...
though I sometimes feel that coding in the right way with lots of
abstractions is counter productive to both coding and maintaining,
like those #pragma config stuff ... had to run circles to ensure
that the correct bits were set because the defs (USBDIV=2 means
USBDIV bit == 1) are so far removed from the datahsheet reality.

SDCC still does not support linear addressing mode (well it does but
then it uses 3 byte pointers and access functions to read/write stuff
through those so that is pretty bad speed wise). So what I did is that
I have basically two ways in my code to send (dev->host) stuff from ROM
and RAM and all the data copying is concentrated into a few places in
the code and hand crafter ie spelled out and this actually saved a lot
of code and ram and gained some speed (not that it mattered).

A SDCC port of M-stack would be interesting ... but might require
more work than you are willing to put in ... I'm ready to participate
if you so feel.

For me to use M-stack (as it is today) would require moving from
SDCC to XC8 (I don't see myself moving from make/Eclipse to MPLABX)
which makes me hesitate but I'm going to make quite a few changes into
the other-than-USB code anyway so this would be a good juncture to
switch over.

I came across this today, have not had time to read it through but
looked interesting and relevant to optimization of PIC code:

http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/

br Kusti

[rcaisse2722]

I am having the same issue on Windows 7. The device fails to enumerate. Using Windows logman, it appears the device is responding with USBD_STATUS_STALL_PID on the first GET_DEVICE_DESCRIPTOR request from the host.

Any ideas?