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

[stibbons]

7 hours ago, zitronen said:

I think @stibbons got a working navball on a 32bit teensy, he can probably tell you what he did to struct packing.

I am running running stuff on a 32 bit teensy (with a Cortex-M4, as opposed to the Due's M3), but the source for the data packets in that sketch shows I'm not doing anything special with the struct packing.

It's worth pointing out that my teensy doesn't plug in to a serial connection, though. It's having VesselData packets sent to it over I2C from another microcontroller.

2 hours ago, c4ooo said:

Is the bottleneck the fact that an arduino cant really drive an LCD or is it your 3D drawing code?

The bottleneck is just that an 8 bit microcontroller is being used to do software 3D transforms. Eyeballing @boostme's code shows tells me that they're using integer math, which makes their code run much faster than mine - I was nowhere near 10fps on my Uno. But the same code runs at upwards of 40fps when I use a Teensy 3.2 to do the drawing. Considering I have the game sending data at 12.5fps it's a very suitable arrangement.

[c4ooo]

Ahh ok. Briefly glancing at his code though, there are some things he could optimize  For example, calculating and storing the Sin() and Cos() values for pitch yaw and only roll once every frame, instead of every time a point is drawn. 

[boostme]

The struct packing indeed fixed it.

The FPS limit is all about how fast the  CPU can get pixels to the LCD. As I recall @stibbons uses an LCD controller that does drawing primitives without CPU intervention.

On the Due the 3D calculations only take about 8 ms. I've stripped out all FP calculations already. The rest of the time it is shifting pixels.

I'm currently drawing a wireframe at 12 FPS and filling it at 3 FPS. The result is only slightly weird.

I'm also toying with only updating one half of the wireframe every frame - a weird kind of 3d interlacing, if you will. That should (effectively) double the FPS.

As it is the trig functions are merely table lookups. Cacheing values between point calculations would merely mean that you now get the value from a different memory location - no change in speed.

Edited December 3, 2016 by boostme
more thoughts

[Mattew]

@stibbons  plugin sends data at rate 12.5 fps? How you get this number?

[stibbons]

49 minutes ago, Mattew said:

@stibbons  plugin sends data at rate 12.5 fps? How you get this number?

The refresh setting in the config file sets time between packets in seconds. I set that to 0.08,but I suspect the default these days is a little higher than that. 

[boostme]

The Mega only managed 10 FPS with a wireframe ball. The Due happily does 12.5 with a filled in ball and 20 with a wireframe.

I'm cheating slightly with the filling, but it's hardly noticeable. I'm filling the triangles next to the equator on every frame, and I let the others lag.

I also thought I'd try a full openGL 3D-rendered ball on a Raspberry Pi-3, but only got around 4 FPS on a very low-res ball.

[Mattew]

Ooooh, I get it now   My IO runs ast 0.2 refresh rate. Work okay. Never bothered to go higher to be honest  

And you, Navball masters, how hard is to get angle to vector?  number tha tell me if I point to vector or somewhere else. 

[zitronen]

Update 0.18.6:

Changes:

• Added navball mode input and output (again thanks to @c4ooo, hero of the republic)
• Note for 18.5 users: changes were made to setting & reading SAS modes because it shares the byte with navball modes (we save 1 byte), see below for how to use SAS mode now
• Added easy to use functions to set and read SAS and navball modes

//Navball Target Modes
#define NAVBallIGNORE   0
#define NAVBallORBIT    1
#define NAVBallSURFACE  2
#define NAVBallTARGET   3

New functions:

byte getSASMode() {
  return VData.NavballSASMode & B00001111; // leaves alone the lower 4 bits of; all higher bits set to 0.
}

byte getNavballMode() {
  return VData.NavballSASMode >> 4; // leaves alone the higher 4 bits of; all lower bits set to 0.
}

void setSASMode(byte m) {
  CPacket.NavballSASMode &= B11110000;
  CPacket.NavballSASMode += m;
}

void setNavballMode(byte m) {
  CPacket.NavballSASMode &= B00001111;
  CPacket.NavballSASMode += m << 4;
}

Arduino code example for changing mode:

setSASMode(SMSAS); //setting SAS mode
setNavballMode(NAVBallSURFACE); //setting navball mode
      

if (getSASMode() == SMPrograde) { //--------- This is how you read SAS modes
	//Blink LED, do stuff, etc.
}

if (getNavballMode() == NAVBallTARGET) { //--------- This is how you read navball modes
	//Blink LED, do stuff, etc.
}

Download link:

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

Arduino code:

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

Edited December 4, 2016 by zitronen

[c4ooo]

Mistake spotted in your example code

getNavBallModr() should be "return VData.NavballSASMode >> 4". The way you have it, the function returns 16, 32, or 48, not 1, 2, and 3

Thanks for the merge

[zitronen]

Oh s*** you are right, I updated the file.

[Freshmeat]

Man, I am running behind times now. Got to find time for a serious hardware/software update.

[Mattew]

Yeah pretty much. We are getting major updates faster then I can draw schematics for said changes   Good job!

On topic of updates. I start working on DUE for KSOIO and some crazy magic happend and Due is talkting to pluggin using its original Atmega16U2 as USB-TTL convertor, like there werent any issue on W10 at all. No need of CH340 (it actualy wasnt able to establish link using ch340, handshake failed).  I dont know how or why. Dont ask   Note that there isnt any hardware connected to Due board atm, but getting succesful handshake is engought I think

[JoshTheCoward]

On 11/29/2016 at 5:20 AM, Freshmeat said:

The problem is driver based, so the plugin cannot fix it. A workaround is to purchase a USB to TTL converter based on a different chip and connect tx, rx to Dig0 and Dig1, and +5V and GND to Vin and GND instead of USB to Arduino.

Sorry I am new to this, I apologize if this is a dumb question. Is the drivers for the arduino? Would the Leonardo be affected too?

 

Edit: Never mind tried Arduino Leonardo on Win10 and it works perfect! Thanks so much guys cant wait to finish my build.

 

Edit 2: Works perfect on my Mega 2560 as well on Win10

Edited December 5, 2016 by JoshTheCoward

[Freshmeat]

8 hours ago, JoshTheCoward said:

Sorry I am new to this, I apologize if this is a dumb question. Is the drivers for the arduino? Would the Leonardo be affected too?

 

Edit: Never mind tried Arduino Leonardo on Win10 and it works perfect! Thanks so much guys cant wait to finish my build.

 

Edit 2: Works perfect on my Mega 2560 as well on Win10

It so happens that several knock-off arduinos use a different usb-ttl converter chip from the original, and those work with win 10. Gratulation on having one of those  

[Mattew]

Uuuu, sooo I did connected I2C 4x20 lcd to my Due and I can confirm that it is getting data from pluggin while using on-board Atmega16U2 (running w10) while Uno with same configuration did not (not trying both boards at same time ofc). Anybody have idea what is going on? May 32-bit Due architecture have something to do with it? I did tiny changes in code but those are mainly for stability and 32bit compatibility.

[stibbons]

It's not likely that changes in KSP 1.2 / 1.2.1 had any effect on the serial comms. But if the Arduino IDE has updated recently it may include newer 16U2 serial drivers that play nicely with our serial library? It would be interesting to check it with an Uno or similar.

[Benji]

With this fix, faster baudrate (115200) and a Due I'm finally able to use this fabolous plugin on Win10.

On 2.12.2016 at 7:30 AM, Mattew said:

Somebody talk about that several pages back. Mega2560 is 8-bit and SAM3X on Due is actualy 32-bit mCu. There are required some changes in code to make it work I think.

Found it.

Critical thing for anybody moving to 32 bit CPUS is that you need to add

struct __attribute__((__packed__)) VesselData

To your message structure definition in the Arduino code, otherwise all the bytes in the message get mixed together.

I get it what problem is going on but i dont get it how to fix it

I can confirm receiving data from KSP by letting this onboard LED show if SAS is on or off.

Also the Due is able to run a TFT Display without causing deconnects.

 

The only thing that doesn't work is sending data. Wasn't it easy as putting something like this ...
    CPacket.Throttle = 1000;
    CPacket.Pitch = 1000;
    CPacket.Roll = -300;

...into void controls() ?

Edited December 6, 2016 by Benji

[Mattew]

Uuum,  Houston, we've had a problem here. I did try send data to game and no succes. Not over Atmega16U but no luck with CH340 either. I am trying do what is already in demo (RCS on/off)  by pulling pin 9 LOW (pin 9 to gnd) wich should activate or deactivate RCS, is that right? Reciving is still fine either on Mega16U or CH340. But send data? Nothing. Any idea what to try? I again thinks its bcs of Due´s 32-bit architecture. Somehow.

[zitronen]

Did you add the stuct packing instructions to both the receiving and sending packets?

[Mattew]

Yeah I did. Nothing changes. I also did try change all uint8_t to uint32_t in KSPsenddata in serialCOM tab. No change and i got random disconnects so i reversed changes. Maybe there are needed some changes in reciving end (pluggin itself) to get work on 32bit?

 So all teensy, due guys did not talk directly to pluggin, is that right?

Is "struct __attribute__((__packed__)) ControlPacket" is right? 

[Benji]

44 minutes ago, Mattew said:

Yeah I did. Nothing changes. I also did try change all uint8_t to uint32_t in KSPsenddata in serialCOM tab. No change and i got random disconnects so i reversed changes. Maybe there are needed some changes in reciving end (pluggin itself) to get work on 32bit?

 So all teensy, due guys did not talk directly to pluggin, is that right?

Is "struct __attribute__((__packed__)) ControlPacket" is right? 

I tried this struct__attribute... on the ControlPacket too.

No succes for the Due. Receiving is still working.

[zitronen]

Are you using KSP 1.2.2? Does it work with 1.2.1? I can't replicate the problem, can only guess...

[Benji]

7 hours ago, zitronen said:

Are you using KSP 1.2.2? Does it work with 1.2.1? I can't replicate the problem, can only guess...

Ohhh, was it "self-updating" again. I thought I had deactivated this.

The Daily Kerbal didn't mention it, or did it? Aha, It's in Announcements now.

Obviously I'm on 1.2.2 now. Didn't know.

 

But as I tried last time, I was still on 1.2.1 . Using Demo16 and 0.18.6 .

Will try again tomorrow. It's very A.M. here.

 

Edited December 9, 2016 by Benji

[Mattew]

oh damn. I didnt know we have new KSP version. It was realy at wednesday? Asking bcs my Due had issues even before that. I start working on it like on tuesday.  

But let me think an loud here. If I understand it correctly then  "__attribute__((__packed__))" for Vessel Packet make Arduino be like "hey, wait until whole data packet is recived and THEN start reading it". So if this is for data recive in arduino, should not be same thing in computer, in pluggin, when arduino send data (control packet) to pc? Or it doesnt matter for pc if data are send as 8-bit or 32-bit?

Still hoping for Teensy guys to save us

Weekend is starting so I can test any suggestion or idea you have  

[zitronen]

struct padding has to do with how things are stored in memory. On 32bit, when you have a struct with some bytes the compiler can choose to add padding so each individual property are 32bit long instead of 8. This is done not to just make our lives miserable, but for performance reasons. So something like

struct {
byte A //compiler will add padding to make this 32 bits
long B
}

end up taking 64 bits in memory instead of 40 bits as you would expect. Obviously if you try to copy data into the struct like we are doing and the struct is not the right size you will get the wrong result. "__attribute__((__packed__))" forces the compiler to make the struct as small as possible.

Edited December 9, 2016 by zitronen