LeafLabs Garden

A place to share, learn, and grow...

1. 

   StephenFromNYC
   Moderator

   Tuesday September 05, 2010

   Hello,

   I am glad to see a burst of activity since Maple IDE 0.0.7 was released. Did I miss the 0.0.7 alpha/beta releases?

   I recently used a software USB sniffer, not the hardware sniffer option described by gbulmer, with a Maple Rev 3 connected.

   If I understand the readout correctly, the Maple seems to be configured to use a 64 byte buffer.

   With the hardware sniffer gbulmer reported seeing 16 byte packets during USB transmission (and an Arduino). I will try to learn how to use the software sniffer to determine the packet size with a Maple.

   In the mean time, is there a way to increase the size of the USB buffer size to 128 bytes or 256 bytes?

   I want to quickly see if changing the USB buffer size affects the SerialUSB.print() problem I still experience with my LabVIEW/Maple project.

   http://forums.leaflabs.com/topic.php?id=209

   If there are 512 bytes available for USB configuration how are the other bytes currently used?

   Also, what is the status of DMA in Maple IDE 0.0.7? I did not see any mention of DMA in the 0.0.7 documents.

   Many thanks for your hard work!

   Stephen from NYC

   Posted 5 years ago #
2. 

   poslathian
   LeafLabs

   No DMA in 0.0.7, 0.1.0 though, as planned.

   USB has 3 buffers. The first is a 512 byte dual port SRAM, directly and simultaneously accessed by the hardware and software. However, the packetsize for serial port endpoint (which is a pair of bulk endpoints) is 128 bytes (64 in, 64 out), so the remaining memory in the 512 byte sram is used for other USB stuff (like the ctrl endpoint) or is empty.

   Next, we have a 64 byte receive buffer, that is a ring buffer (circular) that gets filled by copying data out of the 64 byte packet memory (which cant be used as a buffer since it overwrites that hardware packet memory from 0 at every new usb transaction).

   Finally the tx buffer, which is not a ring buffer (should be though...) is 64 bytes that just directly copies into the packet memory. In future revisions, we should have 1024B of a circular tx buffer, which should do wonders for the SerialUSB stability (albeit not a 100% fix, since theres still the DTR based auto-reset issue).

   As for how to change all these things? There is no API for this, its all configured in libmaple/usb/usb_config.h

   Currently, the size of the receive buffer is set to VCOM_RX_EPSIZE, same as the packet memory itself, which is not really so great. This buffer is established in usb_callbacks.c

   For 0.1.0, what wed like to do is have configurable RX and TX buffer sizes (both ring buffers) with 64 byte default sizes and an API to tweak these ranges. Until then, happy hacking!

   Posted 5 years ago #
3. 

   gbulmer
   Moderator

   I've been thinking about this over the last few days. I am interested in quite high data rates from the Maple to host.

   If a Maple program does a write/print/whatever and it's too big to fit into the maplelib buffer, does the function call block?

   I assume it does.

   If that's the case, then I wondered if there might be some value to having a specialised non-blocking 'constant write'? The 'Constant write' contract is that any buffer handed to it must be treated as 'read only' by the users Maple program until it is released. The buffer is read-only by convention (no fancy tricks) until it is released by a 'constant release' function which the user could poll (there may be a callback function registered too).

   To make it easy to implement, there may be an arbitrary, small, limit to the number of buffers, say, 8 outstanding buffers.

   This way, the user could manage the double buffering to suit their purposes, and maplelib could use small buffers, leaving as much space as practical to the user program.

   Just a thought.

   Posted 5 years ago #

RSS feed for this topic

Reply

You must log in to post.