Friday, February 26, 2016

Upgrade from Redmine 2.x to Redmine 3.x on a Windows server

Today I want to give a summary of the painful steps I came through to install Redmine on a windows server (sometimes, you can't chose).
I assume that you have a backup of your database.

Install Rails

Pick the last installer on http://railsinstaller.org/fr-FR

(take a look at the requirements here)

Extract Redmine

Download the package 3.x from here.
Extract it to server's hardrive (in C:\ for example).

Optional : Recover the password of the database

Get into the previsous redmine installation directory.
Open config/database.yml and note the password.

production:
  adapter: mysql
  database: redmine
  host: localhost
  username: redmine
  password: my_password

Copy your old confiuration files

Go to your old redmine install directory and copy :
  • config/configuration.yml 
  • config/database.yml
to the same location in your new redmine install directory.

Install Dependencies

Open a cmd and type :

gem install bundler
gem install thin
gem install thin_service

Open GemFile at the root of your new redmine install directory and add the following lines;

gem "thin"gem "i18n"

Proceed to Redmine installation

Still from cmd, go to your new redmine install directory (say C:\redmine3.2.0) and type:
bundle install --without development test rmagick

Session store secret generation

Still in the redmine install directory, run:
bundle exec rake generate_secrete_store

Database object creation/migration

Still in the redmine install directory, run:

set RAILS_ENV=production# For french peopleset REDMINE_LANG=fr# Use your own language code otherwisebundle exec rake db:createbundle exec rake db:migratebundle exec rake redmine:load_default_data

Test the installation

Simply run 

rail s

from the install directory. A few seconds later, you should be able to access your redmine at http://localhost:3000

Install redmine as a service

If you already have a Redmine service, delete it first:

sc delete RedmineThin

Optional : Add the following line at the end of your config/environment.rb file if you want to access redmine with a prefix (http://localhost:3000/redmine instead of http://localhost:3000):

Redmine::Utils::relative_url_root = "/redmine"

Finally, run

thin_service install -N RedmineThin -e production -p 3000 --chdir C:\redmine3.2.0 --prefix /redmine

Redmine is now installed as a service. Go in your service configuration panel, and configure it to run automatically on windows start.

Reboot your server.


Friday, February 19, 2016

C++ : auto_ptr

NOTE: auto_ptr is deprecated. Use std::unique_ptr instead !

auto_ptr is a smart pointer facility.
Usually, this is what we do when we manipulate pointers :

void f()
{
   T* pt( new T );
   /*...more code...*/
   delete pt;
}

With auto_ptr, no need to delete the object anymore, it is all  taken care of !

    void f()
    {
      auto_ptr<T> pt( new T );
      /*...more code...*/
    } // cool: pt's destructor is called as it goes out
      // of scope, and the object is deleted automatically

It ensures more robust code as we avoid potential memory leaks.

Ownership


Passing


T* pt1 = new T;
// right now, we own the allocated object
// pass ownership to an auto_ptr
auto_ptr<T> pt2( pt1 );
// use the auto_ptr the same way
// we'd use a simple pointer

*pt2 = 12;       // same as "*pt1 = 12;"

Releasing


...
// use release() to take back ownership
T* pt3 = pt2.release(); // pt3 = pt1 --> points to T object
// delete the object ourselves, since now
// no auto_ptr owns it any more

delete pt3;

Reset


To substitute the pointer owned by auto_ptr with another one, one would use auto_ptr's reset() method:

auto_ptr<T> pt( new T(1) );
pt.reset( new T(2) );
// deletes the first T that was
// allocated with "new T(1)"
 It internally calls delete on T(1) and create a new auto_ptr on T(2).

Notes


  • Never put auto_ptr into standard containers

vector< auto_ptr<T> > v; // No !!!

The problem is that auto_ptr does not quite meet the requirements of a type you can put into containers, because copies of auto_ptrs are not equivalent

C++ : const at the end of function declaration

class User
{
    public:
        User();
        User(std::string name);
        void doSomething() const;

    protected:
        std::string m_name;
};


In .cpp:

void User::doSomething() const
{
    // code
}

The const keyword indicates that *this (the object) is const on the method call. This declaration tells you that the object will not be modified within this function (in the example above, doSomething() cannot modify m_name).

Note : In practice, this notation is just a promise that can be violated by the function (not advised though).

C++ : constructor initialization list

In the implementation of the constructor, it is possible to initialize internal members with an initialization list. It is basically a list of parameters following a semicolon (:) with their initialization values :

Basic initialization


class Something
{
private:
    int m_nValue;
    double m_dValue;
    int *m_pnValue;

public:
    Something()
    {
        m_nValue = 0;
        m_dValue = 0.0;
        m_pnValue = 0;
    }
};


With an initialization list


class Something
{
private:
    int m_nValue;
    double m_dValue;
    int *m_pnValue;

public:
    Something() : m_nValue(0), m_dValue(0.0), m_pnValue(0)
    {
    }
};


Note : This syntax can be used with const member as well. For instance, if m_nValue was a const, it would had the same effect.

Hands on GPIOs

Now that we know what a GPIO is, let's try to write a driver that we will use further to play with our Pi.

The reference document for this work is the BCM2835-ARM-Peripherals.pdf that you can easily find on the web.

GPIO Registers

GPFSELx : GPIO Function Select with x in [0;5]
Everyone of these registers configures up to 10 pins (except for GPFSEL5 which configures only 3).
Each pin can be configured as an input, output or alternate.
Here is the table with the definition of every alternate configuration for every pi.

GPSETx : GPIO Set function with x in [0;1]
Every pin is represented by a bit in these registers. If the pin is configured as an output, setting its bit in  GPSET will drive it to HIGH level.
GPCLRx : GPIO Clear function with x in [0;1]
Every pin is represented by a bit in these registers. If the pin is configured as an output, setting its bit in  GPSET will drive it to LOW level.
GPLEVx : GPIO Level wih x in [0;1]
Every pin is represented by a bit in these registers. You can get the current level of a pin by reading its pin in these registers.
GPEDSx : GPIO pin event status with x in [0;1]
Every pin is represented by a bit in these registers. A bit is set by the micro-controller whenever an event occurs on a pin and matches the event we are waiting for (configurable edge or level).
You can also configure the interrupt controller to be alerted with an interrupt for any pin.

GPIO pin configuration registers

GPRENx : GPIO Rising edge detect enable with x in [0;1]
GPFENx : GPIO  Falling edge detect enable with x in [0;1]
GPHENx: GPIO High detect enable with x in [0;1]
GPLENx : GPIO Low detect enable with x in [0;1]
GPARENx : GPIO Asynchronous rising edge  detect enable with x in [0;1]
GPAFENx: GPIO Asynchronous falling edge  detect enable with x in [0;1]

Asynchronous means the incoming signal is not sampled by the system clock. As such
rising edges of very short duration can be detected.
GPPUD : GPIO Pull up/down register
GPPUDCLKx : GPIO Pull up/down clock register with x in [0;1]
Use GPPUD to configure a pull up, pull down or unused mode. Then, use GPPUDCLKx to apply this mode to the desired pins.

Writing the driver step by step

Now that we know the registers to modify to handle raspberry GPIOs, we can go further and define our design. Here is a list of what we need :

A. GPIO registers memory mapping : Every register is located at a specific address in the microcontroller.  The first step would be to define them.
B. GPIO registers accessors: typically macros to avoid using masks in our code.
C. a GPIO static configuration : we will define the pins default configuration at build time. This is usually done to limit the number of function calls at boot to configure the device.
D. an interface : how will we use this driver ? We won't discuss about the integration of this driver into linux here.

And of course, everything we need to test our work !

A. GPIO Registers memory mapping

Given the BCM2835 document, the addresses start from 0x7E200000 and go to 0x7E2000B0, with 4 bytes per register (32 bits platform). My choice here is to create a structure where all of the registers are listed in the same order as the reference manual rather than defining every one of the registers with a #define statement. It is more elegant and a lot more handy when it comes to use them in the code. The final step will be to define the structure as volatile and to assign to it the GPIO base address (0x7E200000).

typedef struct
{
      uint32_t GPFSEL[6];
      uint32_t Reserved0; // Reserved byte
     
uint32_t GPSET[2]
      uint32_t Reserved1;
     
uint32_t GPCLR[2];
      uint32_t Reserved2;
     
uint32_t GPLEV[2];
      uint32_t Reserved3;
     
uint32_t GPEDS[2];
      uint32_t Reserved4;
     
uint32_t GPREN[2];
      uint32_t Reserved5;
     
uint32_t GPFEN[2];
      uint32_t Reserved6;
     
uint32_t GPHEN[2];
      uint32_t Reserved7;
     
uint32_t GPLEN[2];
      uint32_t Reserved8;
     
uint32_t GPAREN[2];
      uint32_t Reserved9;
     
uint32_t GPAFEN[2];
      uint32_t Reserved10;
     
uint32_t GPPUD;
     
uint32_t GPPUDCLK[2];
      uint32_t Reserved11[4];
      uint8 Test;
}volatile* GPIO_MemMap_ts;


The structures declared in GPIO_MemMap_ts should be defined too.
 When you are done, all you need is to declare a global variable for the GPIO_MemMap_ts:

const GPIO_MemMap_ts GPIO_BASE = 0x7E200000;

B. GPIO Registers Accessors

What we need here is to have an access to the bit of our choice in one of the GPIO registers. There is of course many ways to do that, here is a possible solution:

/* GPFSEL accessing macros */
#define GPFSEL_MODE_INPUT   ((uint32_t)0x000)
#define GPFSEL_MODE_OUTPUT  ((uint32_t)0x001)
#define GPFSEL_MODE_ALT0    ((uint32_t)0x100)
#define GPFSEL_MODE_ALT1    ((uint32_t)0x101)
#define GPFSEL_MODE_ALT2    ((uint32_t)0x110)
#define GPFSEL_MODE_ALT3    ((uint32_t)0x111)
#define GPFSEL_MODE_ALT4    ((uint32_t)0x011)
#define GPFSEL_MODE_ALT5    ((uint32_t)0x010)

#define GPFSEL_SET_FSELy(base, y, mode) (((volatile* GPIO_MemMap_ts)base).GPFSEL[y/10]) |= (mode << (3* (y%10)))

C. GPIO Static configuration

Work in progress...

Emulate raspberrypi on Windows

QEmu

QEmu is a powerfuln and open-source machine emulator. It allows you to run OSes and programs made for specific target machines on your desktop computer.
It can be compared to the popular VirtualBox and VMWare emulators but has a significant advantage in the fact that it can emulate ARM platforms. This is specifically why we are going to use it here.

How to proceed ?

Luckily, a full-packaged solution exists for Windows ! 

  • Follow this link:

and download the zip file.
  •  Unzip the file to your local hard drive 
  • Get into the unzipped qemu folder and double-click on run.bat.
There, you will see QEmu starting and initiating the boot of your virutal raspberry pi. Simply wait until the end of this process.
This is the screen you will normally see on first boot:


Ignore it for now, click on Finish.

  • Start raspbian
Run the following command at prompt:
startx
and there you are ! In your virtual raspberry environment !

Default credentials

Login: pi
Password: raspberry

Enjoy !

 
biz.