Converting BGS5 Project to EHS5 project | Telit Cinterion IoT Developer Community
October 20, 2017 - 7:57am, 3818 views
I have developed my project for BGS5 till now.
Now, because of 3G requirements, we want to create a 3G variant of this product. There will be 2 version of the same product. 2G (low cost) and 3G version. We want everything to be same/identical except network speed.
For this purpose, I want to pass my existing project into EHS5 module.
Is there a guide document for this process? What are the things to care and to change?
Is it possible in Eclipse easily changing the Device
from IMP_NG_BGS5_REMOTE1 to IMP_NG_EHS5_REMOTE1
and don't need any other thing like create new project, copy source files to new project, add jars etc..
I mean everything will be same, only device will be changed from somewhere in Eclipse? Like a configurational change.
Gemerally from the Java API and AT commands perspective the products are very similar so it should not be a big problem to switch from one to another.
In Java API I believe that nothing should chanhe. For AT commands you need to be careful because thre may be some differences in some commands (especially some hardware related configuration) but that also should not affect your project much.
The MIDlet built for BGS5 would probably run on EHS6 also.
But you should change all the libraries to those from EHS6 package so you need at lease the WTK folder for EHS6. If you have EHS6 software installed you should also be able to change the device in the project configuration - you should do that if you want to run/debug the application form your IDE.
Thanks for the answer.
I have installed EHS5 WTK to my pc. EHS5 device added in Eclipse.
I will carry out some tests with EHS5 this week.
Is there a document related to BGS5-EHS5 differences or about deploying a BGS5 project to EHS5?
There's no such document. There is only a chapter in the Java User's Guide about the differences to TC65i which was the previous Java module.
But these two are nearly identical form Java development perspective. AT commands set is also nearly the same - EHS6 supports 3G and BGS5 not, there is also a difference in "Serial/Interface/Allocation" and maybe something more.
A question at this point:
Java API of Cinterion related to ATCommand cwmlib_1.0.jar size is different for BGS5 and EHS5.
EHS5's cwmlib_1.0.jar size: 45.451 byte
Path : C:\Program Files (x86)\Cinterion\CMTK\EHS5\WTK\resources\cwmlib_1.0.jar
BGS5's cwmlib_1.0.jar size: 42.731 byte
Path: C:\Program Files (x86)\Cinterion\CMTK\BGS5\WTK\resources\cwmlib_1.0.jar
Does it mean, there is an implemetation difference between two?
Is it an important factor?
BGS5 and EHS6 modules are similar from the top layer software interfaces perspective (Java API and AT commands) but they have different chips (which can be seen fro the outside as BGS5 is smaller) and separate firmware releases. So there may be some differences inside the cwmlib implementation. But still from the outside (user interface) there should be no difference.
I didn't notice the size but I can say that code executes in EHS5 faster than BGS5. It is probably because of different chip.
At jvm level, there could be implementation differences since hardware is different. But at user interface level, I expect high level java code to be same. You know, platform indepence property of Java requires that. But if cwmlib_1.0 java code carries out low level java native interface operations, maybe size can be different. I don't know this part too much. (cldc_1.1.jar, impng_1.0.jar, jsr75_1.0.jar, jsr177_1.0-crypto.jar, jsr280_1.0.jar are all at same size for BGS5 and EHS5)
Then, can I use cwmlib_1.0.jar of EHS5 WTK for BGS5 and vice versa? If not, I will have to change cwmlib_1.0.jar of Eclipse project at each compile and jar package creation. I want to hold one project alive, do not want to fork it as 2 project.
As there are dedicated libraries for each module and even though the project built for one module may even work on another, it would still be the most safe aproach to use the dedicated libraries for each version. I'm not the developer of these libraries and don't know the implementation details. But as you have written there are native methods calls inside. And these methods may be different and may require slightly different impementation. The user interface should be the same. The software for these two products is maintained as separate projects so it is also possible that some changes can be made for one of them only.
You may also create some build scripts to automate the building process for two platforms.