IOP-DEV-OPTOMMP-LX Integer Data Types and Sizes

Hi All, I am currently working on a project to remote control an excavator via an Ethernet link. The hydraulic valves are controlled by a SNAP PAC R-1, which is connected to a wireless bridge to a control PC running ROS (robot operating system). The system is presently operational and I can control the position of the hydraulic arm using a joystick.

I have been using the “IOP-DEV-OPTOMMP-LX” kit, which works but I am concerned that the data types will not translate well if we decided to use the code on a different platform (e.g. an ARM-based single board computer). The code uses data types like LONG, which are ok, but it also uses “long” as well (I am compiling the code on a 64-bit machine so I’m not exactly sure what effect this has on the code). What are the assumed widths of the data types used (short, int, long)? Are they the same as the Windows standard data types as defined in “Windows Data Types”? If so I can use cstdint, like below (these examples may not be correct, they are off the top of my head). This example may not work in Windows but it will work in Linux, which is the platform I am most interested in at the moment.

#include <cstdint>

typedef std::int32_t LONG;
typedef std::int16_t SHORT;
typedef std::uint8_t BYTE;

The method of connecting to the PAC may also be different but I am more interested in the data type sizes right now.

Any advice appreciated.

Kind Regards
Bart

Hi bjm128,

Welcome to the forums.

I’m a bit of a hack programmer, but from what I understand, the data type lengths are defined by the compiler, not the toolkit.
(I think that’s why you are asking the question).
The toolkit is provided as a framework, it will save you some time, but wont necessarily fit every application or platform.
Since you are talking Windows, Linux, Intel, ARM, 32 bit and 64 bit, your compiler and source code is going to have to change to suit each combination.

Cheers,

Ben.

Hi Ben, everything you say is correct, although there’s a conflict in the code because it’s mixing toolkit defined data types (SHORT, LONG, etc.) with compiler defined data types (short, long, etc.). In O22SIOUT.h we have the following data type definitions:

// The different basic data types that will be used
typedef short               SHORT;
typedef long                LONG;
typedef unsigned short      WORD;
typedef unsigned long       DWORD;
typedef unsigned char       BYTE;
typedef float               FLOAT;

and the following piece of information about the platform it was developed on:

// While this code was developed on Microsoft Windows 32-bit operating 
// systems, it is intended to be as generic as possible.  For Windows specific
// code, search for "_WIN32" and "_WIN32_WCE".  For Linux specific code, search
// for "_LINUX".

That’s completely fine by me. If I want to compile the code for a specific platform I need to change the underlying types for SHORT, LONG. The conflict comes in when some functions mix the defined width types and native types, such as:

LONG O22SnapIoMemMap::OpenEnet2(char * pchIpAddressArg, long nPort, long nOpenTimeOutMS, long nAutoPUC, long nConnectionType)
//-------------------------------------------------------------------------------------------------
// Open a connection to a SNAP Ethernet I/O unit
//-------------------------------------------------------------------------------------------------
{
  m_nAutoPUCFlag    = nAutoPUC;
  m_nConnectionType = nConnectionType;

  return OpenSockets(pchIpAddressArg, nPort, nOpenTimeOutMS);
}

The parameter nAutoPUC is given as a long but m_nAutoPUCFlag is a LONG, but the assignment is made directly without a cast.

My question is which data type definition takes priority? Should I interpret LONG as being a 32-bit integer to be consistent with the Windows definitions and the (I presume) goals of the developers, or should I keep it the same data type as long, so that mixing types in the code won’t cause any problems?

Thanks for your advice
Bart