r1556 Compile errors

[ReSt]

Companion r1556 fails when compiling on win XP SP3 (via Visual Studio 10)

Errors are due to the lately added ISR routines for rotary encoders of open9x in module 'board_gruvin9x.cpp'

Every line of the three ISR routines outputs errors similar to the following:

Code: Select all

2>g:\companion\r1556\src\../open9x/board_gruvin9x.cpp(298): error C2059: syntax error : 'bad suffix on number'
2>g:\companion\r1556\src\../open9x/board_gruvin9x.cpp(298): error C2146: syntax error : missing ';' before identifier 'b00001100'
2>g:\companion\r1556\src\../open9x/board_gruvin9x.cpp(298): error C2065: 'b00001100' : undeclared identifier

2>g:\companion\r1556\src\../open9x/board_gruvin9x.cpp(299): error C2059: syntax error : 'bad suffix on number'
2>g:\companion\r1556\src\../open9x/board_gruvin9x.cpp(299): error C2146: syntax error : missing ')' before identifier 'b00001100'
2>g:\companion\r1556\src\../open9x/board_gruvin9x.cpp(299): error C2059: syntax error : ')'
2>g:\companion\r1556\src\../open9x/board_gruvin9x.cpp(299): error C2065: 'b00001100' : undeclared identifier
2>g:\companion\r1556\src\../open9x/board_gruvin9x.cpp(299): error C2146: syntax error : missing ';' before identifier 'incRotaryEncoder'

Open9x compile with AVR GCC chain does work without problems.

There are also some warning messages:

Code: Select all

2>G:/Companion/r1556/build\./er9x/audio.h(244): warning C4005: 'V_ERROR' : macro redefinition

2>G:/Companion/r1556/build\./er9x/er9x.cpp(748): warning C4805: '|=' : unsafe mix of type 'Er9x::uint8_t' and type 'bool' in operation

2>g:\companion\r1556\open9x\open9x.h(757): warning C4005: 'FORCEINLINE' : macro redefinition

2>g:\companion\r1556\src\../open9x/model_menus.cpp(3247): warning C4805: '!=' : unsafe mix of type 'bool' and type 'Open9x::int8_t' in operation

Reinhard

[bertrand35]

I will take care of that tomorrow.
Bertrand.

[ReSt]

Thanks Bertrand.

Take you time.


Reinhard

[bertrand35]

It should be ok now.
Bertrand.

[ReSt]

Thanks Bertrand,
verified with r1557 and that is ok now.

But another error has been introduced

Code: Select all

2>  open9ximport.cpp
2>g:\companion\r1557\src\../open9x/open9x.cpp(2598): error C3861: 'getADC_bandgap': identifier not found

Reinhard

[ReSt]

sorry to bother again

Problems with Companion version 1556

I'm not sure if it is due to compiling it by myself or if there are real problems (but compiled version of v1540 does work as expected).

In the attached eepe file, I have stripped down the mixes and removed everything that was not needed.

Channel 01 mixes (in reality) correspond to elevator and channel 02 mixes correspond to the motor channel.

THR switch + ID0/1/2 switch the flight phases.

!RUD switch is the safety switch in Custom functions and disables the motor (ch02).

Throttle stick mixes in some down elevator according to curve 2

Failures:
Switch on THR + ID1
--> CH01 starts oscillating

Switch on THR + RUD(safety switch) + ID1
--> CH02 and CH01 start oscillating

This does not happen with Companion v1540

I know, ch01 depends on ch02, and as the safety switch supresses the output of ch02 the reason for ch01 oscillating is probably ch02.
But they oscillate with different speed and asynchronously and none of them should oscillate at all.

The other behaviour where I know, that the reason for it is the safety switch, but I still do not like, is:
Switch on THR + ID0
move throttle stick from low to high
--> Ch02 remains at -100 but CH01 moves according curve 02 even though the mix says that ch01 depends on the position of ch02 and not on the position of the throttle stick.

I know that this is because the input to ch01 is taken before the safety switch is applied to ch02.
But it is not obvious and wouldn't it be possible to use the channel output after the safety switch?

And I still don't like that.


Reinhard

[Kilrah]

The whole idea of the safety switch is to "clamp" an output regardless of what's being done before, and without affecting anything else in the logic flow...

If you prefer to do it in the logic flow, you can always use a "Replace" mix with -100% MAX Switch (!RUD) as the last line of CH2 instead of a safety switch.

Modifying the CHx inputs to take the servo value after the safety switch would only give a different way to do something you can already do, but it would remove the ability to force an output without affecting the other channels that depend on it... your example is a perfect one to see where that possibility is useful. Let's say I mix some down elevator to compensate for nose up tendency when power is added, then on the ground I'd like to be able to disable the motor with the safety switch, but still see the effect of the compensation on the elevator if I want to adjust it, check direction or whatever.

[ReSt]

That are the different points of view.

If I see that the channel 'X' on the display is not moving, I don't expect that another channel that is controlled with channel 'X' does move.

Reinhard

[ReSt]

Problems solved with r1726

Thanks.

Reinhard