USBSERVICE + serout2 problem

[aberco]

Well yeah, you're right! it does enumerates!!! and it even blink on my application.

What's happening, this is due to my programming setup and the specific hardwiring of the 18F1xK50. The USB lines D+/D- are shared with PGD and PGC, and it seems that in order for USB to work, the programmer has to be disconnected. For this purpose, I have purchased microchip special module for the 18F1xK50, that adapt the programming levels of the programmer to something that the PIC can accept, but at the same time allows to leave plugged the USB cable of the host computer by protecting the D+/D- lines from programming voltages.

Well I realized early on that it did not work, and I had to disconnect PGD and PGC in order to have USB working, so I added a set of switches on my programming cable.

Now I've been able to verify different behavior on USB programs, especially DT_HID260 which is the only one "powerful" enough to enumerate even with PGD/PGC connected to the programmer. All others required those lines disconnected to enumerate.



Now, about your little CDC routine, it does work well with PGD/PGC disconnected. But when I connect them back the USB connexion drops and the PIC crashes. No big deal, but I'll have to make sure that communication is established when servicing, and especially turn it of before unplugging USB.

Now I'll try to add USBIN/USBOUT statements and play a bit with communication before building the full program around it. Thanks for your great help!

[aberco]

Well, more progress, and so far so good!
In understood that your program proposal is actually a stripped off version of your USB_ASM_Service routine. I have been able to use it within my program now, but calling the DoUSBSERVICE routine using the USB interrupt triggered by your interrupt routine.

So far so good, it does enumerate, and more importantly I have all the control options given by the connected state, Tx/Rx ready. The LED always blink regardless of what the USB is doing.

The only thing that seems to break the code is "DEFINE RESET_ORG 2048 ' Start code at $0800", I added this at the very top to be ready for the bootloader implementation (leaving 1 kWords available). Probably a problem of memory bank and interrupt...

Seems to work very well so far... I am not posting the code until it is ok with you.

[aberco]

Trying to implement a "console like" behavior but cannot get it to work.

I'm using RX_Ready to read USB and then entering the desired reaction regarding the received command. However it seems that after doing an USBIn command, RX_Ready does not stay = 0 for very long, even if absolutely no data is received.

Is RX_Ready indicating a capacity to receive data (buffer not full), just like TX_Ready? In that case I cannot use this to trigger an event upon packet receive...

To better explain it here is some very dirty code.

MainLoop:

ARRAYWRITE USBBuffer, [">"]
GOSUB DoUSBOut

GOSUB DoUSBIn

SELECT CASE USBBuffer [0]
    CASE "A", "a"
        GOSUB  EchoData
        ARRAYWRITE USBBuffer, ["OK", 10, 13]
        Gosub DoUSBOut
    CASE ELSE
        GosuB EchoData
        ARRAYWRITE USBBuffer, ["Error", 10, 13]
        GOSUB DoUSBOut
END SELECT

PAUSE 1000

GOTO MainLoop

'*******************************************************
'Echo sent frame back
'*******************************************************
EchoData:

GOSUB DoUSBOut
ARRAYWRITE USBBuffer, [10, 13]
GOSUB DoUSBOut

RETURN

I'm confused yet about very simple things, like how to clear the buffer between requests. Also here it is polled every seconds, because I do not know how to trigger the event upon packet received... Tried to look for helpful examples without any luck.

[Darrel Taylor]

If you are trying to tie together USB_ASM_Service and the routine I gave in this thread, it won't work as is.

CDC uses a different endpoint than HID.

[aberco]

Well, I managed to make it all work... possibly partially but so far so good!

I can send and receive 32 bytes packets. However as you said I may have not modofied everything which makes TX_Ready and RX_Ready non functional. However they are tied to USB registers and should not be dependent to endpoints if my understanding of the datasheet was correct...



I'm pasting here part of the main code that I used:

INCLUDE "cdc_desc.bas"
INCLUDE "EEPROM_detect.pbp"

'*******************************************************
'Init the interrupt handling system
'*******************************************************
INCLUDE "DT_INTS-18.bas"     ; Base Interrupt System
INCLUDE "ReEnterPBP-18.bas"     ; Include if using PBP interrupts

ASM
INT_LIST  macro     ; IntSource,          Label,  Type, ResetFlag?
        INT_Handler     USB_INT,  _DoUSBSERVICE,   PBP,  yes
        INT_Handler     TMR1_INT,   _TempCheck,   PBP,  Yes
        INT_Handler     INT0_INT,   _USBAttached,   PBP,  Yes
    endm
    INT_CREATE ; Creates the Low Priority interrupt processor
ENDASM

INCLUDE "USB_ASM_Service.pbp"

[aberco]

Last edited by Darrel Taylor; - 10th October 2010 at 16:56. Reason: Incorrect Mod

Well ok, but what does makes it incorrect?

[aberco]

Ok, there's indeed something that relates to endpoint. I understand that you use two bytes located within the USB RAM space to get the TX and RX reports.

BD1STATOUT = _USBMEMORYADDRESS + 8 ; 408h or 208h
BD1STATIN = _USBMEMORYADDRESS + 0Ch ; 40Ch or 20Ch

Now I'm clueless about what this refers to... tried to look at the hid_desc.pbp/asm code and compare it with cdc_desc.pbp/asm, and also to look on the net for RAM endpoint allocation at these two address but no luck so far