Getting compass and LCD to load on Orion


Hi MB community!

I’ve found that if you want to use both the MeCompass and MeTFT, you have to call the compass BEFORE you call the software serial of the TFT. I’d love to know why, but this seems to be the case


Hi BigAl,

Could you please kindly describe this issue with more details.
Do you mind to paste your program here?


Hi Tec,
There is no issue now. On another post, I described in detail the problem I was having. MeTFT and MeCompass were both on an Orion board. If I initialize the compas before the TFT, the program hangs when you first try to read from the compass. I searched and found, on YouTube, where another user has built a similar bot. I got his code and hee loaded the compass first. I switched my code and it all worked.
I had tried each one by itself, using the examples from the makeblock library and each worked, do i was sure it was a coding issue.
I wrote the faq so others might be able to fix the same issue.
Have a good day!


Hi BigAl,

Great to hear that!
Thanks for your sharing which would help other customer who has similar issue.

Best Regards!


I may have spoken too soon on this. I can get them to LOAD, but getting them to actually work is a bear. I’ve documented this in another thread about the compass and TFT being on the same bot, but there doesn’t seem to be any answers forthcoming.

I’m wondering - since I’ve seen issues about wiring.h and software serial.h on arduino forums - if there are memory issues. The compiler tells me there’s very little memory left and all I’ve done so far is get the two to work. I’ve had to separate out every instance where the TFT is called in the same function as the compass. If I don’t, it simply freezes. And in no way can I seem to get serial, software serial and compass to all work on the same sketch. Frustrating.

I’m new to Arduino programming, but not to programming. So I could be (am) making mistakes. Any suggestions are welcome.



I finally had a chance to look into this. Here is a modified sample program that I manager to get working on my Orion.

 * \par Copyright (C), 2012-2016, MakeBlock
 * @file    MeCompass.ino
 * @author  MakeBlock
 * @version V1.0.0
 * @date    2015/09/09
 * @brief   Description: this file is sample code for Me MeCompass device.
 * Function List:
 * 1. void MeCompass::init(void)
 * 2. double MeCompass::getAngle(void)
 * \par History:
 * <pre>
 * <Author>     <Time>        <Version>      <Descr>
 * Mark Yan     2015/09/09    1.0.0          rebuild the old lib
 * </pre>
#include <MeOrion.h>
//#include <Wire.h>
#include <SoftwareSerial.h>

MeCompass Compass(PORT_3);
MeSerial myTFT(PORT_4);

void setup()
  Serial.println("Initializing I2C devices...");
  Serial.println("Testing device connections...");
  Serial.println(Compass.testConnection() ? "HMC5883L connection successful" : "HMC5883L connection failed");
  myTFT.print("CLS(0);"); // clear the screen
  myTFT.println("DR0;");    // the screen displays in upright way

void loop()
  int16_t head_X, head_Y, head_Z;
  double angle_number = 0;
  head_X = Compass.getHeadingX();
  head_Y = Compass.getHeadingY();
  head_Z = Compass.getHeadingZ();

  angle_number = Compass.getAngle();
  Serial.println(angle_number, 1);
  myTFT.print("DS64(0,0,'Angle: ");
  myTFT.print(angle_number, 1);

I hope this is what you are looking for.



Hey Mike
Thanks for your feedback here! One question… You have Wire.h commented out? I thought MeCompass needed the library.
Does the heading call result in a valid heading? I’m fairly certain the problem is memory, but if I can kill Wire, I doubt that will be a problem.



<wire.h> does not seem to matter. The code compiles to the same size with or without it, and I haven’t noticed any change in functionality.


Note: I have not tried calibrating the compass, but I am getting a full range of numbers.


I tried, commenting out wire.h just wouldn’t compile. But I do have it working and I’ve reduced memory footprint, so perhaps it’s simply a memory issue.
Still, I cannot mix myTFT calls with ANY attempts to use the compass in the same function. I wonder a) if they can’t both be communicating at the same time and b) if there are (right now) unknown port constraints. In other words, would a certain combination of ports work better than others.
I’m too new to all this to have cogent answers (or even questions, frequently) to these problems.



Could you post a copy of your code so I can see what you are working with? Copy / Paste your code into your reply, then select the code and click the </> icon to put it into a code block. That way the code will format properly.




Sent you a PM.


Many thanks to Mike here. He did a bunch of testing of his Orions and found it was a port issue. While I COULD get mine going with the compass in port 8 and TFT in 3, it was very inconsistent and would freeze for no apparent reason.
Today it froze and wouldn’t unfreeze so I took Mike’s suggestion. Moved compass to port 4 and TFT to port 3. Unlike before, everything worked snappy quick! No unexplained freezes or delays.
Now I can work on actually getting the thing to move again. Once I get wifi working on it…

Thanks for all your testing!!!


(reference for the previous post)

I had some trouble getting your code to work. It took a lot of testing, but here is what I found out.

Your code works just fine, IF you change the Compass to port_[3,4,6]. I could not get it to work on port_5 (connection failed), nor would it work on port_[7,8] (appears to be in calibrate mode). I tested this on 2 of my Orion boards with the same results. It appears that the MeCompass prefers blue over white (I have no idea why).

The MeTFT seems to work fine on any blue port, as long as you use .begin(9600).

Again, I found no difference when using or commenting the #include <wire.h>.

I made no other changes to the code.