[Hardware, Plugin] Arduino based physical display + serial port io+ tutorial (24-11-19)

[kungfufishstick]

Oh, I messed it up yesterday sorry.

In the function definition for warningSet, the first word defines what that function returns. I accidentally set it to void when it later returns a byte.

Try this instead:

byte warningSet(byte warnings, byte n, boolean s) {
  if (s) {
    warnings |= (1 << n); // forces nth bit to 1
  } else {
    warnings &= ~(1 << n); // forces nth bit to 0
  }
  return warnings;
}

(future readers, I totally went back and fixed yesterday's post too)

And to any future readers that are new, don't forget to declare byte warnings = 0;

Alright, no errors on compile. I am not getting the LED to come on. Would it be possible that I need to include shift out code?

EDIT: Adding the shift code was necessary. I have the LED working. Now on the the rest.

A quick question:

If I daisy chain additional shift registers, would the numbering for the pin just continue up with each LED?

Edited July 26, 2015 by kungfufishstick
Additional info

[stibbons]

You definitely do need to include shift out code. Even if a single bit changes, you'll have to shift out the entire byte. If you're setting bits in the Indicators() function, then it makes sense to do the shift out at the end of that.

[kungfufishstick]

I just went ahead and added the shift out code within the byte warningSet. For the first version of my controller, I don't plan on using shift registers for anything other than LED indications.

Thank you so much for the help. I really appreciate it.

[Darkblade48]

Update 0.17.4

Changed:

Fixed overheating bug caused by 1.0.4 update (Found by Sputnix, thanks!)

Added current stage number- byte

Added total stages - byte (Thanks Cbrollin)

Plugin:

https://sites.google.com/site/zitronfiles/KSPSerialIO_017_4.zip

Arduino Code:

https://sites.google.com/site/zitronfiles/KSPIODemo13.zip

Plugin link does not seem to work

Edit: Seems to be working now

Edited July 26, 2015 by Darkblade48
Additional information

[zitronen]

Thanks for that!

RE: The Arduino code -

This is the first update that's been rolled since I started using the arduino + plugin --

is it quicker/easier to copy/paste the relevant updated parts of the various tabs to what we have implemented?

Or is it better to just transfer our custom code into the updated arduino sketch / tab?

With this one it's easier to copy the code over to your own, since only 2 values were added.

Hey zitronen, could I bug you to update your git repository again? I'd like to keep marzubus' cross-platform fork up to date while they're MIA.

Done

Plugin link does not seem to work

Edit: Seems to be working now

Sorry I had a typo in the file name.

[stibbons]

Thanks. I've built a new cross-platform release - https://github.com/phardy/KSPSerialIO/releases/tag/v0.17.4-1

[Sputnix]

Problems with KSP_Serial_IO

Ok, so I noticed as I was doing some development near to my current 'code point' that I was getting some drop outs during flights.

I modified the config.xml so that:

Refresh is 0.3 (from default 0.2)

Default Port is COM3 (from default COM8, since my arduino board is detected as COM3)

BaudRate ios 115200 instead of default 38400

I picked up the idea for some of these values from a previous discussion on dropouts.

These values seemed to work pretty good with the previous version of KSPSerialIO.

I was however having issues (on occassion) at launch, where I wasn't getting data coming through to my controller.

This seemed to be tied more to the craft I was using (default, simpler craft seemed ok. My purpose-built more complicated craft seemed to have issues).

The new plugin seems to work once every now and then (seriously. It won't load / display anything on my controller by default. Then, on occasion, it will work).

I disabled everything (LCD / 7-segment Displays / Annunciator panel) - and only left the bare minimum controls (throttles, Stage / RCS / SAS buttons). Still nothing.

Reverting to the old plugin (including the updated DLL that you sent me Zitronen, when we were trouble-shooting the heat warning issue) everything works fine at launch.

I suspect there's some bug somewhere.

And yes, I copied over all the values (from the config file) and ensure everything else was the same (old plugin vs new).

I even went so far as commenting out the new additions to the data packet. Made no difference.

Edited July 27, 2015 by Sputnix

[stibbons]

Does it work better if you decrease the baud rate a little? Try 57600 or even 38400.

[Sputnix]

Does it work better if you decrease the baud rate a little? Try 57600 or even 38400.

I'm using the previous plugin, doing some coding + test flights at the moment.

No problems with that baud rate. However, just to humour everyone, I shall try the latest plugin with a lower baud rate.

Edit: No dice; I dropped it to 38400 - no change.

Edited July 27, 2015 by Sputnix

[stibbons]

I don't have a Windows machine handy, but I did just load up the KSPIODemo13 sketch on a spare Uno and got it syncing on my OS X machine with the plugin release I posted above, at 57600 baud. Not sure yet what could be wrong with your setup.

Still concerned it's got something to do with overflowing the serial buffer in the arduino, but it's a little late for me to logic very good.

[Sputnix]

I don't have a Windows machine handy, but I did just load up the KSPIODemo13 sketch on a spare Uno and got it syncing on my OS X machine with the plugin release I posted above, at 57600 baud. Not sure yet what could be wrong with your setup.

Still concerned it's got something to do with overflowing the serial buffer in the arduino, but it's a little late for me to logic very good.

No need to logic very good. You could logic very bad. Won't fix it

I changed it to what was working for you - 57600; Still no dice.

I go to launch, it displays "Starting Serial Port Com3" - I see tx/rx lights flash on arduino board. But no data coming through.

But, as I said - the older plugin (17.3) has been working fine all night.

I've just commented out the two new data sets - byte CurrentStage; & byte TotalStage;

And the code is working fine.

[zitronen]

Hmm... That's annoying, I can't reproduce it. Try the demo13 code on its own? Can you post the debug log, and share the craft file you are having problems with?

[Sputnix]

Hmm... That's annoying, I can't reproduce it. Try the demo13 code on its own? Can you post the debug log, and share the craft file you are having problems with?

I'll have to futz around with the demo to re-assign the various pin numbers in the morning (Midnight here in the Land Downunder ]

However, it seems to do it with all craft. I'm using Stock craft that come with the game for most of my testing.

This log is with Kerbal X.

As an aside, as I was getting this data, and responding, it suddenly came to life - probably about 00:21:00 (That's 21 minutes past midnight).

This log was started at 16 minutes past midnight.

So... incredible delay? Or something more obscure?

[LOG 00:16:00.671] AddonLoader: Instantiating addon 'SettingsNStuff' from assembly 'KSPSerialIO'

[LOG 00:16:00.676] KSPSerialIO: Loading settings...

[LOG 00:16:00.742] Parsing double

[LOG 00:16:00.742] Parsing string

[LOG 00:16:00.743] Parsing int

[LOG 00:16:00.743] Parsing int

[LOG 00:16:00.744] Parsing int

[LOG 00:16:00.744] Parsing int

[LOG 00:16:00.744] Parsing int

[LOG 00:16:00.745] Parsing int

[LOG 00:16:00.745] Parsing int

[LOG 00:16:00.746] Parsing int

[LOG 00:16:00.746] Parsing int

[LOG 00:16:00.746] Parsing int

[LOG 00:16:00.747] Parsing int

[LOG 00:16:00.747] Parsing double

[LOG 00:16:00.748] KSPSerialIO: Default Port = COM3

[LOG 00:16:00.748] KSPSerialIO: Refreshrate = 0.3

[LOG 00:16:00.749] KSPSerialIO: BaudRate = 38400

[LOG 00:16:00.749] KSPSerialIO: Handshake Delay = 2500

[LOG 00:16:00.750] KSPSerialIO: Pitch Enable = 2

[LOG 00:16:00.750] KSPSerialIO: Roll Enable = 2

[LOG 00:16:00.751] KSPSerialIO: Yaw Enable = 2

[LOG 00:16:00.751] KSPSerialIO: Translate X Enable = 2

[LOG 00:16:00.752] KSPSerialIO: Translate Y Enable = 2

[LOG 00:16:00.752] KSPSerialIO: Translate Z Enable = 2

[LOG 00:16:00.753] KSPSerialIO: Wheel Steering Enable = 2

[LOG 00:16:00.753] KSPSerialIO: Throttle Enable = 1

[LOG 00:16:00.754] KSPSerialIO: Wheel Throttle Enable = 2

[LOG 00:16:00.754] KSPSerialIO: SAS Tol = 0.1

[LOG 00:16:35.760] ExperienceSystem: Found 0 trait types

[LOG 00:16:35.763] ExperienceSystem: Found 9 effect types

[LOG 00:16:37.042] ScenarioTypes: List Created 12 scenario types loaded from 3 loaded assemblies.

[WRN 00:16:37.058] [HighLogic]: =========================== Scene Change : From MAINMENU to SPACECENTER (Async) =====================

[LOG 00:16:38.626] AddonLoader: Instantiating addon 'AddScenarioModules' from assembly 'KSP'

[LOG 00:16:38.627] AddonLoader: Instantiating addon 'ContractDefs' from assembly 'KSP'

[LOG 00:16:40.569] [scenarioDestructibles]: Loading... 0 objects registered

[LOG 00:16:40.573] Loading Depletion Nodes

[LOG 00:16:40.574] DepNodeCount: 0

[LOG 00:16:40.575] Loading Biome Nodes

[LOG 00:16:40.575] BiomeNodeCount: 0

[LOG 00:16:40.576] Loading Planet Nodes

[LOG 00:16:40.576] PlanetNodeCount: 0

[LOG 00:16:48.123] Flight State Captured

[LOG 00:16:48.133] Saving Achievements Tree...

[LOG 00:16:48.137] Saving Achievements Tree...

[LOG 00:16:48.137] Saving Achievements Tree...

[LOG 00:16:48.193] Game State Saved to saves/SANDBOX_KSPIO/persistent

[WRN 00:16:48.212] [HighLogic]: =========================== Scene Change : From SPACECENTER to FLIGHT (Async) =====================

[WRN 00:16:50.333] ApplicationLauncher already exist, destroying this instance

[LOG 00:16:50.340] AddonLoader: Instantiating addon 'NavWaypoint' from assembly 'KSP'

[LOG 00:16:50.344] AddonLoader: Instantiating addon 'KSPSerialPort' from assembly 'KSPSerialIO'

[LOG 00:16:50.347] KSPSerialIO: Version 0.17.4

[LOG 00:16:50.347] KSPSerialIO: Getting serial ports...

[LOG 00:16:50.348] KSPSerialIO: Output packet size: 191/255

[LOG 00:16:50.350] KSPSerialIO: Found 2 serial ports

[LOG 00:16:50.351] KSPSerialIO: trying default port COM3

[LOG 00:16:54.283] KSPSerialIO: found KSP Display at COM3

[LOG 00:16:54.284] AddonLoader: Instantiating addon 'KSPSerialIO' from assembly 'KSPSerialIO'

[LOG 00:16:54.338] ------------------- initializing flight mode... ------------------

[LOG 00:16:54.412] Target vessel index: 8 vessel count: 9

[LOG 00:16:54.414] [FLIGHT GLOBALS]: Switching To Vessel Kerbal X ----------------------

[LOG 00:16:54.417] setting new dominant body: Kerbin

FlightGlobals.mainBody: Kerbin

[LOG 00:16:54.419] Reference Frame: Rotating

[WRN 00:16:54.444] HighlightingSystem : Multiple Highlighter components on a single GameObject is not allowed! Highlighter has been disabled on a GameObject with name 'model'.

[LOG 00:16:54.920] [Kerbal X]: landed - waiting for ground contact to resume physics...

[LOG 00:16:54.925] Camera Mode: AUTO

[LOG 00:16:54.955] stage manager resuming...

[LOG 00:16:56.921] all systems started

[LOG 00:16:59.778] KSPSerialIO: Handshake received - 314

[LOG 00:17:00.027] [scenarioDestructibles]: Loading... 0 objects registered

[LOG 00:17:00.029] Loading Depletion Nodes

[zitronen]

Ok.. so the log looks completely normal. I'll do some more tests when I get back from work.

[nicosilverx]

I'm having some trouble with a 7 segment 4 digit display using the "SevSeg" library... How can I send data to the display? I'm trying with this code:

"

myDisplay.setNumber(VData.G,3);

myDisplay.refreshDisplay(); "

in the loop, but it doesn't work... someone can help me?

[zitronen]

Ok.. so the log looks completely normal. I'll do some more tests when I get back from work.

Ok I tested it with both an old arduino 328 and mega, all worked fine no problems at all career mode or sandbox. Maybe you can try increasing or decreasing handshake delay?

You can just load demo13 without hooking up anything, it should still connect ok.

[Sputnix]

Ok I tested it with both an old arduino 328 and mega, all worked fine no problems at all career mode or sandbox. Maybe you can try increasing or decreasing handshake delay?

You can just load demo13 without hooking up anything, it should still connect ok.

*sigh*

The default worked

Sorry for the run around. Doesn't make a whole lot of sense;

I'll review and revise my code and try work out what's happening.

Thanks for the confirmation.

With the new code, do I just have to add the two new vessel data variables to the list?

[Sputnix]

I'm having some trouble with a 7 segment 4 digit display using the "SevSeg" library... How can I send data to the display? I'm trying with this code:

"

myDisplay.setNumber(VData.G,3);

myDisplay.refreshDisplay(); "

in the loop, but it doesn't work... someone can help me?

I'd suggest using AmeilaEatYaHeart's custom 7-segment display function / code.

That is, assuming the displays use a MAX chip

[kungfufishstick]

Alright, I just want to make sure I have this correct for my shift registers.

I finally got around to making enough jumpers to accommodate all of the LEDs I plan on using and have all 3 shift registers daisy chained together.

There are a couple of things I'm not sure about.

Do I need a shiftOut line for each shift register?

Does the numbering for pins increase as you go up or is there a special numbering after you go through 0-7 pins?

After I got everything hooked up, the lighting has gone crazy. I have 23 LEDs for various indications and there are only 4 that are lighting up when you load into launch from the VAB.

EDIT:

When the code was working fine with just a single shift register, this was the code.

byte warningSet(byte warnings, byte n, boolean s) {
  if (s) {
    digitalWrite(LATCHPIN, LOW);
    warnings |= (1 << n); // forces nth bit to 1
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings);
    digitalWrite(LATCHPIN, HIGH);
  } else {
    digitalWrite(LATCHPIN, LOW);
    warnings &= ~(1 << n); // forces nth bit to 0
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings);
    digitalWrite(LATCHPIN, HIGH);
  }
  return warnings;
}

I changed it to this to try and get the LEDs to light up properly.

byte warningSet(byte warnings, byte n, boolean s) {
  if (s) {
    warnings |= (1 << n); // forces nth bit to 1
    digitalWrite(LATCHPIN, LOW);
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings);
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings>>8);
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings>>16);
    digitalWrite(LATCHPIN, HIGH);
  } else {
    warnings &= ~(1 << n); // forces nth bit to 0
    digitalWrite(LATCHPIN, LOW);
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings);
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings>>8);
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings>>16);
    digitalWrite(LATCHPIN, HIGH);
  }
  return warnings;
}

