Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Even the BREW platform is considered as Object oriented by providing a set of well defined Interfaces like COM (Component object model) on the windows system, the API it provided is NOT.

For many C++ programmers, it is annoying to keep using macros, such as ISHELL_CloseApplet( m_pShell,0) to access the interface, instead of the more natual way: m_pShell->CloseApplet(0).

Writing BREW Extensions is also hard. It is not an easy task to create our own interfaces that extend the existing interfaces.

A free project called lightblue seems to have solved all this issues.

All BREW Interfaces are now abstract C++ classes which could be accessed like any other C++ classes. Extending a BREW Interfaces is also as easy as extending an ordinary C++ classes.

Notes:

lightblue currently supports GNU ARM Compiler and BREW SDK 2.1.3 and 3.1.4.
ADS ARM Compiler is not supported but will be supported in the future version.

This is the "Hello World " example from the lightblue project:
================================================
#include "brewpp_runtime/brewpp.hpp"
#include "helloworld.bid"
class CHelloWorld:public CDefaultBrewApplet
{
public:
enum{CLS_ID = AEECLSID_HELLOWORLD };
CHelloWorld(CDefaultBrewModule* mdl):CDefaultBrewApplet(mdl){}
virtual boolean BREW_CALL_CONV HandleEvent( AEEEvent eCode,uint16 wParam, uint32 dwParam);
;
boolean BREW_CALL_CONV CHelloWorld::HandleEvent( AEEEvent eCode,uint16 wParam, uint32 dwParam)
{
const AECHAR szText[] = {'H','e','l','l','o',' ','W','o', 'r', 'l', 'd', '\0'};
switch (eCode)
{
case EVT_APP_START:
m_pIDisplay->DrawText(AEE_FONT_BOLD,szText,-1, 0,0,NULL, IDF_ALIGN_CENTER | IDF_ALIGN_MIDDLE);
m_pIDisplay->Update(false);
return(TRUE);
case EVT_APP_STOP:
return(TRUE);
default: ; // do nothing.
}
return(FALSE);

extern "C" int AEEClsCreateInstance(AEECLSID ClsId,CDefaultBrewModule *pMod, void **ppobj)
{
*ppobj = NULL;
if(ClsId == CHelloWorld::CLS_ID)
{
*ppobj = (void**)new CHelloWorld(pMod);
return(AEE_SUCCESS);
}
return EFAILED;

===============end of code =================================

This is the "Hello World " example from the lightblue project:
================================================
#include "brewpp_runtime/brewpp.hpp"
#include "helloworld.bid"
class CHelloWorld:public CDefaultBrewApplet
{
public:
enum{CLS_ID = AEECLSID_HELLOWORLD };
CHelloWorld(CDefaultBrewModule* mdl):CDefaultBrewApplet(mdl){}
virtual boolean BREW_CALL_CONV HandleEvent( AEEEvent eCode,uint16 wParam, uint32 dwParam);
;
boolean BREW_CALL_CONV CHelloWorld::HandleEvent( AEEEvent eCode,uint16 wParam, uint32 dwParam)
{
const AECHAR szText[] = {'H','e','l','l','o',' ','W','o', 'r', 'l', 'd', '\0'};
switch (eCode)
{
case EVT_APP_START:
m_pIDisplay->DrawText(AEE_FONT_BOLD,szText,-1, 0,0,NULL, IDF_ALIGN_CENTER | IDF_ALIGN_MIDDLE);
m_pIDisplay->Update(false);
return(TRUE);
case EVT_APP_STOP:
return(TRUE);
default: ; // do nothing.
}
return(FALSE);

extern "C" int AEEClsCreateInstance(AEECLSID ClsId,CDefaultBrewModule *pMod, void **ppobj)
{
*ppobj = NULL;
if(ClsId == CHelloWorld::CLS_ID)
{
*ppobj = (void**)new CHelloWorld(pMod);
return(AEE_SUCCESS);
}
return EFAILED;

===============end of code =================================

This is the example that creates an BREW Extension:
==================================================
#include "extension.h"
#include "brewpp_runtime/brewpp.hpp"
#include "AEEStdLib.h"
class CTestExtensionImp:public CBaseImp
{
public:
CTestExtensionImp(CDefaultBrewModule* pmod)
:m_pIModule(pmod)
{
if(m_pIModule)
{
m_pIModule->AddRef();
}
STRTOWSTR("!!! Hello extension !!!",m_Msg,sizeof(m_Msg));
}
override const AECHAR* BREW_CALL_CONV getString()
{
return m_Msg;
}
override ~CTestExtensionImp()
{
if(m_pIModule)
{
m_pIModule->Release();
}
}
private:
CDefaultBrewModule* m_pIModule;
AECHAR m_Msg[32];
;
extern "C" int AEEClsCreateInstance(AEECLSID ClsId,CDefaultBrewModule *pMod, void **ppobj)
{
*ppobj = NULL;
if(ClsId == CTestExtensionImp::CLS_ID)
{
*ppobj = (void**)new CTestExtensionImp(pMod);
return(AEE_SUCCESS);
}
return EFAILED;

==============end of code ================================

This is the example that creates an BREW Extension:
==================================================
#include "extension.h"
#include "brewpp_runtime/brewpp.hpp"
#include "AEEStdLib.h"
class CTestExtensionImp:public CBaseImp
{
public:
CTestExtensionImp(CDefaultBrewModule* pmod)
:m_pIModule(pmod)
{
if(m_pIModule)
{
m_pIModule->AddRef();
}
STRTOWSTR("!!! Hello extension !!!",m_Msg,sizeof(m_Msg));
}
override const AECHAR* BREW_CALL_CONV getString()
{
return m_Msg;
}
override ~CTestExtensionImp()
{
if(m_pIModule)
{
m_pIModule->Release();
}
}
private:
CDefaultBrewModule* m_pIModule;
AECHAR m_Msg[32];
;
extern "C" int AEEClsCreateInstance(AEECLSID ClsId,CDefaultBrewModule *pMod, void **ppobj)
{
*ppobj = NULL;
if(ClsId == CTestExtensionImp::CLS_ID)
{
*ppobj = (void**)new CTestExtensionImp(pMod);
return(AEE_SUCCESS);
}
return EFAILED;

==============end of code ================================

The lightblue project which provides a pure C++ binding of the BREW SDK now supports BREW SDK 3.1.4.
Please check this post on the forum:
http://brewforums.qualcomm.com/showthread.php?t=11974

The lightblue project which provides a pure C++ binding of the BREW SDK now supports BREW SDK 3.1.4.
Please check this post on the forum:
http://brewforums.qualcomm.com/showthread.php?t=11974

We can use BREW Interfaces as abstract C++ classes Now! No more Macros.
Please check this post on the forum:
http://brewforums.qualcomm.com/showthread.php?t=11974

We can use BREW Interfaces as abstract C++ classes Now! No more Macros.
Please check this post on the forum:
http://brewforums.qualcomm.com/showthread.php?t=11974

according to their website (http://lightblue.tigris.org/) they support Realview ARM Compiler 2.2.
but does this compiler support brew?
has anyone used this lightblue?

according to their website (http://lightblue.tigris.org/) they support Realview ARM Compiler 2.2.
but does this compiler support brew?
has anyone used this lightblue?

I have not used LightBlue Project but RealView 2.2 Supports BREW. I donot see any problem.

I have not used LightBlue Project but RealView 2.2 Supports BREW. I donot see any problem.

I took a look at arm.com and they don't say that ads 2 support brew, only 1.2..
anyone used 2.2 for brew?
what they used to call ADS is now "RealView Development Suite" (RDS)?

I took a look at arm.com and they don't say that ads 2 support brew, only 1.2..
anyone used 2.2 for brew?
what they used to call ADS is now "RealView Development Suite" (RDS)?

yes you are true. i tried to compile but the files failes to run.

yes you are true. i tried to compile but the files failes to run.

yes, since lightblue includes a postlinker called lbmg.exe which is a BrewElf2Mod replacement. This tool understand the specific ELF structure of Realview 2.2 and therefore you can use realview 2.2 to develop brew program

yes, since lightblue includes a postlinker called lbmg.exe which is a BrewElf2Mod replacement. This tool understand the specific ELF structure of Realview 2.2 and therefore you can use realview 2.2 to develop brew program

let me get this straight...
arm and qualcomm says that we can't use 2.2 and you say we can?

let me get this straight...
arm and qualcomm says that we can't use 2.2 and you say we can?

yes, lightblue comes with 6 BREW examples that could be compiled by Realview 2.2 compiler and Run on the phone.

yes, lightblue comes with 6 BREW examples that could be compiled by Realview 2.2 compiler and Run on the phone.

The realview 2.2 compiler seems generates better quality machine code both in speed and space than the old ads 1.2 compiler.
The "Mediaplayer" example in lightblue is the C++ implementation of BREW sdk's "Mediaplayer" example which is written in pure C. The C++ code compiled with rvct2.2 is even several K bytes smaller than the pure C implementation compiled with ads 1.2.

The realview 2.2 compiler seems generates better quality machine code both in speed and space than the old ads 1.2 compiler.
The "Mediaplayer" example in lightblue is the C++ implementation of BREW sdk's "Mediaplayer" example which is written in pure C. The C++ code compiled with rvct2.2 is even several K bytes smaller than the pure C implementation compiled with ads 1.2.

Ronin,
We actually use RVDS 3.0, the latest elf2mod utillity and some internal 'secret sauce' to pump out applications with ~full (no exceptions etc) C++ support. The upgrade front end in RVDS 3 is extremely beneficial.
Lightblue seems interesting, but I dissagree with one of the original thoughts.
'Writing BREW Extensions is also hard. It is not an easy task to create our own interfaces that extend the existing interfaces.'
Thats what programming is all about, gluing things together.... writing wrappers around BREW API calls is pretty easy, and provides you the opportunity to extend their capabilities.
Cheers,

Ronin,
We actually use RVDS 3.0, the latest elf2mod utillity and some internal 'secret sauce' to pump out applications with ~full (no exceptions etc) C++ support. The upgrade front end in RVDS 3 is extremely beneficial.
Lightblue seems interesting, but I dissagree with one of the original thoughts.
'Writing BREW Extensions is also hard. It is not an easy task to create our own interfaces that extend the existing interfaces.'
Thats what programming is all about, gluing things together.... writing wrappers around BREW API calls is pretty easy, and provides you the opportunity to extend their capabilities.
Cheers,

Quote:We actually use RVDS 3.0, the latest elf2mod utillity and some internal 'secret sauce' to pump out applications with ~full (no exceptions etc) C++ support. The upgrade front end in RVDS 3 is extremely beneficial. If you can share the secret to work with RVDS 3.0 for BREW then it will be very helpful to all of us.
Thanks in advance.

Quote:We actually use RVDS 3.0, the latest elf2mod utillity and some internal 'secret sauce' to pump out applications with ~full (no exceptions etc) C++ support. The upgrade front end in RVDS 3 is extremely beneficial. If you can share the secret to work with RVDS 3.0 for BREW then it will be very helpful to all of us.
Thanks in advance.

For the most part you just have to make a stub that'll do a run time address fixup for any non pc relative fixups, globals etc, basically do what BREW doesn't.

For the most part you just have to make a stub that'll do a run time address fixup for any non pc relative fixups, globals etc, basically do what BREW doesn't.

charliex wrote:For the most part you just have to make a stub that'll do a run time address fixup for any non pc relative fixups, globals etc, basically do what BREW doesn't.
Thanks for the replay.
Can you please elaborate what do you mean by "do what BREW doesn't":confused:

charliex wrote:For the most part you just have to make a stub that'll do a run time address fixup for any non pc relative fixups, globals etc, basically do what BREW doesn't.
Thanks for the replay.
Can you please elaborate what do you mean by "do what BREW doesn't":confused:

Well the problem with globals etc in brew is it that the mod file doesn't have any way of fixing up the address of data that are not PC/IP relative ,a class with non static members would be PC relative for instance, a global variable would not.
So normally in an exe file a variables address is stored as a relative offset from 0 or some other constant, then when the program is loaded in memory, the loader runs through all the code and adds that memory location to the relative offsets.

Well the problem with globals etc in brew is it that the mod file doesn't have any way of fixing up the address of data that are not PC/IP relative ,a class with non static members would be PC relative for instance, a global variable would not.
So normally in an exe file a variables address is stored as a relative offset from 0 or some other constant, then when the program is loaded in memory, the loader runs through all the code and adds that memory location to the relative offsets.

Thanks for a that Explination.
But what i want to know is. the ARM site says this Quote:The model for Position Independent (PI) C++ code changed in RealView Compilation Tools (RVCT) 2.0. Therefore, RVCT 2.0 and later is not suitable for developing BREW applications. For BREW development you must use RVCT for BREW 1.2. For more information please visit the 'General BREW FAQ' page from Qualcomm's website: http://www.arm.com/support/faqdev/14109.html But you in your Previous post said "We actually use RVDS 3.0". So i just wanted to know how you managed to get around this problem.
Thanks in advance.

Thanks for a that Explination.
But what i want to know is. the ARM site says this Quote:The model for Position Independent (PI) C++ code changed in RealView Compilation Tools (RVCT) 2.0. Therefore, RVCT 2.0 and later is not suitable for developing BREW applications. For BREW development you must use RVCT for BREW 1.2. For more information please visit the 'General BREW FAQ' page from Qualcomm's website: http://www.arm.com/support/faqdev/14109.html But you in your Previous post said "We actually use RVDS 3.0". So i just wanted to know how you managed to get around this problem.
Thanks in advance.

It means that the later compilers rely more on load/runtime address fixups.
The solution is to use a tool like the author is talking about, the one from qualcomm (which may or may not work with the later format, or write your own.

It means that the later compilers rely more on load/runtime address fixups.
The solution is to use a tool like the author is talking about, the one from qualcomm (which may or may not work with the later format, or write your own.

charliex wrote:It means that the later compilers rely more on load/runtime address fixups.
The solution is to use a tool like the author is talking about, the one from qualcomm (which may or may not work with the later format, or write your own. Sorry but, if i am not wrong you are saying that if i use a tool like one available with bluelight i will be able to use the RVCT 3.0 also. Please suggest me.
Thanks

charliex wrote:It means that the later compilers rely more on load/runtime address fixups.
The solution is to use a tool like the author is talking about, the one from qualcomm (which may or may not work with the later format, or write your own. Sorry but, if i am not wrong you are saying that if i use a tool like one available with bluelight i will be able to use the RVCT 3.0 also. Please suggest me.
Thanks

The definitive answer would be from the lightblue author, but it sounds like it yes.
Its not really a complicated thing to do, its a pretty common problem in embedded systems etc.

The definitive answer would be from the lightblue author, but it sounds like it yes.
Its not really a complicated thing to do, its a pretty common problem in embedded systems etc.

Ooh thanks very much, i will try to compile with RVDS 3.0 if i will face any problem i will ask you help.
Thanks Again

Ooh thanks very much, i will try to compile with RVDS 3.0 if i will face any problem i will ask you help.
Thanks Again

any updates on that, did you manage to use the 3.0 or even the 2.2 compiler?

any updates on that, did you manage to use the 3.0 or even the 2.2 compiler?