In search of the ultimate Devo7E

@HappyHarry, that one works.

As PB mentioned in his other post, you'll want to hook up the five pins on your 7e board as: RST, SWDIO (TMS), SWCLK (TCK), GND, 3.3V.

RES and VDD are marked on you 7e PCB.

@PhracturedBlue, given the small price difference between the RC and RE processors, I swapped out to the RE (just 3 days ago, still experimenting). However I've been using the boot loader that you modified for 256K (both 128k and 256k boot loaders work). Could you possibly point me in the right direction for making the software mods to get to 512k?

Thanks!

thanks for the confirmation

I'm not sure what differences the bootloader has, but your changes will be in src/target/devo7e, or a copy of it.

target_defs.h is where you turn features on and off, so you can go throgh and turn on things for it:

1. turn on HAS_DATALOG, HAS_SCANNER (I think) and HAS_LAYOUT_EDITOR.
2. turn off NO_LANGUAGE_SUPPORT
3. Maybe up NUM_TRIMS to 8

You'll want to change the two .ld files to set the rom and ram lengths for the new CPU. You may need to set the ORIGIN values as well ,depending on the boot loader.

You can delete the MODULAR line in Makefile.inc, which will switch over to building the protocols into the flash. If you do that, you'll need to deal with them in the filesystem as well. If you don't,

If you copy the devo7E directory, add the new directory to the txs in src/Makefile.

@mwm, thanks for the extra input! Much appreciated.

Here's what I did:
1) Replaced processor with a STM32F103RET6 and uploaded devo7e_256 boot loader using st-linkv2.
2) Replaced flash with SST25VF032B since I was already replacing smd devices.
3) Forked deviationtx/deviation to my own repository ( bitbucket.org/silpstream/deviation )
4) Created a new branch "devote_512k"
5) Modified target/devo7e/target_defs.h
6) Modified target/devo7e/devo7e.ld
7) Modified target/devo7e/devo7e_opt.ld
Modified target/devo7e/makefile.inc
9) Built using mwm's docker based toolchain ( www.deviationtx.com/forum/7-development/...r-building-deviation )
10) Uploaded dfu file using walkera fuse tool 2.31 on windows 10 (Deviation Uploader will not work for the 7e with larger processor for some reason)
11) Connected in USB mode to format the new 4mb flash with FAT32 and uploaded filesystem

Everything works great.

A few questions:
1) In target/devo7e/target_defs.h, I set SPIFLASH_SECTOR_OFFSET to 54 (same as devo8). It works and I understand why the larger sector size, but I don't understand why there is a offset for the larger flash.
2) I used the 256k version boot loader that PB created and I'm under the impression that the boot loader limits the file size flashed on to the processor ( www.deviationtx.com/forum/6-general-disc...evo7e?start=40#34816 ). While everything works for now, I'm probably not going to be able to use the full 512K until the boot loader is modified or gotten rid of. Any chance for a 512K version or instructions that I can follow to modify the 256k version boot loader to work for 512k?

Thanks again everyone!

One question..
If I change the MCu with the STM32F103RCT6, after that....need to do anything more? Or Devo recognize it?

Thanks!

Thanks @PhracturedBlue!

I actually had the processor cause I lifted it off of a dev board that I was using to prototype a Flight Controller on for CleanFlight. That project died with the release of the SP Racing Pro F3, so I swapped the processors between the dev board and devo7e. I first chose the RET6 dev board as it was only about a $1 price difference with the RCT6. I don't actually have any plans to fill it up. I was just curious and figured I'd attempt modifying the bootloader for fun.

Overall, using the default UART based BL probably makes most sense since we have TX, RX and GND on the DSC port. Just need to figure out where/how to add software based reset (similar to what is happening in BaseFlight/CleanFlight, but instead of using 'r' we tie it to the 'ENT' button). I've tried a straight compile and upload of code over UART to 0x08000000, but was greeted by a blank screen. I'm guessing it has to do with the make and .ld files being setup to be called by the walkera bootloader, or with the soft power on/off that the transmitter has (less likely).

