|
Software
Several customers have asked why we
developed our own object oriented programming language rather than provide a
product with Linux or an operating system supporting compiled 'C'. If we look
back at the original requirements we can see some of the reasons.
Prime:
A combined operating and communication software offering unique capabilities for
slave / host applications.
1/ The customer’s end user or distributor could write code and
insert images to add in their own functionality with a text editor.
2/ The
program code could be updated or expanded by the host system using ASCII text
over a serial link.
3/ The product should be license free and use simple
development tools.
4/ The customer can create his own large images and
control them like fonts.
5/ The SD card should be able to stream video and
audio with the minimum of user programming.
6/ An existing host software
requires only limited changes to upgrade a display from 4X20 LCD to a full
colour TFT.
7/ The module has the intelligence to operate as a host and the
compact command language to act as a high speed slave.
8/ The number of
commands should be minimized by using 'overloading' and provide a higher level
of functionality than C functions.
9/ The parameters for interfaces and
screen entities should be held in styles similar to HTML.
10/ The
application development time should take days or weeks rather than
months.
11/ If the software engineer leaves the company, it is relatively
easy for the engineering manager to amend the program.
These reasons may not be key to your application, but we believe it
does offer new product opportunities.
High Level Object Oriented
Commands
The module has
an integrated compiler and debugger so that users can write the high level
object oriented language commands in a text file or send via an interface to
develop their application. Although pictures and fonts can be loaded via an
interface, it is best to store these on an SD card or transfer via USB from on a
PC. The multi faceted commands are divided into 4 groups as shown below.
You
may be thinking how can 25 commands operate a host system, so lets take a look
at the LOAD command. It can perform the equivalent language functions of
strcpy, strcat, format, inp, outp and a page collation function. Please study
our application example code for an understanding of this compact
language.
|
library &
system |
page &
visibility |
draw on
page |
functions |
| FPROG:Load Menu/Img to Flash |
PAGE: Create a page of entities |
POSN: Position cursor on page |
FUNC: Create a function |
| LIB: Load Image/Font to RAM |
STYLE: Set parameters |
TEXT: draw text on page |
VAR:
Create a variable |
| INC:Include a sub file |
SHOW: Show a page or entity |
DRAW: draw box circle line graph |
IF ?
: Conditional test-true/false |
| RUN:Call function or user code |
HIDE: Hide a page or entity |
IMG: draw image on page |
LOOP: Repeat commands |
| RESET:Reset system, NAND |
DEL: Delete entity from Library |
KEY:create touch or external key |
CALC: Calculation and string edit |
| ;; Refresh current page |
LOAD: Copy and format pages, strings, interface and data
|
|
WAIT: Set delay period |
| ; Terminate command |
INT: Set an interrupt |
Styles make
your Application Consistent
All
entities and buffers use parameters stored in a Style similar to HTML web pages.
These are extensive and define colours, entity types, buffer size and interface
parameters like baud rate, clock edges and data format. Styles can be embedded
in parent styles to reduce repetition and simplify changes.
Screen Page
Creation and Control
Pages can be smaller than the screen for pop up
help menus, status information and lists. Buttons can be varying size, with
radio, rectangle or check box style with special types for navigation actions.
The cursor position command allows relative or absolute positioning for reduced
instructions during page layout. Entities can be updated by incoming host
commands and their associated functions can run all the time or only when the
entity or it’s page is visible. When a text is numeric, it can be compared,
incremented or decremented or form part of an equation using the CALC command.
Buffers or variables can be created for interfaces, on-board memory, the SD
Card, timers, counters and text. Hex code can be included in text variables when
prefixed by \\.
When creating your page structures and functions in a file,
// prefixes user comments.
Uploading your Menu Structure, Functions
and Images
Data received from interfaces or flash memory is processed
and stored in RAM libraries for high speed access to create or refresh pages and
entities. Every entity has a text name for easy reference by future update
commands.
In a
similar way to a PC, your software could be permanently retained on an SD card
and auto loaded at Power On or saved in internal flash by transferring it from
an SD card or uploading it via an interface port. SD cards of 1G size and SDHC
cards of 4G, 8G, 16G and 32G size are supported. 2G SD cards are not supported.
If an SD Card is used, the module will look for a file called
‘TU480A.MNU’ which will reference all other menu or image files. This may be
your only menu file with all functions included. It would have a header similar
to the example below to copy other files on the SD card to the internal flash
memory. See the 'example projects' section
RESET(LIBRARY);
FPROG;
LIB(BACKIMAGE,”SDHC/backmain.bmp”); //load background
picture into the onboard flash
library
LIB(STARTIMAGE,”SDHC/startbut.bmp”); //load start
button into the onboard flash library
…….. FEND;
Entities can be
changed via the user interfaces by direct reference to there name or style with
version v44
firmware.
Examples:
LOAD(homestyle.back,BLUE”);
change the background colour of the page called homepage to
blue
LOAD(rs2.set,“96e”); change the rs232
baud rate to 9600 baud with even
parity
LOAD(GenText.font,“40X56Kata”); change font size of
all text using style GenText
|
