Marc's open source activities

[webserver home]


What has software programming to do with a funsports homepage?

Imagine, that once upon a time I was selling my boards to the public. Before I've been mainly a PC software programmer. The complexity of my boards more or less forced me to produce them without professional help as this would have raised the price to completely unacceptable levels. So I decided to do everything on my own. This included CNC-machining and Aluminum heat treatment (hardening - which is a 16hour temperature profile process). At that time I was already programming 8051 devices for minor hobby projects and I decided to use these microcontrollers for creating a CNC-lathe and an automatic Aluminum hardening oven. I was using a self-written 8051 assembler. From todays point of view, that was stone age of my programming skills. But, everybody has to start somewhere. For me, together with my failure in beeing successful in selling my boards this caused the shift from operating system based programming (Linux, Java, ...) to "bare-metal" programming. My next job was a electronics and software developer at AEG-MIS company. The consequence of full-time employment in uC-programming and hardware was 'love at first sight' with the ARM-uCs of NXP (former Philips). I gave up all 8051 activities and first realized the need for a cross-platform library for the simple things that have to be done in nearly every program. I also fell in love with GNU C and binutils at that point.

My mindset, coding style in special

Be warned! I'm not a friendly guy. I don't believe in crowd intelligence. And I'm disagreeing with nearly everybody about freedom, terrorism, guilt, egoism, right of knowlegde in classified areas, weapons, the ecological footprint of a human, money, xenophobia, pets, and a trillion other things.

Sharing the programs/libs below as open source does not mean I expect or want you to participate in development. Most programmers are dumb asses, void of discipline. Most programmers are working hard and produce many lines of code, but the outcome is lacking conceptual design. Beeing busy as a bee is not a subsitute for concept. Meaning well is the opposite of doing well in almost all cases. Some programmers are good at conceiving concepts, but fail at the implementation step. These two very widespread types of programmers are best kept away from any source code. Most 'help' multiplies my work.

Here's a preliminary list of my coding rules. Not strictly ordered by severity.

  1. Avoid redundancy. If it cannot be avoided have it generated by an automatic process. Copy and paste is NOT an automatic process!
  2. Use open software. Donate to open source projects. Do not spent money on proprietary software.
  3. Be aware of the rate and kind of your typical errors.
  4. Use systematic names for all identifiers.
  5. Document all of your library functions.
  6. Create libraries at all.
  7. Avoid excessive use of the underscore character.
  8. Know your programming language in depth.
  9. Know your programming tools in depth.
Unfortunately, I'm not a saint and sometimes fail to respect some of the rules. For example, I'm using the EAGLE layout editor for creating PCBs. I mean: I paid a considerable amount of money for it thus supporting non-free software directly. And I did this two times. In the 1990's I spent money on a Win 3.1 license. I can't express in words how deeply I regret this. I once spent money to a turboprint license.


If I haven't managed to scare you off this page, yet, here is my software.

The library is designed for Linux/Unix environments, only. It uses symbolic links. These don't exist on some common operation systems - those are not supported. Please do not bother me with questions like "How can I port this to WinXXX?". I don't care! I don't give a sh*t on these OSes, you understand? I stopped programming on Windows in 1998... any further questions?? You may have a fair chance to compile that stuff on a cygwin system, however :-)

I assume the following tools to be installed on your system:

I'm writing programs for many different targets: Linux PC systems, ARM7 bare metal (LPC21xx, LPC23xx), Cortex-M3 bare metal (LPC17), Cortex-M0/M0+ (LPC11xx, LPC8xx) and others in future. To avoid redundancy I'm using a somewhat complicated system based on Subversion version control system. A program must be compiled within a compilation environment (CE). The CE contains the configuration for the target system and the library dependencies. Dependend libraries are pulled in with Subversion externals definitions automatically. As my programs tend to be small (at least what remains after all generic functionality is moved into libraries) I generally see the programs as part of the compilation environment. To say it the other way around: my compilation environments typically contain a collection of programs not only one program. Compiling a program consists of first building the libraries and then building the executable in the program's directory.

All C code is written in GNU C's dialect gnu99 (flag: -std=gnu99), there's NOW WAY you can compile this with a ANSI-C compiler or a C++ compiler. C++ is not compatible to this (named initialization, dynamic stack allocation). Libraries may impose restrictions, see library c-any. Libraries are static libs (*.a) because I build my executables mostly for bare-metal systems (systems without OS).

In order to produce slim executables I cut most source files into many fragments (slices), compile these slices and put them into a static library. The Perl-program does the cutting. Special comments in the source code control the cutting. You'll easily find out how it works ;-) .

c-any - cross-platform library

This is a collection of handy subroutines and data structures. Everything written in GNU C's dialect gnu99 (flag: -std=gnu99). This library requires, that a 32bit integer is accessed atomically by the executing processor. If that is not true, do not use any part of the library in interrupt routines or multithreading environments. You should not use the library in multithreading environments if more than 2 threads access the same Fifo structure. It's not designed to handle that.

This library is intended to be used as a subproject within compilation environments only. You cannot easily build it outside of a such.

c-linux - Linux compilation environment

This environment contains my Linux programs. It also includes a very small lib in lib/c-linux/ . Mainly for opening serial devices. This directory tree contains the configuration files to compile the libs and programs. It depends of the library c-any. For simplicity I put everything into one archive. This may change in future (by using subversion for downloading).

Download c-linux-r81.tar.bz2 (full environment) (2013-08-20).
Download c-linux-r89.tar.bz2 (full environment) (2014-02-05).

isp/mxli - a NXP ARM processor ISP programmer for Linux.

This has its own page now.

ramloader - a RAM loader for program execution in RAM on NXP ARM devices.

This has its own page now.

lpc8 - Compilation environment for NXP LPC800 controllers

This comilation environment is for *nix systems, only. The use of symbolic links helps reducing redundancy and duplication of mechanisms.

  1. Download lpc8.tar.bz2 Not versioned - file will change without notice.
  2. $ tar xfj lpc8.tar.bz2 ; chdir lpc8; make
  3. $ cd programs; mkdir yourProgram ; cd yourProgram ; ln -s ../Makefile ; vi main.c ; make ramloader
That's it! You don't need any project overhead or some wizzard generating redundancy. A project is nothing more than a new folder in the programs directory with a Makefile. The standard Makefile is fine, if you compile for RAM execution and your project consists of one *.c file only. If your project becomes more complex, copy (rather than symbolic link) the ../Makefile and edit the copy. Setting LDSCRIPT will be required for FLASH images. Look into lpc8/lib/ld for current choices. Feel free to add your own. For global compilation environment settings and environment variables used, look into lpc8/Project.make . If you have questions, ask in the LPCware Forum lpc800. I'm an active member there.
Last modified: 2017-04-25.