search

DeviationTX / deviation

Custom firmware for RC Transmitters
http://www.deviationtx.com
GNU General Public License v3.0
247 stars 153 forks source link

combine t8sg t8sgv2 and t8sgplus releases #649

Open PhracturedBlue opened 5 years ago

PhracturedBlue commented 5 years ago

Has anyone looks at what it would take to have a single binary for these 3 transmitters? The hall-effect sensor should be detectable, right? the v1 vs v2 may be harder...maybe looking at AUX5?

TheRealMoeder commented 5 years ago

I think the issue was the different LCD in V1 vs V2, and since the interface is one way only we really didn't find a solution.

PhracturedBlue commented 5 years ago

did you try snooping the bootloader? if they have different screens, the bootloaders must be dfferent as well....assuming they enable the screen at all.

TheRealMoeder commented 5 years ago

no, the bootloader is exactly your patched 7e-256 bootloader

TheRealMoeder commented 5 years ago

check https://www.deviationtx.com/forum/jumper/7449-jumper-s-short-term-roadmap-discussion?start=120#68958 https://www.deviationtx.com/forum/7-development/1744-need-testers-for-usbcode?start=120

PhracturedBlue commented 5 years ago

I'm glad you guys had the proper discussion. that diode on the power switch may be detectable as a way to determine the difference. we could also do some sort of initialization on boot: 'can you read this?' and then swrite to the tx.ini some info. I hate having 3 targets for a minor hardware change...I feel like there has to be something we can do.

It is so frustrating that there are so many transmitters that have come close to being 'perfect' for Deviation, and they all fall short along the way.

PhracturedBlue commented 5 years ago

I think I have both a V1 and V2plus around somewhere. I guess I should crack them open and see if there's anything i can find

TheRealMoeder commented 5 years ago

Display driver was no option as mentioned above. We thought about detecting the flash memory chip, but someone was afraid of sudden changes in manufacturing which is exactly what has just happened. I also really mislike the jumpers identifying themselves as devo7e, which leads to a lot of confusion with uploader users. That's why I threw in modifying the bootloader with a special dfu into the discussion, which could be handled in the uploader for "first time firmware upgrades of a "fake" 7e.

PhracturedBlue commented 5 years ago

Your idea was actually my 1st thought too...we could make it very easy to do a bootloader update. But not foolproof, and the consequences of a failed bootloader update require the use of specal hardware to resolve, so I am wary of being a party to such a thing. Is there a table of the differences between the 3 models? Is this about right:

V2 - reversed Aux5, button power-on, 2 2-pos switches, different memory chip V2-Plus: Hall-effect and OLED screen

The V1 isn't being made anymore, so it should be a static target to try to create a signature for. The V2 vs V2plus can we do anything to detect the hall-effect as a proxy for this?

hexfet commented 5 years ago

Only thing I could think of to detect hall effect would be a possible difference in endpoints. I have V1 and V2plus - calibration values shown below. (Apparently the V1 has a bad pot). Looks like the hall effects actually have less range. Need a way to measure step size to see if resolution is less. Not sure if this would be a reliable way to detect hall-effect. Also I've seen some posts about putting hall-effect gimbals into non-plus transmitters.

t8sg V1

[calibrate1]
  max=4095
  min=2
  zero=2073
[calibrate2]
  max=2302
  min=1789
  zero=2014
[calibrate3]
  max=4095
  min=2
  zero=1964
[calibrate4]
  max=4095
  min=4
  zero=2186
[calibrate5]
  max=4095
  min=0
  zero=2015
[calibrate6]
  max=4095
  min=0
  zero=1794

t8sg v2 plus

[calibrate1]
  max=3306
  min=635
  zero=2028
[calibrate2]
  max=3138
  min=868
  zero=2038
[calibrate3]
  max=3062
  min=879
  zero=2035
[calibrate4]
  max=3238
  min=731
  zero=2050
[calibrate5]
  max=4095
  min=0
  zero=1716
[calibrate6]
  max=4095
  min=0
  zero=2136
PhracturedBlue commented 5 years ago

I was thinking the hall-effect could be (a lot) less noisy than the pots. But I think a lot of the noise comes from cross-coupling which would negate any possibility of that. What is the backlight pin (B.1) connected to on the Plus? could we do something there?

hexfet commented 5 years ago

I see a short trace from pin 27 disappearing into a via. Someone else should confirm my pin counting. Didn't find where it popped up with an ohmmeter (it's not vcc or gnd) and don't have time to pull the board tonight. In the T8+ target it's initialized to an input but not used otherwise.

howard0su commented 5 years ago

