Skip to content
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

Release v4.4 #1081

Closed
wants to merge 255 commits into from

Conversation

@g-oikonomou
Copy link
Member

commented Oct 4, 2019

For consistency, please change the merge commit message to "Release v4.4"

atiselsts and others added 30 commits May 10, 2019
This allows our assert() to emulate standard lib behaviour when building with gcc
Provide non-returning assert() implementation
The old code seems to have assumed that the type of UIP_ICMP_BUF was
char* (or equivalent) while in fact it was struct uip_icmp_hdr*.

Thus when computing the address to UIP_ICMP_BUF[sizeof(struct
uip_icmp_hdr)], where sizeof(struct uip_icmp_hdr) = 4, it would
increment the pointer by 4*4 = 16 bytes, and not 4 bytes as would be
expected.
Olav Frengstad
`rtimer_arch_schedule/1`  would cast clock_second as `unsigned short` instead
of `unsigned int` causing scheduling to set wrong interval.

Example:

```c
rtimer_set(&timer, RTIMER_NOW() + CLOCK_SECOND, 0, callback, null);

/* with the original code the following would be ouputted from `rtimer-arch.c`:
 * > rtimer_arch_schedule time 46487236 46466024 in 46466.24000 seconds
 *
 * With fix the following, corrected version:
 * > rtimer_arch_schedule time 46463604 1000 in 1.0 seconds
 */
uip-icmp6: in echo_reply_input, pass the correct icmp payload pointer
Merge master back into develop
Fix the jn516x build system when SDK_BASE_DIR is misconfigured
increase the network build time from 15 to 20 seconds in IPv6 regression tests
Edvard Pettersen
Edvard Pettersen
…c26x2-rev-e

Simplelink CC13x2/CC26x2 Rev. E support
This new constant is mandatorily supported by all radio driver get_value() functions.

It represents the maximum payload the radio driver is able to handle.

This includes the MAC header and MAC payload, but not any tail bytes added automatically by the radio. For example, in the typical case of .15.4 operation at 2.4GHz, this will be 125 bytes (127 bytes minus the FCS / CRC16).

This is the maximum number of bytes that:
  * The MAC layer will ask the radio driver to transmit.
    This corresponds to the payload_len argument of the prepare() and
    send() and the transmit_len argument of transmit().
  * The radio driver will deliver to the MAC layer after frame reception.
    The buf_len of the read function will be at greater than or equal to
    this value. The read() function may not return a value greater than
    this constant.
g-oikonomou and others added 17 commits Sep 27, 2019
Fix cc26x0/cc13x0 watchdog and LPM sleep timers
Add new GPIO, button and LED HAL support to platform Cooja
…d both when LLSEC is enabled or disabled
Implemented Snmp v1 and v2c
TSCH: account for security header in max_payload
fix initialization of link stats
Fix broken rtimer for native
@g-oikonomou g-oikonomou changed the title Release 4.4 Release v4.4 Oct 4, 2019
g-oikonomou and others added 10 commits Oct 4, 2019
Improve read_frame and pending_packet consistency in the cc13x0 prop mode driver
travis: specify Trusty explicitly to avoid Xenial
Add readthedocs status badge
@g-oikonomou

This comment has been minimized.

Copy link
Member Author

commented Oct 11, 2019

Closing until we are closer to the release date and PRs have been merged here. At the moment this is just generating unnecessary and long travis builds

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.