Media: USmoBility Technical Reportx

stuckwarmersMobile - Wireless

Dec 14, 2013 (3 years and 8 months ago)

150 views









USmoBility

Technical Report


Nick Graumann

Sean Seifert

Sam Wehri

SD1219 Spring 2013








Table of Contents

Introduction:

................................
................................
................................
................................
...

3

Requirements Overview:

................................
................................
................................
................

3

Final
Product (
pictures and description
):

................................
................................
.......................

4

Software Design:

................................
................................
................................
.............................

4

BSP

................................
................................
................................
................................
...............

5

DirItemList

................................
................................
................................
................................
...

6

GUI

................................
................................
................................
................................
...............

6

Interface Manager

................................
................................
................................
.......................

6

Storage

................................
................................
................................
................................
........

7

Trace

................................
................................
................................
................................
............

7

LCD Driver

................................
................................
................................
................................
....

7

Architecture Diagram

................................
................................
................................
..................

8

Enclosure:

................................
................................
................................
................................
........

8

Troubleshooting:

................................
................................
................................
.............................

9

Project Comments:

................................
................................
................................
.........................

9

Appendix:

................................
................................
................................
................................
......

11




















Introduction:

The USmoBility device is a hand
-
held, portable and convenient device which can be used to
transfer files between any two USB mass storage
-
compatible devices and also an optional micro

SD card. The device
has

a large screen is used to select files to transfer as well navigate and
manage files. The device features both battery and AC power option
s. There are several unique
advantages to our product versus currently available options on the market today. First, the
large, easy
-
to
-
read screen facilitates easy file management in case the need arises to monitor
and manage free space and files on each
drive. Additionally we plan on supporting modern
android devices in USB mass storage mode. Also supported will be a raw
-
copy clone mode to
allow bootable thumb drives to be easily cloned. Additional expansion ideas as time/budget
allow include an SD card
slot, additional ports for multiple
-
drive copy and cloning, and support
for formatting drives. Benefits of this device include ease of transportation and file transactions
without the need for the user to locate a computer. With advent of smartphones capab
le of
holding a large amount of media, this device makes quick sharing of photo and video without a
data connection a reality.


Requirements Overview:

The following list comprises the requirements instated for USmoBility:

1.

A minimum of 2x USB 2.0 type
-
A fem
ale connectors (full
-
speed or high
-
speed) for USB
Mass Storage compatibility.

2.

1x microSD or SD card slot

3.

LCD screen of adequate size such that a file list may be easily read and navigated by the
user.

4.

Minimum LCD resolution should be 240x160 pixels with a

recommended resolution of
320x240. Screen size should be at least 2” diagonal.

5.

Both monochrome and color displays will be considered adequate.

6.

A backlight is optional.

7.

The user input shall be handled by four buttons: Up/Down, Select, and Back.

8.

File attri
butes such as full name, size, and modified date shall be displayed upon
request.

9.

Approximate battery life shall be displayed at all times.

10.

File transfer progress shall be displayed when transfers are in progress.

11.


The unit shall be powered by a single rec
hargeable Lithium Ion cell (3.7V).

12.

The battery should be selected to provide at least 2 hours of use time with screen on.

13.

If a backlight is provided, the total run time should be at least 1 hour.

14.

The unit shall have a female micro
-
USB type
-
B socket which

shall be capable of charging
the internal battery from a PC or a cell phone charger.

15.

A power switch shall be mounted on the external portion of the unit to allow the user to
power off the device when not in use.

16.


Transfer of files of at least 1GB must be
allowed

17.

Filesystems supported shall be FAT and FAT32

18.

The unit shall provide the ability to clone an entire device to another.

19.


The unit shall be no larger than 5” wide by 7” tall (unless the screen size demands a
slightly larger footprint).


Final Product
(
pictures and description
):

Schematics and Hardware Design
:

Schematic here

Charging Schematic:


Protection Circuitry:

5V Supply:

3.3V Supply:

USB:

Buttons:

Reset Pin Configuration:

Boot Pins:

ADC Battery Monitor:








Software Design
:

