Teensy 3.5 FlightSim Float problem

[rich33]

Anyone any ideas why you can read a FlightSim float perfectly ok with a Teensy 3.1 but Teensy 3.5 reads zero all the time?

Using version 1.41 of Teensyduino

[manitou]

As the forum rule states at the top of this thread: Always post complete source code & details to reproduce any issue!

[rich33]

As the forum rule states at the top of this thread: Always post complete source code & details to reproduce any issue!

OK, but the code is not really relevant, since you can't read any FlightSimFloat on Teensy 3.5. The code will work fine on any other teensy. (2++, 3.1 etc)

FlightSimFloat bat_volt; 
FlightSimFloat fuel_flow; 

void setup()
{
 bat_volt = XPlaneRef("sim/flightmodel/engine/ENGN_bat_volt[0]");  //comment this out to make fuel flow setting work
 fuel_flow = XPlaneRef("sim/flightmodel/engine/ENGN_FF_[0]"); 
}

void loop()
{
  FlightSim.update();
  fuel_flow=.0191;
}

[PaulStoffregen]

The TeensyControls plugin on Xplane has has a "show communication" window.

Does it show correct data is being sent from Xplane to that float on Teensy?

[manitou]

google shows several threads where T3.5 isn't working with flightsim floats ??? no solutions
https://forum.pjrc.com/threads/43658...ensy-3-5-Issue
https://forum.pjrc.com/threads/46643...-5-and-X-Plane
https://forum.pjrc.com/threads/43330...ith-X-Plane-10

[rich33]

The TeensyControls plugin on Xplane has has a "show communication" window.

Does it show correct data is being sent from Xplane to that float on Teensy?

Yes it does.

I did find that there is possibly an error in usb_api.cpp in C:\arduino\1.8.1\hardware\teensy\avr\cores\usb_fli ghtsim. But i don't know if these files are compiled when you build the sketch or when you install teensyduino.

This also doesn't explain why it works on teensy 3.1

void FlightSimFloat::update(float val)
{
    value = val;
    if (change_callback) {
        if (!hasCallbackInfo) {
            (*change_callback)(val);
        } else {
            (*(void(*)(long,void*))change_callback)(val,callbackInfo);
           
        }
    }
}

Should that long be a float?

[PaulStoffregen]

It's been a couple years since I've had a computer with X-plane for testing. If we can't get this resolved by guesswork, looks like I might have to set something up again.

As a first blind guess, maybe try editing this in hardware/teensy/avr/cores/teensy3/usb_flightsim.cpp

                                } else if (type == 2) {
                                        FlightSimFloat *item = FlightSimFloat::find(id);
                                        if (!item) break;
                                        #ifdef KINETISK
                                        data.f = *(float *)(p + 6);
                                        #else
                                        data.b[0] = p[6];
                                        data.b[1] = p[7];
                                        data.b[2] = p[8];
                                        data.b[3] = p[9];
                                        #endif
                                        item->update(data.f);
                                }

Maybe just change "#ifdef KINETISK" to "#if 0", so the slower 4 line code is used. Maybe the FPU isn't happy about unaligned data?

If that doesn't help, maybe put a digitalWriteFast() right after "item->update(data.f);" and watch if the pin ever changes. That could at least narrow down whether the data is getting passed with update(), or if the problem is preventing things from getting to the update() call. Then comes more guesswork.... (or setting up a machine again to run Xplane)

[rich33]

It's been a couple years since I've had a computer with X-plane for testing. If we can't get this resolved by guesswork, looks like I might have to set something up again.

As a first blind guess, maybe try editing this in hardware/teensy/avr/cores/teensy3/usb_flightsim.cpp

                                } else if (type == 2) {
                                        FlightSimFloat *item = FlightSimFloat::find(id);
                                        if (!item) break;
                                        #ifdef KINETISK
                                        data.f = *(float *)(p + 6);
                                        #else
                                        data.b[0] = p[6];
                                        data.b[1] = p[7];
                                        data.b[2] = p[8];
                                        data.b[3] = p[9];
                                        #endif
                                        item->update(data.f);
                                }

Maybe just change "#ifdef KINETISK" to "#if 0", so the slower 4 line code is used. Maybe the FPU isn't happy about unaligned data?

If that doesn't help, maybe put a digitalWriteFast() right after "item->update(data.f);" and watch if the pin ever changes. That could at least narrow down whether the data is getting passed with update(), or if the problem is preventing things from getting to the update() call. Then comes more guesswork.... (or setting up a machine again to run Xplane)

