This commit changes the name of the requests over the control endpoints
to control requests instead of setup requests. This is a terminology fix
to follow the USB specification more closely as technically only the
first stage of a control request is named setup which contains a setup
packet. The whole transfer is a control transfer.
This enables 'pthread' support on arduino.
avr-libc C90 'time.h' does not include 'sys/types.h' as POSIX expects it.
However, the type previously defined conflicts with the one in
'cpu/atmega_common/avr_libc_extra/include/sys/types.h' when both are
included, so include 'sys/types.h'.
Maybe it should alway be included by 'time.h' but this
would need its specific review.
llvm-ar behaves weidly when creating thin archive. This only manifests
itself when using arduino sketches as these are built from the "bin"
directory.
Specifically, given a directory "m" and an object in "m/obj.o " an
invocation with CWD==m:
```
llvm-ar rcTs ../m.a obj.o
```
Will create a maformed archive. Binutils does not have any issue with this.
The following command, executed with CWD==m/.. works:
```
llvm-ar rcTs m.a m/obj.o
```
The trick used in this commit is to put the source files in a different
directory than the object files and compile from there.
- add init_schedstatistics function to be called after
auto_init, that way xtimer_is init is called before
the first call to xtimer_now
- register schedstatics code as a callback to be executed
on each sched_run()
- Removed stdio_init() from newlib's _init(), as this is too late in the boot
process to allow DEBUG()ing during periph_init()
- Added stdio_init() to the various cpu_init() routines of the ARM CPUs just
before periph_init()
The function insert returns KERNEL_PID_UNDEF now because pthread_create checks for it.
In pthread_create it checks now if thread_create returns a valid pid
before this commit the src address was checked for multicast, but the dst address should be checked. Therefore udp multicast packets would be flooded back to the src as ICMPv6 error, as not all nodes had a UDP receiver registered.
Replaces the special heap command approach of the lpc_common module with a more general heap command approach. Module lpc_common was already removed with PR #2118. PR #2118 integrated cpu/lpc_common code in cpu/lpc2387. With PR #3530 special heap handling for cpu/lpc2387 was replaced by newlib memory management which uses _sbrk_r to allocate chunks from the heap. _sbrk_r uses _sheap and _eheap symbols that are defined in lpc2387.ld and can be used together with mallinfo function for heap statistics.
- Serial.print() and Serial.println() have been extended to support:
- unsigned int
- long
- unsigned long
- The SerialFormat BIN has been implemented
- Serial.println(void) has been added
Rename TMP006 to TMP00x
Add TMP007 sensor support to TMP00X
Change uint8_t reg to uint16_t
Add to doxygen documentation group
Expose compile time configurations
Move defines from .c to .h
Change double to float, because double is not needed
Add TMP007 register information
Generate a module for arduino sketches in a subfolder of BINDIR.
This prevents issues when doing concurrent builds or out of tree build with
readonly sources.
Declare all generated files as `BUILDDEPS` to be re-created after
`clean` on parrallel `clean all`.
When a keepalive timeout occurs keepalive_retry_cnt remains zero,
so when the connection is re-established _on_keepalive_evt will
immediately disconnect instead of actually sending a keepalive ping.
The sequence looks like:
1. _on_connack: start con->keepalive_timer
2. Server does not respond to keepalive pings
3. _on_keepalive_evt: con->keepalive_retry_cnt reaches zero
4. Connection torn down and ASYMCUTE_DISCONNECTED sent to application
5. Application starts reconnection
6. _on_connack: start con->keepalive_timer again
7. First _on_keepalive_evt: con->keepalive_retry_cnt is still zero
8. Repeat from 4.
So this simply resets keepalive_retry_cnt in _on_connack when
the keepalive timer is restarted. It's a new connection, so
resetting the keepalive retry counter make senses regardless.
Signed-off-by: Derek Hageman <hageman@inthat.cloud>
With the increase of the message queue size from 8 to 16 in
946b06e4f0, the default stack became too small.
This changes the stack size to grow with the message queue size.
The cc110x driver has been re-written from scratch to overcome the limitations
of the old driver. The main motivation of the rewrite was to achieve better
maintainability by a detailed documentation, reduce the complexity and the
overhead of the SPI communication with the device, and to allow to
simultaneously use transceivers with different configuration regarding the used
base band, the channel bandwidth, the modulation rate, and the channel map.
Features of this driver include:
- Support for the CC1100, CC1101, and the CC1100e sub-gigahertz transceivers.
- Detailed documentation of every aspect of this driver.
- An easy to use configuration API that allows setting the transceiver
configuration (modulation rate, channel bandwidth, base frequency) and the
channel map.
- Fast channel hopping by pre-calibration of the channels during device
configuration (so that no calibration is needed during hopping).
- Simplified SPI communication: Only during start-up the MCU has to wait
for the transceiver to be ready (for the power regulators and the crystal
to stabilize). The old driver did this for every SPI transfer, which
resulted in complex communication code. This driver will wait on start up
for the transceiver to power up and then use RIOT's SPI API like every other
driver. (Not only the data sheet states that this is fine, it also proved to
be reliable in practise.)
- Greatly reduced latency: The RTT on the old driver (@150 kbps data rate) was
about 16ms, the new driver (@250 kbps data rate) has as RTT of ~3ms
(depending on SPI clock and on CPU performance) (measured with ping6).
- Increased reliability: The preamble size and the sync word size have been
doubled compared to the old driver (preamble: 8 bytes instead of 4,
sync word: 4 byte instead of 2). The new values are the once recommended by
the data sheet for reliable communication.
- Basic diagnostic during driver initialization to detect common issues as
SPI communication issues and GDO pin configuration/wiring issues.
- TX power configuration with netdev_driver_t::set() API-integration
- Calls to netdev_driver_t::send() block until the transmission has completed
to ease the use of the API (implemented without busy waiting, so that the
MCU can enter lower power states or other threads can be executed).
- Removed cc110x driver
- Updated all makefiles
- Kept both board specific configurations and support for it in RIOT's
upper layers, so re-implementations don't need to start from zero
CTRL-C cancels the current line, similar to how getty works.
This is useful if one is using a dumb terminal to communicate with
a node, as it saves having to repeatedly type backspace to discard the
current line. It also helps when connecting to an already running node,
as one does not know what is on the line buffer, the safest thing to do
is to begin by sending a ctrl-C.
This is a suggestion of @benemorius.
Add an implementation that waits for 's' to print 'START' and return.
If 'r' is given is prints 'READY' to allow querying for state.
The help and answered string have to be different to not match the other.
Using puts/getchar was smaller than using `stdio_read/stdio_write` on the
example I tested with `esp32`.
From the gnrc_pktbuf_mark documentation:
It's not guaranteed that `result->data` points to the
same address as the original `pkt->data.
Thus it should be necessary to update the `hdr` pointer.
if xtimer_set spins the callback is executed in the thread context.
comment to explain irq_disable
and when this line could be removed
(when xtimer stops executing the callback funtion from thread context)
If an address was pre-configured by the upper layer its validity is
currently ignored. It is neither checked if the address is on the
interface at all nor is it checked if it is valid.
This change provides a fix for that by checking both facts.
A proper error code is returned if a key with unsupported (either by the implementation or the AES algorithm) length is passed to aes_init.
This fixes Issue #10175
The length field in an MQTT packet carries the _total_ length of the
packet. If it is below 256 (i.e. fits in one byte) only one byte is
used for the length field. If it is larger than that 3 bytes are used,
with the first byte having the value `0x01` and the remaining bytes
representing the length in as a 2 byte unsigned integer in network byte
order. Resulting from that it can be assessed that the check in
`emcutes`'s `set_len()` function is wrong as it needs to be checked if
`len` is lesser or equal to `0xff - 1`. `len <= (0xff - 1)` can be
simplified to `len < 0xff`. For some larger packages this safes 2 bytes
of wasted packet space.
`len` is used with the `memcpy()` to copy the payload to `tbuf`. With a
payload provided that is just long enough to fill `tbuf`, `len += 6`
leads to the `memcpy()` overriding data after `tbuf` (e.g. the
`mutex` that is unlocked right after) and thus resulting in potential
segmentation faults.
Additionally `+ 6` can only be applied if the total packet length is
below 256 (see spec), so `len + pos` is what needs to be provided to the
corresponding send functions instead (`pos` adapts to the header length
of the PUBLISH message).
Unstructured static initializer like { 0 } lead to compilation errors on ESP8266, MSP430 and MIPS. Error messages are:
error: (near initialization for 'queue.event_list') [-Werror=missing-braces]
error: (near initialization for 'queue.waiter') [-Werror=missing-field-initializers]
This change fixes the compilation problem.
Check for the usage of `newlib_nano` module instead of the
`USE_NANO_SPECS` variable.
This allows also benefiting from the `printf_float` and `scanf_float`
behaviour on `arm7` and `riscv` cpus.
- Add SEMTECH_LORAMAC_ALREADY_JOINED ret code for semtech_loramac_join
- Add SEMTECH_LORAMAC_TX_CNF_FAILED ret code for semtech_loramac_send
- Update shell commands to notify when no ACK is received on cnf tx
stm32eth: Move to stm32_common periph
cpu/stm32_periph_eth: Rebase to current master branch
- Update DMA to use new vendor headers
- Update send to use iolist. It looks like the packet headers are now transfered as seperate iolist entries which results in the eth periph sending each header as own packet. To fix this a rather ugly workaround is used where the whole iolist content is first copied to a static buffer. This will be fixed soon in another commit
- If MAC is set to zero use luid to generate one
- Small code style fixes
cpu/stm312f7: Add periph config for on-board ethernet
boards/nucleo-f767zi: Add config for on board ethernet
tests/stm32_eth_lwip: Remove board restriction
boards/common/nucleo: Add luid module if stm32 ethernet is used
tests/stm32_eth_gnrc: Add Testcase for gnrc using the stm32 eth periph
stm32_eth: Rework netdev driver layour
tests/stm32_eth_*: Use netdev driver header file for prototypes
stm32_eth: Add auto init for stm32 eth netdev driver
boards/stm32: Enable ethernet conf for nucleo boards
stm32_eth_auto_init: Add dont be pendantic flag
stm32_eth: Remove dma specific stuff from periph_cpu.h
Looks like this was implemented in PR #9171 and 021697ae94 with the same interface.
stm32_eth: Remove eth feature from stm32f4discovery boards
stm32_eth: Migrate to stm32 DMA API
stm32_eth: Add iolist to module deps
stm32_eth: Rework send function to use iolist
stm32_eth: Fix ci build warnings
stm32_eth: Fix bug introduced with iolist usage
stm32_eth: Remove redundant static buffer
stm32_eth: Fix feature dependencies
stm32_eth: Fix wrong header guard name
stm32_eth: Implement correct l2 netstats interface
stm32_eth: Rename public functions to stm32_eth_*
stm32_eth: Fix doccheck
stm32_eth: Move register DEFINE to appropriate header file
stm32_eth: remove untested configuration for f446ze boards
stm32_eth: Move periph configuration struct to stm32_common
stm32_eth: Fix naming of eth_phy_read and eth_phy_write
stm32_eth: Remove obsolete test applications
When reworking the reception of IPv6 packets I reset a previously set
`ipv6` snip as follows when the IPv6 extension handler returns a
packet (see first hunk of this commit):
```C
ipv6 = pkt->next->next
```
With `gnrc_ipv6_ext` this makes *somewhat* sense, `pkt->next` was
previously equal to `ipv6` and after the function call `pkt->next`
is the marked extension header, while `pkt->next->next` is the IPv6
header. However, since `ipv6` is already write-protected i.e.
`ipv6->users == 1` (see ll. 665-675), any additional call of
`gnrc_pktbuf_start_write()` [won't][start-write-doc] duplicate the
packet. In fact, the only `gnrc_pktbuf_start_write()` in
`gnrc_ipv6_ext` is used to send the *result* to the subscribers of that
extension header type, leaving the original packet unchanged for the
caller. As such `ipv6` remains the pointer to the IPv6 header whether
we set it in the line above or not. So we actually don't need that
line.
However, the extension header handling also returns a packet when
`gnrc_ipv6_ext` is not compiled in. In that case it is just a dummy
define that returns the packet you give provide it which means that
this still holds true: `pkt->next == ipv6`.
So setting `ipv6` in this case is actually harmful, as `ipv6` now
points to the NETIF header [following the IPv6 header][pkt-structure]
in the packet and this causes the `user` counter of that NETIF header
`hdr` to be decremented if `hdr->users > 1` in the write-protection I
removed in hunk 2 of this commit:
```C
/* pkt might not be writable yet, if header was given above */
ipv6 = gnrc_pktbuf_start_write(ipv6);
if (ipv6 == NULL) {
DEBUG("ipv6: unable to get write access to packet: dropping it\n");
gnrc_pktbuf_release(pkt);
return;
}
```
But as we already established, `ipv6->users` is already 1, so we don't
actually need the write protection here either.
Since the packet stays unchanged after the `ipv6` snip, we also don't
need to re-search for `netif_hdr` after the other two lines are
removed.
[start-write-doc]: https://doc.riot-os.org/group__net__gnrc__pktbuf.html#ga640418467294ae3d408c109ab27bd617
[pkt-structure]: https://doc.riot-os.org/group__net__gnrc__pkt.html#ga278e783e56a5ee6f1bd7b81077ed82a7
Summary for Users
=================
Deprecation is scheduled for 2020.01.
Users which depend on this module and cannot switch libraries may copy
the code into to their own application.
As expressed in PR #11724, the UBJSON module has issues which are not easy
or worth fixing.
Before removing the module, it should be marked as deprecated to give users
time to either migrate to another library, or copy the code to their own
private repo.
The deprecation warning has been supressed from the unit tests. This has the
ugly side-effect of supressing deprecation warning in other unit tests too,
but that should not last long, only until the module is finally deleted.
