打造CP值最高的跨廠牌發射機 Deviation - DEVO10【固定下載】

suvsuvsuv

原帖由 coldfire 於 2013年2月25日 12:07 PM 發表
整点数求根应该不难，性能应该也不差，就是迭代，基本运算是加减法和移位。

下面转自wiki：

short isqrt(short num) {
    short res = 0;
    short bit = 1 = res + bit) {
            num -= res + bit;
            r ...

多谢hmjack2008和coldfire的帮助，我会参考 http://blog.csdn.net/microchenhong/article/details/6316332 和上述快速计算平方根的公式实现曲线平滑功能，应该可以很快实现，目前新版的高级混控也留有按钮位置开/关平滑曲线功能。

不过提醒一下，使用曲线平滑必然比折线性能下降，如果是多个混控来控制，操控性能更是加倍的下降

hmjack2008

原帖由 suvsuvsuv 於 2013年2月25日 12:58 PM 發表
使用曲线平滑必然比折线性能下降，如果是多个混控来控制，操控性能更是加倍的下降...

最初我是發現JR與Futaba有 "任意X位置新增點及生成通過控制點的曲線" 兩個功能, 而其他的控(如:天地飛)卻沒有 !!
我認為: JR與Futaba作此功能一定有原因.我猜測是比賽選手有需求(需要停旋穩定 與 3D靈活),並藉此樹立在市場中高級控的定位.


另,
(1) 若是 "任意X位置新增點" 及 "生成通過控制點的曲線" 這2個功能擇其一讓我選, 我寧願選 "任意X位置新增點" 而放棄 "生成通過控制點的曲線".
(2) 我剛發現早在9個月前(2012/5)
PhracturedBlue便於"Control Mixer(http://www.deviationtx.com/forum/7-development/264-control-mixer)"
提到此計算法: http://scaledinnovation.com/analytics/splines/aboutSplines.html

coldfire

谢谢suv兄！附件的版本不再出现重启问题。

不过我今天有点活见鬼了，现在怎么也编译不出导致重启的版本了。编译出来的都可用，刚把mingw全部删掉了，准备再试一下。

原帖由 suvsuvsuv 於 2013年2月25日 12:46 PM 發表
我目前定位的原因是在clock.c, PB为了实现崩溃前记录错误日志，非常频繁的清除某个外部中断，修改的代码看上去没有任何问题，但是经过验证是起到了反效果--原来很稳定的系统变成很容易重启。我昨天已经将clock.c回滚到之前 ...

coldfire

我觉得留有开/关平滑选项是最好的办法。另外可以设置个阈值，比如超过多少个混控就采用折线。或者预测一下最坏情况需要的时间（不知道可行否）来决定是否用平滑曲线？

原帖由 suvsuvsuv 於 2013年2月25日 12:58 PM 發表

多谢hmjack2008和coldfire的帮助，我会参考 http://blog.csdn.net/microchenhong/article/details/6316332 和上述快速计算平方根的公式实现曲线平滑功能，应该可以很快实现，目前新版的高级混控也留有按钮位置开/关平滑曲 ...

[ 本帖最後由 coldfire 於 2013年2月25日 02:29 PM 編輯 ]

coldfire

我今天晚上人品有点逆天了。。。

想好好看看究竟clock.c哪里改动能导致重启，所以我重新编译了最新源码，结果跑起来没任何问题。。。然后我编译了所有我下午试过可以重启的版本，同样都工作正常（一个有趣的现象是下午我在运行某些版本的时候，电池电压会被报偏低1V的样子，晚上从来没看到）。我甚至编译了和2.3.6对等的版本（df1e10cbb170，见附件），我的运行就正常，suv兄的就会重启。。。感觉有点像欧亨利的《警察与赞美诗》

不管怎么样，我还是决定用suv兄的2.3.8。我看了PB的改动，似乎所有改动（包括稍延长了WDT时间）的目的就是在WDT timeout一秒前能做stack frame dump。我比较好奇的是为什么用EXTI2做中断源呢？会有误触发的可能性吗？另似乎清除此中断只发生在初始化里，其他时间一直都在打酱油。

suvsuvsuv

原帖由 coldfire 於 2013年2月25日 03:44 PM 發表
我今天晚上人品有点逆天了。。。

想好好看看究竟clock.c哪里改动能导致重启，所以我重新编译了最新源码，结果跑起来没任何问题。。。然后我编译了所有我下午试过可以重启的版本，同样都工作正常（一个有趣的现象是下午我在 ...

要重现这个问题最简单的步骤就是切换到hubscan4协议，然后反复不断点击初始化按钮（打断初始化过程，只要速度足够快就很容易重现了）
为了记录core dump而在关键的时间中断中进行另一个中断的清除是冒险的做法，实际上v2.1.1至 v2.3.3版本都是相当稳定的，如果出现重启都是界面代码没写好，找到重现步骤即使没有core dump文件都不难调试解决。而这个改动引入了无法跟踪的硬件级别崩溃 （所有的core dump 文件都是指向A7105_readreg函数，对排查问题没有任何帮助）。所以我的版本完全去掉了这个改动，应该可以回复到v2.3.3之前的稳定级别