search

fishpepper / OpenGround

frsky compatible opensource firmware for the flysky fs-i6s
GNU General Public License v3.0
84 stars 30 forks source link

Add support for the FrSky D16 protocol #9

Open lunohod opened 7 years ago

lunohod commented 6 years ago

D16 (non-EU) can be tested now: https://github.com/lunohod/OpenGround/commits/new_features Binding doesn't work as of now, you have to clone an existing Taranis (in D8 mode). Then just change the RX number in the Model X settings.

scottjw commented 6 years ago

@lunohod Any plans to have this support the evolution? I tried flashing the new_features branch to one and it looked like all the I/O port mapping was for the other model of TX (stick input not there, battery voltage wrong etc.)

lunohod commented 6 years ago

@scottjw hm, I have to test it with my evo. Does the latest version from this repository work for you?

scottjw commented 6 years ago

@lunohod ya master branch from fishpepper's repo works for me. I was thinking it just had a bug with model detection or that model was hard coded. Don't know the code base well enough to figure that out though.

lunohod commented 6 years ago

@scottjw I just flashed my evolution with "make dfu" from the head of the new_features branch and it is working fine. The IO mapping is almost the same, just the first 4 channels are in the different order, so you should have the sticks mapped to the wrong channels in the worst case, but no input at all is a different issue. Make sure you have cloned my repo and switched to the new_features branch with "git branch new_features". BTW, the default settings are TAER and Mode 2 in my repo, you can change them in Config->Chan CFG.

scottjw commented 6 years ago

@lunohod I repeated the procedure from scratch with make dfu, after I re-saved the stick settings, calibration and model it all just worked. I guess you need to overwrite the storage/settings to update them, thanks a lot for the code and the tips.

ameeuw commented 5 years ago

@lunohod hey there - long time no comments here :) is the development completely dead? I found my evolution in the drawer and have an application for it with my 3" quads. They have an xm+ in there and therefore are D16 protocol...

I went and tested your branch - seems to work fine so far, but I have found a curious bug when monitoring the receiver tab in betaflight: As soon as the touchscreen registers an event, the RF module seems to reset and the receiver looses signal. Flight controller registers a fail-safe. I have not

Heres a video of the whole thing - do you have any idea how this could be solved? Maybe the timer I am trying to use gui buttons to set a channel.

lunohod commented 5 years ago

@ameeuw hi! Well, all I needed was implemented and I had no new ideas. I could reproduce the bug with my emax tinyhawk in D8 mode. I guess the touchscreen irq handler is blocking the rx timer interrupt.

ameeuw commented 5 years ago

hey @lunohod - thank you for the super quick reply :)

What would you suggest? Move the checking of the TOUCH_INT_PIN pin from the external interrupt to the sys_tick_handler, poll every sys_tick and apply debouncing?

Debouncing in the IRQHandler seems wrong to me..

lunohod commented 5 years ago

I would just set a flag in the interrupt handler and then trigger the i2c communication from the sys_tick_handler. Maybe we could/should use DMA for the i2c, but I have no idea how to do that.

ameeuw commented 5 years ago

@lunohod I introduced a flag to register touch events and trigger the i2c communication from the sys_tick_handler every some ms. However, it seems that it is not the frequency of i2c reads but the way the touch_i2c_read function works

Next thing I wanted to try is to make a state machine for the byte transfer which would get called repetitively and would return immediately if a condition such as (i2c_busy(TOUCH_I2C) == 1) is not met instead of staying in the while loop.

@fishpepper do you have any smart way in mind to fix this issue? Have you worked with a DMA channel for i2c?

fishpepper commented 5 years ago

You are right, doing the I2C call in the interrupt handler is really stupid^3. No idea how it got there in the first place 8) Setting a flag and doing it in the systick is way better.

I guess a non blocking statemachine would be the prefered way. Are you sure that this blocking is the cause of the link loss? Does it only happen on D16 or on D8 as well?

The frsky stuff should run triggered by the timer and any blocking non ISR code should not crash the link.

ameeuw commented 5 years ago

Are you sure that this blocking is the cause of the link loss? The frsky stuff should run triggered by the timer and any blocking non ISR code should not crash the link.

Nope I am not sure - your thoughts were exactly mine. The ISR should be executed every 9ms no matter what blocking code happens... any further thoughts what might cause the link loss?

Does it only happen on D16 or on D8 as well?

Have not tried it on D8 - I dont think I have a D8 receiver lying around anymore. @lunohod could the D16 extension have anything to do with the link loss?

At the moment I am just trying to figure out the cause. Maybe we should think of all sources for the link loss before implementing fixes :D

Nice of you guys to be so responsive on github :)

lunohod commented 5 years ago

I was able to reproduce the issue with D8 too. But I was using my branch, where the DIY-Multiprotocol-TX-Module code for both D8 and D16 is being used. It's also timer driven though. I can test later with original OpenGround code.

lunohod commented 5 years ago

I just tried the master branch of this repo and the issue is there. Also removed the i2c communication from the irq handler and it doesn't help

lunohod commented 5 years ago

LOL, you can't do that in the systick handler either, it's an isr too!

I moved the I2C communication to the touch_get_last_event(), which is called from the gui main loop. But I had to decrease the gui timeout, because it was skipping touch events.

ameeuw commented 5 years ago

Nice! Did that just now and it works like a charm.

ameeuw commented 5 years ago

Different question now: how to enable 16 channels? :)

lunohod commented 5 years ago

@ameeuw this might be a little harder. If you want to send 16 channels, you send first 8 and then the last 8 channels alternately.

8ch mode is hardcoded, you have to remove three lines there leaving only lpass++ to make 16 channels work: https://github.com/lunohod/OpenGround/blob/d0067095f5e2ff160696f973a04789215e232e29/src/FrSkyX_cc2500.c#L177

And then you have to patch lines 160 and 165, because you have not enough adc inputs to feed all 16 channels.