freertos / freertos-cellular-interface-community-supported-ports

FreeRTOS Cellular Interface Community Supported Ports

This repository contains the cellular module ports supported by FreeRTOS community members. We welcome your contribution to expand the catalog of modems.

How to Contribute a Cellular Module Port

1. Fork the FreeRTOS/FreeRTOS-Cellular-Interface repository.
2. Write code for a new cellular module.
   For details, see Porting the Cellular Interface Library to another Modem.
3. Create a new folder for the new cellular module in the root folder.
4. Create a README.md file and place it at the top level of the new module port folder. Ensure theREADME.md describes the following:
   1. Hardware information: Give the reader a cellular module introduction and the steps to setup the hardware environment.
   2. Objectives: Tell the reader a high-level summary of what steps they need to take and how to use this port.
   3. Relevant information: Tell the reader what they should read or take care if they would like to dive deeper.
5. [Optional] If you are contributing a new cellular module with supporting demos, create a new demo in the cellular demo repository and update the README.md in the root folder.
6. Raise a Pull Request (PR). Maintainers and other contirbutors will review your PR. Please be proactive in the conversation and make the requested changes as soon as possible. The code will be merged after the PR is approved.

License

The FreeRTOS Cellular Interface library is distributed under MIT open source license. The code in this repository is licensed under the MIT License. See the LICENSE file.

freertos-cellular-interface-community-supported-ports's Issues

[sim70x0] Clean up socket receive

If I understand the AWS stack correctly, the higher-level libraries (eg. coreMQTT, or the underlying TLS / SSL encryption layers) interface to sockets via the TCP_Sockets interface, which is provided by wrappers to the actual implementation, which can either be

• the FreeRTOS TCP (providing TCP/IP stack on MCU) or
• the FreeRTOS Cellular Interface (reusing the TCP/IP stack on modem)

Current implementations are available here

The FreeRTOS Cellular TCP_Sockets wrapper provides modem-agnostic blocking receive (handled via event groups and data ready callbacks), thereby allowing the modem implementation only needing to support the non-blocking receive (possibly returning less than the requested number of bytes). The Cellular_SocketRecv() API seems to imply such operation. Some ports (eg. BG96) follow this.

The current sim70x0 implementation has implemented a blocking receive via pSimContext->pdnEvent event group, which is then manipulated in the URC handler and various parser functions.

This can probably be removed without effect on the higher layers, simplifying the port.

sim70x0 Direct access of CellularContext

The CellularContext structure will change
FreeRTOS/FreeRTOS-Cellular-Interface#124

this will break the current sim70x0 port, but this is due to the improper direct access of module context.

_Cellular_GetModuleContext should have been used instead.

Parsing of AT+QCSQ command goes wrong in Quectel's BG96

According to Quectels BG96 specification, the modem's response to an AT+QCSQ command can be any of:

"NOSERVICE"
"GSM", <rssi>
"CAT-M1", <rssi>, <rsrp>, <sinr>, <rsrq>
"CAT-NB1", <rssi>, <rsrp>, <sinr>, <rsrq>

The current implementation however always expects the modem's response to come with all for values, even in the case of GSM, which leads to the libraries inability to read the GSM signal strenght.

See Quectels's BG96 AT Commands Manual v2.3, section 6.18: AT+QCSQ Query and Report Signal Strength