Build and Porting Information  
 
General Information
 
The Front End Module is designed to operate as a services layer module within an embedded environment . MSVC++ 6.0 Professional projects are supplied to allow PC based script and application development . The Front End Module has been constructed in ANSI C and can be easily ported to embedded environments . ANSI C based Object Oriented techniques have been used and the code can be easily converted to C++ .
 
The Front End Module is supplied as source code files . The Module is made up of 109 components and their associated header files . In addition a demonstration application component and associated files are supplied . Also the associated MSVC++ 6.0 Professional project files are supplied . A total of 367 files comprising 10.379MB of source code , project files and documentation are supplied as a zip file . In addition a script file compiler project consisting of 95 core and demonstratioin files is supplied - as a zip file .
 
// comment prefixes have been used . Many C compilers have a switch that allows this commenting prefix to be used . These have been left in as there are various coding standards used with C commenting . The use of the // pattern allows the comments to be easily searched for should changes be required . This is easily accomplished using an editor macro based search and replace operation .
 
The Front End Module is processor , operating system and platform independent . It can be used in conjunction with an RTOS or a COS or stand alone . It is supplied with a basic Co-operative Operating System .
 
Module Size
 
Without application code , Windows level device drivers or scripts the Front End module is approximately 355 KB in size . This is , however , dependent on the type of processor being used and on the efficiency of the optimisation of the compiler .
 
A full set of conditional compiles are provided to allow the features to be compiled in or out . These allow the build size to be reduced to the minimum required . At it's smallest it is approximately 48 KB . This means that The Front End Module can be used as a standardised front end across your company's range of products - from the simplest to the most sophisticated .
 
Typically 384 KB of ROM or Flash PROM should be assigned to the module , the GDI and the application scripts .
 
When comparing the Front End Module against user interfaces constructed with printf statements etc. the size of the Front End Module is the same or less . A simple mobile phone will have approximately 512KB of code . Of this the user interface ( using printf statements etc. ) takes up in excess of 256KB . Higher end mobile phones have typically 1.5 to 2 MB of code with the user interface taking up at least 512 KB . Devices such as mobile phones and digital T.V. set top boxes have the situation where with each generation the size of the user interface increases greater than the increase in complexity - ie. the size increases not in a linear manner but more in an exponential manner . Using the Front End Module the increase in size can be maintained in a much more linear manner and greatly minimised in size .
 

Designing a User Interface using printf and getch statements ( as opposed to using the Module ) results in the following :-

  1. a large amount of object code associated with each printf statement .
  2. a user interface whose code is very specific to the user interface design .
  3. a user interface that is cumbersome in design and limited in operation .
The more that the User Interface is able to handle sophisticated user interface designs the more general it has to be in it's basic design . This is where the Module comes into it's prime . The Module is fully generalised in it's design . As such the specific user interface design is just contained in a few compact binary coded scripts . It avoids all the problems associated with bulky and clunky application specific user interfaces .
 
Speed of Operation
 
The speed of operation is primarily determined by the Display Device Driver - GDI . It is important that this is kept as simple as possible and as close to the hardware as possible . It is also important that the fastest possible techniques are used . The rest of the software of the Front End Module will operate at a high speed .
 
Memory Usage
 
The RAM memory usage is ultimately dependent on the type and number of objects displayed on the screen . It is also dependent on the size of the data . Typically 16 to 32 KB of RAM should be assigned to the module . When the Module executes - displays - scripts it creates script objects and associated display objects ( LocalData , GlobalData , DataField , Button , Repeat , Choice etc. ) . As such it is fairly memory intensive but this is needed to provide the features and capabilities required . The code , however , has been constructed to minimise memory usage . As such , for example , where scripts containing objects - such as Buttons - are multiply executed - using instructions such as Repeat or Page - the subsequent objects use an ' abreviated ' set of parameters - where the core parameters are made dependent on the initial object instantiation .
 
Heap Memory Usage
 
Heap usage is carried out using macros . These can be defined to operating system specific function calls . They can also be directed ( by a conditional compile switch defined in System.h ) to heap check functions - supplied in the HeapCheck component .
 
An exit function has been put in - FrontEnd_ShutDown . This ensures that all objects are removed from the heap . No memory leaks are being detected .
 
Compilation Issues
 
The Module is easy to compile using a broad range of compilers .
 
Pragmas
 
With two exceptions - please see below - no pragmas are used . No processor or platform specific pragmas are used . No processor or platform specific code is used . The code is fully portable and - with the exception of the device drivers - is fully platform independent .
 
Warnings
 