For numbering, it looks something like this for turning the LED on for a given condition.

(simply taken from void initLEDS() but it is the same in each if statement for warnings and cautions)

warnings = warningSet(warnings, 0, true);
    warnings = warningSet(warnings, 1, true);
    warnings = warningSet(warnings, 2, true);
    warnings = warningSet(warnings, 3, true);
    warnings = warningSet(warnings, 4, true);
    warnings = warningSet(warnings, 5, true);
    warnings = warningSet(warnings, 6, true);
    warnings = warningSet(warnings, 7, true);
    warnings = warningSet(warnings, 8, true);
    warnings = warningSet(warnings, 9, true);
    warnings = warningSet(warnings, 10, true);

Edited July 28, 2015 by kungfufishstick
Additional information

[stibbons]

All of your current problems are happening because your warnings variable is a byte, only 8 bits long, and you're trying to read and write more than that. It's a textbook example of a buffer overflow.

There are a couple of approaches you could take to fix this. One is to use three byte variables, one representing the contents of each shift register. You'd then number the bits of each variable 0-7, and just shift each out in turn when you need to. This is the approach I'd take, mostly because associating one shift register with one variable makes sense to me. But I would take it a little bit further by using a single array of byte, like

byte warnings[3];

(incidentally, the thought of having registers chained together using an array of bytes like this is one reason why I suggested not calling shiftOut in the warningSet function yesterday )

