Starts splitting Greentea test suites to TCP and UDP suites and adds
more test cases like
tcpsocket_echotest_burst
tcpsocket_echotest_burst_nonblock
tcpsocket_endpoint_close
tcpsocket_recv_100k
tcpsocket_recv_100k
tcpsocket_recv_timeout
tcpsocket_send_timeout
tcpsocket_thread_per_socket_safety
udpsocket_echotest_burst
udpsocket_echotest_burst_nonblock
udpsocket_recv_timeout
udpsocket_sendto_timeout
- Move CRC polynomial enum into HAL layer, so it's accessible from platform
implementations
- Add enum to CRC class to indicate which mode the CRC class should use:
HARDWARE, TABLE, or BITWISE
- Add calls to HAL Hardware CRC API to each of the compute functions when the
class is in HARDWARE mode.
- Add missing constructor call to template constructor, and remove const from
delegating constructor.
Define the HAL API header for the Hardware CRC module. This set of functions
allows hardware acceleration of a subset of CRC algorithms for supported
platforms by providing access to the hardware CRC module of certain platforms.
The API is defined as four separate functions:
- hal_crc_is_supported(polynomial)
Indicates to the caller if the specific CRC polynomial is supported.
- hal_crc_compute_partial_start(const uint32_t polynomial)
Initializes the hardware CRC module with the given polynomial.
- hal_crc_compute_partial(*data, size)
Writes an array of bytes to the CRC module to be appended to the calculation
- hal_crc_get_result()
Applies the final transformations to the data and returns the result to the
caller.
Long lines like this would have parameters misaligned but shorter lines would be OK.
```
void LoRaMac::check_frame_size(uint16_t size)
{
uint8_t value = _lora_phy.get_max_payload(_mcps_indication.rx_datarate,
- _params.is_repeater_supported);
+ _params.is_repeater_supported);
+
+ _lora_phy.a(_mcps_indication.b,
+ b.is_repeater_supported);
```
With this option (applied to the code above), we get
```
@@ -319,6 +319,9 @@ void LoRaMac::check_frame_size(uint16_t size)
uint8_t value = _lora_phy.get_max_payload(_mcps_indication.rx_datarate,
_params.is_repeater_supported);
+ _lora_phy.a(_mcps_indication.b,
+ b.is_repeater_supported);
```
Both are aligned the same. However there is a limit of astyle - 120 columns for this.
We do in most cases lines from 80 to 120 as suggested in our code lines thus this should
be good.
This was a bug in our configuration. Earlier versions of our style did not
specify this option. We found out for some code in our codebase that it was
changed because of the setting.
An example:
```
case: {
// code here
}
//would be changed to
case: {
// code here
}
```
The first one is correct and do not need to be indented (it's enough switch is
indented).
General stability improvements are performed.
A flag is added if a Class C RX2 window is open.
We shouldn't open it again if its already opened.
TX_CRYPTO_ERROR is renamed to CRYPTO_ERROR.
Keeping TX_CRYPTO_ERROR for backwards compatibility.
In Class C, rx timeout does not take place for RX2 windows, so if we have
not received anything, we would be retrying but if the no. of retries are
maxed out, and we have not recieved anything yet, we need a mechanism to
tell the upper layer that this has happened.
rx_abort() was sort of dead code as it was doing essentially nothing.
It might have actually meddled with the state machine if it was hit by
invoking on_ack_timeout_timer_event().
State machine and corresponding processors now take care of the ack timeout,
retries and all other bits, so we don't need abort_rx().
MCPS confirmation should be filled with the current number of retries
if the ack is not recieved for a CONFIRMED message.
Ack retry number needs to be incremented after the retry is made not before
that.
A few traces are added at the crucial junctions of the code just to tally with
the conceptual flow for debug purposes.
Application can use cancel_sending() API to stop any outstanding, outgoing
transmission (a TX which is not already queued for transmission). This can
potentially enable use cases where the application could cancel a transmission
and go to sleep if the backoff period is long enough rather than waiting for
the transmission to happen.
This API enables the application to get hold of remaining time after which
the transmission will take place. User can query the backoff time whenever
there is a packet in the TX pipe. If the event for the backoff expiry is
already queued, the stack does not provide backoff metadata.
An API is added to fetch any meta-data available after a succesful
transmission. The stack will make the meta data available after the
TX interrupt is processed. User can get the tx meta data after receiving
TX_DONE event.