This is the status update on Arduino USB Host Mini development, announced 3 weeks ago. I received rev.0 PCBs last Saturday – BatchPCB is faster than ever! I made a test build (see title picture) and after fixing one major and several minor mistakes placed an order for what [...]]]>

First prototype of USB Host Mini

This is the status update on Arduino USB Host Mini development, announced 3 weeks ago. I received rev.0 PCBs last Saturday – BatchPCB is faster than ever! I made a test build (see title picture) and after fixing one major and several minor mistakes placed an order for what I’m hoping will be the final pre-production sample.

The prototype was built to sit on top of Arduino Pro Mini to make access to the parts easier during troubleshooting. On the final board USB connector is placed slightly further away from the pins; it will be possible to place Arduino on top of the shield so that the height of the “sandwich” will be less or equal to the height of USB connector.

In 2-3 weeks I’m hoping to finalize the design and start producing the USB Host Mini. Stay tuned!

Oleg.

This post announces starting of development of new Arduino USB Host Shield variant. There are several projects in the works (thanks, guys for letting me know!), where standard size Arduino board is too big. Since electronics of USB Host Shield is pretty simple, it was decided to shrink the board as [...]]]>

USB Host mini rev.0

This post announces starting of development of new Arduino USB Host Shield variant. There are several projects in the works (thanks, guys for letting me know!), where standard size Arduino board is too big. Since electronics of USB Host Shield is pretty simple, it was decided to shrink the board as much as possible. Here is the first iteration.

The initial revision of USB Host Shield in Mini form factor is shown on title picture, It is intended to be used with Sparkfun’s 3.3V Arduino Pro Mini. Intended applications include digital camera control devices, robots, as well as any other projects where size and weight has to be minimized. The Gerbers was sent to BatchPCB; I’m expecting boards back in couple of weeks. The main goals of this first prototype are manufacturability check as well as checking claims made below.

The Mini Host is simplified version of full-sized shield; only USB and GPIO are available. By default, VBUS is routed to VCC, therefore only self-powered USB devices are expected to function (even though I have at least one USB flash drive which works fine powered from 3.3V VBUS). I also provided extra pads to simplify signal re-routing, however, since there was no place left for jumpers a trace has to be cut instead. The same has been arranged for VBUS – if 5V power is necessary, Arduino Pro Mini/Shield combination can be powered with 5V on RAW pin, the VCC trace cut off VBUS and RAW and VBUS connected.

As soon as first prototype is tested, I will post CAD files and also make boards available at BatchPCB. Stay tuned!

Oleg.

Based on some discussion on the Arduino Forum, Richard has added this blog entry as work in progress on developing a library to support FTDI Serial port devices on the USB Host Shield. While cautious to publish at this early testing stage, the content here should help parallel developers.

My [...]]]>

FTDI232RL IC on a breakout board

Based on some discussion on the Arduino Forum, Richard has added this blog entry as work in progress on developing a library to support FTDI Serial port devices on the USB Host Shield. While cautious to publish at this early testing stage, the content here should help parallel developers.

My thoughts last year were that an FT232 driver for the Host Shield was not really useful. It seemed rather reverse to add a USB host plus a USB device to achieve something that can be done with a piece of wire. However USB is coming to be the baseline interface and is now the only interface offered on many serial devices.

USB Shield Hardware
Since my last blog update, Sparkfun have released their own version of the USB Host Shield. Great to have another source of the shield, with good stock at many International Sparkfun distributors. However they did add a couple of problems too:
Sparkfun swapped the RESET and the GPX pins from the original from Oleg. This means the shield will not work with the libraries from Oleg without a modification.
The current Max3421e_constants.h from Oleg has:

/* Arduino pin definitions for USB Host Shield signals. They can be changed here or while calling constructor */
#define MAX_SS 10
#define MAX_INT 9
//#define MAX_GPX 8
#define MAX_RESET 7

These work for the shield from Oleg, and existing published code and libraries without change.

However for the Sparkfun Shield they must be changed in Max3421e_constants.h, or optionally changed when the constructor is called to:


