gnupic: Thread: Re: [gnupic] USB code, PICDEM FS USB and Linux

Alessandro Zummo wrote:
> 
>  Hello,
> 
>    I'm working on the USB HID code sent a few days ago
>  by Ben Dugan and I'm trying to modify to do
>  simple input / output using Linux.
> 
>   I've modified the USB descriptor and altered
>  the code to send out 8 ascii chars which I read
>  with a simple perl script
> 
>   I now need to add support for receiving data
>  from the host, but found no examples so far.
> 
>   If anyone could help I'd be happy to share
>  the code.

Alessandro,

I'd be interested in seeing your code when you think its at a "useful" 
stage.  I'm curious what the new descriptor looks like, especially 
whether its still an HID keyboard.

I also wanted to point out something that might be relevent: I remember 
reading that there is no guarantee that the byte ordering (of the bytes 
within an individual HID keyboard packet) will be preserved.  I have 
noticed that it does seem to be preserved, but this is not guaranteed by 
the HID keyboard spec. as I understand it.  So: its probably safer to 
send ordered packets rather than ordered bytes if you're operating 
within the HID keyboard domain (maybe you're not, though!).

Ben

Alessandro,

I'm just wondering if you were able to send data from the host to the
4550-based device? I'm now thinking I'd like to be able to do, too.

Ben


Alessandro Zummo wrote:
> 
>  Hello,
> 
>    I'm working on the USB HID code sent a few days ago
>  by Ben Dugan and I'm trying to modify to do
>  simple input / output using Linux.
> 
>   I've modified the USB descriptor and altered
>  the code to send out 8 ascii chars which I read
>  with a simple perl script
> 
>   I now need to add support for receiving data
>  from the host, but found no examples so far.
> 
>   If anyone could help I'd be happy to share
>  the code.
> 
> 

> -----Original Message-----
> From: Ben Dugan 
> Sent: Wednesday, January 25, 2006 3:23 AM
>
> Alessandro,
> 
> I'm just wondering if you were able to send data from the host to the
> 4550-based device? I'm now thinking I'd like to be able to do, too.
> 
> Ben

Maybe you want to take a look at the PICkit 1 (assembly for
16C745) and PICkit 2 source codes (MPLAB C18 for 18F2550).

Another option is to ask in the Microchip Forum USB section. There
are quite some experts there.

Regards,
Xiaofan

On Tue, 24 Jan 2006 14:23:04 -0500
Ben Dugan ####@####.#### wrote:

> 
> Alessandro,
> 
> I'm just wondering if you were able to send data from the host to the
> 4550-based device? I'm now thinking I'd like to be able to do, too.

 Hi Ben,

  I haven't worked on it further. Please find attached
 my derived code. I structured it in a way that
 descriptors to be modified in an easy way.

  If you can work on it, I'd be happy to help
 and test.


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

On 1/27/06, Alessandro Zummo ####@####.#### wrote:
>
>
>  I haven't worked on it further. Please find attached
>  my derived code. I structured it in a way that
>  descriptors to be modified in an easy way.
>
>  If you can work on it, I'd be happy to help
>  and test.
>

I have not looked into much detail of Bminch's Lab 2 code,
however, compare to PICkit 1 and 2, there are some features
missing in the code.

1) vendor request is not implemented (from Lab 2 C code, asm
code is similar)

void VendorRequests(void) {
       switch (USB_buffer_data[bRequest]) {
           default:
USB_error_flags |= 0x01; // set Request Error Flag
         }
}

2) interrupt transfer through EP1 is not implemented.
(from lab2.c)

void ProcessInToken(void) {
       ...
       case EP1:
                      break;
        case EP2:
                       break;
        }
}


I think you need to implement at least the first one to
get effective communication.

Here is an example but it is using Microchip USB framework
(using C18)
http://forum.microchip.com/tm.aspx?m=135115

Regards,
Xiaofan

On Fri, 27 Jan 2006 23:34:16 +0800
Xiaofan Chen ####@####.#### wrote:

> I have not looked into much detail of Bminch's Lab 2 code,
> however, compare to PICkit 1 and 2, there are some features
> missing in the code.
> 
> 1) vendor request is not implemented (from Lab 2 C code, asm
> code is similar)

 [..]

> 2) interrupt transfer through EP1 is not implemented.
> (from lab2.c)

 [..]

> I think you need to implement at least the first one to
> get effective communication.

 Thanks a lot. I'm not sure interrupt transfer needs to be supported,
 i could do just fine with bulk transfers. 

 Do you know if there's an SDCC version of any USB code that can work
 with the PICDEM FS USB?

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

On 1/28/06, Alessandro Zummo ####@####.#### wrote:
>
>  Thanks a lot. I'm not sure interrupt transfer needs to be supported,
>  i could do just fine with bulk transfers.

