Renaming Ublox library for mbed cellular framework

[mudassar-ublox]

Description

Renaming UBLOX target library form "UBLOX_LISA_U" to "UBLOX_PPP" for mbed cellular framework.

LISA is not a cellular technology, it is the physical shape of module. Technology used for cellular test is PPP, So changing name from LISA_U to PPP as suggested by @kjbracey-arm (Kevin Bracey).

Pull request type

• Fix
• Refactor
• New target
• Feature
• Breaking change

[kjbracey-arm]

Fine with the new name, but I think you should probably retain a typedef or simple inheritance with deprecation tag for the LISA_U name, as that's what's gone out for 5.8. This would be a breaking change for an app that was manually requesting that driver.

[cmonr]

Agree with @kjbracey-arm on inheritance with current device name.

@mudassar-ublox If you like, you could add a deprecation warning to the old name targeting 5.9.

[bqam-ublox]

@cmonr deprecated warnings have been added

[geky]

Hello, this isn't the correct way to mark a class as deprecated.

The deprecated attribute needs to be before the class:

MBED_DEPRECATED_SINCE("mbed-os-5.9", "This API will be deprecated, Use UBLOX_PPP_CellularPower instead of UBLOX_LISA_U_CellularPower.")
class UBLOX_LISA_U_CellularPower  : public UBLOX_PPP_CellularPower
{
   blablabla

Otherwise this won't compile on GCC or ARM.
https://github.com/ARMmbed/mbed-os/blob/master/platform/mbed_toolchain.h#L297

[bqam-ublox]

Actually, I put a semi colon at the end of the deprecated warning and it compiled successfully.

Thanks for the correction. I have modified the code now.

[geky]

Oh that's interesting. Although the deprecated message still won't show up.

Thanks for fixing this 👍

[cmonr]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 1586
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6402/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

[mbed-ci]

Test : SUCCESS

Build number : 1375
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6402/1375

[mbed-ci]

Exporter Build : FAILURE

Build number : 1225
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6402/

[cmonr]

ARM license network issue.

Will rebuild once CI gap is available.

[cmonr]

/morph export-build

[cmonr]

/morph mbed2-build

[cmonr]

@0xc0170 Might need you to restart these. Looks like GitHub is ignoring me again..

[0xc0170]

/morph export-build
/morph mbed2-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 1237
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6402/

[0xc0170]

@kjbracey-arm @AnttiKauppila or @TeemuKultala @juhoeskeli please review

[cmonr]

Still holding for reviews.

[AriParkkila]

This is a valid change, but still UBLOX_PPP is not a very good name either...

1. u-blox cellular modules support both PPP mode and internal modem IP stack
2. PPP mode is typically configured with "lwip.ppp-enabled" in mbed_app.json

I want to raise another relating concern here...

Ublox-C027 (and ublox-C030) may have different cellular modules like LISA-C200, LISA-U200 or SARA-G350. From AT command point of view u-blox cellular module variation comes from type codes C (CDMA), U (UMTS) and G (GPRS) and associated platform version such as U2 or G3, so I think good naming could be something like "UBLOX_U2".

Mbed OS detects at compile-time only board target ublox-C027 (mbedls target_id) and it does not know which cellular module type is actually mounted on the board.

The problem is that we can't detect automatically at compile-time which cellular device type is mounted on the board. Is there any?

[bqam-ublox]

@RobMeades please comment

[RobMeades]

@AriParkkila: the plan is that u-blox will maintain a PPP-mode driver, which will work with all our of modems that support PPP mode, and one or more AT-mode driver, which will support these modems and others which have no PPP interface. The first driver will be UBLOX_PPP. the others will be UBLOX_ATxxx, where xxx represents any necessary variations since, in those cases, we know that there are ranges of AT commands that do not fall within 3GPP 27.007. Should there be any need for variations in AT command behaviour for different modems within the single PPP set (unlikely given the very small number of AT commands we are concerned with here), we will detect and deal with that at run-time, by querying the module name, as we do today. For instance, U2 and G3 are identical in all of the respects were are concerned with here and so shouldn't need separate handling.

Is there a reason why the above would not work?

[AriParkkila]

If cellular module variation can be handled at runtime then this is good.

[0xc0170]

@AriParkkila @AnttiKauppila Can you approve/request changes please?