Short Guide on Compiling NewRPL

[Han]

This is meant to serve as both my own personal documentation and a short guide on getting the tools to start dabbling in the newrpl source code. I will eventually put up instructions on how to get set up on all the main platforms (Windows, Mac OS X, and Linux). For Windows, I am still using Windows 7. And for Linux, I will likely be using either Slackware or Ubuntu.

Windows 7

1. Download Qt Creator: Qt Creator Download Page (scroll down to the bottom and select the Open Source option)
2. Install Qt Creator (using the default options will be just fine). In addition to the SDK/IDE, it will also install MinGW.
3. Install git for Windows: Git for Windows Download Page or you can alternately use Tortoise Git as recommended by Claudio (see immediate post below)
4. Optional: install GnuWin32 (tools such as diff): GnuWin32 Download Page
5. Adjust your environment path to enable git (and any other GNU software) from any command line (when running cmd.exe)
   
   1. Right click on My Computer (or alternately click on System in the Control Panel).
   2. Select Advanced System Settings at the top left of the System window.
   3. Click on Environment Variables; either modify PATH in the user variables, or modify Path in the system variables to include the directory containing the executable for git (and other GNU software). Some setup programs may have already done this for you.
      
6. Open a new command box (cmd.exe). You need a new one since any command box prior to the changes in the Environment Variables will not have the updated path changes. Type:
   
   git clone git://git.code.sf.net/p/newrpl/sources newrpl-sources
   
   This will create a directory named newrpl-sources in your user folder. For example, if you are logged into Windows as WinUser, then (assuming you do not change directories upon opening a command box via cmd.exe) the folder will be created as C:\Users\WinUser\newrpl-sources.
   

Compiling the NewRPL compiler for Windows

1. Run Qt Creator. Open the newrpl-comp.pro file (project file) and click the "configure" button.
2. To build this project, simply press CTRL+B. Or go to the Build menu and select Build project "newrpl-comp"
3. This process creates a new folder named buil-newrpl-comp-... in the same location as the newrpl-sources folder. Within this folder is a folder named debug, which contains the executable newrpl-comp.exe.
   

Compiling the PC virtual calculator

1. Compile the NewRPL compiler first; see above
2. Copy the newrpl-comp.exe file to tools-bin folder within the newrpl-sources folder.
3. In Qt Creator, open the newrpl-ui.pro (profile file) and compile (same instructions as for newrpl-comp project)
4. Press CTRL+R or select Run from the Build menu to load the UI program (virtual HP50G with newrpl firmware)
   

Compile the firmware on Windows 7

... todo ...
-------------------------------------------------------------------------------------------------

Mac OS X (10.9.5)

1. Install Xcode. Note that the version of Xcode that can be installed will depend on your version of OS X. For example, 10.9.5 can only use up to version 6.2 of Xcode. Xcode Downloads
   
   (You will need to have an Apple developer account set up.)
2. After installing Xcode, install the Command Line Tools. This can be done with:
   
   xcode-select --install
   
   Just follow the on-screen directions (pretty simple).
3. Download Qt Creator: Qt Creator Download Page (scroll down to the bottom and select the Open Source option)
4. Install Qt Creator (using the default options will be just fine). As of November 17, 2016, the installer will install Qt 5.7. When selecting the install options, expand the option for Qt 5.7 and select only the OS X option (that is all that is needed for newrpl).
5. Open a Terminal window. Type:
   
   git clone git://git.code.sf.net/p/newrpl/sources newrpl-sources
   
   This will create a directory named newrpl-sources in your user folder. For example, if you are logged into Mac OS X as MacUser, then (assuming you do not change directories upon opening a Terminal window) the folder will be created as
   
   /Users/MacUser/newrpl-sources
   
   Optional: If you want to consolidate all your build directories (which get created later), I recommend first creating a folder named newrpl, and then run the git command above within the newrpl folder. This will then install the source files to:
   
   /Users/MacUser/newrpl/newrpl-sources
   

Compiling the NewRPL compiler for Mac OS X

1. Run Qt Creator. Open the newrpl-comp.pro file (project file) and click the "configure" button.
2. To build this project, simply press <command>+B. Or go to the Build menu and select Build project "newrpl-comp"
3. This process creates a new folder named buil-newrpl-comp-... in the same location as the newrpl-sources folder. Within this folder is the executable newrpl-comp.
   

Compiling the Mac virtual calculator

1. Compile the NewRPL compiler first; see above
2. In Qt Creator, open the newrpl-ui.pro (profile file) and compile (same instructions as for newrpl-comp project)
3. Press <command>+R or select Run from the Build menu to load the UI program (virtual HP50G with newrpl firmware)
   

Compile the firmware on Mac OS X