The USmoBilit
y software is written on top of the FreeRTOS operating system. It is assumed the
reader has an adequate knowledge of this operating system and its available constructs in order
to completely understand this document.


Inter
-
task communication is achieved
through the queue mechanism provided by FreeRTOS.
This allows asynchronous event production and handling, while also providing a fast, thread
-
safe method of transferring data between tasks. Once an event has been received, its ID is used
to index an array
of function pointers which point to the appropriate event handlers within the
module. This approach is often referred to as a “jump table.” Jump tables are extremely
efficient and have an almost guaranteed execution time, whereas switch statements do not
n
ecessarily compile into optimal assembly. More information on jump tables can be found at
http://www.rmbconsulting.us/Publications/jump
-
Tables.pdf
. The event data structures
themselves are also optimized for size and performance through the use of a union of nested
structures, which ensures the event data is as small as possible. Efficiency is thereby increased
when adding and removing events from event queues.


An arbiter sc
heme is used to prevent hardware peripheral race conditions, that is, only one task
(or execution context) is allowed direct access to a given hardware peripheral. This has the
added benefit of keeping the architecture relatively simple and allowing natura
l division of code
modules based on underlying peripherals or functionality.


Source files can be found in the src directory inside the USmoBility project folder. Modules are
then divided into additional subdirectories as appropriate.


Listing of modules:



BSP

o

LPC18xx startup code

o

Processor and board
-
specific setup code



GUI

o

DisplayManager


handles screen update events

o

GUI Abstraction layer

o

LCD Driver



InterfaceManager


Main event processing, state machine



Storage

o

DriveManager


handles drive requests

o

Drive
Abstraction layer

o

USB Mass storage layer

o

SD card layer



Trace


Misc. debugging utilities



Watchdog


System watchdog task (hardware and software
-
based)


BSP

The Board Support Package (BSP) configures the board hardware for operation. It disables all
unneces
sary CPU clocks to save power and sets up the main PLL and USB PLL. It then configures
appropriate pins according to the version of PCB for which the software is being built. It also
contains helper functions for reading the ADC.

DirItemList

This module is

a flexible linked
-
list interface used to access lists of items with properties (in this
case, files and/or drives). It is currently implemented as a contiguous static character array in
memory, however the interface is designed to force the client to use
it as a linked list so it can
be easily converted in the future. This would allow more efficient memory allocation than the
present fixed
-
size two dimensional array type. The list is accessed by both the DriveManager
and the DisplayManager task, with point
ers being passed through the InterfaceManager in
order to avoid the use of global variables. Reads and writes are guaranteed never to happen at
the same time by the order of events in the system, that is, the DriveManager always
completely enumerates and s
orts a list before passing it on. Thus, race conditions associated
with multiple tasks accessing a shared resource can be avoided.

GUI

The manager of this module is the DisplayManager. It handles all drawing
-
related events. The
DisplayManager is an unintel
ligent module in that it has no internal state; any screen or display
can be directly drawn through an event. This confines all state machine logic to the
InterfaceManager which eases maintenance and increases debugability. It is also responsible
for small

tasks related to the user experience such as scaling units from bytes to kB/MB/GB and
wrapping text.


The DisplayManager makes calls to a set of GUI functions which are responsible for drawing
common elements such as lists, popups, status bars, and
indicators. This layer then calls
functions directly in the LCD driver which are capable of drawing basic primitives and text. The
low
-
level LCD driver is a third
-
party driver called UTFT.

Interface Manager

The InterfaceManager is responsible for keeping t
he state of the entire system. Among other
things, it contains a state machine, current directory and nesting depth, and button press
status. It is the primary event hub in the system; it receives events such as button events
generated by the button monito
r task, transfer status updates from the FileTransfer task, drive
(dis)connect events, amongst others.


This module contains two sub
-
tasks. The first is a battery monitor which queries the battery
voltage via ADC every five seconds and sends updates to th
e DisplayManager so the
appropriate percentage can be displayed. The second task is the ButtonMonitor. This task is
responsible for querying the hardware buttons at a specified interval (10ms). It has internal
debouncing logic as well as repeat capability,

press/release event detection, and hold
detection. The events it spawns are sent to the InterfaceManager to be processed in the main
state machine.


