the timing table was not correct, thanks to APD for pointing this out.
This is recalculated from
https://www.kvaser.com/support/calculators/can-fd-bit-timing-calculator,
with transmitter timing delay compensation added and tested with Salae
captures to ensure we are getting the right bit rates
our CANFD timings were resulting in a lot of busoff errors. Here is an
example of master at 1Mbit/5MBit:
Getting @SYS/can0_stats.txt as -
------- Clock Config -------
CAN_CLK_FREQ: 80MHz
Std Timings: bitrate=1000000 presc=7
sjw=0 bs1=7 bs2=0 sample_point=90.00000%
FD Timings: bitrate=5000000 presc=1
sjw=0 bs1=5 bs2=0 sample_point=90.00000%
------- CAN Interface Stats -------
tx_requests: 2689
tx_rejected: 0
tx_overflow: 443
tx_success: 7
tx_timedout: 2232
tx_abort: 0
rx_received: 18470
rx_overflow: 0
rx_errors: 0
num_busoff_err: 34439
num_events: 18477
ECR: F8
fdf_rx: 18467
fdf_tx_req: 2182
fdf_tx: 0
here is an example with the new timings:
------- Clock Config -------
CAN_CLK_FREQ: 80MHz
Std Timings: bitrate=1000000 presc=8
sjw=1 bs1=8 bs2=1 sample_point=90.00000%
FD Timings: bitrate=8000000 presc=2
sjw=3 bs1=8 bs2=3 sample_point=80.00000%
------- CAN Interface Stats -------
tx_requests: 3023
tx_rejected: 0
tx_overflow: 0
tx_success: 3023
tx_timedout: 0
tx_abort: 0
rx_received: 27865
rx_overflow: 0
rx_errors: 0
num_busoff_err: 0
num_events: 30888
ECR: 0
fdf_rx: 27862
fdf_tx_req: 3016
fdf_tx: 3016
I am testing between a CubeOrange and a Pixhawk6X. I tested 1, 2, 4, 5
and 8 MBit (which are the only valid FD bitrates in our parameters)
Many thanks to Kai from Salient Motion for finding this issue and
providing the corrected timing table
`__main_thread_stack_base__` and `__main_thread_stack_end__` are
variables whose address is defined to be the corresponding part of the
stack. These are declared as `extern stkalign_t` in ChibiOS code, and
being declared as `extern uint32_t` in ArduPilot code creates a warning
at link time when using LTO. Correct the declaration to eliminate this
warning.
Also update `__main_stack_base__` and `__main_stack_end__` which don't
currently trigger this warning but serve similar purposes and so might
in the future.
The hardware expects an alignment of `stkalign_t` (which is 8 bytes) and
the linker script defines the variable values with this alignment as
well, so this is safe.
No code size or functional change.
this isn't built on the firmware server, so we won't notice when it dies
In this case the SMBUS batter define was being set differently
Also remove some redundant defines which come from includes anyway
this fixes DMA failures affecting IMUs on H743. The reason for the
failure is not yet clear, but this reverts back to our old stragegy of
always using the bouncebuffer on H7 as a quick workaround
SERIAL_ORDER has been around for a few years now and UART_ORDER is
rejected by the hwdef script, so support for UART_ORDER and associated
processing in the hwdef script is removed, along with the order
conversion script.
add support to tell if shared DMA channel is actually shared
avoid starting and stopping the timer peripheral with bdshot
ensure that rcout DMA allocation and deallocation happens entirely within the lock
increase rcout thread working area for bdshot
fix mode mask that is sent to the iomcu
ensure iomcu rcout thread gets timeouts for callbacks
control bdshot input and output line levels on f103
use input capture channel pairs to read rising and falling edges of telemetry on f103
reset channel pairs together on iomcu
generalize the bdshot input path to support suitable buffer sizes for iomcu
generalize DMAR reading of CCR registers to read two at a time on iomcu
enable bi-directional dshot channels on PWM1-4 on iomcu
add methods to directly access erpm values from rcout
update erpm mask and esc telemetry correctly for firmware supporting dshot
add support for propagating bdmask to iomcu
dshot commands to all channels need to be aware of iomcu
ensure esc type is propagated to iomcu
cope with iomcu channel numbering when using EDT
ensure pwm driver is reset properly for dshot commands on iomcu
correctly reset pwm for dshot commands
correctly mask off bdshot bits going to iomcu
don't reset GPIO modes on disabled lines
don't reset pwm_started when sharing DMA channels
set thread name on iomcu rcout and reduce stack size on iomcu
ensure that bdshot pulses with no response are handled correctly
correctly setup DMA for input capture on f103
deal with out of order captured bytes when decoding bdshot telemetry
ensure DMA sharing on f103 does not pull lines low
only disable the timer peripheral when switching DMA channels on iomcu
add support for waiting for _UP to finish before proceeding with dshot
re-order iomcu dshot channels to let TIM4_UP go first
ensure that a cascading event will always come when expected on rcout
allow timeouts when using cascading dshot
always rotate telemetry channel after trying to capture input
cater for both in order and out-of-order bdshot telemetry packets
cope with reversed packets when decoding bdshot telemetry
ensure UP DMA channel is fully free on iomcu before starting next dshot cycle
refactor rcout for iofirmware into separate file
added ethernet config to hwdef
updated readme.md
hwdef: MAC parameters redefined according to ChibiOS
hwdef: add default params for Airvolute DCS2 on board FMU
update according to new changes in ChibiOS MAC driver
added defines to support ethernet communication
bootloaders: Airvolute-DCS2
Returns a mutable reference to the same HAL for certain purposes where
the HAL needs to be mutated to avoid UB problems with casting away const
and to make the fact that mutation is happening obvious.
fixes compilation problem with gcc 10.3
../../libraries/AP_HAL_ChibiOS/SPIDevice.cpp: In static member function 'static void ChibiOS::SPIDeviceManager::__static_initialization_and_destruction_0(int, int)':
../../libraries/AP_HAL_ChibiOS/SPIDevice.cpp:76:18: error: statement has no effect [-Werror=unused-value]
76 | ChibiOS::SPIDesc SPIDeviceManager::device_table[] = { HAL_SPI_DEVICE_LIST };
| ^~~~~~~~~~~~~~~~
compilation terminated due to -Wfatal-errors.
cc1plus: some warnings being treated as errors
- checking the build type is very rarely used and definitely not required here
- fix boilerplate to conform to normal pattern of including the config header and #if'ing based on the _ENABLED directly after that
Andy Piper
Iampete1
Peter Barker
Andrew Tridgell
bugobliterator
Henry Wurzburg
David O'Connor
Leonardo Garcia
yjuav
Hayden Donald
MallikarjunSE
Thomas Watson
Davide_Lentini
Maxim Buzdalov
jamming
alexklimaj
tomas.vrsansky
Martin Luessi
jfbblue0922
daniel.li
Tom Pittenger
Jonathan Loong