64K blocks are supported by all chips and have a higher bytes-per-second
erase rate than 4K "sectors". The block counts previously were in 64K
units so they don't change.
Also cleans up the calculations a bit.
The address in the `JEDEC_READ_DATA` command for JEDEC NOR chips is
absolute, not relative like for W25NXX. Fix erroneous reads by only
using relative `JEDEC_READ_DATA` address on W25NXX.
Match the chips which use the JEDEC driver in AP_Logger. Other chips are
(or should be) compatible. They are all NOR; NAND chips seem to use a
slightly different protocol described by AP_FILESYSTEM_FLASH_W25NXX.
messages coming in with a size of 24120 bytes. It takes so long to try to read those bytes in (at the device's message rate) that we time out the GCS and try detecting again
Smooth altitude changes were always referred to as "glide slopes"
despite this not being the appropriate aviation term in the case of a
climb. A better option is "altitude slope", which encompasses both
smooth climbs and descents.
Changed all references to glide slopes, except those that specifically
refer to a single kind (like those used for landings), to the more
general term. This also includes changing the GLIDE_SLOPE_MIN and
GLIDE_SLOPE_THR parameters to ALT_SLOPE_MIN and ALT_SLOPE_MAXHGT,
respectively.
Smooth altitude changes were always referred to as "glide slopes"
despite this not being the appropriate aviation term in the case of a
climb. A better option is "altitude slope", which encompasses both
smooth climbs and descents.
Changed all references to glide slopes, except those that specifically
refer to a single kind (like those used for landings), to the more
general term. This also includes changing the GLIDE_SLOPE_MIN and
GLIDE_SLOPE_THR parameters to ALT_SLOPE_MIN and ALT_SLOPE_THRESH,
respectively.
Smooth altitude changes were always referred to as "glide slopes"
despite this not being the appropriate aviation term in the case of a
climb. A better option is "altitude slope", which encompasses both
smooth climbs and descents.
Changed all references to glide slopes, except those that specifically
refer to a single kind (like those used for landings), to the more
general term. This also includes changing the GLIDE_SLOPE_MIN and
GLIDE_SLOPE_THR parameters to ALT_SLOPE_MIN and ALT_SLOPE_THRESH,
respectively.
Smooth altitude changes were always referred to as "glide slopes"
despite this not being the appropriate aviation term in the case of a
climb. A better option is "altitude slope", which encompasses both
smooth climbs and descents.
Changed all references to glide slopes, except those that specifically
refer to a single kind (like those used for landings), to the more
general term. This also includes changing the GLIDE_SLOPE_MIN and
GLIDE_SLOPE_THR parameters to ALT_SLOPE_MIN and ALT_SLOPE_THRESH,
respectively.
Studied by copying and pasting the equations into a simple program to
step through each file offset and print the results.
* The equations return nonsense results for small file positions. This
is expected (and noted by the LittleFS author) as block 0 does not
have any pointers according to the LittleFS design; it's entirely
filled with data. Therefore, check and avoid calculating them when we
know we're in the first block.
* This function always assumes we are writing a full block, so
`block_size - block_offset <= nbytes` is always true.
* `block_size == block_offset` can never be true, `block_offset` is at
maximum `block_size-1`. Therefore we can remove the logic to sync when
they are equal and we will always calculate the result to be
`block_size - block_offset`.