There is another option that springs to mind, and your code is almost all of the way towards implementing it. You can use a larger data type for the warnings variable, and then shift out chunks of it at a time. For three shift registers you need 24 bits. There's no native 24 bit data type, but there are a few that are 32 bits. I would suggest using an unsigned long. I think just changing the type of warnings like this is enough to get your code working

unsigned long warnings;

It's worth pointing out, though, that the Arduino shiftOut docs shift out in the opposite order to what you're doing. If you're still getting unexpected results it might help to switch that around.

Edited July 28, 2015 by stibbons

[zitronen]

*sigh*

The default worked

Sorry for the run around. Doesn't make a whole lot of sense;

I'll review and revise my code and try work out what's happening.

Thanks for the confirmation.

With the new code, do I just have to add the two new vessel data variables to the list?

Yes the only difference is 2 more bytes. Have you tried reducing the refresh rate further?

[kungfufishstick]

All of your current problems are happening because your warnings variable is a byte, only 8 bits long, and you're trying to read and write more than that. It's a textbook example of a buffer overflow.

There are a couple of approaches you could take to fix this. One is to use three byte variables, one representing the contents of each shift register. You'd then number the bits of each variable 0-7, and just shift each out in turn when you need to. This is the approach I'd take, mostly because associating one shift register with one variable makes sense to me. But I would take it a little bit further by using a single array of byte, like