#define MAX_SS 10
#define MAX_INT 9
//#define MAX_GPX 7
#define MAX_RESET 8


To add further complication, In the FTDI code I will describe below MAX_GPX is used, so must be uncommented in Max3421e_constants.h or added as a #define in the sketch. Again this should match the shield type as above.

The other common problem with the Sparkfun shield is that it is powered differently from the shield from Oleg. The Sparkfun Shield and the connected USB device is powered from Vin via voltage regulators. While the Arduino 5V and 3.3V supplies can be provided by either Vin or Vusb, Vin cannot be provided by Vusb. This means the Sparkfun shield must have an external Vin supply to work, while the shield from Oleg does not need this.

Library Updates
There have been some library updated from Oleg over the last months to include a number of changes to support latest applications. The latest version from Oleg should be backward compatible to existing sketches and examples.
Here again, I will propose another addtional change to the usb.h library. The reason for this is that the existing devices which have been used on the USB Host Shield, all returned either a known number of bytes during an in transfer, or the data bytes contained the length within the data itself. The FTDI device, does not do this and sends a variable length packet, without length indication within the data. Thus we need to pass the data length back to the sketch in some other way.
To maintain backward compatibility I added an new version of the in transfer:
In usb.h
byte inTransfern( byte addr, byte ep, unsigned int* nbytes, char* data, unsigned int nak_limit = USB_NAK_LIMIT );

and in usb.cpp

/* Version with pointer to nbytes, to return actual number */
/* IN transfer to arbitrary endpoint. Assumes PERADDR is set. Handles multiple packets if necessary. Transfers 'nbytes' bytes. */
/* Keep sending INs and writes data to memory area pointed by 'data' */
/* rcode 0 if no errors. rcode 01-0f is relayed from dispatchPkt(). Rcode f0 means RCVDAVIRQ error,
fe USB xfer timeout */
byte USB::inTransfern( byte addr, byte ep, unsigned int* nbytes, char* data, unsigned int nak_limit )
{
 byte rcode;
 byte pktsize;
 byte maxpktsize = devtable[ addr ].epinfo[ ep ].MaxPktSize;
 unsigned int xfrlen = 0;
  regWr( rHCTL, devtable[ addr ].epinfo[ ep ].rcvToggle ); //set toggle value
  while( 1 ) { // use a 'return' to exit this loop
    rcode = dispatchPkt( tokIN, ep, nak_limit ); //IN packet to EP-'endpoint'. Function takes care of NAKS.
    if( rcode ) {
      return( rcode ); //should be 0, indicating ACK. Else return error code.
    }
    /* check for RCVDAVIRQ and generate error if not present */
    /* the only case when absense of RCVDAVIRQ makes sense is when toggle error occured. Need to add handling for that */
    if(( regRd( rHIRQ ) & bmRCVDAVIRQ ) == 0 ) {
      return ( 0xf0 ); //receive error
    }
    pktsize = regRd( rRCVBC ); //number of received bytes
    data = bytesRd( rRCVFIFO, pktsize, data );
    regWr( rHIRQ, bmRCVDAVIRQ ); // Clear the IRQ & free the buffer
    xfrlen += pktsize; // add this packet's byte count to total transfer length
    /* The transfer is complete under two conditions: */
    /* 1. The device sent a short packet (L.T. maxPacketSize) */
    /* 2. 'nbytes' have been transferred. */
    if (( pktsize = *nbytes )) { // have we transferred 'nbytes' bytes?
      if( regRd( rHRSL ) & bmRCVTOGRD ) { //save toggle value
        devtable[ addr ].epinfo[ ep ].rcvToggle = bmRCVTOG1;
      }
      else {
        devtable[ addr ].epinfo[ ep ].rcvToggle = bmRCVTOG0;
      }
      *nbytes = xfrlen;
      return( 0 );
    }//if (( pktsize = *nbytes ))...
  }//while( 1 )...
}

FTDI FT232 devices
The FT232 range of devices from FTDI is now fairly large and quite a lot of data is available on the FTDI Website.
Further information was taken from linux driver sources and other USB Host sources.
I did not get a chance to test devices other than the FT232B and FT232R at this time.

