The UART3 also have the I2C bus 2 functions so moving GPS to UART7 to
have one additional I2C.
To keep GPS working is also necessary update the FPGA RTL to version
0xC1 or higher.
The Make.defs compisition is
ARCHWARNINGS = $(PX4_ARCHWARNINGS)
ARCHCWARNINGS = $(PX4_ARCHWARNINGS) $(PX4_ARCHCWARNINGS)
ARCHWARNINGSXX = $(ARCHWARNINGS) $(PX4_ARCHWARNINGSXX)
so the pieces from nuttx-configs/PX4_Warnings.mk should not be combined.
The recent changes to the timers increased memory by 8 bytes.
and should have ONLY added 8 bytes
was 20000dc0 40 20000E00
is: 20000dc8 40 20000E08
s/b 20000E08 1f3 next symbol
But for some unknown reason the linker skipped to the next alignment
of 256 and wasted 246 bytes.
20000F00 1f3 next symbol
Even with .align 8 in the .S file and . = ALIGN(4); in the linker
script I could not move the allocation back only up to the next
512 alighment.
So this is a hack to shift things back 8 bytes.
Log file download via Mavlink is the one that needs the most bandwidth.
It needs typically around 200B TX buffer, and spikes at around 1500B every
10sec, with an average download speed of 230KB/s.
Log file download via Mavlink is the one that needs the most bandwidth.
It needs typically around 200B TX buffer, and spikes at around 1500B every
10sec, with an average download speed of 230KB/s.
Log file download via Mavlink is the one that needs the most bandwidth.
It needs typically around 200B TX buffer, and spikes at around 1500B every
10sec, with an average download speed of 230KB/s.
Log file download via Mavlink is the one that needs the most bandwidth.
It needs typically around 200B TX buffer, and spikes at around 1500B every
10sec, with an average download speed of 230KB/s.
Log file download via Mavlink is the one that needs the most bandwidth.
It needs typically around 200B TX buffer, and spikes at around 1500B every
10sec, with an average download speed of 230KB/s.
Log file download via Mavlink is the one that needs the most bandwidth.
It needs typically around 200B TX buffer, and spikes at around 1500B every
10sec, with an average download speed of 230KB/s.
Log file download via Mavlink is the one that needs the most bandwidth.
It needs typically around 200B TX buffer, and spikes at around 1500B every
10sec, with an average download speed of 230KB/s.
* Backport:stm32f7: stm32_allocateheap: allow use DTCM memory for heap
Back port of upstrem contrib by Jussi Kivilinna <jussi.kivilinna@haltian.com>
stm32f7: stm32_allocateheap: allow use DTCM memory for heap
STM32F7 has up to 128KiB of DTCM memory that is currently left unused.
This patch adds DTCM to main heap if CONFIG_STM32F7_DTCMEXCLUDE is not enabled.
* px4fmu-v5_default:Enable inclusion of the DTCM in the heap
CONFIG_MM_REGIONS=3 adds the DTCM region to the heap.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.
The mavlink shell is the only process creating a pipe.
José Roberto de Souza
Lorenz Meier
David Sidrane
Henry Zhang
Beat Küng
Andrew C. Smith
Lucas De Marchi
Mohammed Kabir