coordinate system
Previously there were hacks spread throughout to deal with various ways of
positioning the chips. Now the driver structure specifies the rotation
of the chip relative to the board layout and the output X/Y/Z are already
in OP convention.
This flag seems to do the right thing for Revolution, CC3D, and RevoMini
Preallocated buffers with various preambles etc. Used SPI_TransferBlock for
anything over a few bytes instead of burstWrite. Also make more of the
communications wrappered in a large semaphore grab using a new rfm22_write_noclaim()
Still needs work - probably because most of the methods to repeated calls they should
all use the noclaim, or more specifically that function becomes rfm22_write/read.
The abstraction should probably be improved but ideally we start using
the DMA SPI transfers for PipX and grabbing/releasing the semaphore less
frequently (e.g. not for each 1-2 bytes).
Adds a new RCTransmitter setting for the USB HID interface which
emulates a USB HID joystick. The scaled RC receiver channels
from any RCVR protocol are passed through to the various emulated
joystick controls.
The main use for this feature is to allow you to use your own RC
transmitter with any RC simulator on a PC.
This is known to work with CRRCsim but should work with any simulator
that supports joystick input.
PIOS_Flash_Jedec_EraseChip is called during early
init when the table_magic has changed. This call
happens on CC/CC3D prior to the OS being initialized
so it is not OK to call vTaskDelay() yet.
This was leading to boards locking up (no flashing blue
LED) immediately after jumping to the application when
the table_magic had changed or was being init'd for the
very first time.
flash so it says completed. However, it still blocks the system for a long
time. During an erase the heartbeat will flash at 10 Hz to indicate what's
happening.
This still blocks telemetry even after lowering hte system priority (and there
is a vTaskDelay) which makes me think that the SPI bus being locked is blocking
Sensors or somethign else. This should not be permited when the system is
armed.
The reason the system locks up during the erase is that the file system
operations occur within the event dispatcher thread. It is very bad practice
for anything to block this (i.e. callbacks should never take very long). We
should probably move the object persistence handling into the system thread or
something but that can be a separate issue.
