Flash programing on the K66 has to be units of 8 bytes. So we cache
the write of words until there are 2 written. Then the 2 words are
written to FLASH. This change ensure the bin file has an even
number of (4 byte) words by padding the last section in progflash
with 0xffffffff if needed.
This is needed for companions with high baudrate and high data rate.
Tested with 1500000 Baudrate and mavlink TX rate of ~120KB/s: no drops.
I did not test the exact limit, something like 2500 might be enough. But
we (still) have enough free RAM on FMU-v5.
This fixes automatic upload. Since ed95dced0f the NuttX string
is used for device detection, but Linux uses the bootloader's USB vendor
and product strings.
So the NuttX strings must match with the ones from the bootloader.
- nuttx in PX4/Firmware (537fe886015be0ccb6b691a8a2802fb29d17c410): 63775322bf
- nuttx current upstream: f57752b6f1
- Changes: 63775322bf...f57752b6f1
f57752b 2018-06-25 Daniel Agar - Merged in dagar/nuttx/pr-fixCompileError (pull request #660)
If the PX4FMUv2 board does not have the v5 uploader, it's not possible
to check the silicon revision to make sure it's safe to upload the
firmware which is more than 1 MB. However, if the user is sure the
silicon revision is not affected by this errata, he can upload the
firmware using px4_uploader.py with --force argument. This commit adds
`force-upload` make target to do it more convenient way.
Signed-off-by: Andrei Korigodski <akorigod@gmail.com>
to disable automatic evaluation of /dev/ttyS* expression in cygwin.
On linux verbatim seems to be default anyways. At least it doesn't get
evaluated on linux.
These hard coded paths assume all Nuttx targets are ARMv7-M targets. Updating them to use ${CONFIG_ARCH} and ${CONFIG_ARCH_FAMILY} instead allows for the architecture defined by the incoming Nuttx defconfig to be correctly targeted.
Flight tested: ekf2 w/ mag and compass by @nathantsoi: https://logs.px4.io/plot_app?log=79b81031-cf1e-41f0-890b-d6cd7d559766
NOTE: external I2C devices need a pullup. I have tested with a 3.3v 2.2k pullup.
Working:
- mpu6000, bench tested and verified via nsh
- fmu
- all 6 ch output bench tested w/ pwm and oneshot via nsh
- ppm input bench tested
- dsm input bench tested
- bmp280, bench tested and verified via nsh
- hmc5883, bench tested and verified via nsh, but requires an external i2c pullup
- gps on uart6
- startuplog, nsh, mavlink on uart4, but params are not sent for some reason. RSSI pin is TX, MOTOR 5 is RX (normal mode, 57600 baud)
- rgbled over i2c, bench tested and workingp
- sbus via the shared sbus/ppm pin (which includes an inverter to the mcu SBUS in pin), remove the solder bridge or jumper to the ppm pin before use
Not yet implemented:
- ADC
- OSD: passthrough video is untested, use at your own risk until a basic driver is implemented.
In the Cygwin environment the native Windows serial COM# ports get mapped
to /dev/ttyS# for POSIX compatibility. While # is one number lower inside
the environment than the COM port number because it's 0 indexed instead
of 1.
I added the necessary handling to all the dependent parts I found which
allows uploading to /dev/ttyS# when the cygwin platform is detected.
Now the usual "make px4fmu-v4 upload" and
"./Tools/upload.sh build/px4fmu-v4_default/px4fmu-v4_default.px4" work.
This change fragments MAVLink packets more efficiently and therefore increases the net throughput. This in turn makes the connection significantly more stable and the Crazyflie experience overall more usable.
David Sidrane
Jan Okle
Beat Küng
Daniel Agar
PX4 Jenkins
korigod
MaEtUgR
Joshua Whitehead
DanielePettenuzzo
nathan
barzanisar
Lorenz Meier