Teensy 3.5 FlightSim Float problem

Status
Not open for further replies.
R

rich33

Member
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
 
As the forum rule states at the top of this thread: Always post complete source code & details to reproduce any issue!
 
manitou said:
As the forum rule states at the top of this thread: Always post complete source code & details to reproduce any issue!
Click to expand...

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)




Code: 
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;
}
 
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?
 
PaulStoffregen said:
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?
Click to expand...

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_flightsim. 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

Code: 
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?
 
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

Code: 
                                } 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)
 
PaulStoffregen said:
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

Code: 
                                } 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)
Click to expand...


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)
 
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.
 
Thanks for confirming. I've committed this change to the code on github.

https://github.com/PaulStoffregen/cores/commit/25d2728d7cb0362cd08b12074fe3ee06ae1f4c57

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.
 
PaulStoffregen said:
Thanks for confirming. I've committed this change to the code on github.

https://github.com/PaulStoffregen/cores/commit/25d2728d7cb0362cd08b12074fe3ee06ae1f4c57

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.
Click to expand...

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!
 
Teensy 3.5 and FlightSimFloat

rich33 said:
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!
Click to expand...



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.
 

Attachments

  • RadAlt_test.ino
    1.6 KB · Views: 69
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??
 
Status
Not open for further replies.
Back
Top