1. Download the libelf source files from: http://freecode.com/projects/libelf
2. Compile and install libelf. Open a Terminal window and type:
   
   cd ~/Downloads
   tar xfzv libelf-<your version>.tar.gz
   cd libelf-<your version>
   chmod u+x configure
   ./configure
   make
   make install
   
   This sequence of commands will compile libelf, and install the relevant files in /usr/local (Should you ever want to uninstall it, you can do so with: make uninstall in libelf source directory.)
3. Run Qt Creator. Open the elf2rom.pro file located within the newrpl-sources/tools/elf2rom subfolders. Click on the elf2rom.pro file shown in the Qt Creator window pane (left side of window). Modify the contents to look like:
   
   
   Code:
   

   TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt

SOURCES += \
    elf2rom.c

INCLUDEPATH += /usr/local/include

LIBS += -L/usr/local/lib -lelf

install_bin.path = $$PWD/../../tools-bin
install_bin.files = $$OUT_PWD/elf2rom
INSTALLS += install_bin
   
   The changes are the addition of the INCLUDEPATH line and the modification of the LIBS line to add -L/usr/local/lib
4. Build the elf2rom project using the Build menu or using <command>+B.
5. Download the arm toolchain for Mac OS X here: Arm Toolchain Download Page
6. Install the toolchain. Open a Terminal window if necessary, and type:
   
   cd ~/Downloads
   tar xfzv gcc-arm-none-eabi-<your version>-mac.tar.bz2
   sudo mv gcc-arm-none-eabi-<your version> /usr/local/gcc-arm
   
   The last line will move the folder containing the toolchain to /usr/local/gcc-arm
7. In Qt Creator, open newrpl-fw.pro (project file). Then proceed to open the file named newrpl-fw.pro shown in the left pane of the Qt Creator window. Scroll down until you see a line with GCC_LIBDIR and modify it to:
   
   GCC_LIBDIR = /usr/local/gcc-arm/arm-none-eabi
   
   Then scroll down a bit more to where you see references to QMAKE_CC, QMAKE_CXX, and QMAKE_LINK. Modify these lines to look like the ones below:
   
   QMAKE_CC = /usr/local/gcc-arm/bin/arm-none-eabi-gcc
   QMAKE_CXX = /usr/local/gcc-arm/bin/arm-none-eabi-g++
   QMAKE_LINK = /usr/local/gcc-arm/bin/arm-none-eabi-gcc
   
   Save the file.
8. If there are other projects open in Qt Creator, right-click newrpl-fw in the projects section and choose: Set "newrpl-fw" as Active Project. Then build the firmware using the Build menu or simply use <command>+B. The firmware file will be in the build-newrpl-fw-... folder (same location as newrpl-sources) and the file is named newrplfw.elf
   
   This section will eventually be removed once the sources are updated to presumably address the issues.
   If you see an error the function sig_digits within the decimal.c file, modify
   
   int sig_digits(BINT word)
   
   to
   
   BINT sig_digits(BINT word)
   

[Claudio L.]

(11-17-2016 07:01 PM)Han Wrote:  Install git for Windows: Git for Windows Download Page

For windows users, may I suggest TortoiseGIT https://tortoisegit.org? It integrates well with the system, for users that may actually modify the code and commit their changes.

(11-17-2016 07:01 PM)Han Wrote:  Copy the newrpl-comp.exe file to tools-bin folder within the newrpl-sources folder.

In my case this alone wasn't enough, as newrpl-comp refused to run. I had to also copy the following files to the same directory:
libgcc_s_dw2-1.dll
libstdc++-6.dll
libwinpthread-1.dll

Perhaps they improved the installers, my Qt install is from a couple of years back.

[Han]

(11-17-2016 07:26 PM)Claudio L. Wrote:  

(11-17-2016 07:01 PM)Han Wrote:  Install git for Windows: Git for Windows Download Page

For windows users, may I suggest TortoiseGIT https://tortoisegit.org? It integrates well with the system, for users that may actually modify the code and commit their changes.

I'll add that as well.

(11-17-2016 07:26 PM)Claudio L. Wrote:  

(11-17-2016 07:01 PM)Han Wrote:  Copy the newrpl-comp.exe file to tools-bin folder within the newrpl-sources folder.

In my case this alone wasn't enough, as newrpl-comp refused to run. I had to also copy the following files to the same directory:
libgcc_s_dw2-1.dll
libstdc++-6.dll
libwinpthread-1.dll

Perhaps they improved the installers, my Qt install is from a couple of years back.

I have not tested newrpl-comp.exe by itself beyond seeing if the executable was visible by Qt (from within the newrpl-comp project). Doing so gave me a window that showed the help info for running newrpl-comp and left me with essentially an "ended session" (as if I ran newrpl-comp without any arguments). But for running the UI, the most recent Qt Creator (4.1.0) did not require me to copy those DLL files (this was to get the UI project to run).

