Dienstag, 14. November 2017

Windows firewall rule for Open DHCP Server

The Windows firewall will normally block requests to the DHCP server, so an exception has to be added to the firewall fules.
Open Windows Defender Firewall with Advanced Security and go to Inbound Rules.
In General tab make sure the rule is enabled and Action is Allow the connection. In Programs and Services select the Open DHCP Server executable. In Protocols and Ports select UDP as Protocol type and enter 67, 68, 547, 546 as Specific Ports.  In the Advanced tab make sure the rule is selected for the current profile.

Montag, 6. November 2017

This article describes how to setup an Eclipse project so that it is possible to debug a program running on the NXHX51-ETM eval board from Hilscher. Hopefully the procedure should be similar for other processors/eval boards.
This tutorial expects that you have setup your project in eclipse and that it compiles using the GCC cross compiler.

Prerequisites

 The following software is needed to be able to debug:

gdb Standalone

 You can try to debug the program on the command line first to check if everything is woking fine.

Find Program Entry Point

The program entry point has to be determined so that the program counter can be set to the correct position before running the program.
The entry point can be determined with the readelf tool:
"<Path to netx Studio GCC-installation>\arm-none-eabi-readelf.exe" -l "<ELF-file>"

Example for ELF entry point


Starting OpenOCD

 The debug server can be started with the following command:
"<path to openocd>\bin\openocd.exe" -c "gdb_port 3333" -c "adapter_khz 1000" -s "<path to netx openocd scripts>" -f interface\hilscher_nxhx_onboard.cfg -f board\hilscher_nxhx51.cfg -c "load_image <ELF-file> 0x0 elf" -c "puts gdb-server-ready"
It ist importand to replace the "\" with "/" in the path of the elf-file for the load_image command.
The path to the script OpenOCD script files would be:
%ProgramData%\Hilscher GmbH\netX Studio CDT\BuildTools\openocd

Starting gdb

The debugger can then be started with the following command:
"<path to netx Studio GCC-installation>\arm-none-eabi-gdb.exe" --eval-command="target remote localhost:3333" "<ELF-file>"
If you use the Hilscher compiler the GCC installation is in the following directory:
%ProgramData%\Hilscher GmbH\netX Studio CDT\BuildTools\arm-none-eabi-gcc\4.5.2\bin

Debugging Using Eclipse

Before setting up Eclipse make sure you have installed the GNU MCU Eclipse plugin.

Setup Eclipse

 Create a new debug configuration in Eclipse. Go to Run -> Debug Configurations... and create a new GDB Hardware Debugging configuration.
 Select the ELF-file which should be debugged and select Disable auto build if needed.
 In the Debugger dialog select the path to the GCC installation. Select Use remote target and select GNU ARM OpenOCD as JTAG Device. Select the Port number which was given as command line argument to OpenOCD.
Set the program counter to the entry point which was determined previously in the Startup dialog and store the settings with Apply.

Start Debug Session

First start OpenOCD:
"<path to openocd>\bin\openocd.exe" -c "gdb_port 3333" -c "adapter_khz 1000" -s "<path to netx openocd scripts>" -f interface\hilscher_nxhx_onboard.cfg -f board\hilscher_nxhx51.cfg -c "load_image <ELF-file> 0x0 elf"
Then start the previously configured debug session.

Example Scripts to Run Program Directly on Target

environment.cmd
run_openocd.cmd

Freitag, 25. August 2017

The following code snipped shows the cases in which the different constructors and assignment operators will be used by the compiler: 

#include <iostream>
#include <vector>

using namespace std;

template<typename T>
class MyClass
{
public:
  MyClass(vector<T> inputVector);
  MyClass(const MyClass<T> &other);
  MyClass(MyClass &&other) noexcept;
  MyClass &operator=(const MyClass &other);
  MyClass &operator=(MyClass &&other);

  virtual ~MyClass();

private:
  vector<T> mVector;
};

template<typename T>
MyClass<T>::MyClass(vector<T> inputVector)
  : mVector{inputVector}
{
  cout << "\tMyClass constructor" << endl;
}

template<typename T>
MyClass<T>::MyClass(const MyClass<T> &other)
  : mVector{other.mVector}
{
  cout << "\tMyClass copy constructor" << endl;
}

template<typename T>
MyClass<T>::MyClass(MyClass<T> &&other) noexcept
  : mVector{std::move(other.mVector)}
{
  cout << "\tMyClass move constructor" << endl;
}

template<typename T>
MyClass<T>& MyClass<T>::operator=(const MyClass<T> &other)
{
  cout << "\tMyClass assignment operator" << endl;
  this->mVector = other.mVector;
  return *this;
}

template<typename T>
MyClass<T> &MyClass<T>::operator=(MyClass<T> &&other)
{
  cout << "\tMyClass move assignment operator" << endl;
  this->mVector.operator=( std::move(other.mVector) );
  return *this;
}


template<typename T>
MyClass<T>::~MyClass()
{
  cout << "\tMyClass vector size: " << mVector.size() << endl;
}


MyClass<int> GetClass()
{
  MyClass<int> obj{ {1, 2} };
  return obj;
}

MyClass<int> GetClass2()
{
  return MyClass<int>{ {1, 2} };
}

