Build and Porting Information  
 
General Information
 
The Front End Module is designed to operate as a middleware 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 C++ . The Front End Module is supplied as dnamic library files - Windows , Linux - and static libraries for full embedded builds .
 
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 .
 

Please Note : the module just requires a basic GDI having the following facilities :-

  1. area blank - filled rectangle .
  2. area fill .
  3. line draw .
  4. frame - rectangle border - draw .
  5. arc and circle draw .
  6. font render .

Some GUI's provide these facilities directly . Some GUI's , however , provide added complexity in between - which can get in the way .

 
Module Size
 
Without application code , Windows level device drivers or scripts the Front End module is approximately 660KB in size . This is , however , dependent on the type of processor being used and on the efficiency of the optimisation of the compiler . Typically 1MB 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 1 to 2 MB of code . Of this the user interface ( using printf statements etc. ) takes up in excess of 256KB . Higher end mobile phones have typically 2 to 4MB 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 or using a standard GUI ( 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 32 to 64 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 . Where multimMedia facilities are being used a larger RAM size would be required - allow 128 to 256 KB .
 
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.hxx ) to heap check functions - supplied in the HeapCheck component . Extensive use has been made of recycling heap memory blocks in order to avoid heap fragmentation problems .
 
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 . It will compile on the MS VS VC++ compiler and on the GNU GCC compiler .
 
Pragmas
 
With one exception - 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.hxx 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 . The code is fully portable .
 
Please Note :- The module is currently being ported onto Linux . It is compiling on the GNU GCC compiler without any warnings .
 
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 provide a free porting service . 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 .
 
Please Note :- The module is continually being upgraded - as such the module will be ported onto other platforms at a future date .
 
Windows Port
 
The module is ported onto Windows using a basic GDI setup . There are currently no multimedia codecs being used .
 
Linux Port
 
The module is ported onto Linux .
 
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 .