Storage

The DriveManager module is responsible for handling storage. It is mainly a collection of
function
s designed as an abstraction layer for different types of storage medium. It allows
clients (such as FatFS) to access storage in a generic way with capabilities like read/write blocks,
query free size and total space, pathname conversions, etc. It also con
tains a File Transfer task
which is event
-
driven much like the other tasks in the system. This task is capable of
transferring either a single file, or a directory (or drive) recursively.


Below the DriveManager are the actual storage API layers. The USB

Mass Storage layer
intefaces with the LPCUSBLib USB host stack. Drive connect/disconnect interrupts are
converted to events and forwared to the InterfaceManager at this stage. The SD Card layer
interfaces with the DMA
-
enabled SDMMC register interface of t
he LPC1830.


Trace

Trace is a set of functions and macros used early in development to allow the system to run at
full speed without a debugger stepping through the code and still gather debugging
information. TRACE macros copy data into a circular buffer
of characters which can later be
read with a debugger to get a textual history of the code execution.


LCD Driver

The LCD driver uses a 16 bit parallel interface to control the 2.4” color LCD screen. The screen
came with a very basic open source driver for

Arduino. The original UTFT driver had to be
ported for our LPC 1830 micro.
Functions such as drawing a pixels, lines, rectangles, circles, and
text were included, and mostly working. After improving the base functions, additional

custom
functions were bui
lt on top the
base driver functions
.
New functions such as

drawing
test
lis
ts,
pop
-
ups, titles, and status bars were all added. A custom font, which looked a lot
neater,

was
added. Now the GUI API will be much higher level and easy to work with.



Archite
cture Diagram




Enclosure:

The
enclosure gives

the device a nice solid handheld
feel
, provides

storage for the battery
, durability to our
components,

and
gives

our device a finished look. The
2D layout was exported
directly from our PCB layour
in

Altium
. This layout was converted

into a .dxf file.
This file is very commonly used with AutoCAD or
other modeling programs. The 2D model of our PCB
was completed in AutoCAD due to my familiarity with
the program.

All traces were deleted out of the
model. Small
components that wouldn’t affect the
enclosure were also removed. These parts included
capacitors, resistors, IC’s etc. The only parts remaining
on the board were parts that had to be used in
conjunction with the enclosure.

These parts include: USB ports, micro SD card slot, four
navigation buttons, micro USB port and power switch.

The model was then imported into Google SketchUp. By extruding

major components, including
the PCB itself,
a basic 3D model of our board was made
. The enclosure was then built around
the 3D model of our PCB. This ensured that every part
will

align perfectly with the enclosure. By
fitting the PCB model into the enclosure

within Google Sketchup
, I was able to see exactly how
everything should fit onc
e it has been printed.
This made visualizing the final enclosure very
easy and intuitive.

Extra plugins were used to create rounded corners for the top and bottom for the enclosure.
Plugins for Google Sketchup are ruby scripts that can automate tasks, suc
h as rounding corners.
I used the “RoundCorner” tool by Fredo6. This free tool allows for three different types of
rounded edges/corners and gave the enclosure a for finished looked.


Troubleshooting:

Listed here are some issues that may come up with
normal use of the product, as well as steps
to take to fix them:

1.

Problem: Screen turns white on start
-
up.

Answer: Toggle on/off switch or wait about 60 seconds and it should display the normal
screen. This is an issue found in the errata of the external FL
ASH chip.

2.

Problem: Screen freezes

Answer: Toggle on/off switch.

3.

Problem: Screen shuts off and stops powering devices

Answer: Plug in charging cord. The battery will last about two hours but may vary. Pay
attention to the battery life percent indicator in
the top right of the screen and try and
keep charged.


Project Comments:

The following are problems that we encountered in the completion

of the USmoBility
:

1.

Power supply was too small


For our first revision, we under
-
specified the required
current that t
he device would draw and need to continue running. First rev boost power
supply chip and associated components were designed with intent to power about
500mA maximum. Upon c
ompletion of first revision, we found this was not sufficient to
power the screen,
micro, and USB ports. To resolve this, we designed another boost
converter circuit that would be able to provide at least 1.5A.

