Devo 12

another possibilty is the HX8504-A. This looks like it could possibly match up to the connectors on the ribbon cable:
wenku.baidu.com/view/b8a8f87e31b765ce050814c5.html

Given the position of the notch, pin 1 should be top-right in the images you've posted.

Here are some more Tx pictures:
www.rcgroups.com/forums/showpost.php?p=20842363&postcount=104

kohansey wrote: I trying contacting HiMax requesting datasheets on the HX chips, hopefully I'll hear something back. In the meantime, I'll try ohm'ing out the pins on the micro so we can get a connection map going.

If you can provide high res images of the front and back of the board, I found it really useful to align and print them onto a double-sided sheet of paper. It makes it a lot easier to follow routes than on the screen.

Another route may be to send Walkera an email and ask them. I wouldn't expect a response, but you never know

PhracturedBlue wrote:

kohansey wrote: I trying contacting HiMax requesting datasheets on the HX chips, hopefully I'll hear something back. In the meantime, I'll try ohm'ing out the pins on the micro so we can get a connection map going.

If you can provide high res images of the front and back of the board, I found it really useful to align and print them onto a double-sided sheet of paper. It makes it a lot easier to follow routes than on the screen.

I used to align the two images one of them mirrored.
That way you can switch back and force on the screen and follow the routes...

msc2 contains the usb library. I couldn't get libopencm3's USB to work reliably, so we currently include the STMicro version.

As you noted there is libopencm3 + newlib which provides the hardware and stdlib interface

we use petitfat for the fileystem, but it is a modified copy so I don't really consider it a library at all.

I'm not sure what organization you have in mind. Deviation is released as an entire package, you shouldn't really be trying to pull pieces of it and still expect things to work.

You will need to re-implement (or copy/modify) everything in devo8. you'll also need to look at devo_common, since the code there is all based on the common layout of the other devo models (SPI FLASH + F103 MCU). For instance, the petit_io.c, spi_flash.c, and spi_touch.c (which actually belongs in /devo8) won't work. the cyrf6936.c, power.c, pwm.c, sound.c may use different I/O pins on the Devo12. Basically you should expect to need to go through everything in devo_common and make sure it is correct for the Devo12 as well.

Eventually we'll need to decide what to do about the GUI, but as a stop-gap, the easiest answer may be to provide a 320x240x16 interface, and scale the pixels in the LCD driver.

Disassembling the firmware should not be necessary for enabling the Devo12. The important piece is to be able to generate the dfu such that the bootloader will accept it, and we know how to do that now.

There are a couple of parts:
crc.h contains a unique-key per transmitter model. This value is not in the dfu shipped by Walkera, it is actually applied by the DFuSE tool. The only way I know to find this CRC is to snoop the USB bus, and it needs to be done for each Tx. It is only useful if you want to use a tool other than walkera's DFuSe uploader though (so it isn't critically important)
The linker script (devo8.ld) has to leave a hole for the CRC. This is already coded (search for '.crc'), so if you only modify the ROM and RAM ranges when porting devo8.ld, you'll be fine.

There is light encryption when generating the DFU. I implemented this in dfu.py, but you need to set the right offset when calling dfu.py. The offset should be the number of channels in the Tx (8 = devo8, 10 = devo10, so it should be 12 for the devo12). Note that the devo6 is weird in that it uses the same values as the devo8, but I'm pretty sure I tested the devo12 and verified the offset is 12. This is set in the Makefile.inc in the devo8/ dir