Skip to content

Renaming Ublox library for mbed cellular framework #6402

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Apr 6, 2018

Conversation

mudassar-ublox
Copy link
Contributor

@mudassar-ublox mudassar-ublox commented Mar 20, 2018

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
Copy link
Contributor

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
Copy link
Contributor

cmonr commented Mar 21, 2018

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.

(cherry picked from commit 737609736591d12ea369d5b364d132e7a6367ae2)
@bqam-ublox bqam-ublox force-pushed the cellular_test_target branch from 1e673c8 to eb806b6 Compare March 26, 2018 12:14
@bqam-ublox
Copy link
Contributor

@cmonr deprecated warnings have been added

@@ -35,6 +35,11 @@ class UBLOX_LISA_U_CellularPower : public AT_CellularPower
virtual nsapi_error_t off();
};

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Thanks for fixing this 👍

@cmonr
Copy link
Contributor

cmonr commented Mar 27, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented Mar 27, 2018

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
Copy link

mbed-ci commented Mar 27, 2018

@mbed-ci
Copy link

mbed-ci commented Mar 27, 2018

@cmonr
Copy link
Contributor

cmonr commented Mar 27, 2018

ARM license network issue.

Will rebuild once CI gap is available.

@cmonr
Copy link
Contributor

cmonr commented Mar 28, 2018

/morph export-build

@cmonr
Copy link
Contributor

cmonr commented Mar 28, 2018

/morph mbed2-build

@cmonr
Copy link
Contributor

cmonr commented Mar 28, 2018

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

@0xc0170
Copy link
Contributor

0xc0170 commented Mar 28, 2018

/morph export-build
/morph mbed2-build

@mbed-ci
Copy link

mbed-ci commented Mar 28, 2018

@0xc0170
Copy link
Contributor

0xc0170 commented Mar 28, 2018

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

@cmonr
Copy link
Contributor

cmonr commented Mar 29, 2018

Still holding for reviews.

@cmonr cmonr requested a review from AriParkkila March 29, 2018 06:26
@AriParkkila
Copy link

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
Copy link
Contributor

@RobMeades please comment

@RobMeades
Copy link
Contributor

@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
Copy link

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

@0xc0170
Copy link
Contributor

0xc0170 commented Apr 4, 2018

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

@0xc0170 0xc0170 merged commit f331ac3 into ARMmbed:master Apr 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants