Home
last modified time | relevance | path

Searched refs:garbage (Results 1 – 18 of 18) sorted by relevance

/Zephyr-latest/tests/kernel/pipe/pipe_api/src/
Dconcurrency.c33 uint8_t garbage[DUMMY_DATA_SIZE] = {}; in thread_write() local
35 zassert_true(k_pipe_write((struct k_pipe *)arg1, garbage, sizeof(garbage), in thread_write()
36 K_MSEC(partial_wait_time)) == sizeof(garbage), "Failed to write to pipe"); in thread_write()
41 uint8_t garbage[DUMMY_DATA_SIZE]; in thread_read() local
43 zassert_true(k_pipe_read((struct k_pipe *)arg1, garbage, sizeof(garbage), in thread_read()
44 K_MSEC(partial_wait_time)) == sizeof(garbage), "Failed to read from pipe"); in thread_read()
68 uint8_t garbage[DUMMY_DATA_SIZE]; in ZTEST() local
71 zassert_true(sizeof(garbage) == k_pipe_write(&pipe, garbage, sizeof(garbage), K_MSEC(1000)), in ZTEST()
77 zassert_true(k_pipe_write(&pipe, garbage, sizeof(garbage), K_MSEC(1000)) == -EPIPE, in ZTEST()
108 uint8_t garbage[DUMMY_DATA_SIZE]; in ZTEST() local
[all …]
/Zephyr-latest/drivers/net/
Dslip.h39 uint16_t garbage; member
Dslip.c205 SLIP_STATS(slip->garbage++); in slip_input_byte()
/Zephyr-latest/doc/services/storage/zms/
Dzms.rst24 When the current sector is full we verify first that the following sector is empty, we garbage
26 N+1 empty sector, we erase the garbage-collected sector and then we close the current sector by
31 the first sector after garbage collecting it and erasing its content.
88 ``GC_done ATE`` is written to indicate that the next sector has already been garbage-collected.
142 garbage collect the sector after the newly opened one then erase it.
180 When closing a sector, all the remaining space that has not been used is filled with garbage data
183 Triggering garbage collection
193 full. This will of course trigger the garbage collection operation on the next sector.
194 This will guarantee the application that the next write won't trigger the garbage collection.
212 ZMS always needs an empty sector to be able to perform the garbage collection (GC).
[all …]
/Zephyr-latest/arch/common/
DCMakeLists.txt39 # garbage collect them
/Zephyr-latest/doc/develop/languages/rust/
Dindex.rst12 Additionally, Rust offers powerful abstractions without a runtime or garbage collector, allowing
/Zephyr-latest/boards/shields/esp_8266/doc/
Dindex.rst79 - ESP-8266 bootloader won't send garbage. Try connect at 74880 bps if
/Zephyr-latest/arch/x86/zefi/
DREADME.txt39 work fine and then fail inexplicably at runtime with a garbage
/Zephyr-latest/doc/develop/west/
Dbuilt-in.rst144 may be garbage-collected and lost at some point in the future. To avoid
/Zephyr-latest/doc/connectivity/usb/device/
Dusb_device.rst201 as (invalid) command and user will see garbage as a result. While minicom does
/Zephyr-latest/doc/releases/
Drelease-notes-1.10.rst51 kernel by passing it garbage.
Drelease-notes-2.1.rst793 * :github:`18870` - zsock\_getaddrinfo() returns garbage values if IPv4 address is passed and hints…
Drelease-notes-3.6.rst63 platforms (garbage in .device_states section).
Drelease-notes-2.0.rst524 * :github:`18795` - FS:NVS: garbage collection when restart
Drelease-notes-2.7.rst1140 * :github:`38552` - stm32: g0b1: garbage output in log and suspected hard fault when configuring mo…
Drelease-notes-3.2.rst2080 * :github:`48863` - hawkbit subsystem - prints garbage if debug enabled and no update pending
Drelease-notes-1.14.rst1674 * :github:`12652` - UART console is showing garbage with driver uart_ns15560
Drelease-notes-3.3.rst2813 - :github:`54705` - CDC USB shell receives garbage when application starts