2. Building a Model.................................................................................................................................................6
2.1 Getting Started ...........................................................................................................................................6
Creating a New Model ........................................................................................................................6
Performing a Model Update (ctrl+d) ..................................................................................................6
Building a Raptor™ Touchscreen Display Model ...............................................................................6
Programming the Display ...................................................................................................................9
3. Creating a Display ............................................................................................................................................ 11
Figure 3.1.2.a – Raptor™ Goto Screen Block Called by a Falling Edge Trigger .......................................................12
Figure 3.2.1.a – Previous and Next Ports .................................................................................................................13
Figure 3.2.2.a – Standard Drawing Blocks ...............................................................................................................14
Figure 3.2.4.a – Block to Clear Screen Area .............................................................................................................15
Figure 3.2.5.a – Raptor™ String and Printf blocks ..................................................................................................16
Figure 3.2.5.b – Basic Example to Draw Text ..........................................................................................................17
Figure 3.2.5.c – Drawing text in an Element Block Triggered Subsystem ................................................................17
Figure 3.2.5.d – Comparing Techniques Drawing Text Without an Element Block vs. With One ............................18
The Raptor™™ Touchscreen Display is a unique offering from New Eagle. By combining a general
purpose controller and a wide array of communications with a 7-inch touch screen display on top of the Raptor™
model-based development platform, engineers with little to no programming experience have unprecedented
power to create intuitive Man-Machine Interfaces that may either directly control the host system, or
coordinate with other devices.
1.1 Motivation
The purpose of this paper is to introduce the reader to the Raptor™ Touchscreen Display. A user with no
knowledge of the device should be able to put together a simple but useful application. It is assumed that the
reader has a basic understanding of Matlab, Simulink, and the Raptor™ platform.
Figure 1.a – The Raptor™ Display Library
1.2 Setup
This guide assumes some knowledge of the Raptor™ platform and model-based development with
Simulink. The minimum requirements to get started are described below:
7” Resistive Touchscreen Color Display
WVGA 800 x 480 color TFT LCD
Max brightness of 1000 NIT (cd/m2).
Fully waterproof (IP65)
(3) Deutsch 12-pin connectors
2 USB po
Freescale iMX 286 processor
Operating Temperature: -30 to +80°C.
Operating Voltage: 10-32 VDC
rt
s
Available I/O:
14 Analog Inputs
4 Digital Inputs
8 Outputs
2 CAN Channels
Ethernet
2 USB Ports
PC
1 gigahertz (GHz) or faster 32-bit (x86) processor
1 gigabyte (GB) RAM (32-bit)
16 GB available hard disk space
DirectX 9 graphics device with WDDM 1.0 or higher driver.
One USB port and flash drive with 128MB or higher free space
Datalink Adapter (optional)
Though optional, a CAN adapter will allow you to send CAN messages back and forth, and if you
have Raptor-Cal installed take measurements and set adjustments via XCP.
The Raptor™ platform provides a comprehensive suite of tools to design and program each of the display
devices.
Raptor 2015b and newer no longer support 32-bit MATLAB instillations
Figure 1.2.2.a – Raptor™ Compatibility Matrix
Development Environment
Windows 7 or Windows 10
Matlab 2014a or newer
CodeSourcery, Sourcery G++ Lite for ARM GNU Linux
Visual Studio 2010
Visual C++ 2010 SP1 Full
Visual Studio 2010 SP1 Update
.NetFX4.5
Raptor™ 2016b
Figure 2.1.1.a – A Template Touchscreen Display Project
Performing a Model Update (ctrl+d)
The user may validate a model without executing a full build by performing a Model Update.
This will validate parameters, connections, data types and block-specific constraints to let the user know
if a build will fail, and what can be done to prevent it.
Building a Raptor™ Touchscreen Display Model
In Simulink, a build can be triggered with ctrl+b. This will begin the task of translating blocks
placed in the model into C code and compiling them into either a PC simulator or device binary. By
default the model is configured to generate both. The simulator is useful for debugging, or doing
developing without any display hardware present. Build configuration parameters can be set in the
Target Definition block.
Checking Auto-Run
one has been generated). Here, the user can test functionality of their display by using their mouse as if
it were their finger. You can pause, zoom, grid, and control the fps of the display. These features allow
for additional bug fixing, as well as cosmetic optimization.
Simulator
will start the simulator executable as soon as the build is finished (if
Figures 2.1.3.c & d – An Example of Auto-Run Simulator
In addition to simulating the on-screen graphics, users can use a virtual CAN channel to test the
functionality of the display. Open Raptor-CAN and select the simulate tab, notice that the screen will be
blank at first. Next, choose the DBC file you want to simulate by selecting ‘Add DBC’. The messages from
the DBC file will appear, they can be expanded using the ‘+’ icon give the user access to individual signals.
To simulate the messages over the virtual CAN bus, press the play button next to the messages. From
here, the user can adjust the values by using the sliders or typing values in to the text fields on the right,
this will cause the data going into the display to change.
The contents of the build directory will vary depending on what options were selected in the
target definition block. For instance, a device binary will only be generated if a compiler was selected for
one. For more details see section 2.1.3.
Programming from a USB drive
Programming the display requires a USB flash drive. To begin reprogramming, unzip the
contents of the device binary into top level of the flash drive. (ie. so the file system on the flash drive
mirrors what is inside of the .zip file) With the display turned on, insert the flash drive into either USB
port. After a few seconds the device should detect a new program on the USB drive and begin
reprogramming. Follow the instructions on the screen to complete the process.
Figure 2.1.4.a – USB Drive Inserted in Front of a Raptor™ Display
Raptor-Cal
Raptor-Cal allows the user to program the display from a Raptor™ Package file (.rpg), as well
as connect over XCP to probe adjustment and measurement values. For more information on Raptor-Cal
go to www.neweagle.net.
Occasionally software loaded onto the display may cause it to become inoperable. Sometimes a
startup sequence will put the device into a loop that prevents traditional programming, or a program
may simply crash on startup. When this happens there is a hard-reset option available.
From the hardware manufacturer:
Make sure the power is off then insert the USB Stick into the USB Port. Turn on the power
while simultaneously holding down the small red button right next to the USB port on the
back of the unit. The screen will turn blue and after a few seconds the update process will
begin. There will be on-screen information during the update process. Please remove the USB
Stick when prompted and the target unit will automatically reboot into the new software.
Raptor™ has special blocks for defining graphical output in displays. The main block that organizes the
sequence of drawing UI elements is the Screen Definition block.
Screen Outputs
As a rule of thumb,
Create_Background()
Figure 3.1.a – Screen Definition
and
UpdateForeground()
should only be used for
drawing and display logic. While it’s valid to poll I/O, communications, or work with other pieces of
application logic in these subsystems, it is cleaner to do so in either the
Init()
or IsCurrentScreen
subsystems, using ports as necessary to pipe relevant data back and forth.
Init()
Actions that are executed when a screen is initialized go into the
subsystem is called each time the screen is brought up as the current screen.
That is, for two hypothetical screens,
MyScreen1, switches to MyScreen2, and then switches back to MyScreen1, the
MyScreen1
and MyScreen2, if the application begins on
called twice; once when the application starts up, and once when switching back from MyScreen2.
Init()
Init()
function. This
function will be
Create_Background()
Actions that are executed only when a complete redraw of a screen is required go into the
Create_Background()
function. These because these actions do not happen frequently, only items that
go into the background such as background images or non-moving parts should go here. This is also a
good place to initialize button definitions.
Update_Foreground()
The display SDK queues foreground drawing tasks and executes them in a tight loop.
Update_Foreground()
is the function that should contain any moving parts or elements that will be
updated live on the screen.
IsCurrentScreen
IsCurrentScreen
traditional application for this is to attach it to an enabled subsystem allowing everything inside it to
run continuously (free of the display loop.) This is where logic I/O and communications relevant to a
particular screen should go.
Switching Between Screens
is a Boolean output that gets set high when the given screen is current. The
Figure 3.1.2.a – Raptor™ Goto Screen Block Called by a Falling Edge Trigger
Switching between screens can be done with the Goto
Screen
block. When executed this block
will switch from the current screen to the specified screen.
Note: When executing this block inside of a Screen function (eg. IsCurrentScreen) it is highly
recommended to place the Goto
Screen
block inside of a triggered subsystem with a falling-edge trigger
to allow the value that triggered the switch to reset before changing screens. This helps to prevent
infinite loops, or being prevented from returning to this screen again
Most drawing blocks have an option to show ‘previous’ and‘next’ ports. Next ports output a
Boolean when the drawing block is finished to enable the next block to begin drawing. This ensures
order which is important when an element is meant to overlap another.
Figure 3.2.1.a – Previous and Next Ports
As shown in figure 3.2.1.a, to draw one element on top of another, simply put the next port of
the element that goes on bottom into the previous port of the element that goes on top.
Standard Drawing Blocks
There are ten standard drawing blocks that cover everything from drawing and filling in
differently shaped regions, to writing text to the screen. As an aid, all of these blocks show a sample of
their selected color on the mask when the color value is set directly in the block (as opposed to taken
from a port.)
Draw Arc
Draws an arc of a specified color, thickness, and radius from one angle to another.
Draws a line of specified color, thickness,
and style from one point to another.
Draw Text
Draws text onto the screen at a specified
location. The block has two ports for X and Y
location. What this location means in terms of
positioning is determined by the horizontal and
vertical alignment parameters which are set in the
mask.
Text may either be directly set in the
block, or taken from a port. For trying to write live
updated text, this can be very useful when used
together with the Raptor™
more help with drawing text see section 3.2.5.
Draw Circle
Draws a circle of specified color and
thickness around a coordinate location with a
specific radius.
printf
block. For
Figure 3.2.2.a – Standard Drawing Blocks
Fill Circle
Fills in a circle area of specified color around a coordinate location with a specific radius.
Draw Rectangle
Draws a rectangle of specified color and thickness between two coordinate locations.
Fill Rectangle
Fills a rectangle area of specified color between two coordinate locations.
Draw Polygon
Draws a polygon of specified color and thickness between a set of ordered pairs
Fill Polygon
Fills a polygon area of specified color between a set of ordered pairs
Fill Ellipse
Fills an ellipse area of specified color about a given center point with a specific x-radius, y-radius,
and rotation.
The Clear
application for this is right before a background display gets drawn.
Screen
block clears an entire screen to show only the background color. A good
Element
The
screen, the
Element
Element
block outputs a function call trigger. For elements being actively drawn on the
block will first clear the area behind it before drawing. This can be useful for text
being drawn and updated on the screen in the same position.
It should be noted that for elements that will be changing position on the screen, this block is
not a good option, as it will only clear the next position that a block is to be drawn in, leaving an artifact
still from the previous position.
Drawing Text Example
Working with Raptor™ Strings, Printf, etc.
Because the end goal of Simulink is to generate C code, there is no direct notion of a String
object. Raptor™ provides a few blocks to make working with String text easier.
3.2.5.a – Raptor™
The first block Raptor™ provides is the String block. The String block allocates a block of
program memory of a particular character length and if defined, initializes it with a null-terminated
String value. The benefit to this is that a String of text can now be passed around without needing to
explicitly handle it as an array of characters.
The other String block that is commonly useful in display design is the
Printf
block exposes all the functionality of a C format string in Raptor™ . Perhaps the most powerful
feature of this block is that it will read the provided format string, and create input ports for each of the
parameters. The block then outputs the formatted string.
There are a number of other String blocks available in the Raptor™ library as well to convert
Raptor™ Strings to and from arrays, determine length, and even perform a Scanf on a string.
String
and
Printf
blocks
Printf
block. The Raptor™
Drawing String Text
Drawing text is fairly straightforward, with a few caveats.
In this example there’s aDraw
alignment are set to center.) There is a
Text
block centered on a point. (i.e. Both horizontal and vertical
Printf
block with a format string, “My Value = %d”. Raptor™
reads this string and recognizes that there is one integer parameter, and creates an input port on the
block according. Finally, there is an empty Raptor™ String initialized to 20 characters wide to hold the
output value. There is also a custom subsystem that increments a number from zero once a second to
give us some sample data to change live at runtime.
Figure 3.2.5.b – Basic Example to Draw Text
The above example will draw text on the screen, updating the text value every second. The
problem with this approach is that Raptor™ will not clear the previous string before drawing the next
one. The result will be a strange overlapped string drawn on the screen.
To updated strings from being written over old ones the easiest technique is to put the live
element being drawn into a function call subsystem triggered by the
the entire area being written is cleared in between each successive redraw.
What sets this display apart from other display offerings from New Eagle is the 7” resistive touchscreen.
Touchscreen input allows for a wide range of user experience options
Touchscreen Calibration
Figure 3.3.1.a – Touch Calibration Screen and Recalibrate
Touchscreen calibration is automatically launched when the device is first turned on after
reprogramming. The application designer can (and should) provide some extra gesture to recalibrate the
display if need be. This can be a long press, a button, or a simple pattern.
If the touchscreen needs to be recalibrated this can be done with the Recalibrate
triggered with a Function call generator. If possible in the application, the gesture to initiate
recalibration should not be dependent on needing to press a particular location on the screen. The
reason for this being that if the touchscreen calibration is very far off the user may not know what
location is actually being clicked in spite of what location is being pressed on the display.
The most direct way to work with the touchscreen is via the touchscreen status block. This block
provides information directly from the touchscreen drivers to show whether or not the screen is
currently being touched, and if so in what coordinate location.
Figure 3.3.2.a – Display Touchscreen Status block
Possible uses include:
Detecting when a particular area has been pressed
Determining how long the screen has been pressed
Transforming user input
Drawing a cursor momentarily when the user presses the screen to indicate where the
program interprets the location of the screen press
The Raptor™ Touchscreen Display does not have hardware buttons like the other display
modules. In order to get the same kind of functionality, Raptor™ provides a set of blocks to draw
buttons on the screen that act just like physical buttons.
There are two parts to the touchscreen buttons. A Button
Def
block and a Button Status block.
The Button
software. This block should be placed in the
Def
block does the work of both drawing and initializing the button status in
Create_Backgound()
subsystem of a Screen_Definition. This
ensures that the button will only be active when the current scree on which the button is drawn is
active.
The Button Status block may be placed anywhere in the model and acts just like a digital input,
outputting a high value when the button is pressed, and low when released.
Note: When using a touchscreen button to switch between screens, it is highly recommended to place
the Goto
Screen
block inside of a triggered subsystem with a falling-edge trigger to allow the button
status value that triggered the switch to reset before changing screens. This helps to prevent infinite
loops, or being prevented from returning to this screen again.
The Raptor™ Data Logging Blockset within Raptor-Dev allows the user to streamline file read and write
development within their Raptor™ display application. These blocks come prewritten when the user opens a new
raptor display model, using the “raptor_create_touch_display(‘ProjectName’)” function in MATLAB.
4.1 Under the Hood
When the user delves into the Simulink code behind the data logger
(example_project/Foreground/Display/CAN Logging/Log CAN1), they will eventually see the image below:
In Subsystem2, the user can see how the file handle for the file to be written is made. Every time the USB is inserted,
a new logging file is created with the name of the Raptor™ build number and number associated with the log file.
Figure 4.1.b- Subsystem2
A very important part of this code is the parameters of the Printf block. Here, the string is formatted in order to give
a path to where the file will be written. ‘disk_sda1/’ is referencing the USB. This allows the file to be written onto
the USB. bdroot is the project title, ‘_v%03.0F_%06.0F_’ formats the path to include the number of the Log created
(with leading zeros and no decimals), as well as the build number used (with leading zeros and no decimals). E.g. if
the user plugs in the USB for the third time, on their second build, the text file on the USB will read
“example_project_v003_000002”.
Since the display cannot connect directly with a computer, a USB is used to transfer important files from the
computer to the display. Raptor
your display. While the following example is not created when the user creates a new model, the example can be
easily replicated.
™ has blocks that can handle these interactions while the application is running on
Figure 4.2.a- Simple USB Read Application
Within the Open a File triggered subsystem, the File Open block takes in a string with the path of the file the user
wishes to open (keeping in mind to include ‘disk_sda1/’, as it allows access to the USB). Within the Read a File
enabled subsystem, there is a File Read block that then reads a certain length of the file when the user enables the
subsystem with the DO_READ variable.
Figure 4.2.b- Raptor™ Code for Simple USB Read Application
The USB Status Block allows the user to know, in software, whether or not a USB device is inserted into the
display. This is a useful tool to trigger logging events. Additionally, this block can be configured to handle the file
path, and eject ready status.
Figure 4.2.1.a- USB Status Block
4.2.2 USB Eject
The USB Eject block can be put into a triggered subsystem that is triggered whenever the user would like to
disconnect the USB from the display. This Raptor™ block ensures that the USB drive is safely removed upon the user’s
approval.
Figure 4.2.2.a- USB Eject Block
5. Conclusion
The Raptor™ Touchscreen Display is a powerful tool for creating interactive controls applications. By
now the reader should feel confident to begin architecting software on the Raptor™ Touchscreen Display.
For further information and support, or to inquire about purchasing options contact New Eagle at
www.neweagle.net/contact
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.