64 bit Windows

[Bart Vanhauwaert]

Hello all,

I was wondering if it is possible to compile the OpENer library easily as 64 bit with Visual Studio?

cu bart

[Bill McCormick]

Visual Studio makes a lot of things "easy", but I suspect this wouldn't be one of them.

This might be helpful.

[Bart Vanhauwaert]

I should have been more accurate. My apologies. I do not want to use Visual Studio, I want to use the Visual Studio Compiler.

For now I'll see if I can get away with just creating a Visual Studio project file with all .c and .h files in there and defining RESTRICT and WIN32 by hand. Anything else I should watch out for?

Kind regards

Bart

[Bill McCormick]

I use gcc, so I have no idea what you'll run into. Just curious though, why spend time blazing some new use with VS compiler when you could just use gcc/mingw and have something working in short order?

[Martin Melik-Merkumians]

Have you just tried to generate a 64 bit Visual Studio Solution with CMake?

The definition for RESTRICT and WIN32 are in the CMake files, as these definitions are dependent on the compiler chain used (gcc vs. MSVC) and on the comiler (C++ does not know the restrict keyword)

In principle, you can copy the support files for the WIN32 build (which is also more a historical name for Windows builds), and change the according parameters in the CMake files.

Best regards,

Martin

[Bart Vanhauwaert]

Because we will have to integrate OpENer in an existing codebase for which switching to a different compiler is not feasible.

[Bart Vanhauwaert]

In the end I went with just recreating a quick VS project that includes all the files necessary and the relevant defines. However, it seems like the WIN32 subsystem itself also has been in  bit of  disuse. There is a very trivial typo in the code that makes it not compile (I submitted a pull request on github), there is a crash in the ConfigureDomain code (I just don't configure the domain right now, not sure if that is going to byte me later). But it seems that the MINGW code has the two lines that crash also commented out. And then there are obviously some warnings, as usual when you let a different compiler loose on a code base. Hopefully later today I'll have to opportunity to try to get an actual ethernet/IP master to connect and see if everything is working as it supposed to be.

 cu bart

[Martin Melik-Merkumians]

Hi,

you are right the WIN32 is not much in use from my side. I try to keep it up to date and mainly provide it for convenience. I mainly do my developments under Linux, so POSIX is probably the best tested arch.

Unfortunately I didn't have time right now to get a build on TravisCI or AppVeyour to run, so that I get such trivial errors right away.

Thanks and best regards,

Martin

[Bart Vanhauwaert]

Currently I am hitting an issue in AddNewActiveCconnection. It tries to add the connection to the connection_list with a call to DoublyLinkedListInsertAtHead. Unfortunately, it seems that connection_list is never initialized. Is this something my code should do? If so, any constraints on the allocator/deallocator or can I simply wrap malloc and free?

cu bart

[Martin Melik-Merkumians]

Hi,

if you do not use the provided main routine, you have to initialize the list, with the allocator and deallocator yourself. malloc and free should work as allocator and deallocator, as I use them also in my tests for the doublylinkedlist.

Best

Martin

[Bart Vanhauwaert]

Thanks for all your help!

The allocators need a different signature than malloc and free though? Or do you mean within my own provided allocats, I can just use malloc free? The CipConnectionObjectListArrayAllocator uses a static list of nodes instead of dynamically creating one. Is there are reason for this or is it to guarantee no allocations in the eventloop path wrt timing? My application is certainly not real time sensitive.

I managed to connect to our Ethernet IP master and it seems it is filling me with data so far. I had to use the OPENER_PRODUCED_DATA_HAS_RUN_IDLE_HEADER options. Is there a reason that one is a define instead of a runtime option? I am worrying that should we have a different master, I may need to compile without this one.

cu bart

[Martin Melik-Merkumians]

Hi,

yes the second one, you can provide your own allocators which then use malloc/free, take a look in the corresponding tests/utils file for the doubly linked list.

The reason for the default implementation for static lists is, that OpENer is primary targeted at small platforms, without memory management and real-time behavior.

Also OpENer in its standard config, has a fixed number of possible connections, so it is more efficient to create them upfront.

They are compile time options, because I thought this is defined by the slaves EDS file, at least there are options in the EDS file editor (EZ-EDS from the ODVA) where you can define this in each connection type of the device.

Best,

Martin