int main()
{
  {
    cout << "Constructor" << endl;
    MyClass<int> myClass{ { 1, 2 } };
  }
  {
    cout << "Move constructor" << endl;
    MyClass<int> myClass{GetClass()};
  }
  {
    cout << "Assignment operator" << endl;
    MyClass<int> origObj{ { 1, 2 } };
    MyClass<int> myClass{ { 3, 4 } };
    myClass = origObj;
  }
  {
    cout << "Move assignment operator" << endl;
    MyClass<int> myClass{ {3, 4} };
    myClass = GetClass2();
  }

  // References are handled differently:
  // A reference is basically a pointer to an object.
  // The references have to be const because the objects returned by the
  // GetClass functions are rvalues and thus the references have to be
  // rvalues also.
  {
    cout << "Reference construction (direct initialization)" << endl;
    const MyClass<int> &myClass{GetClass()};
  }
  {
    cout << "Reference construction (assignment)" << endl;
    const MyClass<int> &myClass = GetClass();
  }

  return 0;
}



This should result to the following output by the compiler:
Constructor
        MyClass constructor
        MyClass vector size: 2
Move constructor
        MyClass constructor
        MyClass move constructor
        MyClass vector size: 0
        MyClass vector size: 2
Assignment operator
        MyClass constructor
        MyClass constructor
        MyClass assignment operator
        MyClass vector size: 2
        MyClass vector size: 2
Move assignment operator
        MyClass constructor
        MyClass constructor
        MyClass move assignment operator
        MyClass vector size: 0
        MyClass vector size: 2
Reference construction (direct initialization)
        MyClass constructor
        MyClass move constructor
        MyClass vector size: 0
        MyClass vector size: 2
Reference construction (assignment)
        MyClass constructor
        MyClass move constructor
        MyClass vector size: 0
        MyClass vector size: 2

Samstag, 12. August 2017

Developing a kernel module on Archlinux with Eclipse

In this blog post I will try to write down everything on how to setup an environment for developing kernel drivers on Archlinux.

In my case I've wanted to use the current git version of the kernel to develop so I've downloaded linux-git from AUR:
$ git clone https://aur.archlinux.org/linux-git.git
and then build the kernel
$ nice -n19 makepkg

Now start Eclipse and create your project.

Go to Project -> Properties -> C/C++ General -> Preprocessor Include -> GNU C and delete all entries in CDT Managed Build Setting entries.


Select CDT User Settings Entries and then click Add...
Select Include Directory and File System Path
Select Contains system headers and select the <path to abs package>/pkg/linux-git-headers/usr/lib/modules/<linux version>/build/include/



Repeat the above steps for the <path to abs package>/pkg/linux-git-headers/usr/lib/modules/<linux version>/build/arch/x86/include/ directory

And one more time for <path to abs package>//pkg/linux-git-headers/usr/lib/modules/<linux version>/build/arch/x86/include/.

Now click Add... again and select Preprocessor Macro File and File System Path and add <path to abs package>/pkg/linux-git-headers/usr/lib/modules/<linux version>/build/include/linux/kconfig.h

 Now go to Paths and Symbols, select #Symbols and add a symbol named __KERNEL__ and give it a value of 1.

Sonntag, 12. März 2017

Edit Windows UEFI boot entry using windows PE

To be able to edit the boot settings you need to be able to boot from another boot device like USB stick or CD. You need to create a bootable WinPE boot media first
When you have started the WinPE (this should work starting with WinPE for Windows 7) environment open a command line and start a command prompt. First you need to mount the EFI system partition:

# diskpart
# list disk
# sel disk 0
# list partition
# assign letter=b
# exit

Now the EFI system partition should be as drive b:.

In the next step you can start to edit you BCD entry:

# bcedit /store b:/efi/microsoft/boot/bcd /enum
# bcedit /store b:/efi/microsoft/boot/bcd /deletevalue {default} safeboot

In this example a safeboot entry would be deleted from the store.

Dienstag, 31. Januar 2017

Configure CodeLite to develop C++14 applications with CMake and CLang

First configure CodeLite so that it uses CLang for code completion: Settings -> Code Completion... -> Clang. Enable both Enable clang code completion and Only use clang code completion.

The structure of the project will be:
<project dir>
  |- Debug
  |- src
  |- Release

Create first a new workspace and then open the Workspace Settings....


On the Code Completion tab select Enable C++14 Standard.

Create a new project inside this workspace (File -> New -> New Project) and select Others -> Custom makefile as project type. Then select a project name and the <project dir> for the project path. Select the clang compiler, LLDB Debugger and CMake in the next step and finish the project wizard.

Select Import Files From Directory to import your source files.



Open the project settings and adjust the following settings:
General:


  • Intermediate Folder: $(ProjectPath)/$(ConfigurationName)
  • Output File: Name of your executable
  • Executable to Run / Debug: $(ProjectPath)/$(ConfigurationName)/$(OutputFile)
Custom Build:



  • Working Directory: $(ProjectPath)/$(ConfigurationName)
  • CMake: mkdir -p $(ProjectPath)/$(ConfigurationName) && cd $(ProjectPath)/$(ConfigurationName)  && cmake ../src -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DCMAKE_BUILD_TYPE=Debug
Repeat the steps also for the Release configuration and change -DCMAKE_BUILD_TYPE=Debug to -DCMAKE_BUILD_TYPE=Release.

Then execute your custom CMake command:
 

and the build your project.

Now the code completion should work.

A list of variables supported by CodeLite can be found in the following source file: macrosdlg.cpp