|
|
|
Re:Basic USB - Using Microchip Stack and C#.Net
|
|
Date: 2006/08/04 08:59
|
By: Polaris
|
Status: Visitor
|
|
|
|
|
|
|
Fantastic work. Straight-forward with results and I didn't even bother reading up on the USB standard. Even so, I do have one problem. The Add function in the C# program doesn't work. It always returns zero. I put a breakpoint in my code at the top of the ServiceRequests function in the users.c file and it does get hit when the Add button is pressed but the code never actually makes it to the line of code for adding when I attempt to single step any further. You posted in your documentation:
>> (If the application returns an incorrect value for the Add function, this is most likely due to the total lack of overflow code present in the pic, this is to maintain simplicity!)
I'm not sure what you mean by "the total lack of overflow code". Can you explain this and possibly give me some clue as to what I need to do to get the Add function to work?
Thanks again for the great work!
Polaris
|
|
|
|
|
|
Re:Basic USB - Using Microchip Stack and C#.Net
|
|
Date: 2006/08/04 10:06
|
By: Polaris
|
Status: Visitor
|
|
|
|
|
|
|
|
Did a re-compile using extended mode with an updated .lkr file and the problem disappeared. I tend to use extended mode for most applications using the PIC18F4550.
|
|
|
 |
|
Re:Basic USB - Using Microchip Stack and C#.Net
|
|
Date: 2006/08/04 10:20
|
By: Mat
|
Status: Admin
|
|
|
Karma: 7
|
|
| Posts: 211 |  |
|
|
Well done,
I like this, people solve their own problems before I even get there!!
Mat
|
|
|
 |
