String length problems

[hyperion007]

When I am sending a String to the PIC using the USB Slave component, it seems as if only the first 30 letters are shown and after that there are some strange characters.

The String variable has a set length to [80] like: String[80] but maybe there is another limit that I am unaware of?

Please see attached photo.

[Benj]

Hello,

If you click on the USB Slave component on the panel, then select custom code, then select the defines function and click edit.

Find this line.

Code: Select all

#define USB_EP1_OUT_SIZE	32

and change to make as big as you like (think it may have to be a power of 2 to work?)

eg.

Code: Select all

#define USB_EP1_OUT_SIZE	128

I think the OUT buffer is from the PC to the uC and the IN buffer is from the uC to the PC, may have got this the wrong way around so something to try if your having problems.

[hyperion007]

Ah great! Thanks. I had already tried the USB_EP1_IN_SIZE. I was close

[hyperion007]

Hi Ben (or anyone really)

This did the trick. but I think the PIC18F4550 is out of memory because I have two strings with max size [80], one with [40], one with [16] plus almost 40 variables which are mostly Byte size but one is ULong

I can increase this custom code to 64, but anything past that is a no go. I have tried: 72, 80, 96, 128

If I send a string to the PIC with more than the maximum number specified in the variable, normally the string is just cut off, but now I am seeing only the last bytes of the string if it is too long.

I thought it might be because I have a larger limit in the custom code than the string variables but it's the same if I change it so both the variables and the custom code has 64 as max length.

Do you think this is the problem, running out of memory?

[hyperion007]

I don't think it should be a memory issue but maybe USB RAM addressing issues?

From the Datasheet of PIC18F4550:

17.3 USB RAM
USB data moves between the microcontroller core and
the SIE through a memory space known as the USB
RAM. This is a special dual port memory that is
mapped into the normal data memory space in Banks 4
through 7 (400h to 7FFh) for a total of 1 Kbyte
(Figure 17-5).
Bank 4 (400h through 4FFh) is used specifically for
endpoint buffer control, while Banks 5 through 7 are
available for USB data. Depending on the type of
buffering being used, all but 8 bytes of Bank 4 may also
be available for use as USB buffer space.
Although USB RAM is available to the microcontroller
as data memory, the sections that are being accessed
by the SIE should not be accessed by the
microcontroller. A semaphore mechanism is used to
determine the access to a particular buffer at any given
time. This is discussed in Section 17.4.1.1 “Buffer
Ownership”.

[hyperion007]

Are these addresses the starting point or end point?
#define USB_EP0_OUT_ADDR 0x0500
#define USB_EP0_IN_ADDR 0x0508
#define USB_EP1_IN_ADDR 0x0510
#define USB_EP1_OUT_ADDR 0x0530

Because just changing the #define USB_EP1_OUT_SIZE 128 instead of 32 doesn't work.

For example: I have changed the USB_EP1_OUT_SIZE to 64 and set the String variable that I store the incoming string in to [63] and also tried setting it to [72] with the same results

And when I send this string: "Motörhead - One Track Mind - Live At Manchester Apollo 10th June 1983" which is 69 bytes all that the String[63] is containing is: " 1983" which are the 5 bytes that are "left"

This is to me a bit strange, since I have set the limit to 64 in the custom code of the USB Slave component, it is still reading all 69 bytes but cannot parse these bytes to the string[63/72] variable. Then my code is reading the data that is left, which normally has a length of 0, and overwriting my String variable with the leftover bytes not read from the USB buffer last go around.

[hyperion007]

Nothing?

I have two days off and would like to get this sorted

[hyperion007]

Anyone wanting to take a stab at this?

[kersing]

Have not looked at the sources to verify my assumption, but it looks like you are getting two packets from the PC. The first one with 64 bytes and the second with the remainder. Could you add a count of total packets received to your program, increment it for each incoming packet and display that count to see if it increments twice for these longer strings?

[hyperion007]

Even if I send a string of lets say 20 bytes, it's still not working when USB_EP1_OUT_SIZE is above 64

That is what confuses me. If I have USB_EP1_OUT_SIZE set to 64 or less and receive a 20 byte string it works fine.
If I send a string that is 65 bytes long then I will only get the 64 first bytes into my String[80] variable and the 65th byte will remain in the incoming buffer. And because my code is checking RX and storing anything that is in the buffer into String[80], then I get the length of the String[80] and if the length is >0 it stores the value of String[80] in String2[80], it causes the first part of the incoming string to be overwritten with whatever is left in the buffer. If the length is 0 then I skip the String2[80]=String[80] part of the code.

[hyperion007]

Maybe Ben have time to look at this?

[Benj]

Hello,

Hmm this seems odd. What size are you changing the end point to? Probably needs to be a power of 2 to work correctly. 128, 256 etc.

I know for devices such as HID the packet size cannot go over 64-bytes so this could potentially be the limitation.

There is nothing in the code as far as I can remember that will stop the data count going higher. I will have a quick look through as a sanity check.

From a very quick once over of my old scope app it looks like I was using packet sizes of 128 bytes though it may never have actually been receiving all 128 bytes.

#define USB_EP1_IN_SIZE 128

Dim bDataIn(128) As Byte
lRetVal = ECIO_Transmit(bDataOut(0), 2, nTxDataCnt, bDataIn(0), 128, nRxDataCnt, 50)

[hyperion007]

I have tried everything to get it to work, set the end point to 128, 256 etc, nothing past 64 will work

And If I set it higher than 64, nothing seems to work.

Have you had a chance to check in to it a bit more? I know you are all busy with FC V6.

Best regards,
Daniel