Hi Paul, thanks for looking at this. It is driving me mad!

i will try those things now and report back.

Can you confirm when usb_api.cpp gets compiled? (if ever)

[rich33]

Well removing the #ifdef KINETISK works!

Must be something odd going on with the teensy3.5's FPU...

Thanks Paul, this will allow us to press on with the cockpit build!

I'd be interested to know what's actually going wrong though.

[PaulStoffregen]

Thanks for confirming. I've committed this change to the code on github.

https://github.com/PaulStoffregen/co...e3ee06ae1f4c57

I believe the issue has to do with the FPU expecting 32 bit data to be aligned to a 32 bit boundary in memory. Cortex-M4 permits unaligned access for integers, but Cortex-M0+ (on Teensy LC) does not. Apparently the FPU has some issues with it too.

Hope you'll post some photos as the project comes together, maybe even details we could show on a blog post?

Also to answer your question, usb_api.cpp is the older version of the code which is used if you have Teensy 2.0 or Teensy++ 2.0. It's not used at all if you have Teensy 3.5.

[rich33]

Thanks for confirming. I've committed this change to the code on github.

https://github.com/PaulStoffregen/co...e3ee06ae1f4c57

I believe the issue has to do with the FPU expecting 32 bit data to be aligned to a 32 bit boundary in memory. Cortex-M4 permits unaligned access for integers, but Cortex-M0+ (on Teensy LC) does not. Apparently the FPU has some issues with it too.

Hope you'll post some photos as the project comes together, maybe even details we could show on a blog post?

Also to answer your question, usb_api.cpp is the older version of the code which is used if you have Teensy 2.0 or Teensy++ 2.0. It's not used at all if you have Teensy 3.5.

Interesting. It seems to handle normal non-flightsim floats ok. Are the floats 'deconstructed' to bytes when they pass over the usb and 'reassembled' in the teensy? Also interesting that you can set a flightsim float, as long as you don't read any.

I'll see if my colleague will post some info about his build. It's based around a real Piper fuselage/cockpit with wrap around projection. Pretty cool. i just help out with any software issues!

[P Dobson]

Interesting. It seems to handle normal non-flightsim floats ok. Are the floats 'deconstructed' to bytes when they pass over the usb and 'reassembled' in the teensy? Also interesting that you can set a flightsim float, as long as you don't read any.

I'll see if my colleague will post some info about his build. It's based around a real Piper fuselage/cockpit with wrap around projection. Pretty cool. i just help out with any software issues!

Hi Paul, Rich33, Thanks both very much for your help. Now all 7 instruments are running from a single Teensy3.5 using floats. I will post some photos of the final hardware build.

To put the icing on the cake I decided to add a digital output for Decision Height using "sim/cockpit2/gauges/indicators/radio_altimeter_height_ft_pilot". But for some reason this is not being read by the Teensy. Yet "sim/cockpit2/gauges/indicators/altitude_ft_pilot" is read correctly. Is there a DataRef length limit for the Teensy3.5??

The enclosed code simply outputs the dataRefs to a PWM so you can see what is going on, no Constrain has been included so wrap around overflow is possible. (stick below 4096 ft!!.

Test code included.

[PaulStoffregen]

Yes, the same dataref name length limit applies to all boards.

[P Dobson]

Thanks for the quick response Paul,

So How do I get round this problem?? I am not aware of a shorter data ref for Radio Height??

[P Dobson]

Can DataRefs be abbreviated in any way??

[PaulStoffregen]

Can DataRefs be abbreviated in any way??

Not easily, and not on the Teensy side. That needs to happen in Xplane plugins.

[rich33]

Not easily, and not on the Teensy side. That needs to happen in Xplane plugins.

Seems like a bit of a flaw in the X-plane API? Why would Datarefs be defined such that they cannot be read? Or is it flaw in the plugin?

[PaulStoffregen]

It's really my fault on the plugin. The reality is I'm not really developing the xplane plugin anymore.

Here's a copy of the plugin from Jorg Neves Bliesener that may fix this problem.

https://github.com/jbliesener/X-Plane_Plugin

Look in the target/TeensyControls folder for a compiled plugin. Maybe that will help?

[PaulStoffregen]

I've added a link to Jorg's repository on the flightsim page. Hopefully that'll help anyone else in the future.

https://www.pjrc.com/teensy/td_flightsim.html