Blocking vs. Unblocking code
The eventual objective is to create a version of the serial library which supports the FTDI Serial port over the USB Host Shield. The existing serial libraries allow for blocking code, especially when waiting for input. It was therefore decided to use interrupts to perform the regular tasks required for the USB protocol layers, so the FTDI libraries could appear identical to the existing serial drivers.

The MAX3421e MAX_GPX pin is set up to send a pulse output at the SOF rate of the USB (1 per ms) and this generates a pin change interrupt on the Arduino. This interrupt routine then performs the required USB tasks without need for the sketch to repeatedly call them. Some protection is also added to ensure that USB transactions generated outside the interrupt routine and any associated temporary data, are protected from the interrupt routines.

Buffer Management
Seperate data buffers are created for the transmit and receive directions.
The transmit buffer is filled by the calls to send a serial byte via the FTDI. If the buffer is filled by the byte the data is sent over the USB immediately, other wise it is sent at the next SOF interrupt.

Calls to read the receive buffer check for any characters locally, and return them if found. If there are no characters in the local buffer, a read is made to the remote FTDI device to check if any data is ready there. This process is to reduce the local buffer requirement. The first two bytes returned over USB are status bytes, not data, and these are also sent at regular intervals without data. I am not sure whether this is the best way to handle the receive buffers.

Code is here on github

Developer Si Li shared his version of PTPDevinfo.pde, which fits into older Aduinos. Si wanted to get PTP device information from Canon EOS 500D, but he only has 16K Seeduino at hand. So he stripped devinfoparser off all unnecessary strings leaving only ones essential for [...]]]>

Blue Arduino USB Host Shield tied to telephoto lens mount

Developer Si Li shared his version of PTPDevinfo.pde, which fits into older Aduinos. Si wanted to get PTP device information from Canon EOS 500D, but he only has 16K Seeduino at hand. So he stripped devinfoparser off all unnecessary strings leaving only ones essential for parsing Canon EOS camera device info.

The modified devinfoparser files are available from “Downloads” section.

A reel of ADuM4160s

Lynxmotion AL5D robotic arm

I made (hopefully) last iteration of magnetic probe amplifier board. Schematic remains the same. Layout, however, is slightly different. First, I made it more narrow to better fit Tektronix 7000-series time base plugins external trigger input, as can be seen on the title picture. Second, the amplified [...]]]>

Magnetic probe amplifier connected to external trigger input

I made (hopefully) last iteration of magnetic probe amplifier board. Schematic remains the same. Layout, however, is slightly different. First, I made it more narrow to better fit Tektronix 7000-series time base plugins external trigger input, as can be seen on the title picture. Second, the amplified probe output is made via SMx type connector – PCB-mounted SMA and SMB all have the same footprint. I used straight SMB since I have a surplus of Tektronix P6041 cables. The board layout permits soldering right-angle connector here as well. This arrangement is much handier than previous one.

Since publishing initial design I haven’t seen much interest in it, so instead of ordering a bunch of PCBs I made this board available on BatcPCB Marketplace. Schematic and board layout in Eagle 5.x format are also available. I built one board and haven’t found any errors on copper or silkscreen – if you find any, please let me know.

Oleg.

I found this little video while looking for ideas for my digital camera controller. There is also project description and summary page. Device consists of Arduino board mated with Asynclabs WiShield controlling shutter release of SLR camera via cable release port. Arduino runs TCP/IP stack and Web server while access to pre-focus, time [...]]]>

I found this little video while looking for ideas for my digital camera controller. There is also project description and summary page. Device consists of Arduino board mated with Asynclabs WiShield controlling shutter release of SLR camera via cable release port. Arduino runs TCP/IP stack and Web server while access to pre-focus, time interval and other settings is done via web browser on an iPod. In addition, it is possible to release shutter using signal from proximity sensor or even set conditions based on states of different Arduino pins.

The web interface is well designed – watch this little movie and see it for yourself. There is also a demo page, where you can play with controller functions. The “Adm” page is my favourite. I’m looking forward to see the code, which author is going to publish soon.