I saw that you stripped out a lot from the make and .ld files for your x9d target. Is that the way to go if I want to get rid of the walkera bootloader? Any other areas, I should look into?

Thanks also for the clarification on the flash offset!

As an aside, for anyone in Singapore that wants to do the processor change, PM me. I'd be happy to help out and see if we can get the numbers for an official Ultimate7e target in Deviation.

Thanks again for the pointers PB! I'll give it a try.

my interest is piqued. I search the file for the boot loader

LOL... no it's not 'because I can'. Mainly I've been seeing some talk about dropping/freezing the RBT6 based 7e and since that's the transmitter I have, I'm hoping to see if we can recover the space and possibly extend it's lifespan as part of the 'latest official' targets within the deviation project.

I've got the option to swap processors cause smd work is easy for me, but many don't. I came off of the opentx with a turnigy 9x cause I really like the 7e. It feels more solid, has better gimbals and has a nice size, all for a similar price. I'm not interested in more expensive options, if not I'd have jumped on the x9d.

From my perspective, the entire opentx movement took off cause the transmitter itself was priced in the $60 range which made it accessible to many and was a big upgrade from dx5/6 platforms from both a price and programmability stand point. I'd hate to see the 7e become a 2nd class citizen here cause I think it's where a lot of us would start.

From a 9x standpoint, UART/SWD is simple compared to soldering in a USBISP that the avr needs. If the USBASP could be adopted/implemented by the masses on the 9x, I don't see why people would cringe at losing USB-DFU. It's a minor inconvenience for better functions. In fact a good number of us have also swapped to the 128 or 2561 avrs, so the processor swap really isn't that scary. Soldering to processor pins is required for telemetry for the 9x. Sure the 64 is a larger package, but the pots mod you did is definately doable.

I also saw someone comment about repurposing pins PC9 and PC10 to the button matrix for extra switches. If we did that we could have 4x3way and 2x2way switches plus the 2 pots you added. If that could all be fit into 128k, the 7e would be, to me at least, the perfect transmitter (once the UniversalTX module or possibly the taobao 4/3-in-1 is added). The hardware fits, I've already done it (like you I jumped on the aesthetics to try it out ) Now I just need the code to get it to work.

Either way, I hope that the development on the 7e in either standard or ultimate form continues on deviation as a first class citizen.

512k was the processor I had on hand transplanted from a development board. I'm going to continue using the 256k bootloader you made on it and merge/patch new code into it until you guys decide to make it official.

The way I read things in other threads indicates v5.0 may be the last official release for the 7e. Using the UART based bootloader to free up space is because I'd like to see if we can fit 6 switches and 2 pots into the 128k devo7e build, as well as possibly extend it's lifespan a bit longer before it takes a backseat to it's more powerful siblings.

My bad for the long rant before and not clarifying concisely.

'I have to say that in 1981, making those decisions, I felt like I was providing enough freedom for 10 years. That is, a move from 64 K to 640 K felt like something that would last a great deal of time. Well, it didn't - it took about only 6 years before people started to see that as a real problem.' -- Bill Gates

With all due respect ... If the chip is cheap then consider suggesting the larger one now. And consider having the firmware auto-adjust. If it's available now, someone will use it very soon for something.

IF we're going to be replacing bootloaders, how about making them work with a standard dfuse tool? Getting the walkera dfuse loader working seems to be one of the biggest hurdles to getting started with deviation.

Yes, I think it would be better. It means you could use pretty much any OS, not windows, and hence avoid that problem. if for some reason, you still insisted on using windows (considering you can install a free Linux VM for a free virtual machine system and use that) you would be able to use a supported tool instead of one that isn't available from the company that created it any more.

At some point, I'm hoping to add a web server to the docker images I created so that you can start up a browser and do click-and-point builds. Adding a command line dfu utility to those might let you use them to do installs as well.

Admittedly, most of those benefits accrue to our own dfuse tool as well. But supporting a standard bootloader makes those easier to deal with.