byte warnings[3];

(incidentally, the thought of having registers chained together using an array of bytes like this is one reason why I suggested not calling shiftOut in the warningSet function yesterday )

There is another option that springs to mind, and your code is almost all of the way towards implementing it. You can use a larger data type for the warnings variable, and then shift out chunks of it at a time. For three shift registers you need 24 bits. There's no native 24 bit data type, but there are a few that are 32 bits. I would suggest using an unsigned long. I think just changing the type of warnings like this is enough to get your code working

unsigned long warnings;

It's worth pointing out, though, that the Arduino shiftOut docs shift out in the opposite order to what you're doing. If you're still getting unexpected results it might help to switch that around.

I'm right back into not quite understanding what is going on.

I gave unsigned long for warnings a shot (I keep trying to figure out array but it is just flying right over my head). I set up warningSet a couple of different ways.

byte warningSet(byte warnings, byte n, boolean s) {
  if (s) {
    digitalWrite(LATCHPIN, LOW);
    warnings |= (1 << n); // forces nth bit to 1
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings);
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings>>8);
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings>>16);
    digitalWrite(LATCHPIN, HIGH);
  } else {
    digitalWrite(LATCHPIN, LOW);
    warnings &= ~(1 << n); // forces nth bit to 0
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings);
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings>>8);
    shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings>>16);
    digitalWrite(LATCHPIN, HIGH);
  }
  return warnings;
}

