Shared memory buffer - nxpUSBLib

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Shared memory buffer - nxpUSBLib

1,023 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by fjarnjak on Tue Jul 03 21:38:17 MST 2012
Shared memory buffer in the nxpUSBLib is limiting my application...

What I want to do is to constantly stream data as fast as possible (no explicit delays, except ones that occur due to snprintf, send, etc) as a virtual COM port to my Windows machine. In case user sends something to the device, stream will be changed, stopped, or whatever else...

However, buffer gets corrupted the moment I send something to the device; streaming one-way works fine. If I send data for example every 1 second, and in the mean time something comes from the PC to the device, buffer is not corrupted because send/receive operations do not overlap. Sometimes though, it naturally happens in case you were unlucky and typed when device was about to send/or sending.

Shared buffer would work in the request & reply scenario - PC sends command; device responds; PC sends another command; device responds, and so on.

Is there a plan to make 2 separate buffers for outgoing and incoming endpoint? Maybe as user-configurable option to save memory for those who do not need separate buffers?


Also, I noticed that when I follow CDC library documentation - meaning calling CDC_Device_USBTask followed by USB_Task() function, after receiving 1 charachter as in the virtual serial demo, it will constantly send charachters back (echo). If I comment out CDC_Device_USBTask it sends one echo. I can see in the example that call to CDC_Device_USBTask was commented out...which seems to confirm my observation. I suggest this issue should get documented or even better it should be resolved so that we can follow API. 


It would be nice to have working CDC_Device_CreateStream to get the stream and use printf type methods directly...



Labels (1)
0 Kudos
7 Replies

980 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by triffid_hunter on Tue Jul 30 17:36:24 MST 2013
https://github.com/arthurwolf/Smoothie/tree/master/src/libs/USBDevice may interest you :)
0 Kudos

980 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mozmck on Tue Jul 30 09:17:05 MST 2013
Did this problem ever get fixed/resolved?
0 Kudos

980 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by peplin on Wed Sep 05 13:05:06 MST 2012
I've started working on a solution for this in my fork of the library, in the 'buffer-per-endpoint' branch: https://github.com/openxc/nxpUSBlib/tree/buffer-per-endpoint

The first step is to have it use a separate buffer for each endpoint. That's working, at least with the LPC1768 board I have to test on. The next step is to use separate buffers for IN/OUT on each endpoint as well.
0 Kudos

980 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Hansi on Sat Aug 04 13:20:28 MST 2012
I also found the problem of the original poster annoying. Why not have a separate buffer for _every_ endpoint instead of one common buffer? That would IMHO follow the original intention of the USB core and its Endpoint command/status list (see user manual, p. 203ff). The buffer could be reserved Endpoint_ConfigureEndpoint() automatically.

Bye
  Hansi
0 Kudos

980 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by tuong on Thu Jul 12 00:55:23 MST 2012
Hi All,

I also think seperating the buffer for IN and OUT can slove this issue.

BTW, have you try the demo running on ROM stack by define:
      #define USE_USB_ROM_STACK  1

With best regards!
0 Kudos

980 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by triffid_hunter on Sat Jul 07 03:58:22 MST 2012
wow that's a huge show stopper for me using nxpUSBLib, thanks for the heads up guys :)
0 Kudos

979 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by rsargant on Wed Jul 04 09:12:58 MST 2012
+1 on this from me.  The CDC_Device_Receive_Byte and CDC_Device_SendByte are sharing the same buffer variables.

uint8_t usb_data_buffer[USB_DATA_BUFFER_TEM_LENGTH] ATTR_ALIGNED(64) __DATA(USBRAM_SECTION);
uint32_t usb_data_buffer_size;
uint32_t usb_data_buffer_index;

IMHO, CDC mode is currently unusable in a "two way communication" production environment.


0 Kudos