adding support for Multiplex SRXL V2 #1538
Conversation
|
@hydra : X-bus driver is getting a bit too complicated and ugly, it should be cleaned up ... |
|
@hydra @ledvinap Very good idea, maybe a good approach would be leave the code in there for the RJ01 (because it is anyway different). And move the SRXL (Xbus-modeB) to a new sourcefile? With this step i also suggest to take the SRXL name and not xbus modeB. See: http://wiki.beastx.com/index.php/SRXL_-_Serial_Receiver_Link_protocol/en |
|
Splitting will only increase code size and result in code duplication. The code needs some rewrite ... Main problem is parsing packets in IRS handler. It is increasing interrupt latency, increasing max stack usage and bas practice in general. I would redesign receiver routine to just store packets, possibly decoding it's length (it is not strictly necessary - just use interbyte interval to terminate packet). Also waiting for header byte is problematic - receiver may sync into packet. Interbyte timing handles this easily. Packet processing may be called from main loop (quite easy with task scheduling) and decode what is received. Also crc calculation should be moved to separate file (reuse is possible) and implemented efficiently. |
The main point is that there is loads of great re-usable code for both OSD and FCs and allow the both to be configured using the Cleanflight configurator. The Cleanflight codebase can now be used to build TWO types of targets: FC or OSD. This commit seperates as all the FC specific code into the src/main/fc directory, OSD code goes in src/main/osd. Shared code is everywhere else. some files have an `_fc` suffux to allow the files to be distinguished (e.g. on IDE editor tabs). The idea is that we can now build F1 or F3 based OSDs that use the MAX7456 IC. The display logic should be reusable for other OSD driver ICs (e.g. BrainFPV). The OSD code should also be usable if the MAX7456 is directly connected to an FC in the future. We'll cross that bridge when we come to it however as right now the scheduler tasks, bootup sequence and other code will likely have to be refactored/reoganized somewhat. Later commits will add OSD code to the STM32F3DISCOVERY target and perhaps an an STM32F3DISCOVERYOSD for development of OSD only boards.
screen to show the cleanflight logo.
code. the concept of font mapping, raw characters, cursors, writing strings and a screen buffer is no-longer in the video driver. The main OSD code that deals with putting characters in certain positions and using characters to display raw font symbols is no-longer video driver dependant. The font mapping is now located with the font.
max7456 osd specific code now lives in osd_max7456.c and is compiled in when needed by the target.
Flashes 'NO CAMERA' when camera disconnected. Flashes fc related information when FC timeout occurs. The timer code is borrowed and refactored from the LED Strip code. There may be some parity and use-use to be found in a later-refactoring. EXTI configuration needs to be moved to target definition. This commit also adds some EXTI LOS/VSYNC/HSYNC debug code which a later commit will remove.
First four motors only, regardless of mixer type, assumes quad X.
Allow configurator to get all voltage meters (Some hacks were required, see cleanflight#2221). fix baudrate changes missed in previous commit.
display artifacts. This also relocates quite a lot of low level code into the video driver from the high level osd_max7456.c
disconnected. The state introduced into the statusIndicator code ensures that each mode is completed before allowing a chaning to a different status mode. Move some msp client state out of fcState.
Conflicts: Makefile src/main/rx/rx.c src/main/rx/xbus.c
…mer_assignments Fixed timer assignments for BEEROTORF4 target.
Multiplex introduced a new protocol with identifier "A2" as an indicator for Version 2 protocol of the SRXL. it can now contain 16 Channels instead of 12.
Previous working recievers with identifier "A1" are not affected on this change.
Tested with Mutliplex RX-4/9 FLEXX receiver.
Thanks to Steffen Graap for the code.
Maybe a short comment helps to understand what SRXL is. In fact JR's XBus mode B is SRXL which is used by a couple of manufacurers. It makes more sense to use the name SRXL because thats the standard defined by srxl.org. But a rename is a lot of work and confuses users but definately make sense in along term period.