I also tried switching the order of the shift out so that it went warnings, warnings>>8, warnings>>16 with no change.

I did read over what you said, but I am not sure where the shiftout would go within void indicators.

I am going to go ahead and hope that I don't have to put a shiftOut function within every if statement.

So how would it be able to interact with the warnings within the if statements if it is not within each if statement or within warningSet?

Would the shiftOut go after all of my if, else statements? This is the only thing I can think of. Since void indicators() will run down each if else statement in turn, and then it can spit out the results when it reaches the shiftout section.

I have my if statements set up in a pattern like this:

if (fuelcaution != 0 && fuelwarning == 0)    
    warnings = warningSet(warnings, 0, true);
  else
    warnings = warningSet(warnings, 0, false);


  if (fuelwarning != 0)                     
    warnings = warningSet(warnings, 1, true);
  else
    warnings = warningSet(warnings, 1, false);

I don't think I can put the shiftOut before the if, else statements, and it doesn't make sense to me that it would go after all of them. Each if, else calls on warningSet and it does its thing......unless I just had a light bulb and the result of warningSet running its course for every if, else statement is being held for the duration of void indicators until a shiftOut is reached (before the void cycles through again).

I will give an array a try. I want to make absolutely sure that I can't figure it out myself before I take the time to add a bunch of 2s and 3s to set it up so that I have warnings2 and warnings3 to go with new warningSet2 and warningSet3.

I will do a bunch of trial and error for an array (most likely error unless I get very lucky stumbling through it).

EDIT: Alright, I put