2.

Buttons were small and very close


First revision issue, buttons were very small and
close together. Fixed on second rev by get
ting larger buttons and spreading them out on
PCB.

3.

Enclosure issues


The first enclosure that we constructed with the 3D printer was very
warped and ugly. To be fair, it worked, the button and other holes were placed correctly
and the PCB fit inside it qu
ite well. The appearance was subpar, so we did a second
revision, which also added rounded corners and a tapered hole for the microSD card for
better access, and it turned out much better.

4.

Backwards components


We encountered issues with flipped component
s on both the
first and second revisions. On the first rev, we had the USB flash drive headers on
opposite sides of the board. The device still worked and we were able to transfer files
between the flash drives, but in order to plug in the flash drives, yo
u had to flip them
upside down. Not a huge deal, but not extremely user
-
friendly. To fix this while keeping
the integrity of the USB signals on the printed circuit board

and turning the screen 90
degrees
,
we flipped the microcontroller to the other face of

the board and placed both
headers on one side of the board. In order to be able to use the reflow oven on most of
our surface mount components, we flipped many of the other components to the
bottom face of the board as well. There was a problem with this
because the screen
header also got flipped when it wasn’t supposed to. We were able to fix this on rev 2 by
switching the screen to 8 bit mode, disconnecting some of the signals and using
modification wire to connect the necessary pins.

5.

Footprint issues


There were several footprint issues that came up with the design of
USmoBility. We caught this issue before ordering a PCB for rev 1 so it wasn’t a big
problem, but it is important to pay attention to the package details of components; we
have two SOIC
-
8
chips in our design, but one is an SOIC
-
8 150mm and one is a SOIC
-
8
208mm package. SOIC
-
8 packages are not all identical. Another issue was the default
libraries for footprints in Altium must be us
ed very, very carefully. First, millimeter
rulings and inch

ruling must be known when using any footprint. A 2013 metric package
seems very similar to a 2010 package in inches, but they are not close.


The following are improvements that can be made on future revisions:

1.

Make the enclosure smaller


At this point,

the PCB is 3” x 5”, with the enclosure being
even larger. We can improve the PCB size by reducing it and reducing the enclosure size.

2.

Bigger battery


We currently have a 1250mHh single cell lithium battery powering our
device. This meets requirements, bu
t we could double the battery size to lengthen
battery life

3.

Charging light


We have an LED that is meant to indicate when the device is charging;
however it is on the bottom of the board right on the PCB. To improve this, we could
move the LED to the top
of the board in a convenient place to have a hole in the
enclosure that is more visible to the user.

4.

Better SD card performance


The current USmoBility does have the capability to
transfer files between a microSD card and a flash drive. The issue is when
disconnecting
a microSD card and inserting a different one, the power has to be cycled in order to re
-
enumerate the plugged in devices and pick up the new microSD card. This can be fixed
in software to reset somehow and be able to just plug in different mi
croSD cards with
no problem.

5.

Internal storage


UsmoBility does not have any on
-
board memory storage. We could
improve the product by having some sort of memory storage on the board so the user
could transfer files from a flash drive to the board to anothe
r flash drive at another
point.

6.

Cheaper and more efficient boost converter


The boost converter chip we have on the
USmoBility currently is a $13.00 chip. This happened after our rev 1 boost supply was
too weak for the application and we didn’t want it t
o happen again on rev 2 so we over
-
designed it; this chip has a switching current of 6 amps, which is much more than our
application requires. This boost converter also has about a 65
-
70% efficiency within our
application. We could improve both areas with
another design with a smaller boost
converter.

7.

Buttons with symbols


We hand
-
painted symbols on our buttons for rev 2 with white
-
out. To improve, we could get buttons that already have symbols on them.

8.

Screen improvement


Currently we have about a $20.00 screen. It works well with our
application, but it contains a full size SD card slot as well as touch screen capability. To
improve this, we could either find a screen much cheaper without the SD card s
lot and
touch screen or we could use the SD card slot (via SPI) and the touch screen and get the
full usage out of the screen.


Appendix: