aboutsummaryrefslogtreecommitdiffstats
path: root/libmaple/usb/usb.c
diff options
context:
space:
mode:
authorAJM <poslathian@poslathian.(none)>2010-12-13 22:03:14 -0500
committerAJM <poslathian@poslathian.(none)>2010-12-13 22:03:14 -0500
commit873356a31fae8cf4e8b6a5ab609125a5a501d1c4 (patch)
tree7747300a71f5597ef048128c47ec267a59e9e04b /libmaple/usb/usb.c
parentb67d281d85bd59a9738a9a43c4db1027f81d9208 (diff)
downloadlibrambutan-873356a31fae8cf4e8b6a5ab609125a5a501d1c4.tar.gz
librambutan-873356a31fae8cf4e8b6a5ab609125a5a501d1c4.zip
candidate bugfix for serialusb receive bug
changed USB driver to nak whenever it cant fill an entire endpoint (64B) worth of new data. The old scheme was to set receive valid as long as as the endpoint buffer wasnt full, the new scheme is to nak until it is completely empty.
Diffstat (limited to 'libmaple/usb/usb.c')
-rw-r--r--libmaple/usb/usb.c30
1 files changed, 10 insertions, 20 deletions
diff --git a/libmaple/usb/usb.c b/libmaple/usb/usb.c
index 923e54b..2b99132 100644
--- a/libmaple/usb/usb.c
+++ b/libmaple/usb/usb.c
@@ -332,23 +332,11 @@ void usbWaitReset(void) {
* This function will quickly copy up to 64 bytes of data (out of an
* arbitrarily large buffer) into the USB peripheral TX buffer and return the
* number placed in that buffer. It is up to usercode to divide larger packets
- * into 64-byte chunks to guarantee delivery. Use usbGetCountTx() to determine
- * whether the bytes were ACTUALLY recieved by the host or just transfered to
- * the buffer.
+ * into 64-byte chunks to guarantee delivery.
*
- * The function will return -1 if it doesn't think that the USB host is
- * "connected", but it can't detect this state robustly. "Connected" in this
- * context means that an actual program on the Host operating system is
- * connected to the virtual COM/ttyACM device and is recieving the bytes; the
- * Host operating system is almost always configured and keeping this endpoint
- * alive, but the bytes never get read out of the endpoint buffer.
- *
- * The behavior of this function is subtle and frustrating; it has gone through
- * many simpler and cleaner implementation that frustratingly don't work cross
- * platform.
- *
- * */
-uint16 usbSendBytes(uint8* sendBuf, uint16 len) {
+ *
+ */
+uint32 usbSendBytes(uint8* sendBuf, uint16 len) {
uint16 loaded = 0;
@@ -384,7 +372,7 @@ uint16 usbSendBytes(uint8* sendBuf, uint16 len) {
}
/* returns the number of available bytes are in the recv FIFO */
-uint8 usbBytesAvailable(void) {
+uint32 usbBytesAvailable(void) {
return VCOM_RX_EPSIZE - maxNewBytes;
}
@@ -392,7 +380,7 @@ uint8 usbBytesAvailable(void) {
usb packet buffer) into recvBuf and deq's the fifo.
will only copy the minimum of len or the available
bytes. returns the number of bytes copied */
-uint8 usbReceiveBytes(uint8* recvBuf, uint8 len) {
+uint32 usbReceiveBytes(uint8* recvBuf, uint8 len) {
if (len > VCOM_RX_EPSIZE - maxNewBytes) {
len = VCOM_RX_EPSIZE - maxNewBytes;
}
@@ -403,11 +391,13 @@ uint8 usbReceiveBytes(uint8* recvBuf, uint8 len) {
recvBufOut = (recvBufOut + 1) % VCOM_RX_EPSIZE;
}
- maxNewBytes += len;
+ maxNewBytes += len; /* is this the potential bug? */
+ // assert(maxNewBytes < VCOM_RX_EPSIZE)
/* re-enable the rx endpoint which we had set to receive 0 bytes */
- if (maxNewBytes - len == 0) {
+ if (maxNewBytes >= VCOM_RX_EPSIZE) {
SetEPRxCount(VCOM_RX_ENDP,maxNewBytes);
+ SetEPRxStatus(VCOM_RX_ENDP,EP_RX_VALID);
}
return len;