|
Re:Basic USB - Using Microchip Stack and C#.Net
|
|
Date: 2006/08/06 23:25
|
By: dariog
|
Status: User
|
|
|
Karma: 6
|
|
| Posts: 107 |  |
|
|
I got interested by your sentence
"I tend to use extended mode for most applications using the PIC18F4550."
So, did anybody try to use extended mode for USB (or other projects)? Successfully? Any drawbacks?
I did read a little about extended mode, but it was not mentioned very deply (in my mind) so I needed more info. I suppose the code will be more efficient and the CPU itself may be leveraged a bit more, isn't it?
Thank you for any info.
|
|
|
|
|
|
Re:Basic USB - Using Microchip Stack and C#.Net
|
|
Date: 2006/08/09 19:26
|
By: majestrix
|
Status: User
|
|
|
Karma: 0
|
|
| Posts: 29 | |
|
|
Hi guys,
here is probably a dumb qn.. but something i really couldnt figure out.. 
in the user.c
if(USBGenRead((byte*)&dataPacket,sizeof(dataPacket)))
how does this line work with respect to the dataPacket "object"?
when i looked at the usbgen.c the declaration of USBGenRead (..) its as byte USBGenRead(byte *buffer, byte len).
so where is this *buffer and where is len in the typedef union DATA_PACKET (user.h)?
in the user.c, i see its CMD as the main switch operators (so i'm gussing first byte is related to this) and things like (dataPacket.led_num == 3) used as a condition, so i'm gussing the data received (the second byte) is stored in led_num.. am i right..? so does that mean i have to have a different struct{} for every additional byte i send..?? OR i have to add another variable as..
struct
{
unsigned :8;
byte led_num;
byte led_status;
byte new_variable;
};
one more thing.. how does the lead_status get a value..??
sorry abut these basic qns.. i just wanted to really understand this program, so that i can develop this further..
thanks a lot.
|
|
|
|
|
|
Re:Basic USB - Using Microchip Stack and C#.Net
|
|
Date: 2006/08/09 19:26
|
By: majestrix
|
Status: User
|
|
|
Karma: 0
|
|
| Posts: 29 | |
|
|
Hi guys,
here is probably a dumb qn.. but something i really couldnt figure out..
in the user.c
if(USBGenRead((byte*)&dataPacket,sizeof(dataPacket)))
how does this line work with respect to the dataPacket "object"?
when i looked at the usbgen.c the declaration of USBGenRead (..) its as byte USBGenRead(byte *buffer, byte len).
so where is this *buffer and where is len in the typedef union DATA_PACKET (user.h)?
in the user.c, i see its CMD as the main switch operators (so i'm gussing first byte is related to this) and things like (dataPacket.led_num == 3) used as a condition, so i'm gussing the data received (the second byte) is stored in led_num.. am i right..? so does that mean i have to have a different struct{} for every additional byte i send..?? OR i have to add another variable as..
struct
{
unsigned :8;
byte led_num;
byte led_status;
byte new_variable;
};
one more thing.. how does the lead_status get a value..??
sorry abut these basic qns.. i just wanted to really understand this program, so that i can develop this further..
thanks a lot.
|
|
|
|
|
|
Re:Basic USB - Using Microchip Stack and C#.Net
|
|
Date: 2006/08/12 19:00
|
By: majestrix
|
Status: User
|
|
|
Karma: 0
|
|
| Posts: 29 | |
|
|
Hello guys,
well, i did more digging and more comparing with the windows program and the datapacket object..
so here is what I THOUGHT is happening... (guys; those of you who are looking for an answer abut this datapacket's real format, pls dont get confused.. this may not be true)
yeah..
the send_buf[0] corresponds to CMD
the send_buf[1] corresponds to the byte led_num;
the send_buf[2] corresponds to byte led_status; <-this i'm not sure
but from these deductions i seem to have gotten a little bit more confused.. 
whats the use of "byte len" and "byte ID".?? even if they are not raelly used for the PIC program, why doesnt the received data correspond to them. i mean from windows the send_buf goes as 0, 1 and 2. but how come the value of send_buf[1] corresponds to led_num, which is in the 3rd stuct, but not to the ID (which is the second)..?
and how does len gets its value..?
sorry to be noisy like this..
but i hope someone can clear some of these for me. 
thanks a lot. this forum has be just great to be honest. 
|
|
|
|
|
|
Re:Basic USB - Using Microchip Stack and C#.Net
|
|
Date: 2006/08/12 19:00
|
By: majestrix
|
Status: User
|
|
|
Karma: 0
|
|
| Posts: 29 | |
|
|
Hello guys,
well, i did more digging and more comparing with the windows program and the datapacket object..
so here is what I THOUGHT is happening... (guys; those of you who are looking for an answer abut this datapacket's real format, pls dont get confused.. this may not be true)
yeah..
the send_buf[0] corresponds to CMD
the send_buf[1] corresponds to the byte led_num;
the send_buf[2] corresponds to byte led_status; <-this i'm not sure
but from these deductions i seem to have gotten a little bit more confused..
whats the use of "byte len" and "byte ID".?? even if they are not raelly used for the PIC program, why doesnt the received data correspond to them. i mean from windows the send_buf goes as 0, 1 and 2. but how come the value of send_buf[1] corresponds to led_num, which is in the 3rd stuct, but not to the ID (which is the second)..?
and how does len gets its value..?
sorry to be noisy like this..
but i hope someone can clear some of these for me.
thanks a lot. this forum has be just great to be honest.
|
|
|
|
|
|
Re:Basic USB - Using Microchip Stack and C#.Net
|
|
Date: 2006/08/12 19:03
|
By: majestrix
|
Status: User
|
|
|
Karma: 0
|
|
| Posts: 29 | |
|
|
|
oops, it got posted twice.. sorry..
|
|
|
|
|
|
Re:Basic USB - Using Microchip Stack and C#.Net
|
|
Date: 2006/08/13 16:57
|
By: dariog
|
Status: User
|
|
|
Karma: 6
|
|
| Posts: 107 | |
|
|
Hi,
well, usually the first byte in the PIC array is the ID (0, 1... in the case of a Report sent FROM PC TO PIC it should be 2 (and "1" in the PIC sends to PC;
the second is CMD (that is, in a WriteFile from PC you must set the byte at index 0 of the array to "2", then the second can be a "CMD", then come the remaining part of the packet.
"len" should always be the lenght defined in your descriptor.
All that I'm stating is for a HID device, using WriteFile/ReadFile on the PC side.
I know that there can be several more ways to receive bytes on the PIC side (in 16C745 I knew of a different "message" which did not show you the ID... but it still had to be there!
|
|
|
|
|
|
Re:Basic USB - Using Microchip Stack and C#.Net
|
|
Date: 2006/08/13 19:23
|
By: majestrix
|
Status: User
|
|
|
Karma: 0
|
|
| Posts: 29 | |
|
|
Hi,
thanks for the ans. i think i have got some insight now. when i read this with the USB Complete by Jan Axelson, things become much clear. (an excellent book on USB design btw, although i feel like the book goes very much deep into USB which is good in a way but not that easy for USB beginners)
thanks.
|
|
|
|
