Jumper T8SG - First TX stock running on Deviation

If a touch screen is a option it needs to be a real touch screen not one of the pressure touch screens...Needs to be a capacative touch screen allowing the user to swipe and scroll using there fingers ect...Just like the ones on smart phones now days..

dc59 wrote: they will send sample TX to 8 developers on your list

I strongly suggest they also send a sample to RoGuE_StreaK, he's a vital part of the deviation community and... and... just send me one, OK?!

PhracturedBlue wrote: dc59,
Can you ask them whether they have a USB bootloader installed in the firmware? Otherwise, it makes it much harder for an end-user to update their device.

I have connected USB to T8SG and copy my 7e-256 model files into T8SG, I think it's same as devo7e-256! but I will confirm it with maker again.

PhracturedBlue wrote: That just means they are using my usb filesystem code (which is expected). the question is how you update the firmware version.
I hope they didn't take Walkera's stupid bootlader I honestly doubt they did, as it would say 'Walkera' on it.

I will try to update firmware after work.
BTW, would you please PM me your information for sample TX shipping?
Thank you!

PhracturedBlue wrote: That just means they are using my usb filesystem code (which is expected). the question is how you update the firmware version.
I hope they didn't take Walkera's stupid bootlader I honestly doubt they did, as it would say 'Walkera' on it.

Maybe this is the time to finally write our own bootloader. I know you refrained from doing so to make it possible to downgrade from deviation to Walkera firmware, but having the option to flash our own bl (and as such freeing memory for devo7e users) sounds nice. I wonder how many users actually went back to Walkeras fw.... But we're off topic now.

RoGuE_StreaK wrote:

dc59 wrote: they will send sample TX to 8 developers on your list

I strongly suggest they also send a sample to RoGuE_StreaK, he's a vital part of the deviation community and... and... just send me one, OK?!

Sorry for miss your reply, I will discuss with them soon!

goebish wrote: Subscribed, @dc59 I sent my address in PM on rcgroups

I've got your PM,thanks!

PhracturedBlue wrote: That just means they are using my usb filesystem code (which is expected). the question is how you update the firmware version.
I hope they didn't take Walkera's stupid bootlader I honestly doubt they did, as it would say 'Walkera' on it.

I downloaded NB Sep. 1 and try to update to T8SG with Walkera upgrade tool and got some problem.
1, When I entered upgrade procedure I got all dark screen.



2, It can upgrade FW with Wakera upgrade tool without problem,but after upgrade , I got inverted screen ....





I think they use Walkera bootloader , the problem about screen come from different LCD driver.
Is it correct PB?

I have no experience with this stuff,so leave this up to you (and the clone manufacturer). Still I'll help wherever I can.

vlad_vy wrote: dc59 can you test build with LCD code corrected to T8SG?

Attachment not found

Thanks vlad_vy, but it didn't work, I still got inverted screen ....

PhracturedBlue wrote: Appears so. what is the upgrade procedure for this tx? Does it detect as a '7e' in the walkera uploader?

Do you want me to try to build you a firmware using their driver to get it so your screen is the right way around?

We might recommend that they not use walkera's bootloader, but if they are about to ship, it may be too late. As I mentioned above, it isn't as easy to change last minute.

I get this screen when I upgrade firmware with walkera tools



Is it detected as 7e by Walkera uploader?

I'll try to contact with them about bootloader change issue.

If we can replace the Walkera bootloader and have a copy of it available, then we can put it back with the same process used to replace it. It does make going back harder, but is certainly possible.

IIRC, the Arduino_STM32 bootloader is timing based. After either a hardware reset or one of the USART control flow pins toggling (DTR?), it watches for a signal on the USB serial comm for a few seconds. If that happens, it goes into the dfu loading process. Otherwise, it jumps into application code. Not really what we want. I believe the dfu loader proper is from an ST Micro app note that provides a sample dfu bootloader, by way of the Maple project.

I'm pretty sure using a different bootloader would require a different build, or at least our own custom dfuse program to take care of the Walkera code obfuscation that the Walkera bootloader currently handles. Personally, I'd rather go with more builds - let's let people use standard dfuse tools.

If you really wanted to save bootloader space, the STM32F103 ROM bootloader enables the STM32 protocol on USART1, which is what the trainer port connects to. That would require hardware mods to activate the ROM bootloader, hardware mods to the trainer port which break Walkera's detection of the trainer cable, and that code doesn't use the screen. I think the µcu upgrade is probably a better option.