HTCC_AB01 Compile Problem

#1

Hi All,

New to the world of AB01s…

Having a bit of an issue when trying to compile an arduino sketch for the AB01_V2. I have run through the install process etc but getting this error:
"In file included from c:\users\geoff\appdata\local\arduino15\packages\cubecell\tools\gcc-arm-none-eabi\8-2019-q3\arm-none-eabi\include\c++\5.4.1\cstdint:35:0,
from d:\User\Geoff\Documents\Arduino\libraries\AESLib\src/AESLib.h:12,
from C:\Users\Geoff\Desktop\DeviceNet V2.0\DeviceControllerServer\DeviceControllerServer\Message.h:6,
from C:\Users\Geoff\Desktop\DeviceNet V2.0\DeviceControllerServer\DeviceControllerServer\DeviceControllerServer.ino:3:
c:\users\geoff\appdata\local\arduino15\packages\cubecell\tools\gcc-arm-none-eabi\8-2019-q3\arm-none-eabi\include\c++\5.4.1\bits\c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support "

Given it is one of the Heltec files referenced in the error and I would have thought compiler support was provided through the install process, I’m scratching my head a little. Here is a bit of the reference code:
#include <SPI.h>
#include <RH_RF95.h>
#include “Message.h”
#include “LoRa_APP.h”
#include “ASR_Arduino.h”

Any suggestions?

#2

The most immediate problem with the “bit of reference code” that you provide is that I’m not sure what you’re doing using both the RH_RF95.h and LoRa_APP.h libraries—the former appears to be a library for the HopeRF [SX1276] LoRa node IC while the latter is the Heltec LoRa library that supports the SX1262 LoRa node chip in the CubeCell. I can’t immediately see how this might relate to the error messages you have reported, but it’d be no surprise to me if this was causing a problem somewhere along the line.

Either way, I think we might need to know a bit more about your operating environment and the code that you are trying to compile to offer any more useful suggestions.

#3

Hi Pete,

Thanks for the response. Yes indeed I had an attack of the fat fingers and left both lora libraries in the reference list. I also missed the fact that RH only does SX1276 - I assumed it did the newer boards as well but hadn’t checked. As a result, I have updated my code so it only uses the LoRa_APP.h lib. Unfortunately it still wont compile, I believe this is due to the AESLib have been using for message encryption. This worked great with my Uno boards and the SX1276 shield but the form factor sucks hence the desire to move to the HHTC-AB01. For some reason it is still throwing the original error. AESLib is calling cstdint from the cubecell packages and for some reason the compiler doesnt like it.

Here is a few bits of the new code from:
#include <SPI.h>
#include <LoRa_APP.h>
#include “Message.h”

    #define BAND    915E6  // 915MHz band
    #define PABOOST true

    //Constants an stuff here...

    void setup() 
    {
      ...
      
      Serial.begin(9600);
      while (!Serial) ; 
      if (!LoRa.begin(BAND, PABOOST)) {
        Serial.println("init failed");
      } 
    else 
    {
            Serial.println("init success");
          }
        
      LoRa.setTxPower(20, RF_PACONFIG_PASELECT_PABOOST);
      

    }

    void loop() {
      if (LoRa.parsePacket())  // Check for incoming packet
      {...}

Here is the class that calls the encryption stuff:
#ifndef MESSAGE_H
#define MESSAGE_H

#include <stdint.h>
#include <Arduino.h>
#include <AESLib.h>
#include <string.h>

// Message structure constants

...


// Message structure

struct Message {

    ...

};

// Deserialize result enum

enum class DeserializeResult {

    ...

};

// Unencrypted message functions

DeserializeResult deserializeMessage(const uint8_t* buffer, Message& msg) {
    ...
}

void serializeMessage(const Message& msg, uint8_t* buffer) {
    ...
}

// Encrypted message handling

class MessageEncryption {

...

        }

    }

...

    }

   

    static DeserializeResult decryptMessage(const uint8_t* buffer, Message& msg) {

        ...

        }

       

        // Unpack message

       ...

       

        return DeserializeResult::Success;

    }

};
...
...

}

#endif // MESSAGE_H
#4

Sorry had a few formatting issues with my response

#5

Without any more info, I don’t really know what AESLib is doing and whether it might have some processor dependency—that’d be the first thing to check.

But your call to LoRa (as in LoRa.begin(…)) looks like a call to an SX1276 library, not something supported by the LoRa_APP [SX1262] library. You should probably have a look at the CubeCell factory test sketch (under Examples in the Arduino IDE) for details on how to use the LoRa_APP library calls. This discussion might also help understand the difference.

#6

Hi again,

Thanks Pete, yes I was still running my original SX1276 code - bit of an oops. Have now adjusted the code but still have the compile issue. A few goofy things with it so I will tidy it up but a bit hard to check the behavior since it wont compile. Is there an encryption lib known to work with the HelTec CubeCells? I was going to try out the newer Arduino Cryptography Lib but don’t want to waste my time if there is a decent go-to for the community.

#7

I’ve not used encryption in any of my appliations so, sorry, I can’t help there.

#8

If you use a LoRaWAN library, that’ll handle the encryption for you (given that you’d want to use LoRaWAN).