digitalWrite(LATCHPIN, LOW);
shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings>>16);
shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings>>8);
shiftOut(DATAPIN, CLOCKPIN, MSBFIRST, warnings);
digitalWrite(LATCHPIN, HIGH);

At the end of void indicators(), initLEDS(), and LEDSAllOff(). The good news is that there is no more dim flickering across all the LEDs. The bad news is that only LED 7 for gear works properly.

EDIT 2: One last update. I did everything I could think of and even tried to adapt things I found in google searches. Nothing got it to function properly when the registers were chained together.

I threw my hands up in frustration and decided that was a terrible choice as well. I have the shift registers defined separately and and hooked up properly (I think).

Something is going wrong. Only the first register is functioning properly. The other two have arbitrary LEDs lighting up and they aren't changing to reflect a state change.

After getting the shift registers hooked up on their own pins, this is all that I did:

added byte declarations for warnings2 = 0, warnings3 = 0;

split the 23 LEDs into 3 groups of 8, 8, and 7 bits

wrote up 2 additional byte warningSet and named them warningSet2 and warningSet3

Everything is coded the same for warnings2 and warnings3 (same for warningSet2/warningSet3) but changed to work with the right group (warnings2, latchpin2, clockpin2, datapin2). My only guess to the issue is that I used a number in the name for the different declarations, since warnings and warningSet do not have a number in their name.

I'm tired after fighting with this code all night. It's bed time. Hopefully someone has an answer, and hopefully not something that I am going to smack myself when I get it for being too stupid to realize it.

Edited July 29, 2015 by kungfufishstick
Additional wording

[stibbons]

Sorry I wasn't quite clear before. In theory it would have worked if you changed all the types from byte to long. But that's probably by the by now.

I'm not sure what might be going wrong now. Putting numbers in the function and variable names is fine. If you'd like, upload all of the code you've written to pastebin or something and I can take a look at it.

[kungfufishstick]

Sorry I wasn't quite clear before. In theory it would have worked if you changed all the types from byte to long. But that's probably by the by now.

I'm not sure what might be going wrong now. Putting numbers in the function and variable names is fine. If you'd like, upload all of the code you've written to pastebin or something and I can take a look at it.

Its alright. I tried my hardest to get it working. I will put the code up somewhere tomorrow after I swap out the jumpers for register 2 with ones that I didn't make myself to rule that possibility out. Ill also just send you a message, rather than plastering big posts all over zitronen's post for this plug-in. When this whole mess gets sorted out, I will just put up a link to how it was sorted out. I feel kind of bad about the wall of text from that last post.

[PyG_]

HI ! First think it's an amazing idea this mod thanks you !

I've test the with the KSPIODemo13 and KSPSerialIO_Mac_Linux_Win_0.17.4-1

Arduino Uno R3. The 3 LEDS works perfectly, input buttons too. RCS/SAS Leds works.

My problem it's when i plug my I2C 20x4 Screen. The 5 leds stop working, LCD get 1 initale data and second line: ovfl

It's supose to do (0,0) RAlt (0.1) Alt.

after nothing work.

If i unplug the screen leds restart.

I2C is pluggued in A4/A5 VCC/GND

Part of my code:

#include <Wire.h>

#include <LiquidCrystal_I2C.h>

#include <LCD.h>

#include <SPI.h>

#define I2C_ADDR 0x27

#define BACKLIGHT_PIN 3

#define En_pin 2

#define Rw_pin 1

#define Rs_pin 0

#define D4_pin 4

#define D5_pin 5

#define D6_pin 6

#define D7_pin 7

LiquidCrystal_I2C lcd(I2C_ADDR, En_pin, Rw_pin, Rs_pin, D4_pin, D5_pin, D6_pin, D7_pin);

// ... default code ... //

void setup() {

Serial.begin(115200);

lcd.begin (20,4);

lcd.setBacklightPin(BACKLIGHT_PIN,POSITIVE);

lcd.setBacklight(HIGH);

lcd.home ();

initLEDS();

InitTxPackets();

controlsInit();

LEDSAllOff();

}

void loop()

{

input();

output();

lcd.setCursor(0,0);

lcd.print(VData.RAlt, 2);

lcd.setCursor(0,1);

lcd.print(VData.Alt, 2);

}

Nothing else in code change and screen work without trouble in other projets o.O

Thanks for help =)