USB issue - 18F4550

[Scampy]

@Darrel,

Hi, need some advice regarding the way the HID260 USB routine works.

I commented out the send section in my main code thus:

 ;   if TX_READY = 1 and plugged = 1 then gosub SendUSB
    if RX_READY = 1 and plugged = 1 then gosub GetUSB 
    if plugged = 0 then FirstSend = 1       'If we unplug then reset the first read packet as dont want it!

So this way I can check the sending of data from the PC to PIC. As the software is written to read the EEPROM data from the PIC first, the application displayed garbage values in the sliders which was as expected. Opening up the port monitor I got one TX report for each time I clicked on the update button, and whilst I couldn't see what values I was sending to the PIC, the LCD appeared to respond and display the change of values.

I removed the comment from that line and again the PIC was spewing report after report as you found. I therefore added the line

SendData:
    
        USBOut 1, USBTXBuffer, USBBufferCount , SendData  ' if bus available, transmit data
        plugged = 0
        return

The theory being that once it's sent that first report the software would then behave as if the USB lead had been removed - there was no change when the USB port was monitored. So I tried the following

        USBOut 1, USBTXBuffer, USBBufferCount , SendData  ' if bus available, transmit data
        TX_READY = 0
        return

Again, my logic thinking that once the report had been sent and the TX_ready state set to "not ready" it would stop transmission - but again no change. It's as if something else is over-riding the values used, which originate in the included HID260 file. The code I'm using doesn't have any other calls or conditions connected with the USB, just those IF / THEN statements to check the status of ready and plugged, and then the send and receive routines. Can you advise where or why over-riding these variables have no effects.

Cheers

Malcolm

[Darrel Taylor]

PLUGGED, RX_READY and TX_READY are status bits that DT_HID copies from the hardware USB registers on each USB interrupt.

They allow your program to know the USB status.
But they do not control anything.

Why not just increment a variable, and only send data when it reaches 127.
Then it should send it once a second.

[Scampy]

Thanks for the info,

I've added a counter and condition as suggested and it does indeed now pole once a second, but I'm still getting the same issue, but this time it's easy to spot. I can move a slider, click update, but a second later it will revert back to it's default setting. Watching the port monitor, only RX reports are being shown. However if I comment out the part of the code which does the checks for TX ready and plugged, I can send updates from the PC, which is shown in the port monitor window. It's as if the RX part on the PIC side is being ignored

[Darrel Taylor]

I'm guessing that you still haven't enabled the status LED's from post #3.
Since you're using an EasyPIC board, you should have lots of LED's to use.
It makes it a lot easier to see what's going on.

The PIC program has no problem receiving data from my PC app.
Can you post your friend's PC app?

[Scampy]

Hi Darrel,

Sorry, no I've not had much chance of hooking up the LEDs to the USB activity... Looking at the manual for the EasyPIC5, setting the jumpers to route the D+ and D- etc from the socket to RC4 and RC5 results in these pins being disconnected from the rest of the board. I'll see if a breadboard approach might help.

I've attached a zip file containing the PC software, hope that it helps

[Darrel Taylor]

The Status LED's do not connect to the D+ or D- pins.
You can use any pin besides those.

And your problem is definately in the PC program you just posted.

It does not update anything until it receives a report from the PIC.
Even the clock in the bottom right corner only updates on each report from the PIC.

If you make it so the PIC does not send anything, then the PC program will send updates.
But as soon as the PIC sends something, the PC program will never send anything again.

That program needs some serious work.

[Scampy]

Darrel,

As stated, I didn't write the bulk of the code, as both it and the application was written by a friend, who said that back in 2006 it worked fine but on a different chip. I can confirm that he did indeed write the application to function in that way, ie the PIC sends data when it detects the USB connected and then sends updated data back once the update setting button is pressed. I agree a better approach would of been to have the application set the values and then simply update the PIC once the update button has been pressed. I could ask him if he still has the source code and if it can be modified to work that way.

Thanks again for your input.