Platform support for new CellularInterface in UBLOX_C027 and UBLOX_C030_U201. #4337
Conversation
|
Do you plan to add support for CellLocate? |
|
Yup, though that doesn't need to go into mbed-os, there will be a separate Mercurial library providing support for HTTP as well as CellLocate. |
|
Could you change the title to remove the |
RobMeades
changed the title
|
@theotherjimmy : done. |
|
Thanks! Looks great. |
|
Do I understand it correctly?
|
CellLocate is entirely AT based, so it doesn't actually require anything at all, other than a base class which instantiates the AT parser. EDIT: my mistake, checking again it does require an "AT DATA" -style connection to have been established previously so yes, it does require the AT DATA flavour.
It presents a sockets interface, both UDP and TCP, exactly as LWIP does.
Not tested yet but, provided DTLS makes no calls around the sides of the absolutely standard sockets interface, it should work in exactly the same way as it does with LWIP. You'll be somewhat challenged for RAM on C027 of course. |
|
I've update this pull request to align with the latest changes in #4119. The submits are now all a bit of a mess, please advise how you would like me to proceed. |
|
@RobMeades Can you please rebase again ? There was a PR merged ahead of #4119 that introduced changes in lwipopts.h. #4119 is now updated. |
|
Done. Test results, in case anyone needs them: |
|
Current mbed-client doesn't seem to work with the AT_DATA flavour For some reason, this palStatus_t pal_plat_getAddressInfo(const char *url, palSocketAddress_t *address, palSocketLength_t* length)
{
palStatus_t result = PAL_SUCCESS;
SocketAddress translatedAddress; // by default use the fist supported net interface - TODO: do we need to select a different interface?
result = s_pal_networkInterfacesSupported[0]->gethostbyname(url, &translatedAddress);
if (result == 0)
{
result = socketAddressToPalSockAddr(translatedAddress, address, length);
}
else // error happened
{
result = translateErrorToPALError(result);
}
return result;
}
ends up here nsapi_error_t UbloxCellularDriverGenAtData::socket_listen(nsapi_socket_t handle,
int backlog)
{
return NSAPI_ERROR_UNSUPPORTED;
}
while the PPP flavour ends up here (as expected) nsapi_error_t NetworkInterface::gethostbyname(const char *name, SocketAddress *address, nsapi_version_t version)
{
return get_stack()->gethostbyname(name, address, version);
}
|
|
Interesting: I thought |
|
What's also interesting, with PPP, socket_listen() doesn't actually get called |
|
@RobMeades Yes that is right, socket_listen() is purely used for TCP server type sockets. I can't think of any reason that gethostname() would fallback to socket_listen() somehow. That would be absurd. I have not seen your code yet, but I'm sure your resolving DNS using AT command and hence providing nsapi_error_t NetworkInterface::gethostbyname(blah, blah). If not, then there is problem here. |
|
Yes, |
|
@RobMeades @amq It could be setsockopt() or getsockopt(). A quick look at PAL code, |
|
I can implement |
|
@RobMeades I don't really know if this is a requirement. I don't have PAL code base to check the usage. @JanneKiiskila Do you have any idea where client cloud would use PAL layer abstraction of setsockopt() getsockopt() ? |
|
@RobMeades here is the test code: https://github.com/amq/mbed-os-example-client Compiles for UBLOX_C027 and UBLOX_C030_U201 (with a separate For a full functionality, you'd need to get the |
|
Looks like it's not setsockopt() or getsockopt(), at least breakpoints don't trigger there. Here is a call trace: |
|
@avolinski can give a hand with PAL issues. |
|
Update: looks like this is simply down to ordering of the inherited classes in |
|
@RobMeades Thanks for the PR. Also, we recommend our contributors follow Chris Beam’s seven rules of great commit messages to keep the commit history clear. We find the commit.template feature particularly helpful. When you refresh this PR, could you please match this format by shortening the subject line and changing it to the imperative mood? For example, you could change it to "Implement new CellularInterface in UBLOX_C027, UBLOX_C030_U201" Thanks for your contributions. |
|
@RobMeades What is the status of this ? |
|
It's because the code came from startup code where you could not use DigitalIn etc. Easily changed if you prefer it that way. |
|
Hmm, actually maybe not, trying to include |
|
The point is the Ublox cellular library should have these, not a .c hal driver mbed.h in the hal is very bad idea. Where is the cellular-library, I could make comments there |
|
I was following the pattern established for C027 in #4119 ( |
|
The other thing to bare in mind is that both C027 and C030 are cellular boards. Without cellular they have no meaning. Having their "on" switch inside their target code in FYI, all the example code and libraries are in the u-blox team depot here. |
Right but this isn't necessarily right. Boards compose with libraries. The APIs for IO support static initialization for all needed modes. This is where gpio_ex sutff came from in 2013. The cellular library should be able to handle the IO for the modem and the PPP communication. I dont see why its needed in 2 places. |
|
It is in one place: with the target CELLULAR board where it makes sense, the on-switch API for the board. That way it can be used by As you can probably tell, I'm kinda losing my patience with this now. Please tell me how you would like the cellular on/off-switch implemented, provided that:
|
|
How does a K64F use the Ublox cellular library? Can you share a link to where this work is? |
|
I believe you're talking about the cellular shield from Embedded Artists. That re-uses the C027_Support library. When compiled for C027 and with an on-board modem, |
|
Right, but what if I have a K64F not a C027? |
|
That's entirely up to them, the u-blox code does not provide a way to power up and down their shield, it only calls the hooks into the on/off functions for the C027 board in mbed; see around line 2285 here. |
|
@sg- I will try to clear the air here once again. If you have a K64F board and an Embedded Artist shield, you will inherit either from UARTSerialInterface or PPPCellularInterface depending upon your needs and you will override modem_init(), modem_power_up(), modem_power_down(), modem_deinit() APIs. That's the model which should be followed. It is clearly documented in the API docs. |
|
Please read the documentation: https://github.com/ARMmbed/mbed_OS_API_Docs/blob/5.5/docs/APIs/communication/cellular.md |
|
/morph test |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
It seems the case 4 is the model that's best fitted (need some wordsmiths here). https://github.com/ARMmbed/mbed_OS_API_Docs/blob/5.5/docs/APIs/communication/cellular.md#providing-module-modem-api |
|
@sg- Yes, absolutely spot on. If they have a modem on a shield, and target it let's say K64F, Case 4 applies plus Case 1 or 2 depending upon their use of AT only or PPP mode. |
|
@sg- Are you happy with this change set? |
|
The PR looks good to me. |
This change implements the platform support which allows both the mbed-os OnboardModem and the u-blox PPP and AT data drivers to be used with both the u-blox C027 and u-blox C030 platforms.