no, the bootloader is exactly your patched 7e-256 bootloader

This is interesting. so bootloader can use same code to drive the screen but we cannot?

Can we check backlight pin to difference? we can still try to read that pin to see the value there. I bet if it not used, it may grounded in t8sg_v2_plus.

hexfet commented 5 years ago

The screen remains dark when the T8+ bootloader is running. The B.1 pin is not connected to ground or Vcc.

PhracturedBlue commented 5 years ago

I pulled mine out to take a look...They did not make it easy to disassemble, did they? It appears the entire thing needs to come apart to remove the main-board, including removing the sticks. I don't have time for that tonight either. On the 7e, I think the B1 drives a FET which applies power to the screen. B1 can be attached to the adc, so we may be able to (roughly) measure the rc time-constant and detect if the FET is there or not.

PhracturedBlue commented 5 years ago

well, it doesn't look like the backlight pin will help us either. On the T8SGV2-Plus, PB1 is attached to a 10k pulldown and through a 10k resistor to a J3Y NFET which then goes to a through-hole pin which is not connected. So it looks like they left the same circuit in place for the backlight that is used with the LCD screen.

hexfet commented 5 years ago

Tested voltage difference on my t8sg v1. About 15mV difference between backlight off and full on, using lipo at 7.3V. Doesn't seem like that would be too reliable.

PhracturedBlue commented 5 years ago

I'm starting to think a custom bootloader may be our best bet after all. It would also improve the experience by enabling the screen during upgrade. I like the bootloader that comes with opentx in that it allows uploading the firmware without any host software. I'm wondering whether we could use something like it (but without buffering the file before install). That would be a pretty big win. The opentx bootloader is 32kb which is way too big though. Not sure how small we could make such a bootloader

howard0su commented 5 years ago

The size of boot loader can be workarounded by expose some functions to main ROM. For example the usb stack.

What is the first time user experience to flash the boot loader?

PhracturedBlue commented 5 years ago

yes, I've considered that in the past. I even considered using it on the devo7e (the bootloader is built with the standard stm32 toolchain and has many functions we could use). The downside is that it makes it hard to update anything in the bootloader. anyhow, I think it is worth considering further. The idea of not needing an uploader is very enticing.

PhracturedBlue commented 5 years ago

we would build a 'bootloader uploader' image which installs the same way a current rom installs today. basically a rom to update the bootloader. So the 1st time, it would be like doing an upgrade today. after that (possibly) it'd be as easy as plugging the tx into a PC and dragging a file to it.

PhracturedBlue commented 5 years ago

Just to get a feel for it, I started a new project: https://github.com/DeviationTX/deviation-bootloader

It currently just builds the MSC driver with FAKEFAT enabled. It doesn't have any LCD or actual Flash support. It is untested and may need other initialization as well.

Even with LTO enabled, the image comes in at 13.3kB. The existing bootloader fits in 12kB for the 7e. If it is solely for the T8SG, we could afford a larger bootloader, but I think all Tx could benefit from this.

@howard0su You've been looking at the usb stuff. Do you think the MSC driver can be reduced?

I haven't played with it on the STM32F1 yet, but the 'usb_msc' from libopencm3-examples builds in ~8k for the F2, and I assume they should be very similar. That example is pretty similar to the FAKE_FAT case, so it may be a better place to start.

PhracturedBlue commented 5 years ago

I added the usbmsc example on the cm3 branch. It compiles to 7.28kB for the F1. I think it should be possible to squeeze a minimal lcd driver and Flash writing into the 4kB, so this is definitely promising

howard0su commented 5 years ago

Msc code can be simplified when we can allocate a 4kb as the buffer as it is same as sector size. Can u checked in your code somewhere I can use MSC code to see how it fits. My last testing shows msc inside libopencm3 is smaller in the size.

PhracturedBlue commented 5 years ago

Everything is checked in here: https://github.com/DeviationTX/deviation-bootloader

I am currently working on the cm3 branch. Even with flash support it is only 8.5kB (still actually untested).

TheRealMoeder commented 5 years ago

In case you didn‘t already find it: https://github.com/davidgfnet/stm32-dfu-bootloader

PhracturedBlue commented 5 years ago

I now have a proof of concept for uploading firmware to the Tx via USB MSC through a custom bootloader now (still very crude). However, it has some downsides. Because the OS manages the filesystem, there is no way to disable caching which means you can't be sure when the firmware is finished uploading (without an extra user step), and it is possible for the directory view to get out of sync since the OS doesn't read back the root-dir after updating it.

I do, however like the approach, as it is very easy to upload firmware without any special software install. I think looking at ptp may be worth the effort.