I think interrupt transfer is not necessary. It seems to me that lab2
code only implements control transfer (EP0).

>  Do you know if there's an SDCC version of any USB code that can work
>  with the PICDEM FS USB?
>
>

I only know the following but I have not tried it yet. Hope this helps.
The email should be in the mailing list archive but I forward it here again.

Regards,
Xiaofan

---------- Forwarded message ----------
From: Xiaofan Chen ####@####.####
Date: Dec 18, 2005 10:26 PM
Subject: Re: [PIC] USB Resources.(/PICkit2)
To: "Microcontroller discussion list - Public." ####@####.####
Cc: GNUPIC ####@####.#### ####@####.####


On 12/15/05, Timothy Gale ####@####.#### wrote:
> Hi Olin,
>
> I'm not sure whether this will be exactly what you want, but over the
> past little while I've been playing with the 2550 and written a C
> library for SDCC.  It's available for download here:
> http://www.geocities.com/tegale2001/downloads/pickit2.tar.gz
>
> usb.c and comms.c are the places where the main USB work is done.
> Unfortunately, no support for interrupt pipes as yet, but bulk ones
> appear to go pretty well (using linux here for the client).  As
> suggested by the filename, it's intended for the PICkit 2 - the goal is
> to get STDP for dspics working, but unfortunately at the moment it
> doesn't seem to be working, whether due to not entering the mode or not
> recognising commands I'm not sure.  If anyone figures out what's wrong,
> I'd be very grateful!
>
> Hope this is of some use
> Tim
>
> PS SDCC version used was from about June - not sure whether the current
> one will still work
>

After a bit of tweaks of the source code (Nop()--> Nop();) and the Makefile,
I can build the source code using the latest CVS version of SDCC. I have
not tested this yet though on the real PICkit 2.

On 1/28/06, Xiaofan Chen ####@####.#### wrote:
> 
>  On 1/28/06, Alessandro Zummo ####@####.#### wrote:
>>
>>    Thanks a lot. I'm not sure interrupt transfer needs to be supported,
>>    i could do just fine with bulk transfers.
>  
>  I think interrupt transfer is not necessary. It seems to me that lab2
>  code only implements control transfer (EP0).
>
The lab 2 code is an HID 1.0 compliant device (a keyboard), which has an
interrupt IN enpoint (EP1 IN) that is used to send the input report every
10 ms or so.  There is no interrupt OUT endpoint, though it would not be
hard to add one.  Output and feature reports in HID 1.0 devices are sent 
via the class request SET_REPORT through EP0.

Brad Minch.

On Sat, 28 Jan 2006 16:47:39 +0800
Xiaofan Chen ####@####.#### wrote:

> I think interrupt transfer is not necessary. It seems to me that lab2
> code only implements control transfer (EP0).

 I've added support for vendor requests (attached). now you can use
 libusb/usb_control_msg to send minimal data to the device using
 the index and value field. It can be useful for small application.

 I'm not sure I've implemented it correctly, but it works ;)

 I think that's the last thing I want to do in assembly for USB
 next step: find something for sdcc.

> >  Do you know if there's an SDCC version of any USB code that can work
> >  with the PICDEM FS USB?

> 
> I only know the following but I have not tried it yet. Hope this helps.
> The email should be in the mailing list archive but I forward it here again.

 I'll have to try it, thanks. 

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

Alessandro and Xiaofan,

Thanks for your recent emails about this. I committed the faux-pas of
asking a question and then going on vacation, so I have only read the
responses now. I will be trying the vendor-request stuff out soon and
I'll write to the list about what I find. I think it might cover what I
need; I only need to transmit small amounts of data to my usb device.

Anyway, thanks again.

Ben




Alessandro Zummo wrote:
> On Sat, 28 Jan 2006 16:47:39 +0800
> Xiaofan Chen ####@####.#### wrote:
> 
> 
>>I think interrupt transfer is not necessary. It seems to me that lab2
>>code only implements control transfer (EP0).
> 
> 
>  I've added support for vendor requests (attached). now you can use
>  libusb/usb_control_msg to send minimal data to the device using
>  the index and value field. It can be useful for small application.
> 
>  I'm not sure I've implemented it correctly, but it works ;)
> 
>  I think that's the last thing I want to do in assembly for USB
>  next step: find something for sdcc.
> 
> 
>>> Do you know if there's an SDCC version of any USB code that can work
>>> with the PICDEM FS USB?
> 
> 
>>I only know the following but I have not tried it yet. Hope this helps.
>>The email should be in the mailing list archive but I forward it here again.
> 
> 
>  I'll have to try it, thanks. 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####