Incidentally, I am trying to compile the actual firmware. It complains of missing memory.h (referenced in runstream.c). Is this include file from the mpdecimal library? I ask because compiling with Qt Creator on Windows 7 seems to not recognize subdirectories when searching for includes (unless explicitly specifying it in the project file).

EDIT: Forgot to mention I'm using https://developer.arm.com/open-source/gn.../downloads -- after a much more closer inspection, the download page says it's for Cortex-M and Cortex-R ... is that the same chip on the 50g? (My guess is not since the compiler seems to be missing stuff.) Or maybe it was from here: https://launchpad.net/gcc-arm-embedded/+download (I don't remember; got rid of the install files.) Do you have a recommended ARM cross compiler?

EDIT2: It appears likely that nothing is wrong with the cross compiler and my issues may be due to Windows and how it parses paths. On Mac OS X, I am able to compile all three main projects (with some minor edits).

[Han]

Updated to include Mac OS X instructions. I compiled the firmware, but have not tested the firmware file (left my 49G+ and 50G at the office). Claudio, can you comment on the errors mentioned at the end of the Mac OS X section in the first post?

[Claudio L.]

(11-18-2016 03:12 AM)Han Wrote:  Updated to include Mac OS X instructions. I compiled the firmware, but have not tested the firmware file (left my 49G+ and 50G at the office). Claudio, can you comment on the errors mentioned at the end of the Mac OS X section in the first post?

I can tell you that I compiled both UI and FW on Ubuntu (64-bits) and on FreeBSD (32 and 64 bits) (most similar OS to a Mac that I can get) and it compiled with zero errors. I also compile UI on Windows (32-bits) and get zero errors. Sometimes I get a spurious warning about a comparison on ui_cmdline.c that makes no sense to me.
Regarding memory.h: It was an old #include needed back in the early days, but I eventually replaced all calls to memcpy and friends with my own memcpyw and memcpyb to become completely independent from any system library, so memory.h became obsolete and can be removed with no consequences (I'll commit that change tomorrow). It's a standard header, though, it should be there even on Mac. Perhaps there's some missing basic headers?

Also the problem with types should never happen: The first thing newrpl.h does is define all those custom types: WORD is defined as uint32_t to be 100% consistent across multiple platforms. Replacing WORD with unsigned int is superfluous, as they are the same type, same as replacing int with BINT in your example. I'm not sure where those errors come from.

The arm-none-eabi-gcc you are using should be fine. A while back they had declared ARM9 obsolete and removed libgcc.a from the packages, but they eventually included everything back. Even though they say Cortex, the old arm920t is supported and they provide a libgcc.a that is armv4t compatible.
As far as recommended ARM compiler: I tested the arm-none-eabi-gcc in the Ubuntu packages and works well. I also used the freebsd package and worked just as well. For the UI project, I used Clang on FreeBSD and it compiles fine too.


A few details on your tutorial:

* All tools like elf2rom and newrpl-comp have a proper "install" target that copies the executable file into tools-bin for you. It is supposed to work on all targets except Windows. When you configure the project, select the "Release" target, then add a custom step after build, in which you put "install" as the sole argument. When you hit build, it will copy the file at the end for you. Doesn't work on Windows, as the executable has a different extension and the cp command is not supported.

* I gave up on trying to cross compile the firmware on Windows. arm-none-eabi-gcc always has issues with the paths. To build the firmware on Windows, I recommend an Ubuntu VM.

[Han]

Thank you for the info on the errors and memory.h

(11-18-2016 04:57 AM)Claudio L. Wrote:  

(11-18-2016 03:12 AM)Han Wrote:  Updated to include Mac OS X instructions. I compiled the firmware, but have not tested the firmware file (left my 49G+ and 50G at the office). Claudio, can you comment on the errors mentioned at the end of the Mac OS X section in the first post?

I can tell you that I compiled both UI and FW on Ubuntu (64-bits) and on FreeBSD (32 and 64 bits) (most similar OS to a Mac that I can get) and it compiled with zero errors. I also compile UI on Windows (32-bits) and get zero errors. Sometimes I get a spurious warning about a comparison on ui_cmdline.c that makes no sense to me.

On Mac, there are numerous warnings about instances were const is used twice in a declaration (e.g. const unsigned int const <blah>) but this is likely just due to Xcode being extremely picky. Once I got the projects to compile, though, I no longer saw them in the logs so I cannot give any further details. (Even using make clean and rebuilding did not show any warnings after the minor modifications I had mentioned.)

(11-18-2016 04:57 AM)Claudio L. Wrote:  Regarding memory.h: It was an old #include needed back in the early days, but I eventually replaced all calls to memcpy and friends with my own memcpyw and memcpyb to become completely independent from any system library, so memory.h became obsolete and can be removed with no consequences (I'll commit that change tomorrow). It's a standard header, though, it should be there even on Mac. Perhaps there's some missing basic headers?

