Modular Integrated Stackable
Layers (MISL)
Texas A&M University College
Station, TX
TI Innovation Challenge 2014 Project Report
Team Leader:
Tanner Perkins: VectorEngineeringSystems@gmail.com
Team Members: Team Kelson Astley: VectorEngineeringSystems@gmail.com
Ty Navarrete: VectorEngineeringSystems@gmail.com
Ty
Advising Professor:
Dr. Joseph Morgan: morganj@entc.tamu.edu
Prof. George Wright: g-wright@suddenlink.net
Texas Instruments
Mentor (if applicable):
Peggy Liska: Peggy@ti.com
Date:
5/21/2014
Qty.
List all TI analog IC or
TI processor part
number and URL
1) Explain where it was used in the project?
2) What specific features or performance made this
component well-suited to the design?
1
RM48L952ZWTT
The RM48 will be the microcontroller for the MISL system. The Ball Grid Array
configuration of the ZWT pin package is required by our customer and the amount of
interfaces that the RM48 has is ideal for this application. Because this system will be
running a RTOS the RM48’s abilities make it the perfect microcontroller for this system.
1
TPS2552DRVT-1
This power-distribution switch was idea based on its ability to precisely current limit the
amount of current that it will source. This component was used to regulate the 5 Volts
needed for USB when the RM48 board was in USB Host mode.
1
TPS73701DRBR
This Low-Dropout Regulator will be used on the RM48 board of the MISL stack to
convert the 3.3V from the power bus utilized in the MISL system to the 1.2V also needed
by the RM48 microcontroller.
1
SN74CBTLV3257RGYR
This MUX was chosen to switch between host and device mode when utilizing the boards
USB functionality.
1
TUSB1105RGTR
This USB serial bus transceiver is used for USB communications in both host and device
modes to communicate with external sources. This controller was chosen for its
dependability shown by the HDK.
1
HVDA541QDRQ1
This CAN transceiver was used for CAN communications between the MISL system and
external peripherals.
1
DP83640TVV/NOPB
This Ethernet PHY is utilized for the Ethernet communications from the RM48 to any
external destination. The use of this PHY on the RM48 HDK proved that this IC was
reliable and robust.
All packages were chosen for small form factor since our board was required to be 2” X
3.5”. All components also had to meet industrial temperature range requirements.
The Command and Data Handling (C&DH) Branch of NASA Johnson Space Center (JSC) Engineering
Directorate developed the Modular Integrated Stackable Layer (MISL) system. This “Rack-and-Stack” Arduinolike modular layer system utilizes a data bus and power bus to connect between boards. The boards, or layers, are
currently defined as power, microcontroller, communication, sensing, and interface. NASA has designed a few
different types of boards to fill these layers. By utilizing different boards, the system can be easily adapted to
many different applications and projects including spacecraft instrumentation and control systems. In this way,
NASA aims to encourage open source development of space qualified projects by reducing time and cost
associated with developing control and monitoring equipment.
NASA desires to expand the capabilities of the MISL system by creating a new processing layer
utilizing the RM48L952ZWTT microcontroller. In addition the MISL system needs to be integrated into the
Articulated Suspension Exploratory Platform (ASEP) robotic vehicle to demonstrate the possible uses of the
MISL system.
The MISL system that our Capstone Team, Vector Engineering Systems (VES) is developing for use
with the ASEP robotic vehicle will include the standard power, microcontroller, and communication layers as
well as an external sensor array to give the user data about location and orientation of the robot. This system will
allow users to drive the robotic platform with a handheld gaming controller while the Graphical User Interface
(GUI) displays instrument readouts of the sensors.
This MISL/ASEP prototype is meant to show off the possible future uses of the MISL system and is the
first step in expanding development of a fully space-qualified, modular, open source microcontroller system. As
a preliminary prototype, it will be tested and demonstrated in a mild environment with refined terrain. This
means that no extreme temperatures or large obstacles will be present during the demonstration.
Modular Integrated Stackable Layers
(MISL)
TI Design Contest
Vector Engineering Systems
Team Members:
Tanner Perkins
Kelson Astley
Ty Navarrete
Sponsor:
National Aeronautics and Space Administration (NASA)
Advisors:
Mr. George Wright
Dr. Joseph Morgan
Table of Contents
Table of Contents .................................................................................................................................... 4
List of Figures ......................................................................................................................................... 5
Project Design: ........................................................................................................................................ 5
Hardware Design .................................................................................................................................... 7
Software Design ...................................................................................................................................... 9
Testing .................................................................................................................................................. 13
Conclusions ........................................................................................................................................... 14
Future Work .......................................................................................................................................... 14
MISL Achievements ............................................................................................................................. 14
Acknowledgements ............................................................................................................................... 15
References ............................................................................................................................................. 15
Appendix:.............................................................................................................................................. 15
Appendix A: Schematics................................................................................................................... 15
Appendix B: Board Layout ............................................................................................................... 20
Top Layer ...................................................................................................................................... 20
Internal Plane 1 ............................................................................................................................. 20
Mid-Layer 1 .................................................................................................................................. 21
Mid-Layer 2 .................................................................................................................................. 21
Internal Plane 2 ............................................................................................................................. 22
Internal Plane 3 ............................................................................................................................. 22
Mid-Layer 3 .................................................................................................................................. 23
Mid-Layer 4 .................................................................................................................................. 23
Internal Plane 4 ............................................................................................................................. 24
Bottom Layer ................................................................................................................................ 24
Top Silkscreen .............................................................................................................................. 25
Bottom Silkscreen ......................................................................................................................... 25
Top Solder Mask ........................................................................................................................... 26
Bottom Solder Mask ..................................................................................................................... 26
Top Pads........................................................................................................................................ 27
Bottom Pads .................................................................................................................................. 27
Drill Guide .................................................................................................................................... 28
Drill Draw Fabrication .................................................................................................................. 29
Drill Draw Notes ........................................................................................................................... 30
Appendix C: Bill of Materials (Quantity of 100) .............................................................................. 32
Appendix D: Embedded RTOS Code ............................................................................................... 33
D1: sys_main.c .............................................................................................................................. 33
D2: RTOS_DataFormat.h ............................................................................................................. 37
D3: Wireless.c ............................................................................................................................... 37
D4: Wireless.h............................................................................................................................... 41
D5: WizFi630Board.c ................................................................................................................... 41
D6: WizFi630Board.h ................................................................................................................... 45
D7: WizfiPacketFormat.h ............................................................................................................. 46
D8: notification.c .......................................................................................................................... 47
D9: Sensor.c .................................................................................................................................. 50
D10: Sensor.h................................................................................................................................ 55
D11: MotorControl.c..................................................................................................................... 56
D12: MotorControl.h .................................................................................................................... 57
Appendix E: The Modular Integrated Stackable Layer System: A NASA Development Partnership
.......................................................................................................................................................... 58
List of Figures
Figure 1: Conceptual Block Diagram ..................................................................................................... 6
Figure 2: Overall Functional Block Diagram ......................................................................................... 8
Figure 3: Board Stack-Up ....................................................................................................................... 9
Figure 4: Overall Board Layout .............................................................................................................. 9
Figure 5: Hierarchy Chart ..................................................................................................................... 11
Figure 6: RTOS Interrupt Diagram ....................................................................................................... 11
Figure 7: Command Flowchart ............................................................................................................. 12
Figure 8: Sensor Flowchart ................................................................................................................... 12
Figure 9: Graphical User Interface........................................................................................................ 13
Figure 10: Test Matrix .......................................................................................................................... 14
Project Design:
In today’s industry, there is a demand for a wide variety of electronic systems with a plethora
of applications. Designing and developing custom boards for each application is extremely
expensive and time consuming. To help offset these challenges, standards have been created
so that a large variety of boards can be interfaced seamlessly. This interface implies a
standardized connection which will allow the system to be tailored to a variety of needs by
switching out boards. To increase development of both software and hardware for this system,
it is being released to the public as an open source platform so that anyone can benefit, use, or
develop the system further. While the standards must be retained, the public will have the
freedom to alter the system to their needs. This will allow the system to be extremely
versatile and be able adapt to a large range of projects by both industry and hobbyist alike.
Due to this need for a versatile system NASA has set a standard for a stackable layer system
that utilizes a standardized power and data bus connector between the boards. This system is
called the Modular Integrated Stackable Layers (MISL) System. By creating this standard
and cooperating with academics and industry, NASA has given an opportunity to the public
to help develop and manage an open source community. VES has lead this development of
this idea starting with both the design and development of a new and more powerful RM48
microcontroller board and with the creation of an open source Wikipedia page,
mislwiki.tamu.edu. This open source wiki page will allow all supporting documentation,
development files, and source code to be viewed by the public so that they can further
develop the system. VES has also integrate the system into an Articulated Suspension
Exploratory Platform (ASEP) robotic vehicle that will use an Operator Control Unit (OCU)
for wireless control and to receive and display sensor data. This will demonstrate the
capabilities of the MISL system and show the public and industry how the system can be
used in a variety of projects. VES believes the following design meets the stakeholder’s
intentions and will allow NASA, researchers, and the public to continue development of the
MISL system.
The primary objective of this project is to design, develop, implement, and deliver a working
prototype of the MISL system utilizing the RM48 board. This prototype will be mounted onto
the ASEP robot for demonstration purposes. To convey what VES has understood to be the
scope of the project, a conceptual block diagram was created to visually communicate what
the system should look like, shown in Figure 1.
Figure 1: Conceptual Block Diagram
The conceptual block diagram clearly shows the MISL system, which is to consist of three
boards: the RM48 Board, 28V Power Board, and a Wiz-Fi630 Communication Board. This
system is to read data from the IMU and GPS sensor which will be physically mounted on the
ASEP robotic vehicle along with the MISL system. The ASEP vehicle will be used as a
mobile platform for the MISL system and will be powered by a Lithium Polymer Battery.
The Li-Po battery will allow for rechargeability and long lasting use time. This wireless
system will then communicate to an OCU laptop running a windows operating system which
will interface with a USB controller. Therefore the user can control the robot wirelessly from
the OCU using the USB controller, as well as receive data back from the IMU and GPS
sensor to be displayed on the OCU GUI.
Hardware Design
Figure 2, shows the detailed functional block diagram for our design. Blocks bordered in red
indicate that this portion of the system was developed by the VES team; ie. the RM48 board
hardware and software as well as the laptop GUI were developed by VES. The power board
supplies power via the power bus to the whole MISL Stack as shown. Although the DataBus
is 100 pins only 6 lines were used for the necessary functionality of this project. These 6 line
were used for communication from the RM48 board to the WizFi630 board for UART and
GPIO communications. This WizFi630 board then communicated via 802.11 wireless over
the shown UDP port numbers. The GUI was developed for the laptop, base station, or user
interface which is why it is boarded in red. A standard off the shelf USB controller or joystick
is used for the controls of the vehicle. Moving back to the RM48 board, the PWM signals are
sent from the microcontroller to the motor driver board to determine the speed of the wheels.
The SCI2 port transmits UART signals to the MAX3161 chip which translates to RS232 then
transmits to the 25 pin microD connector. This connector then connects to the IMU and GPS
sensor modules.
It’s important to note that although USB, Ethernet, CAN, and microSD card are not shown on
the functional block diagram they are implemented on the board within the hardware
development. These items were not shown in the functional block diagram because they were
not needed for this project however they were a late addition to the project scope by NASA.
Therefore it was agreed that NASA would do the software development and testing on these
portions of the board.
Figure 2: Overall Functional Block Diagram
The schematics will not be covered in detail; however the full schematics can be viewed in
Appendix A. Both schematic design and pcb layout were done in Altium Designer. The
schematic is a hierarchy design therefore there is a top sheet when connects all of the lower
sheets together. Although this board is not large enough or complex enough to really warrant
a hierarchy design. NASA uses exclusively hierarchy designs to make their schematics easy
for future users to read. Much of the schematic design was base off of the RM48 HDK then
minimized to suit the needs of our stakeholders and sometimes altered completely to satisfy
this board’s limitations.
As Figure 3 indicates, this is a 10 layer controlled dielectric board to allow for clean signals
to be transmitted through the board. Note there is only one VCC plane which is internal plane
2 while internal planes 1, 3, and 4 are all ground planes. This is to help prevent any noise that
could be caused from the power levels. The top and bottom layers both have 5 mil cores to
allow the signals to closely couple to the reference plane to keep noise and EMF noise at a
minimum. The prepreg value of 8 mils was chosen since it is a standard prepreg thickness
and allowed for the desired 93 mil board thickness. The cores between Mid-Layers 1 and 2 as
well as Mid-Layers 3 and 4 are 14 mils to help prevent cross talk by separating these signals.
It is also important that the overall trace run orthogonally to each other between the two
layers. The 10 mil core was chosen to achieve overall board thickness as desired, however
this thickness could be anything and not affect the functionality of the board.
Figure 3: Board Stack-Up
Figure 4 shows the overall board layout from every layer, since this makes it difficult to see,
each layer is shown individually in Appendix B. At this level you can see that the DataBus
was placed at the top edge of the board while the PowerBus was placed at the left side of the
board. The mounting holes are spaced evening on the board as these are all MISL standards;
please reference The Modular Integrated Stackable Layer Systems: A NASA Development
Partnership for more information on the MISL standards.
Figure 4: Overall Board Layout
Software Design
The software that was developed for the MISL system using FreeRTOS which would allow
the system to operate the modules of the system together, by using interrupts and set priority
levels to transition between the modules as needed. During the development of the software
for the system the modules were created individually and tested before integrating them all
together in the RTOS. This allowed the specific parts of the system to be tested in way that
didn't rely on the other parts to be completely functional. As well when developing these
modules the software was keep as simple as possible, so as to not create unnecessary
complexity that would hinder any future development of the system by others or cause
unneeded computing that would slow down the systems operations. One such way of doing
this was to suspend the motor task of the RTOS and only resume the task when the wireless
task received different motor control values, which freed up processing time by only having
the motor task run when it was actually needed. In order to use the suspend and resume task
operations the idle task of the RTOS was need. The idle task is created by the RTOS and has
the lowest possible priority level in the RTOS, this is where the RTOS frees up its kernel
memory where it stores the available tasks and interrupt data. The RTOS needs to be allowed
to run the idle task so that when the motor task is suspended and resumed it does not keep
filling the kernel memory with its interrupt data. When reading in the serial data from the
wireless module an interrupt was used to receive the data as it was sent from the device. This
interrupt was used because the time at which the data from the device was sent was not
known and we did not want to waste processing time by constantly polling the serial line to
look for the data coming in, or even potentially missing the data. However, when receiving
serial data from the sensor module a polling method was used, this is because a
predetermined packet was sent to the sensor and we knew that the sensor would immediately
reply with a specific length packet.
The RTOS utilizes an interrupt based systems so the hierarchy chart shown in Figure 5 is
only an outline of the structure of the RTOS and does not describe the actual process order of
the RTOS. The main function of the RTOS calls the initialize functions of each of the
interface modules and creates the tasks before calling the TaskScheduler function. Once the
TaskScheduler function is started the RTOS operates based on the highest priority task
available. The Wireless Main function is where all of the wireless communications are
handled, in which it calls the GetControls function and then the fillTelemetry function which
uses the FloatToLong and LongToFloat functions. The WizFi630Board functions are also
called by the Wireless Main function and the WizFi630Board calls the SendPacket,
SendDataByte, and ParsePayload functions. Then there is the Control Main that will call the
sendPWM function to control the motor board. Finally there is the Sensor Main function
where the SendPing function is called to ping the sensor and check its acknowledgement
before it calls the GetAHRS and GetGPS functions to poll the sensor for their respective data
packets and then use the HexToFloat and HexToDouble functions to convert this data from
an array of hex bytes to the correct data type. Snippets of code used for this project are shown
in Appendix D; please not that this is only partial code, in addition all comments and include
functions have been removed for the purposes of this paper.
Figure 5: Hierarchy Chart
The RTOS interrupt diagram in Figure 6 shows how the RTOS process’ based on the priority
level of the tasks. The RTOS utilizes interrupts to switch to the available task with the highest
priority level. The possible sequences of operation for how we are have developed the RTOS
is highlighted by the arrows between each task, with the direction and interrupt priority
shown on each arrow. The idle task is only interrupted to and from the wireless task because
the wait that causes the priority 0 interrupt when the wireless task is completed is only 1 tick,
about 1ms. The same can be said for the interrupt to the motor task, because the motor task is
only resumed from the wireless task and when the task is resumed it is instantly the highest
priority task available. However, when the task is once again suspended the RTOS will
interrupt to either the wireless task or the sensor task depending on the wait sequence of the
sensor task. The wait sequences that are seen in the figure put that task in an inactive state
until the wait time is over where once again the task becomes available for interrupt based on
its interrupt level.
Figure 6: RTOS Interrupt Diagram
To illustrate the communication between the MISL stack running the RTOS and the GUI
running on the OCU the flowchart in Figure 7 is used. The GUI begins by building the
command packet based on the input read from the joystick and once built the command
packet is then sent to the MISL stack. The RTOS running on the MISL stack will receive the
command packet using the receive interrupt of the SCI module. The command packet is then
parse to get the motor channel values and then the RTOS will build the telemetry packet that
will be sent back to the GUI. Once the telemetry packet is sent and while the GUI receives
the packet, the RTOS resumes the motor task if the motor channel values have changed. In
the motor task the PWM signal to the motor control board is changed based on the new
channel values and the motor task is suspended once again.
Figure 7: Command Flowchart
To illustrate the communication between the MISL stack running the RTOS the flowchart in
Figure 8 is used. The RTOS first sends a ping command to the sensor which responds with a
ping acknowledgement back, and once the RTOS checks the acknowledgement the AHRS
poll command is sent to the sensor which responds with the AHRS data. The RTOS then
parses the data and converts the data to the correct variable type. The RTOS then sends the
GPS poll command to the sensor which again responds with the GPS data, with which the
RTOS parses and converts to the correct variable type.
Figure 8: Sensor Flowchart
The Graphical User Interface or GUI was created in LabVIEW which was built into a
windows executable, so that the GUI could be run on both windows tablets and laptops.
Figure 9 shows the GUI used to control the ASEP robotic vehicle as well as to display sensor
data from the vehicle. On the left side of the GUI the acceleration values in 3 axis are shown
below the .stl file of the ASEP robot which is rotated as the vehicle moves. In the center of
the GUI are crosshairs which show the value being input by the user. Just to the right of that
is the values actually output to the left and right motor channels on the robot. Finally on the
right side of the GUI is where the raw latitude and longitude data is displayed. In addition
there are breadcrumbs placed on the graph so that the user can see where the vehicle has been
driving. There are reset buttons for both the GPS bread—crumbing and IMU data .stl rotation.
Figure 9: Graphical User Interface
Testing
There were 3 man testing phases of this project, hardware testing, software testing, and
functional testing. The hardware testing was done on the isolated MISL stack by first
checking voltage levels at given points on the board. After which various code snippets were
run to isolate specific onboard functionality. For example when testing RS232, a simple piece
of code was run on the RM48 HDK and the signal was viewed from the corresponding
UART port of the RM48 microcontroller with a bit scope or logic analyzer. The logic
analyzer was then put into RS232 mode and the same code was run on the developed RM48
MISL board which is converts that UART signal to a RS232 signal. Therefore the logic
analyzer should read equivalent values from the RS232 signal to verify that the expected
values were output by both boards. It’s important to note that a logic analyzer does not view
the true raw signals but rather sets thresholds for digital 1’s and 0’s; therefore all digital
signals were viewed by an oscilloscope so that an problematic or noisy signals could be
discovered.
While the hardware was being test as much of the software as possible was being run and
tested on the RM48 HDK. However only so much could be tested on the HDK, therefore
there was additional software testing to be done after the MISL hardware testing was
completed. This seamlessly transitions into functional testing when the software is tweaked to
gain function performance as desired. However specific functional test also needed to be
done to show our customer, NASA, and other stakeholders that all functional requirements
had been meet. Therefore the Test Matrix, shown in Figure 10, was created to prove that each
function requirement had been met.
Figure 10: Test Matrix
Conclusions
Overall the project has been planned, designed, implemented, delivered, and documented
ahead of schedule and under budget. The ASEP vehicle has been delivered to the ESET
department for further demonstrations to potential students, faculty, and sponsors. The RM48
MISL board designs have been delivered to the Command and Data Handling branch at
NASA JSC for further functionality testing and radiation testing in preparation for space
qualifications.
Future Work
The MISL system is being integrated into the curriculum in the Electronic Systems
Engineering Technology (ESET) Department at Texas A&M University. There are currently
two courses that use the MISL system, an Introduction to Embedded C Coding course, and an
Assembly course; however there the Advanced Embedded C Coding course will begin to use
the MISL system after this summer. Over this summer two student workers will be
developing two new layers for the MISL system which will be utilized in this course. A new
sensor board that utilizes on board and external sensors that communicate over UART,
RS232, SPI, ect. and an analog motor board that will allow students to control external
motors and actuators. It’s important to note that the MISL stack used for these educational
classes utilized a breakout board which give access to all powerbus and databus pins, as well
as an MSP430 processing board, and a battery board which powers the system.
In addition to the work being done at Texas A&M University, Perdue has also become
interested in the MISL system and is evaluating the system for their educational needs.
Lastly, the open source wiki will continue to be further developed so that one day there may
be an open source community that can easily access and add information to the community.
MISL Achievements
The MISL system and VES team have had multiple achievements throughout the last 8
months. These include winning first place for best student paper and presentation at the 2014
Southwest ASEE Conference in New Orleans. Winning first place for the TEES Most
Commercially Ready Award at the Spring 2014 Texas A&M Engineering Showcase. Lastly
the VES team has been invited to give presentations to both the Software Cartel, which is a
software development club in Bryan, TX; as well as at NASA JSC to the several Division
Chiefs.
Acknowledgements
Texas Instruments: provided multiple RM48 HDKs for testing and software development.
Saleae: provided a Logic 16, logic analyzer for software testing and debugging.
NASA: provided support and hardware proofing and feedback.
Texas A&M University (ESET): provided an abundance of software including Altium and
Solidworks.
References
Perkins, T.L., Astley K.G., Navarrete T. B., Dr. Morgan, J.M., Delaune, P.B., “The Modular Integrated
Stackable Layers System: A NASA Development Partnership,” Accepted and presented at 2014 ASEE Gulf
Southwest Annual Conference - Won best student paper/presentation
Appendix:
Appendix A: Schematics
Appendix B: Board Layout
Top Layer
Internal Plane 1
Mid-Layer 1
Mid-Layer 2
Internal Plane 2
Internal Plane 3
Mid-Layer 3
Mid-Layer 4
Internal Plane 4
Bottom Layer
Top Silkscreen
Bottom Silkscreen
Top Solder Mask
Bottom Solder Mask
Top Pads
Bottom Pads
Drill Guide
Drill Draw Fabrication
Drill Draw Notes
Appendix C: Bill of Materials (Quantity of 100)
Description
Designator
Manufacturer
Quantity
Manufacturer Part #
Abracon Corporation
100 ASEM1-25.000MHZ-LC-T
CAP CER 1000PF 2KV 10% X7R
C9 1206
Kemet
CAP CER 10UF 6.3V 20% X5R
C11
0603
CAP CER 2.2UF 6.3V 10% X5R
C660603
Subtotal
Unit Price
130.41
1.3
100 C1206X102KGRACT U
37.38
0.37
Yageo
100 CC0603MRX5R5BB106
10.72
0.11
Kemet
100 C0603C225K9PACT U
5.23
0.05
CAP CER 22PF 25V 5% NP0 C75
0603
AVX Corporation
100 06033A220JAT 2A
3.3
0.03
CAP CER 4700PF 25V 5% NP0
C18
0603
T DK Corporation
100 C1608C0G1E472J080AA
10
0.1
CONN HEADER 100POS 0.5MM
P4 GOLD
Samtec Inc
CONN HEADER 40POS 0.8MM
P2 GOLD
Samtec Inc
100 ERM8-020-02.0-S-DV
CONN HEADER 4POS 1.5MM
J2R/A SMD
Molex Inc
100 0874380443
25 MHz Oscillator
Y1
0
0
69.14
0.69
1.27
CONN HEADER 8POS 1.25MM
J3 R/A SMD Hirose Electric Co Ltd
100 DF14-8P-1.25H(56)
127.05
CONN MICRO SD R/A PUSH-PUSH
U11 SMD Molex Inc
100 5027740891
291.19
2.91
CONN PLUG MICRO-D 25POS
J1 R/A PCB Molex Connector Corporation
100 0836149012
1233
12.33
395.78
3.96
0.53
CONN RCPT 100POS 0.5MMP3
GOLD SMD Samtec Inc
CONN RCPT 40POS 0.8MM GOLD
P1
SMD Samtec Inc
100 ERF8-020-05.0-S-DV-K-T R
CRYST AL 16MHZ 20PF SMDY2
T XC CORPORAT ION
100 7A-16.000MAAJ-T
52.5
DIODE ZENER 3.6V 150MWD2
0603
Comchip T echnology
100 CZRU52C3V6
20.2
0.2
15.86
0.16
66.53
0.67
EMI/RFI Suppressors & Ferrites
F1470000pF 20%
Murata
16Volts
Electronics North America
100 NFM21PC474R1C3D
Ground T est Point
T3
IC 4BIT 1-4 FET MUX/DEMUX
U4 16VQFN T exas Instruments
100 SN74CBT LV3257RGYR
IC ANLG SWIT CH DUAL SPST
U8 10QFN
Vishay Siliconix
100 DG9236DN-T 1-E4
139.2
1.39
IC MCU ARM 3MB FLASH 337BGA
U3
T exas Instruments
100 RM48L952ZWT T
3543.75
35.44
IC PWR DIST SWIT CH ADJ 6SON
U5
T exas Instruments
100 T PS2552DRVT -1
208.8
2.09
IC REG LDO ADJ 1A SOT 223-6
U10
T exas Instruments
100 T PS73701DRBR
125.28
1.25
IC SRL BUS T XRX UNVRSL 16-QFN
U7
T exas Instruments
100 T USB1105RGT R
124.74
1.25
IC T XRX CAN W/ST ANDBYU6
5V 8SOIC
T exas Instruments
100 HVDA541QDRQ1
216.49
2.16
IC T XRX RS232/485/422 24SSOP
U9
Maxim Integrated Products
100 MAX3161ECAG+
974.1
9.74
LED GREEN CLEAR 0603 SMD
D1
Lite-On Inc
100 LT ST -C190GKT
12.42
0.12
LED SUPER RED CLR T HIN D3
0603 SMD
Lite-On Inc
100 LT ST -C191KRKT
12.96
0.13
MOSFET N-CH 20V 0.2A SOT
Q1
-723
Rohm Semiconductor
100 RUM002N02T 2L
20.19
0.2
RES 1.5K OHM 1/10W .1% 0603
R55 SMD
Panasonic Electronic Components
100 ERA-3AEB152V
14.34
0.14
RES 100 OHM 1/10W 5% 0603
R102
SMD
Panasonic Electronic Components
100 ERJ-3GEYJ101V
0.96
0.01
RES 4.87K OHM 1/10W 1% 0603
R21 SMD
Panasonic Electronic Components
100 ERJ-3EKF4871V
1.14
0.01
RES 53.6K OHM 1/10W 1% 0603
R48 SMD
Yageo
100 RC0603FR-0753K6L
0.6
0.01
SWIT CH DIP 1-POS SLIDE SMD
S1 6V
Copal Electronics Inc
100 CHS-01T A
81.46
0.81
SWIT CH DIP 4POLES ST D SMD
S2
Omron Electronics Inc-EMC Div100 A6H-4101
195.83
1.96
T ACT ILE SIDE ACT UAT EDS3
W/BOSS
Omron Electronics Inc-EMC Div
T XRX PHY IEEE 1PORT 1588
U1 48LQFP
T exas Instruments
100 DP83640T VV/NOPB
829.17
8.29
XFRMR MODULE 1:1 100D SIN
U2 SMD
Pulse Electronics Corporation
100 HX0068ANLT
434.72
4.35
CAP CER 10PF 50V 5% NP0 C72,
0603C73
Kemet
200 C0603C100J5GACT U
2.76
0.01
CAP CER 1UF 10V 10% X5RC30,
0603C74
Kemet
200 C0603C105K8PACT U
3.92
0.02
Loading...
FERRIT E CHIP 220 OHM 2000MA
L1, L2 0805 Murata Electronics North America 2 BLM21PG221SN1D
9.77
0.04
RES 100K OHM 1/10W 5% 0603
R44,SMD
R49
Panasonic - ECG
2 ERJ-3GEYJ104V
1.79
0.01
RES 120 OHM 1/10W 1% 0603
R74,
SMD
R75
Vishay/Dale
2 CRCW0603120RFKEA
5.02
0.03
RES 15K OHM 1/10W 5% 0603
R60,
SMD
R62
Panasonic Electronic Components 2 ERJ-3GEYJ153V
1.79
0.01
RES 62.0 OHM 1/10W 1% 0603
R50,
SMD
R51
Vishay Dale
2 CRCW060362R0FKEA
RES 75.0 OHM .5W 1% 1206R28,
SMDR29
Vishay Dale
2 CRCW080575R0FKEAHP
5.02
0.03
18.28
0.09
CAP CER 0.01uF 50V 5% X7R
C7,
0603
C8, C70 T DK Corporation
3 C1608C0G1H101J080AA
3.02
0.01
CAP CER 22UF 6.3V 20% X5R
C35,
0603
C47, C56T DK Corporation
3 C1608X5R0J226M080AC
41.12
0.14
CAP T ANT 10UF 20V 20% 1206
C31, C32, C65Kemet
3 T 491A106M020AT
86.34
0.29
CAP T ANT 22UF 6.3V 10% 1210
C34, C46, C71AVX Corporation
3 T AJB226K006RNJ
86.27
0.29
2.15
0.01
11.35
0.02
RES 1K OHM 1/10W 5% 0603
R80,
SMD
R82, R83Panasonic Electronic Components 3 ERJ-3GEYJ102V
FERRIT E BEAD 60 OHM 0603
L3, L4, L5, L6
T aiyo Yuden
4 BKP1608HS600-T
Mounting Hole
4
H1, H2, H3, H4
RES 49.9 OHM 1/10W 1% 0603
R17,
SMD
R18, R19,
Vishay/Dale
R20
4 CRCW060349R9FKEA
10.04
0.03
RES 5.0K OHM .2W 0.1% 0805
R76,
SMD
R77, R78,
Vishay/T
R79 hin Film
4 PNM0805E5001BST 5
708.4
1.77
RES 75.0K OHM 1/10W 1% 0603
R63, SMD
R64, R65,
Vishay/Dale
R66, R67
5 CRCW060375K0FKEA
12.55
0.03
T EST POINT
7
2.68
0
4.58
0
RES 10K OHM 1/10W 5% 0603
R3,SMD
R5, R31, R37,
Panasonic
R46, R47,
Electronic
R53, R61,
Components17
R85, R86, R89,
ERJ-3GEYJ103V
R90, R91, R92, R93, R94, R103
5.98
0
T 1, T 2, T 4, T 5, T 6, T 7, T 8
RES 2.20K OHM 1/10W 1% 0603
R1, R2,
SMD
R7, R9,
Yageo
R12, R13, R14, R26, R27, R36 10 RC0603FR-072K2L
0603 NOP CAP, NOP 060 Resistor
C3, C4, C5, C6, R10, R15, R40, R41, R45, R81,11
R87
RES 0.0 OHM 1/10W 0603 SMD
R8, R11, R38,Panasonic
R39, R42,- R43,
ECG R68, R69, R70, R71,
13 ERJ-3GEY0R00V
R72, R73, R84
RES 22 OHM 1/10W 5% 0603R4,
SMD
R6, R16, R22,
YageoR23, R24, R25, R30, R32, R33,
26 R34,
RC0603JR-0722RL
R35, R52, R54, R56, R57, R58,
6.65
R59, R88, R95,
0 R96, R97, R98
CAP CER 0.1UF 25V 10% X7R
C1,0603
C2, C10, C12,
YageoC13, C14, C15, C16, C17, C19,
50 C20,
CC0603KRX7R8BB104
C21, C22, C23, C24, C25, C26,
27.75
C27, C28,0.01
C29, C33, C36, C37
Total: $10,461.67
Appendix D: Embedded RTOS Code
D1: sys_main.c
//**************************************************************************
***
// Workspace: Capstone/Code/RTOS
// Project: MISL/ASEP RTOS
// sys_main.c
// Originally created by: Ty Navarrete
//
// Description: RTOS for the MISL/ASEP system running on RM48.
//
// Wireless:
//
CTS - GIO at Pin D1
// Input from WizFi630 RTS output
//
RTS - GIO at Pin D2
// Output to WizFi630 CTS input
//
CPURST - GIO at Pin D5 // Output from WizFi630 POReset input
//
WPS - GIO at Pin E19
// Output to WizFi630 WPS input
//
RESET - GIO at Pin B6 // Output to WizFi630 RESET input
//
TX - sciREG_TX // Pin N2
//
RX - sciREG_RX // Pin W3
//
// Sensor:
//
TX - scilinREG_TX // Pin A7
//
RX - scilinREG_RX // Pin B7
//
// Motor:
//
PWM0 - NHET104 or Pin B12 -> Left Motor Channel
//
PWM1 - NHET116 or Pin A4 -> Right Motor Channel
//
// WiFi setup: UDP Server mode, IP: 192.168.16.254, Port: 30190
//
Server Mode means WiFi data packets are sent only in response to
CMD/STATUS
//
packets from the client GUI
//
***************************************************************************
*
// Standard includes
#include <stdio.h>
#include "stdlib.h"
#include "sys_common.h"
#include "sys_core.h"
#include "math.h"
#include "float.h"
// Kernel includes
#include "FreeRTOS.h"
#include "os_task.h"
#include "os_timer.h"
#include "os_semphr.h"
// Include Files
#include "het.h"
#include "sci.h"
#include "RTOS_DataFormat.h"
#include "Wireless.h"
#include "Sensor.h"
#include "MotorControl.h"
// Defined Variables
#define Version "MISL/ASEP RM48 RTOS V1.4"
// Declared Functions
static void vWireless(void *pvParameters);
static void vSensor(void *pvParameters);
static void vMotor(void *pvParameters);
// Global Variables
ASEP_Data_Format ASEP_Data;
static prev_val prev_Motor;
xTaskHandle xMotorHandle = NULL;
unsigned char gu8PacketFromWiFiUart[66];
//
***************************************************************************
*
// User program starts here
//
***************************************************************************
*
void main(void)
{
hetInit();
sciInit();
sciSetBaudrate(sciREG, 115200);
sciSetBaudrate(scilinREG,9600);
prev_Motor.Left = 12;
prev_Motor.Right = 12;
ASEP_Data.Motor_Left = 12;
ASEP_Data.Motor_Right = 12;
_enable_IRQ();
xTaskCreate(vWireless, (const signed char*) "Wireless Task", 100, NULL, 1, NULL);
xTaskCreate(vSensor, (const signed char*) "Sensor Task", 100, NULL, 2, NULL);
xTaskCreate(vMotor, (const signed char*) "Motor Task", 100, NULL, 3, &xMotorHandle);
sciReceive(sciREG,66,&gu8PacketFromWiFiUart[0]);
vTaskSuspend(xMotorHandle);
vTaskStartScheduler();
return;
}
//
***************************************************************************
*
// DESCRIPTION: Call Wireless code module to read in packets from WizFi630 board, and
if the
//
values for the motor control channels have changes resume the Motor
task.
//
// @param none
// @return none
//
***************************************************************************
*
static void vWireless(void *pvParameters)
{
for(;;)
{
prev_Motor.Left = ASEP_Data.Motor_Left;
prev_Motor.Right = ASEP_Data.Motor_Right;
WirelessMain();
if((prev_Motor.Left != ASEP_Data.Motor_Left) || (prev_Motor.Right !=
ASEP_Data.Motor_Right))
{
vTaskResume(xMotorHandle); // Resume Motor task
}
vTaskDelay(1 / portTICK_RATE_MS); // Go to idle task to free kernal memory
}
}
//
***************************************************************************
*
// DESCRIPTION: Call Sensor code module to poll the sensor and parse the data in. Record
sensor
//
data at 10Hz rate.
//
// @param none
// @return none
//
***************************************************************************
*
static void vSensor(void *pvParameters)
{
portTickType xLastWakeTime; // tick time in ms
xLastWakeTime = xTaskGetTickCount();
for(;;)
{
SensorMain();
vTaskDelayUntil(&xLastWakeTime, 100); // Delay for 10Hz period
}
}
//
***************************************************************************
*
// DESCRIPTION: Call Motor Control code module to send the motor speed rates to the
motors.
//
Suspend task after completion.
//
// @param none
// @return none
//
***************************************************************************
*
static void vMotor(void *pvParameters)
{
for(;;)
{
MotorControlMain();
vTaskSuspend(xMotorHandle); // Suspend task until motor values change again
vTaskDelay(1 / portTICK_RATE_MS);
}
}
D2: RTOS_DataFormat.h
// RTOS_DataFormat.h
#ifndef RTOS_DATAFORMAT_H_
#define RTOS_DATAFORMAT_H_
typedef struct data
{
float Euler_X;
// X angle
float Euler_Y;
// Y angle
float Euler_Z;
// Z angle
float Accel_X;
// X acceleration
float Accel_Y;
// Y acceleration
float Accel_Z;
// Z acceleration
double Latitude;
// Sensor GPS latitude
double Longitude;
// Sensor GPS longitude
int Motor_Left;
// Right motor channel value
int Motor_Right; // Left motor channel value
} ASEP_Data_Format;
typedef struct prev
{
int Left; // Right motor channel previous value
int Right; // Left motor channel previous value
} prev_val;
#endif
D3: Wireless.c
//
***************************************************************************
*
// Workspace: Capstone/Code/RTOS
// Project: MISL/ASEP RTOS
// Wireless.c
// Originally created by: Brett Parrish
// Modified by: Ty Navarrete
//
// Description: This Modular Integrated Stackable Layer (MISL) program was written for
the TI
//
RM48 HDK to interface with the WizFi630 WiFi board via UART.
//
// UART:
//
CTS - GIO.A0
// Input from WizFi630 RTS output
//
RTS - GIO.A1
// Output to WizFi630 CTS input
//
CPURST - GIO.A4 // Output from WizFi630 POReset input
//
WPS - GIO.A5
// Output to WizFi630 WPS input
//
RESET - GIO.A6 // Output to WizFi630 RESET input
//
TX - sciREG_TX // Pin N2 or NHET113
//
RX - sciREG_RX // Pin W3 or NHET106
//
// WiFi setup: UDP Server mode, IP: 192.168.16.254, Port: 30190
//
Server Mode means WiFi data packets are sent only in response to
CMD/STATUS
//
packets from the client GUI
//
***************************************************************************
*
// Standard Includes
#include <stdio.h>
#include "stdlib.h"
#include "sys_common.h"
#include "system.h"
#include "sys_core.h"
#include "math.h"
#include "float.h"
// Kernel Includes
#include "FreeRTOS.h"
#include "os_task.h"
#include "os_timer.h"
#include "os_semphr.h"
// Include Files
#include "sci.h"
#include "WizFi630Board.h"// WizFi630 board built by Dave Eslinger and Brett Parrish
#include "Wireless.h"
#include "RTOS_DataFormat.h"
// Global Variables
unsigned char gu8ByteFromWiFiUart[66];
unsigned char gflagDataByteRcvdFromWizFi630ViaUart;
// UART/WiFi received
packet flag
unsigned short u16XmtSeqCnt=1; // local sequence of each response packet sent to GUI
STRUCT_CMD_PKT strucPktCmdPayload; // Reserve memory for payload portion of UDP
// command packet received from GUI
STRUCT_TLM_PKT strucPktTelemetryPayload; // Reserve memory for payload portion of
UDP
// telemetry packet sent back to GUI
//
***************************************************************************
*
// User program starts here
//
***************************************************************************
*
void WirelessMain(void)
{
//
**************************************************************************
// As a server, this application only responds when queried by the GUI
// Command Packet UART from WiFi received?
//
**************************************************************************
if(gflagDataByteRcvdFromWizFi630ViaUart) // was UART/WiFi received flag set by
// sciNotification?
{
// a packet of WiFi RCV data was received by our ISR from the WizFi via our UART
gflagDataByteRcvdFromWizFi630ViaUart = 0; // clear UART/WiFi received flag
// Frame Sync and parse UART data received from the WizFi210, when
RcvPktBuildCmplt1 -> 1
// a full command packet has been received from the GUI and is sitting in
gstrucPktCmdPayload
// Call WizFi630_FindInsertTagAndParsePacketPayloadData() once per each received
packet
if(RCVD_CMPLT_PACKET ==
WizFi630_FindInsertTagAndParsePacketPayloadData(&gu8ByteFromWiFiUart[0],
&strucPktCmdPayload))
{
// WE HAVE A COMPLETE CMD PACKET FROM THE GUI in
gstrucPktCmdPayload!
getControls(&strucPktCmdPayload);
fillTelematry(&strucPktTelemetryPayload);
//
**********************************************************************
// init payload fixed data: packet version and payload size
//
**********************************************************************
strucPktTelemetryPayload.packet_version = htons(PACKET_VERSION);
//
0x0203
strucPktTelemetryPayload.size
= htons(PAYLOAD_SIZE);
// 64 bytes
strucPktTelemetryPayload.xmtSeqCnt
= 0;
// initial sequence
count
// Fill the unused portion of the packet data field with known, easily identified ASCII
numbers
//0x3030, 0x3131, 0x3232...
unsigned char u8LoopCnt;
for(u8LoopCnt=0; u8LoopCnt<12; u8LoopCnt++)
strucPktTelemetryPayload.tbd[u8LoopCnt] = (0x30 + u8LoopCnt)<<8 | (0x30 +
u8LoopCnt); //start at 0 and double up 00, 11, 22, 33, 44 etc.
strucPktTelemetryPayload.rcvSeqCnt
= htons(strucPktCmdPayload.rcvSeqCnt);
// reflect cmd seq cnt back
strucPktTelemetryPayload.xmtSeqCnt = htons(u16XmtSeqCnt);
// store our SEQ cnt
//
**********************************************************************
// Send the packet (actually all we have to do is send the 64 byte payload portion of
the packet
// and the WizFi630 does the rest because the WizFi serial port is configured to UDP
server
//mode so it automatically answers back to the IP ADD and IP Port of the client who
queried us
//
**********************************************************************
taskENTER_CRITICAL();
WizFi630_SendPacket(PAYLOAD_SIZE, (char*)&strucPktTelemetryPayload);
taskEXIT_CRITICAL();
}
}
}
static void getControls(STRUCT_CMD_PKT *pCmdPkt)
{
int channelL=12,channelR=12;
channelL=(((int)pCmdPkt->cmd_data[0]) + 6);
channelR=(((int)pCmdPkt->cmd_data[1]) + 6);
ASEP_Data.Motor_Left=channelL;
ASEP_Data.Motor_Right=channelR;
}
static void fillTelematry(STRUCT_TLM_PKT *pTelemetryPkt)
{
pTelemetryPkt->Accel_X = LongToFloat(htonl(FloatToLong(ASEP_Data.Accel_X)));
pTelemetryPkt->Accel_Y = LongToFloat(htonl(FloatToLong(ASEP_Data.Accel_Y)));
pTelemetryPkt->Accel_Z = LongToFloat(htonl(FloatToLong(ASEP_Data.Accel_Z)));
pTelemetryPkt->Euler_X = LongToFloat(htonl(FloatToLong(ASEP_Data.Euler_X)));
pTelemetryPkt->Euler_Y = LongToFloat(htonl(FloatToLong(ASEP_Data.Euler_Y)));
pTelemetryPkt->Euler_Z = LongToFloat(htonl(FloatToLong(ASEP_Data.Euler_Z)));
pTelemetryPkt->Latitude =
LongToFloat(htonl(FloatToLong((float)ASEP_Data.Latitude)));
pTelemetryPkt->Longitude =
LongToFloat(htonl(FloatToLong((float)ASEP_Data.Longitude)));
}
static long FloatToLong(float dataF)
{
union ftol{ float data; long l; } val;
val.data=dataF;
return val.l;
}
static float LongToFloat(long dataL)
{
union ltof{ long data; float f; } val;
val.data=dataL;
return val.f;
}
D4: Wireless.h
//
***************************************************************************
*
// Wireless.h
//
***************************************************************************
*
#ifndef WIRELESS_H_
#define WIRELESS_H_
#include "WizFi630Board.h"
#include "RTOS_DataFormat.h"
extern ASEP_Data_Format ASEP_Data;
extern unsigned char gu8PacketFromWiFiUart[66];
//prototypes
void WirelessMain(void);
static void getControls(STRUCT_CMD_PKT *pCmdPkt);
static void fillTelematry(STRUCT_TLM_PKT *pTelemetryPkt);
static float LongToFloat(long dataL);
static long FloatToLong(float dataF);
#endif
D5: WizFi630Board.c
//
***************************************************************************
*
// Workspace: Capstone/Code/RTOS
// Project: MISL/ASEP RTOS
// WizFi630Board.c
// Originally created by: Brett Parrish
// Modified by: Ty Navarrete
//
// Description: Drivers for the WizFi630 WiFi module with UART interface.
//
***************************************************************************
*
// Standard includes
#include <stdio.h>
#include "stdlib.h"
#include "sys_common.h"
#include "system.h"
#include "sys_core.h"
#include "math.h"
#include "float.h"
// Kernel includes
#include "FreeRTOS.h"
#include "os_task.h"
#include "os_timer.h"
#include "os_semphr.h"
// Include files
#include "sci.h"
#include "WifiPacketFormat.h"
#include "WizFi630Board.h"
// Global Variables
#define PACKET_PAYLOAD_LEN 64
char szPktPayloadLen[] = "64";
char szInsertTagMain[] = "\x21\x3F";
//
***************************************************************************
*
// Function: WizFi630_SendPacket
// Parameters: unsigned char u8PayloadLen, char *payLoad
// Purpose: Send payload data to WizFi
// Return: None
//
***************************************************************************
*
void WizFi630_SendPacket(unsigned char u8PayloadLen, char * payLoad)
{
unsigned int i;
// this is where CTS from GIO port would be added to check before sending to wizfi
for(i=0; i<u8PayloadLen; i++) WizFi630_SendDataByte(payLoad[i]);
}
//
***************************************************************************
*
// Function: WizFi630_SendDataByte
// Parameters: character data to send to WizFi630 over uart.
// Purpose: This function selects the UART used to communicate with the WizFi. The
parameter
//
received is stored in the UART transmit buffer and it blocks until byte buffer is
sent or until
//
more that 100ms-200ms expires.
// Return: None
// CALLED BY: various routines in this file only
//
***************************************************************************
*
void WizFi630_SendDataByte(char data)
{
portTickType pttEntryTime1msTicks = xTaskGetTickCount();
// this is where CTS from GIO port would be added to check before sending to wizfi
sciSendByte(sciREG,data);
// Transmit character
// Wait until finished sending
while((xTaskGetTickCount() < pttEntryTime1msTicks + 200) &&
(!sciIsTxReady(sciREG)));
}
//
***************************************************************************
*
// Function: WizFi630_FindInsertTagAndParsePacketPayloadData
// Parameters: ptr to latest received data byte from WizFi630, ptr to payload buffer/structure.
// Purpose: Scan the incoming data to find the WizFi630 INSERT_TAG pattern
(programmed into
//
WizFi via WEBserver or via serial commands) and payload data from GUI.
// Return: None
//
***************************************************************************
*
#define PARSESTATE_SEARCHING_FOR_WIZFI630_INSERT_TAG 0
#define PARSESTATE_SEARCHING_FOR_END_OF_CMD_DATA64 3
unsigned char WizFi630_FindInsertTagAndParsePacketPayloadData(unsigned char
*u8DataIn, STRUCT_CMD_PKT* pstrucCmdPktPayload)
{
static unsigned int i=0;
static char
buffer_w[48];
static int
state = PARSESTATE_SEARCHING_FOR_WIZFI630_INSERT_TAG;
static unsigned int payloadCntr = 0;
static short checksum;
for(i=0;i<48;i++)
{
buffer_w[i] = *(u8DataIn+i);
}
// Look for WizFi630 "INSERT TAG"
if(state == PARSESTATE_SEARCHING_FOR_WIZFI630_INSERT_TAG)
{
if((buffer_w[0] == szInsertTagMain[0]) && (buffer_w[1] == szInsertTagMain[1]) )
{
state = PARSESTATE_SEARCHING_FOR_END_OF_CMD_DATA64;
}
else
{
return 0;
}
}
// payload data
if (state == PARSESTATE_SEARCHING_FOR_END_OF_CMD_DATA64)
{
if((buffer_w[2] != 0x02) || (buffer_w[3] != 0x03))
{
state = PARSESTATE_SEARCHING_FOR_WIZFI630_INSERT_TAG;
return 0;
}
else
{
pstrucCmdPktPayload->packet_version = (buffer_w[ 2] & 0xff) << 8 | buffer_w[ 3]
& 0xff;
pstrucCmdPktPayload->size = (buffer_w[ 4] & 0xff) << 8 | buffer_w[ 5] & 0xff;
pstrucCmdPktPayload->rcvSeqCnt = (buffer_w[ 6] & 0xff) << 8 | buffer_w[ 7] &
0xff;
pstrucCmdPktPayload->command = (buffer_w[ 8] & 0xff) << 8 | buffer_w[ 9] &
0xff;
pstrucCmdPktPayload->cmd_data[0] = (buffer_w[10] & 0xff) << 8 | buffer_w[11] &
0xff;
pstrucCmdPktPayload->cmd_data[1] = (buffer_w[12] & 0xff) << 8 | buffer_w[13] &
0xff;
pstrucCmdPktPayload->cmd_data[2] = (buffer_w[14] & 0xff) << 8 | buffer_w[15] &
0xff;
pstrucCmdPktPayload->cmd_data[3] = (buffer_w[16] & 0xff) << 8 | buffer_w[17] &
0xff;
pstrucCmdPktPayload->cmd_data[4] = (buffer_w[18] & 0xff) << 8 | buffer_w[19] &
0xff;
pstrucCmdPktPayload->cmd_data[5] = (buffer_w[20] & 0xff) << 8 | buffer_w[21] &
0xff;
pstrucCmdPktPayload->cmd_data[6] = (buffer_w[22] & 0xff) << 8 | buffer_w[23] &
0xff;
pstrucCmdPktPayload->cmd_data[7] = (buffer_w[24] & 0xff) << 8 | buffer_w[25] &
0xff;
pstrucCmdPktPayload->cmd_data[8] = (buffer_w[26] & 0xff) << 8 | buffer_w[27] &
0xff;
pstrucCmdPktPayload->cmd_data[9] = (buffer_w[28] & 0xff) << 8 | buffer_w[29] &
0xff;
pstrucCmdPktPayload->cmd_data[10] = (buffer_w[30] & 0xff) << 8 | buffer_w[31]
& 0xff;
pstrucCmdPktPayload->cmd_data[11] = (buffer_w[32] & 0xff) << 8 | buffer_w[33]
& 0xff;
pstrucCmdPktPayload->cmd_data[12] = (buffer_w[34] & 0xff) << 8 | buffer_w[35]
& 0xff;
pstrucCmdPktPayload->cmd_data[13] = (buffer_w[36] & 0xff) << 8 | buffer_w[37]
& 0xff;
pstrucCmdPktPayload->cmd_data[14] = (buffer_w[38] & 0xff) << 8 | buffer_w[39]
& 0xff;
pstrucCmdPktPayload->cmd_data[15] = (buffer_w[40] & 0xff) << 8 | buffer_w[41]
& 0xff;
pstrucCmdPktPayload->cmd_data[16] = (buffer_w[42] & 0xff) << 8 | buffer_w[43]
& 0xff;
pstrucCmdPktPayload->cmd_data[17] = (buffer_w[44] & 0xff) << 8 | buffer_w[45]
& 0xff;
pstrucCmdPktPayload->cmd_data[18] = (buffer_w[46] & 0xff) << 8 | buffer_w[47]
& 0xff;
payloadCntr++;
state = PARSESTATE_SEARCHING_FOR_WIZFI630_INSERT_TAG;
// Add command packet together to get checksum
checksum=(buffer_w[ 2])+(buffer_w[3])+(buffer_w[4])+(buffer_w[5])+(buffer_w[6])+(buffe
r_w[7])+(buffer_w[8])+(buffer_w[9])+(buffer_w[10])+(buffer_w[11])+(buffer_w[12])+(buff
er_w[13])+(buffer_w[14]);
if(checksum!=buffer_w[15]) // If checksum does not equal received checksum
{
state = PARSESTATE_SEARCHING_FOR_WIZFI630_INSERT_TAG;
return 0; // Exit! Packet was damaged
}
return 1; // HAPPY OUTPUT! A packet has been extracted and stored in payload
structure
}
}
else
state = PARSESTATE_SEARCHING_FOR_WIZFI630_INSERT_TAG;
return 0;
}
D6: WizFi630Board.h
//
***************************************************************************
*
// WizFi630Board.h
//
***************************************************************************
*
#ifndef WIZFI_H_
#define WIZFI_H_
#include "WifiPacketFormat.h"
#define WIZFI_MODE_CMD 0
#define WIZFI_MODE_DATA 1
#define RCVD_CMPLT_PACKET 1
//prototypes
void WizFi630_SendDataByte(char);
void WizFi630_SendPacket(unsigned char u8PayloadLen, char *payLoad);
unsigned char WizFi630_FindInsertTagAndParsePacketPayloadData(unsigned char
*u8DataIn, STRUCT_CMD_PKT* pstrucCmdPktPayload);
// Host to Network and Network to Host macros 16bit(htons) and 32bit(htonl)
#define htons(a) (unsigned short)(((a&0x00ff)<<8) | ((a&0xff00)>>8))
#define ntohs(a) (unsigned short)(((a&0x00ff)<<8) | ((a&0xff00)>>8))
#define htonl(a) ( ((a & 0x000000ff)<<24) | ((a & 0x0000ff00)<<8) | ((a &
0x00ff0000)>>8) | ((a & 0xff000000)>>24) )
#define ntohl(a) ( ((a & 0x000000ff)<<24) | ((a & 0x0000ff00)<<8) | ((a &
0x00ff0000)>>8) | ((a & 0xff000000)>>24) )
#endif
D7: WizfiPacketFormat.h
//
***************************************************************************
*
// WiFiPacketFormat.h
//
***************************************************************************
*
#ifndef PACKET_H_
#define PACKET_H_
#define PAYLOAD_SIZE 64
// 64 bytes => 32 Words
#define PACKET_VERSION 0x0203
typedef struct telemetry
{
unsigned short packet_version; // latest version of the code
unsigned short size;
// payload size (currently fixed at 64)
unsigned short rcvSeqCnt;
// received sequence count (send back what is received)
unsigned short xmtSeqCnt;
// transmitted sequence count
float Euler_X;
// X angle
float Euler_Y;
// Y angle
float Euler_Z;
// Z angle
float Accel_X;
// X acceleration
float Accel_Y;
// Y acceleration
float Accel_Z;
// Z acceleration
float Latitude;
// Sensor GPS latitude
float Longitude;
// Sensor GPS longitude
short tbd[12];
// to be defined/reserved
} STRUCT_TLM_PKT;
typedef struct command
{
unsigned short packet_version; // latest version of the code
unsigned short size;
// payload size (currently fixed at 64)
unsigned short rcvSeqCnt;
// received sequence count (send back what is received)
unsigned short command;
// command word
unsigned short cmd_data[28]; // command data for 64 byte (32 word) payload
} STRUCT_CMD_PKT;
#endif
D8: notification.c
/** @file notification.c
* @brief User Notification Definition File
* @date 24.Feb.2014
* @version 03.08.01
*/
/* Include Files */
#include "esm.h"
#include "sys_selftest.h"
#include "adc.h"
#include "can.h"
#include "gio.h"
#include "mibspi.h"
#include "sci.h"
#include "spi.h"
#include "het.h"
#include "i2c.h"
#include "crc.h"
#include "sys_dma.h"
#include "Wireless.h"
// Kernel Includes
#include "FreeRTOS.h"
#include "os_task.h"
#include "os_timer.h"
#include "os_semphr.h"
// Globals
extern unsigned char gu8PacketFromWiFiUart[66];
extern unsigned char gu8ByteFromWiFiUart[66];
extern unsigned char gflagDataByteRcvdFromWizFi630ViaUart;
unsigned char junkPulled = 0;
#pragma WEAK(esmGroup1Notification)
void esmGroup1Notification(uint32 channel)
{
}
#pragma WEAK(esmGroup2Notification)
void esmGroup2Notification(uint32 channel)
{
}
#pragma WEAK(memoryPort0TestFailNotification)
void memoryPort0TestFailNotification(uint32 groupSelect, uint32 dataSelect, uint32 address,
uint32 data)
{
}
#pragma WEAK(memoryPort1TestFailNotification)
void memoryPort1TestFailNotification(uint32 groupSelect, uint32 dataSelect, uint32 address,
uint32 data)
{
}
#pragma WEAK(adcNotification)
void adcNotification(adcBASE_t *adc, uint32 group)
{
}
#pragma WEAK(canErrorNotification)
void canErrorNotification(canBASE_t *node, uint32 notification)
{
}
#pragma WEAK(canStatusChangeNotification)
void canStatusChangeNotification(canBASE_t *node, uint32 notification)
{
}
#pragma WEAK(canMessageNotification)
void canMessageNotification(canBASE_t *node, uint32 messageBox)
{
}
#pragma WEAK(gioNotification)
void gioNotification(gioPORT_t *port, uint32 bit)
{
}
#pragma WEAK(i2cNotification)
void i2cNotification(i2cBASE_t *i2c, uint32 flags)
{
}
#pragma WEAK(mibspiNotification)
void mibspiNotification(mibspiBASE_t *mibspi, uint32 flags)
{
}
#pragma WEAK(mibspiGroupNotification)
void mibspiGroupNotification(mibspiBASE_t *mibspi, uint32 group)
{
}
#pragma WEAK(sciNotification)
void sciNotification(sciBASE_t *sci, uint32 flags)
{
int i;
if(junkPulled==1)
{
for(i=0;i<66;i++)
{
gu8PacketFromWiFiUart[i]=0;
}
junkPulled=0;
}
else if(gu8PacketFromWiFiUart[0] == 0x21)
{
for(i=0;i<66;i++)
{
gu8ByteFromWiFiUart[i]=gu8PacketFromWiFiUart[i];
gu8PacketFromWiFiUart[i]=0;
}
junkPulled=0;
gflagDataByteRcvdFromWizFi630ViaUart = 1;
}
else
{
for(i=1;i<66;i++)
{
if(gu8PacketFromWiFiUart[i] == 0x21)
{
junkPulled=1;
sciReceive(sci,(i),&gu8PacketFromWiFiUart[0]);
break;
}
}
if(junkPulled!=1)
{
ASEP_Data.Motor_Left = 12;
ASEP_Data.Motor_Right = 12;
}
else
{
return;
}
}
sciReceive(sci,66,&gu8PacketFromWiFiUart[0]);
}
#pragma WEAK(spiNotification)
void spiNotification(spiBASE_t *spi, uint32 flags)
{
}
#pragma WEAK(spiEndNotification)
void spiEndNotification(spiBASE_t *spi)
{
}
#pragma WEAK(pwmNotification)
void pwmNotification(hetBASE_t * hetREG,uint32 pwm, uint32 notification)
{
}
#pragma WEAK(edgeNotification)
void edgeNotification(hetBASE_t * hetREG,uint32 edge)
{
}
#pragma WEAK(hetNotification)
void hetNotification(hetBASE_t *het, uint32 offset)
{
}
#pragma WEAK(crcNotification)
void crcNotification(crcBASE_t *crc, uint32 flags)
{
}
#pragma WEAK(dmaGroupANotification)
void dmaGroupANotification(dmaInterrupt_t inttype, uint32 channel)
{
}
D9: Sensor.c
//
***************************************************************************
*
// Workspace: Capstone/Code/RTOS
// Project: MISL/ASEP RTOS
// Sensor.c
// Originally created by: Ty Navarrete
//
// Sensor: MicroStrain 3DM-GX3-45
//
// Description: Sends data polling commands to the Sensor, reads in the hexadecimal
packages it sends
//
back, and interprets those packages into the Sensor data.
//
***************************************************************************
*
// Standard includes
#include <stdio.h>
#include "stdlib.h"
#include "sys_common.h"
#include "system.h"
#include "sys_core.h"
#include "math.h"
#include "float.h"
// Kernel includes
#include "FreeRTOS.h"
#include "os_task.h"
#include "os_timer.h"
#include "os_semphr.h"
// Include Files
#include "sci.h"
#include "Sensor.h"
#include "RTOS_DataFormat.h"
//
***************************************************************************
*
// User program starts here
//
***************************************************************************
*
void SensorMain(void)
{
static AHRS_data AHRS;
static GPS_data GPS;
if(SendPing()==0)
{
AHRS=GetAHRS();
GPS=GetGPS();
ASEP_Data.Accel_X=AHRS.Accel_X;
ASEP_Data.Accel_Y=AHRS.Accel_Y;
ASEP_Data.Accel_Z=AHRS.Accel_Z;
ASEP_Data.Euler_X=AHRS.Euler_X;
ASEP_Data.Euler_Y=AHRS.Euler_Y;
ASEP_Data.Euler_Z=AHRS.Euler_Z;
ASEP_Data.Latitude=GPS.Latitude;
ASEP_Data.Longitude=GPS.Longitude;
}
return;
}
//
***************************************************************************
*
// DESCRIPTION: Sends Ping command to the Sensor and reads in the acknowledgment and
//
compares it to the correct ack and returns 1 if not correct.
//
// @param none
// @return int
//
***************************************************************************
*
static int SendPing(void)
{
int j;
unsigned char ack_pkg[11];
taskENTER_CRITICAL();
sciSend(scilinREG,8,Ping);
while(!sciIsRxReady(scilinREG));
sciReceive(scilinREG,10,ack_pkg);
for(j=0;j<10;j++)
{
if(ack_pkg[j]!=Ping_ack[j])
{
taskEXIT_CRITICAL();
return 1;
}
}
taskEXIT_CRITICAL();
return 0;
}
//
***************************************************************************
*
// DESCRIPTION: Sends AHRS Poll command to the Sensor and reads in the package, then
parses
//
the package and converts the AHRS data to its floating point values.
//
// @param none
// @return AHRS_data
//
***************************************************************************
*
static AHRS_data GetAHRS(void)
{
AHRS_data AHRS_in;
int i;
unsigned char AHRS_pkg[34];
unsigned char *Ax,*Ay,*Az,*Ex,*Ey,*Ez;
AHRS_in.Accel_X=0;
AHRS_in.Accel_Y=0;
AHRS_in.Accel_Z=0;
AHRS_in.Euler_X=0;
AHRS_in.Euler_Y=0;
AHRS_in.Euler_Z=0;
for(i=0;i<34;i++)
{
AHRS_pkg[i]=0;
}
taskENTER_CRITICAL();
sciSend(scilinREG,10,AHRS_poll);
while(!sciIsRxReady(scilinREG));
sciReceive(scilinREG,33,AHRS_pkg);
taskEXIT_CRITICAL();
if((AHRS_pkg[2]!=0x80)||(AHRS_pkg[5]!=0x04)||(AHRS_pkg[19]!=0x0C)) return
AHRS_in;
Ax=&AHRS_pkg[6];
Ay=&AHRS_pkg[10];
Az=&AHRS_pkg[14];
Ex=&AHRS_pkg[20];
Ey=&AHRS_pkg[24];
Ez=&AHRS_pkg[28];
AHRS_in.Accel_X=HexToFloat(Ax);
AHRS_in.Accel_Y=HexToFloat(Ay);
AHRS_in.Accel_Z=HexToFloat(Az);
AHRS_in.Euler_X=HexToFloat(Ex);
AHRS_in.Euler_Y=HexToFloat(Ey);
AHRS_in.Euler_Z=HexToFloat(Ez);
AHRS_pkg[33]=sciReceiveByte(scilinREG);
return AHRS_in;
}
//
***************************************************************************
*
// DESCRIPTION: Sends GPS Poll command to the Sensor and reads in the package, then
parses the
//
package and converts the GPS data to its double values.
//
// @param none
// @return GPS_data
//
***************************************************************************
*
static GPS_data GetGPS(void)
{
GPS_data GPS_in;
int i;
unsigned char GPS_pkg[50];
unsigned char *Lat,*Long;
GPS_in.Latitude=1; // Initialize to 1 for testing
GPS_in.Longitude=1; // Initialize to 1 for testing
for(i=0;i<50;i++)
{
GPS_pkg[i]=0;
}
taskENTER_CRITICAL();
sciSend(scilinREG,10,GPS_poll);
while(!sciIsRxReady(scilinREG));
sciReceive(scilinREG,49,GPS_pkg);
taskEXIT_CRITICAL();
if((GPS_pkg[2]!=0x81)||(GPS_pkg[5]!=0x03)) return GPS_in;
Lat=&GPS_pkg[6];
Long=&GPS_pkg[14];
GPS_in.Latitude=HexToDouble(Lat);
GPS_in.Longitude=HexToDouble(Long);
GPS_pkg[49]=sciReceiveByte(scilinREG);
return GPS_in;
}
//
***************************************************************************
*
// DESCRIPTION: Converts the hexadecimal char value of the Sensor data to its floating
point value.
//
// @param char*
// @return float
//
***************************************************************************
*
static float HexToFloat(unsigned char* Hex)
{
union htof{ char dataF[4]; float f; } val;
val.dataF[3]=*Hex;
val.dataF[2]=*(Hex+1);
val.dataF[1]=*(Hex+2);
val.dataF[0]=*(Hex+3);
return val.f;
}
//
***************************************************************************
*
// DESCRIPTION: Converts the hexadecimal char value of the Sensor data to its double
value.
//
// @param char*
// @return double
//
***************************************************************************
*
static double HexToDouble(unsigned char* Hex)
{
union htod{ char dataD[8]; double d; } val;
val.dataD[7]=*Hex;
val.dataD[6]=*(Hex+1);
val.dataD[5]=*(Hex+2);
val.dataD[4]=*(Hex+3);
val.dataD[3]=*(Hex+4);
val.dataD[2]=*(Hex+5);
val.dataD[1]=*(Hex+6);
val.dataD[0]=*(Hex+7);
return val.d;
}
D10: Sensor.h
//
***************************************************************************
*
// Sensor.h
//
***************************************************************************
*
#ifndef SENSOR_H_
#define SENSOR_H_
#include "RTOS_DataFormat.h"
extern ASEP_Data_Format ASEP_Data;
// Commands
static unsigned char Ping[8]={0x75,0x65,0x01,0x02,0x02,0x01,0xE0,0xC6}; // Sensor Ping
command
static unsigned char
Ping_ack[10]={0x75,0x65,0x01,0x04,0x04,0xF1,0x01,0x00,0xD5,0x6A};
static unsigned char
AHRS_poll[10]={0x75,0x65,0x0C,0x04,0x04,0x01,0x01,0x00,0xF0,0xDC};
static unsigned char
GPS_poll[10]={0x75,0x65,0x0C,0x04,0x04,0x02,0x01,0x00,0xF1,0xDF};
// Structures
typedef struct {
float Accel_X; // X acceleration
float Accel_Y; // Y acceleration
float Accel_Z; // Z acceleration
float Euler_X; // X angle
float Euler_Y; // Y angle
float Euler_Z; // Z angle
} AHRS_data;
typedef struct {
double Latitude; // Sensor GPS latitude
double Longitude; // Sensor GPS longitude
} GPS_data;
// Prototypes
void SensorMain(void);
static int SendPing(void);
static AHRS_data GetAHRS(void);
static GPS_data GetGPS(void);
static float HexToFloat(unsigned char* Hex);
static double HexToDouble(unsigned char* Hex);
#endif
D11: MotorControl.c
//
***************************************************************************
*
// Workspace: Capstone/Code/RTOS
// Project: MISL/ASEP RTOS
// MotorControl.c
// Originally created by: Ty Navarrete
//
// Motor Controller: T'Rex ROB-12075
//
// Description: Takes in the speed variable for each motor channel, translates it to the proper
PWM
//
signal and sends it to the motor controller board.
//
***************************************************************************
*
// Standard includes
#include <stdio.h>
#include "stdlib.h"
#include "sys_common.h"
#include "system.h"
#include "sys_core.h"
#include "math.h"
#include "float.h"
// Kernel includes
#include "FreeRTOS.h"
#include "os_task.h"
#include "os_timer.h"
#include "os_semphr.h"
// Include Files
#include "het.h"
#include "MotorControl.h"
#include "RTOS_DataFormat.h"
//
***************************************************************************
*
// User program starts here
//
***************************************************************************
*
void MotorControlMain(void) // will take in two variables of motor speeds
{
int lmotor=ASEP_Data.Motor_Left; // PWM duty cycle values 6% to 18%
int rmotor=ASEP_Data.Motor_Right; // PWM duty cycle values 6% to 18%
setPwm(lmotor, rmotor);
return;
}
//
***************************************************************************
*
// DESCRIPTION: Sets the motor PWM duty cycle for each channel.
//
// @param none
// @return none
//
***************************************************************************
*
static void setPwm(int DC_Left, int DC_Right)
{
int LeftChannel = DC_Left;
int RightChannel = DC_Right;
taskENTER_CRITICAL();
pwmSetDuty(hetRAM1,0,LeftChannel); // Left channel duty cycle
pwmSetDuty(hetRAM1,1,RightChannel); // Right channel duty cycle
taskEXIT_CRITICAL();
return;
}
D12: MotorControl.h
//
***************************************************************************
*
// MotorControl.h
//
***************************************************************************
*
#ifndef MOTORCONTROL_H_
#define MOTORCONTROL_H_
#include "RTOS_DataFormat.h"
extern ASEP_Data_Format ASEP_Data;
// Prototypes
void MotorControlMain(void);
static void setPwm(int DC_Left, int DC_Right);
#endif
Appendix E: The Modular Integrated Stackable Layer System: A NASA
Development Partnership
Section: N
THE MODULAR INTEGRATED STACKABLE LAYERS SYSTEM: A
NASA DEVELOPMENT PARTNERSHIP
Tanner L. Perkins, Kelson G. Astley, Ty B. Navarrete, Paul B. Delaune, Dr. Joseph A.
Morgan
Electronic Systems Engineering Technology
Texas A&M University
Abstract
The need for more advanced and powerful microcontrollers within electronic systems
has increased significantly over the last several decades. While many hobbyists, by default,
seek out Arduino platforms, industry typically have electronic systems custom made to suit
their processing needs. In order to give industry, as well as hobbyists, a more power and cost
effective embedded processing solution, NASA and Texas A&M University’s Electronic
Systems Engineering Technology (ESET) Program have formed a partnership to further
develop the Modular Integrated Stackable Layers (MISL) system, originally created by
NASA. The MISL system is being expanded to utilize the RM48L952 microcontroller,
produced by Texas Instruments. This “rack and stack” system was designed with
standardized data and power buses so that additional boards, or layers, with specific
functionality, may be stacked and easily integrated. This allows the user to mix-and-match
hardware within the RM48 based system. MISL is being designed and developed as an open
source hardware and software system to allow the technology community to continue
development and customization of the system to meet their needs long after inception.
Keeping the MISL system completely open source will in turn drive the cost of individual
units down. This all provides a versatile, inexpensive, and space-qualified solution to the
processing needs of new products and systems in a wide range of design and development
environments including automotive, aerospace, medical, and oil and gas industries. This
paper will provide an overview of the MISL systems’ current status, its use within education,
and the plans for the open community being developed by Texas A&M University in
partnership with NASA.
Introduction
The use of microcontrollers and embedded systems within our technologically
advancing world dominates realms including, but not limited to, industry, consumer market,
and hobbyist sectors. Systems like Ardunio have taken a major role in a large amount of
simple electronics projects within the hobbyist and academic realms. One feature that has
added to Ardunio’s success is their Shield system, which allows for added capability and
expandability of the hardware. However, the Ardunio platform is only meant for simple
projects because of its limited memory, lack of industry communication protocols, and its
insufficient processing power needed for major projects. But, Adruino is not the only
company that currently supplies “rack-and-stack” type systems. Texas Instruments has a
system of interconnecting boards called LaunchPad. These boards are very inexpensive, but
connect using large, fragile header pins. Freescale also has a system called Tower that is
more robust and expensive, but is also quite large in size. Due to these constraints, there is a
need for a new system that utilizes powerful microcontrollers that can be used by industry,
academia, and other markets needing more advanced processing power, durability, is
relatively inexpensive, and in a small form factor. For this reason, the Command and Data
Handling (C&DH) branch at The National Aeronautics and Space Administration (NASA)
Johnson Space Center (JSC) created the Modular Integrated Stackable Layer (MISL) system.
NASA has created standards for data and power buses for connectivity between the multiple
layers of this rack-and-stack type system. The Electronic Systems Engineering Technology
(ESET) program at Texas A&M University (TAMU) is continuing the development of this
system by creating a new processing board. This board is centered around the RM48L952
microcontroller manufactured by Texas Instruments (TI). In addition, the ESET program has
begun creating a MediaWiki page to act as a resource for the MISL system open source
community. Coupled with the drive for an open source system, the ESET program is
currently making use of the MISL system in their Embedded Systems Development in C
course. This sophomore level class focuses on an introduction to programming using the C
programming language and the design and use of embedded microcontroller systems.
MISL Standards
The MISL system uses several standards to allow for multiple layers to connect easily.
Figure 1 shows that the data bus connector is always positioned horizontally on the relative
top of the board while looking at the face of the board. Similarly, the power bus connector is
always positioned vertical at the left side of the board, again when looking at the top face of
the board. This standard placement allows for the board to be any size but still keep the data
and power bus connectors correctly located, which is depicted by dotted lines.
Data
Connector
Power
Connector
I/O
Connectors
Figure 1: Connector and Board Layout
The height of the MISL stack will vary depending on the number of boards used and
which connectors are appropriate for a given board. There are two possible heights to both
the male and female connectors, which allow four possible heights between boards. For
example, Figure 2 shows four layers with two different height dimensions between the layers,
0.354 and 0.276 inches. If both the short male (ERM8 & ERM5) and female (ERF8 & ERF5)
connectors are used, the resulting board spacing is 0.276 inches, while a short male connector
with a tall female connector will result in a height of 0.354 inches. The double red asterisk
indicates the board thickness in this example is 0.062 inches. The bottom board in this
example is the AA battery pack board which has a bottom height of 0.5 inches. After totaling
all of the dimensions, the total stack height is just less than 2 inches in this example.
ERF8
0.25
ERF5
**
ERM8
ERM5
ERF8
ERF5
0.354
ERM8
ERF8
**
ERM5
ERF5
0.276
**
ERM8
0.354
ERF8
**
0.5
**
0.062 x 4 = 0.248
Expected Total Height = 1.982 in
Figure 2: Stack Height
The height of the connectors chosen is determined by the max height of the
components on the board. The potential problem of having a component height greater than
the height of the tallest connector could arise. In response to this, several solutions have been
found. The first would be to extend the board in one of the two available directions. An
example is shown in Figure 3, where the board has been extended horizontally for a
connector that would not fit in between the layers of the stack. The red area shows the board
extensions with the two taller components shown in black.
Extension of board
Taller Components
ERF8
0.25
ERF5
**
ERM8
ERM5
ERF8
ERF5
0.354
ERM8
ERF8
**
ERM5
ERF5
0.276
**
ERM8
0.354
ERF8
**
0.5
**
0.062 x 4 = 0.248
Expected Total Height = 1.982 in
Figure 3: Board Extension for Taller Components
If a component on the interior of the board layout is too tall or board dimensions are a
strict constraint, then using the stack-up board adapter may be the best solution. This will be
the best solution for users that are not designing hardware for the MISL stack. The stack-up
board adapter is shown in Figure 4, with the red sections highlighting the solutions to the
height problems.
Stack-Up Board Adapter Layer
ERF8
**
ERM8
ERM5
ERF8
ERF5
ERM8
ERF8
0.25
ERF5
0.630 +
**
ERM5
ERF5
A taller
component
space
**
ERM8
0.354
ERF8
**
0.5
**
0.062 x 4 = 0.248
Expected Total Height = 1.982 in
Figure 4: Stack-Up Board Adapter
The bus connectors being used are manufactured by SAMTEC. The ERF8 and ERM8
series are 50 pin connectors which act as the power bus for the MISL system. The ERF5 and
ERM5 are 80 pin connectors which act as the data bus between layers for the MISL system.
In Table 1, the various possible heights are illustrated.
Table 1: Data Bus Mated Connector Heights
ERM5-02.0
ERM5-05.0
0.276 in (7.0 mm)
0.394 in (10.0 mm)
ERF5-05.0
0.354 in (9.0 mm)
0.472 in (12.0 mm)
ERF5-07.0
Table 2: Power Bus Mated Connector Heights
ERM8-02.0
ERM8-05.0
0.276 in (7.0 mm)
0.394 in (10.0 mm)
ERF8-05.0
0.354 in (9.0 mm)
0.472 in (12.0 mm)
ERF8-07.0
Current boards being produced are now going to be 0.93 inches thick as opposed to
the original boards which were 0.62 inches. This solves the problems associated with the
alignment posts on the connectors. This problem arose because the posts are 0.43 inches long
and had to be cut in half to properly align on a 0.63 inch board. Therefore, the standard board
thickness will be 0.93 inches to accommodate the bus connectors properly.
Capstone Project
The ongoing project at Texas A&M University by three ESET students is to take the
current MISL system and create a new processing board, developed around Texas
Instruments’ RM48L952 microcontroller. This processing board will be used with the
existing 28 Volt power board and WizFi630 communication board to make up the MISL
system for this project. This stack will then be mounted onto the Articulated Suspension
Exploratory Platform (ASEP). The MISL system will allow the user to control the ASEP
vehicle remotely using a gaming controller connected through a base station running a
LabVIEW created Windows executable graphical user interface (GUI). This executable will
allow the GUI to be run on any Windows machine, including Windows tablets. The GUI will
also display Global Positioning System (GPS) and Inertial Measurement Unit (IMU) data
received from a sensor mounted on the ASEP robotic vehicle.
Figure 5 gives a high level pictorial description of the Capstone MISL project.
Located in the center of the figure is the ASEP robotic vehicle which will have the MISL
stack mounted onboard. To power both the vehicle and the MISL System, a Lithium Polymer
battery will provide 7.4 Volts DC. The MISL system’s 28 Volt power board will then
regulate and convert this 7.4 Volts to 5 and 3.3 Volts DC which can be used by the other
boards within the stack via the power bus. This same 7.4Volts will be supplied to the ASEP’s
motor driver board to power the left and right channels for the motors. Since a two channel
design is being used, the vehicle will drive similar to a tank type vehicle which will give the
capability to make sharp turns. The GPS and IMU sensor being mounted to the ASEP vehicle
is manufactured by Microstrain and will be powered by and communicate directly to the
RM48 processing board via an onboard 25 pin micro-D connector. The data from the sensor
will be polled at 10Hz, giving sufficient IMU data for the GUI. The stack will use the
WizFi630 board to wirelessly communicate with the base station running the Windows GUI
over 802.11. The USB controller, wired directly to the GUI, will provide user input and the
controls for the robot. These commands will be wirelessly relayed to the MISL system so that
they can be interpreted on the RM48 processing board. The processing board will then
provide appropriate signals to the motor driver board to control each channel of motors.
Figure 5: Conceptual Block Diagram
The processing board being developed will utilize the Ball Grid Array (BGA) package
of the RM48L952. This microcontroller has 337 pins which will connect to several onboard
peripherals as well as the data bus. Much of the controller’s input/output (I/O) pins are
mapped to the data bus so that other boards on any given layer can connect to the
microcontroller. For example, the WizFi630 board being used in this project will
communicate using the Serial Communication Interface (SCI) pins. Although the bus will be
accommodating most of the I/O connections, several onboard peripherals will also be
connected to the microcontroller. This includes: Ethernet, Controller Area Network (CAN),
RS232, RS485, Universal Serial Bus (USB), Micro SD card slot, and the Joint Test Action
Group (JTAG). The onboard Ethernet controller can be set to Reduced Media Independent
Interface (RMII) or Media Independent Interface (MII), however when RMII is used a
50MHz oscillator must be soldered on the board instead of the 25MHz oscillator used for MII.
USB can also be put in either host or device mode with the flip of a dip switch. The
microcontroller’s Universal Asynchronous Receiver / Transmitter (UART) pins are used for
the RS232 / RS485 module. This module can be put into a given mode by the use of a set of
four dip switches on the board. A few of the same microcontroller connections made onboard
are also connected to the data bus. For example, the SCI pins mentioned before are available
through the data bus as well as the RS232 circuitry. Therefore, depending on the user’s
requirements, one of the uses must be selected. Most of the onboard communications will be
available through a 25 pin micro-D connector, which will allow for the use of custom cabling
to connect the sensor and motor driver board to the MISL system. CAN will be used to
communicate from the RM48 board to the motor driver board, while RS232 will be used to
communicate from the IMU/GPS sensor to the MISL stack.
Figure 6 shows the GUI that has been created in LabVIEW and converted to a
windows executable. On the left side, the vertical and horizontal bars indicate the levels of
joystick input from the USB controller. This will then be translated into vehicle motion
through the MISL system. Below this, the current GPS data is displayed in Latitude and
Longitude values along with a graph that tracks the movement of the vehicle with respect to a
starting point. This starting point can be reset to the current location by the user at any time.
On the right, a 3D model of the vehicle is displayed; this image will be rotated according to
the IMU data received from the robot.
Figure 6: Graphical User Interface
MISL Open Source Community
In order to facilitate the open source community associated with the MISL system, the
ESET department has been developing a MediaWiki. This Wiki page will contain
information about the MISL system and its standards, hardware and software designs, current
MISL boards in production, current and past projects that utilize the MISL system, a user
forum, and a section outlining the use of MISL within the educational environment. The bus
and connector standards, as discussed earlier, will be presented in value and pictorial format
in order to allow users to design boards that will work with any boards produced previously.
Currently, NASA has produced about a dozen boards to fill different power, communication,
and intelligence requirements for a variety of projects. However, some of the boards will not
be released to TAMU or the public. This is due in part to security reasons and also a few of
the boards created would not be applicable to public use. For example the ISA100
communication board would not be of benefit because the ISA100 protocol is almost strictly
used by NASA. This being said, most of the existing boards will be released for public use,
which in turn will create a library of available boards for purchase. Having past and present
projects displayed on the Wiki will allow potential users to see how the MISL system could
meet their needs as well as displaying the wide range of capabilities of the MISL system. The
opportunity of having a moderated forum could allow users to interact and help grow the
support community and knowledge base of the MISL system. Finally, displaying the use of
the MISL system within the educational environment will allow other educators to see how
the MISL system could be integrated into their electronics, robotics, and/or embedded design
courses. How the MISL system is being used currently within the educational realm will be
discussed in the next section. Having a place that contains this wealth of knowledge will
harbor an environment of cooperation that is the foundation of an open source community.
This open source community would in-turn, allow for further rapid development of additional
hardware and software for the MISL system, while at the same time driving cost down and
making it an affordable system for all to utilize.
MISL within Education
The MISL system has had the opportunity to be used within the educational sphere
when it was implemented by the ESET department in their sophomore level Embedded
Systems Development in C course. This class is the first opportunity for ESET majors to be
introduced to both the C programming language as well as the design and use of embedded
systems. In this manner, the MISL system is a perfect platform to explore these two topics.
The MISL stack being used contains the 5 Volt battery board, the Texas Instruments’
MSP430 intelligence board, and a breakout board that allows for the complete pin-out of the
data bus. This pin-out allows for the system to be connected to a breadboard which could
connect a variety of circuitry containing numerous peripherals. The breakout board also has
onboard light emitting diodes (LEDs) which will allow students to not only learn how to
control pin outputs, but can also be used to debug more intermediate code. Many educators
have chosen various Adruino systems to implement embedded design, however the ESET
program at TAMU believes that MISL system gives students a more advanced and industry
minded system to learn on. This will better prepare students for future job opportunities using
an industrial grade microcontroller. This also adds the idea of assigning a specific pin an
available function. For example, a given microcontroller may have a pin capable of
communicating using the SCI protocol, however the pin may also have the capability to act as
an Inter-Integrated Circuit (I2C) communication line. In addition, almost all digital lines can
act as a General Purpose Input and Output (GPIO). Therefore, the user must tell the
microcontroller how each pin should behave. To do this with a Texas Instruments’
microcontroller, the use of Halcogen is necessary to enable and assign pin functions to
multipurpose pins. The use of this system in STEM education, both at a high school and
college level, could greatly benefit our next generation of engineers.
Summary and Conclusion
To conclude, the MISL system is a versatile, space qualified system that is applicable
in many environments including education, industry, hobbyist projects, as well as space
applications. This multipurpose platform is composed of a layering system which allows for
rack-and-stack, inter-board connections through a power and data bus. This gives the user the
ability to choose the functionality they need for their specific project. The ability to swap
space qualified hardware as well as the support of an open source community will set MISL
apart as a versatile, high quality, inexpensive electronic solution for all users. Because of
MISL’s capabilities and the opportunities it presents to learn about embedded software
development and electronics in general, the MISL system has been integrated into the ESET
program at Texas A&M University. To demonstrate the newly created RM48 microcontroller
board, Texas A&M is currently integrating the MISL system into the ASEP robotic vehicle to
give remote control from a Windows laptop or tablet. On this windows laptop a LabVIEW
base executable GUI will display IMU and GPS sensor data from the ASEP robot.