The Front End Module contains C++ // style comment prefixes . Most ANSI C compilers have a switch to accept this form of comment prefix . If required these can be easily changed over to ANSI C style /* comment prefixes and */ comment suffixes by using an editor based macro - ctrl shift R in MSVS \ MSVC++ . If the Module is compiled in MSVC++ with the /Za ( compile using strict ANSI C rules ) compile switch enabled a " warning C4001: nonstandard extension 'single line comment' was used " warning message will be generated on the first occurrence of the // style comment prefix in each file . The pragma - " #pragma warning( disable : 4001 ) " - has been placed in the System.h file to switch this off in MSVC++ builds where the /Za compile switch is used . This is only required in MSVC++ builds and , as such , a Windows based conditional compile switch has been placed around it .
 
Because The Front End Module uses tables to access component functions - eg. script commands are used to index component and component function tables to call the associated command handler functions - there are many situations where there are function parameters that are not used . When undertaking a Level 4 compile MSVC++ will generate a - " warning C4100: ' ... ' : unreferenced formal parameter " - message . The pragma - " #pragma warning( disable : 4100 ) " - has been placed in the System.h file to switch this off in MSVC++ builds . This is only required in MSVC++ builds and , as such , a Windows based conditional compile switch has been placed around it . The Module compiles without any other warnings .
 
These pragmas do not affect the physical compilation of the code . They only relate to warnings . As such they do not affect the portability of the code - the code is fully portable .
 
Other Issues
 
The Module does use nested variable declarations . These are declared within macro definitions . These can be moved out of the definition bodies and placed at the start of the function body . MSVC++ , with the /Za switch ( strict ANSI C compliance compilation ) enabled , compiles these without any warnings . These modifications , if required , are relatively straight forward .
 
The ability to handle nested variable declarations is primarily a C++ feature . Most current C compilers also compile C++ code . C++ compilers are available for a wide range of processors . As such this is usually not an issue .
 
Porting
 
  All that's required for porting is an integration engineer to :-
 
  1. Attach the GDI ( display device driver ) to the Front End Module . If a supplied GDI is not being used the engineer will have to construct the GDI . Basic functionality is supplied within the Display Device Driver component - it's just a matter of adapting these functions and adding in any extra features and customised rendering required . The GDI functions required are only a basic set of physical level functions . Most of the low level functionality is handled within the Module .
  2. Attach the Front End Module to the Operating System - including the keyboard and mouse and the file services . Interface functions , definitions and macros are provided .
  3. Ensure that the RTL functions are in place . Also ensure that any malloc and free substitutions required are put into the macro definitions . The RTL function calls are macro'ed .
  4. Carry out general platform checks - ensure that everything is up and running as intended . The Module is extensively instrumented .
The total porting time should take a couple of days maximum . If further customisation is required this will require further time to be allocated . It's not uncommon for projects or project variations to have specific rendering style requirements . These are handled within the GDI . The only part of the GDI development that may take extra time is the rendering of fonts - where this requires a font rendering engine to be developed . GDI's can be readily obtained and easily attached to the Module .
 
Porting Support
 
We will , providing the cost is proportionate , purchase a copy of the compiler that you are using and will ensure that the Module compiles ok. on the compiler .
 
User Interface Development
 
Once the Front End Module has been installed all that is required is the design of the user interface . This generally takes the following steps :-
 
  1. A specification - either formal or informal - is drawn up describing what is to be displayed on the screens where . This includes items such as specific messages , input fields and buttons .
  2. The coding of the screens - the writing of the scripts - is then carried out . The scripts are either compiled using the Application Scripts project or are compiled as part of the Application code . If a script library is required - to specify the design of common objects - such as menus and combo boxes - this is also constructed .
  3. The Application data and functions along with the Object Tables are constructed .
  4. The script file is then installed in the file area of the platform . Alternatively the scripts can be compiled in as part of the platform build . The OS interface to the Script Files is to obtain the location of the Script File - whether this be in code memory , Flash PROM memory or be loaded onto heap memory .
  5. The Application functions along with the Front End Module and the Operating System are then installed in the code area of the platform . The Application data and functions are linked to via the Object Tables . The Object Tables are mirrored in the scripts by the GlobalData instruction . This ensures that data altered in the User Interface is set to the corresponding value in the Application . Likewise corresponding Application functions are called in response to actions on the User Interface .
  6. The User Interface is then tested - the screens should display correctly and global data inputted should set corresponding data in the Application and any associated functions should be executed .
The total development time is dependent on the complexity of the User Interface . It will , however , be considerably less than designing the interface using other means . It's not uncommon for the initial User Interface to be designed in a week . Further as a project is evolved through subsequent versions and as changes and variations are put in place it's User interface will be very easily and quickly updated . IE. instead of development times for subsequent versions rising exponentially - due to complexity on complexity - they will always be retained at the minimum - due to the separated nature of the User Interface design from the Front End Module and the Application and due to the extensive features supplied by the Front End Module .