It's there, but I think runstream.c was looking for it within the mpdecimal library. At least the newRPL-BASE.pro file seems to suggest so, anyway. But I am glad to read that removing it is OK.

(11-18-2016 04:57 AM)Claudio L. Wrote:  Also the problem with types should never happen: The first thing newrpl.h does is define all those custom types: WORD is defined as uint32_t to be 100% consistent across multiple platforms. Replacing WORD with unsigned int is superfluous, as they are the same type, same as replacing int with BINT in your example. I'm not sure where those errors come from.

I was surprised by this as well. I think the Mac compiler is just super picky. At any rate, the differences were:

• battery.c vs hal_api.h: battery.c uses unsigned int __battery __SYSTEM_GLOBAL__; and at the same time includes ui.h (which then includes hal_api.h). Within hal_api.h is the declaration WORD __battery; which makes the Xcode compiler upset
• decimal.h declares BINT sig_digits(BINT word); but decimal.c defines the function using int sig_digits(BINT word). So it seems that Xcode just likes to be very particular about types (despite the typedef in newrpl.h)
  

If you already tried compiling the firmware on Windows with no success, then I probably won't bother trying too hard (I too ran into path issues despite using the "DOS" paths that I had to manually determine using dir /X). The only thing I have not tried is to install the compiler in a simple directory at the root of the drive.

[Claudio L.]

(11-18-2016 01:35 PM)Han Wrote:  

• battery.c vs hal_api.h: battery.c uses unsigned int __battery __SYSTEM_GLOBAL__; and at the same time includes ui.h (which then includes hal_api.h). Within hal_api.h is the declaration WORD __battery; which makes the Xcode compiler upset
• decimal.h declares BINT sig_digits(BINT word); but decimal.c defines the function using int sig_digits(BINT word). So it seems that Xcode just likes to be very particular about types (despite the typedef in newrpl.h)
  

I'll fix this. Could you email me a complete capture with all your warnings and errors? Picky or not, the ones above need to be fixed in the code, and the others about const probably too, I just never came across these issues because my compiler never told me :-).

[Han]

(11-18-2016 02:54 PM)Claudio L. Wrote:  

(11-18-2016 01:35 PM)Han Wrote:  

• battery.c vs hal_api.h: battery.c uses unsigned int __battery __SYSTEM_GLOBAL__; and at the same time includes ui.h (which then includes hal_api.h). Within hal_api.h is the declaration WORD __battery; which makes the Xcode compiler upset
• decimal.h declares BINT sig_digits(BINT word); but decimal.c defines the function using int sig_digits(BINT word). So it seems that Xcode just likes to be very particular about types (despite the typedef in newrpl.h)
  

I'll fix this. Could you email me a complete capture with all your warnings and errors? Picky or not, the ones above need to be fixed in the code, and the others about const probably too, I just never came across these issues because my compiler never told me :-).

I emailed you text files of only the warnings (since my tree has the modified sources). I can start fresh (new git clone) if you want the errors, too (although the above modifications fix the errors).

[Han]

Manged to compile newrplfw.elf on Windows up until calling elf2rom. Looks like I will need to figure out how to compile libelf using the mingw installation within Qt.

[Han]

Here's the sig_digits error:

Code:

/usr/local/gcc-arm/bin/arm-none-eabi-gcc -c -mtune=arm920t -mcpu=arm920t -mlittle-endian -fomit-frame-pointer -fno-toplevel-reorder -msoft-float -Os -pipe -mthumb-interwork -nostdinc -DTARGET_50G -DNDEBUG -DNEWRPL_BUILDNUM=711 -I../newrpl-sources -I. -I/usr/local/gcc-arm/arm-none-eabi/include -I../newrpl-sources/firmware/include -I../newrpl-sources/newrpl -I/usr/local/include -I/usr/include -I../../Qt/5.7/clang_64/mkspecs/macx-clang -o decimal.o ../newrpl-sources/newrpl/decimal.c
../newrpl-sources/newrpl/decimal.c:1358:5: error: conflicting types for 'sig_digits'
 int sig_digits(BINT word)
     ^
In file included from ../newrpl-sources/newrpl/newrpl.h:78:0,
                 from ../newrpl-sources/newrpl/decimal.c:9:
../newrpl-sources/newrpl/decimal.h:160:6: note: previous declaration of 'sig_digits' was here
 BINT sig_digits(BINT word);
      ^
make: *** [decimal.o] Error 1
20:10:06: The process "/usr/bin/make" exited with code 2.
Error while building/deploying project newrpl-fw (kit: Desktop Qt 5.7.0 clang 64bit)
When executing step "Make"
20:10:06: Elapsed time: 00:02.